Use the parent's maven-source-plugin version.

[carryel]

It's probably 3.2.1, not 3.3.x.

Refer to the comment below:
https://github.com/eclipse-ee4j/glassfish-grizzly/blob/2f34e152864e2bdc76c46ed07f373f5923dc8a13/boms/bom/pom.xml#L188-L195

[pzygielo]

• Buy why? Do we have a problem after Switch maven-source-plugin to jar-no-fork #31?

[carryel]

Yes, I was hoping that fix would fix it, but I'm still getting the same error.
https://ci.eclipse.org/glassfish/view/Grizzly/job/1_grizzly_memcached-build-and-stage-test/4/console

<parent>
<groupId>org.eclipse.ee4j</groupId>
<artifactId>project</artifactId>
<version>1.0.9</version>
</parent>

It seems to be related to the parent project pom above, but I haven't found a definitive solution yet.

[pzygielo]

It's perhaps due to very bad maven goals:

+ mvn -U -C -DstagingDescription=org.glassfish.grizzly:grizzly-memcached:1.4.0 -DskipTests -Ddoclint=none clean package gpg:sign install:install org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:javadoc install -am -Poss-release --batch-mode -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn -Pstaging

install:install (as explicit plugin goal) and then install (maven lifecycle) again.

Calling :javadoc explicitly also seems wrong.

[pzygielo]

Also - using staging is probably not the good idea, as there is no easy way to release to Central Portal now.

[pzygielo]

Also install (phase) includes every previous phase already, with package being one of them.

[carryel]

I think I'll need to replace the old script.

Is there a job in the Glassfish project that I can refer to?

Maybe referencing https://ci.eclipse.org/glassfish/view/Release/job/1_concurro-build-and-stage/
would be a good idea?

[carryel]

Is it possible that we can't currently release Glassfish-related projects?
For example, I remember running a build-and-stage job and then releasing via staging-to-release.

Is a deploy-snapshot like https://ci.eclipse.org/glassfish/view/Release/job/concurro-deploy-snapshot/
the best solution at the moment?

I was wondering if there were any jobs I could reference at https://ci.eclipse.org/glassfish/view/Release/
because I was wondering if the build-and-stage and staging-to-release jobs from https://ci.eclipse.org/glassfish/view/Grizzly/ weren't working properly, so I wanted to test them.

[pzygielo]

Is it possible that we can't currently release Glassfish-related projects?

No, it isn't. All projects can be released to Central, but without staging to separate repository. For example - https://www.eclipse.org/lists/glassfish-dev/msg01699.html - announced that GF 7.1.0-M1 was published successfully.

For example, I remember running a build-and-stage job and then releasing via staging-to-release.

Since https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/5854 this process has changed.

Is a deploy-snapshot like https://ci.eclipse.org/glassfish/view/Release/job/concurro-deploy-snapshot/ the best solution at the moment?

From the name - it's for deployment of SNAPSHOTs only I guess. Not for full release.

[carryel]

Thank you so much for your kind explanation. I will read it carefully and refer to it.

[dmatej]

Also - using staging is probably not the good idea, as there is no easy way to release to Central Portal now.

If you would wait until the next week, I can upgrade Grizzly just like other, so the deployment to Central will be easier than ever was :-)

[pzygielo]

So this PR could be closed, right? There is no need to go backward.

And the actual message

Presumably you have configured maven-source-plugn to execute twice times in your build. You have to configure a classifier for at least on of them.

is pointing out to the fault in project configuration of plugin or to the inappropriate maven call.

[pzygielo]

To clarify

Also - using staging is probably not the good idea, as there is no easy way to release to Central Portal now.

there is no easy way to release from staging to Central Portal now

As the nomenclature

• was: stage - release the old way
• and is: deploy - publish new way.

[dmatej]

Yes, I would close it. However I have noticed something in the Eclipse Parent today too. It sets the plugin management - it is better to override it in own pluginManagement, not just in plugins. Overriding version number is simple, overriding+disabling executions means explicitly using their id and mapping them to phase "none" or "disabled" etc.
My problem in another project was with javadoc.

Then there is the oss-release profile, which does many things ... while ie. Soteria has its own profile, so it doesn't trigger this.
I am still learning all these scenarios ... in repackaged I simply removed all profiles, it is so nice when it can follow just common Maven Lifecycle ...

[dmatej]

was: stage - release the old way
and is: deploy - publish new way.

Yes, the pressure is to keep good old maven standards: continuous integration, repeatable builds, so testing with snapshot should have same results with the release made immediately after that, release safely possible in few hours. All that was an issue in the past:

• OSGI often created 1.2.3.SNAPSHOT version ids, which broke classloaders
• Two consecutive builds created two different artifacts
• ...

[carryel]

If you would wait until the next week, I can upgrade Grizzly just like other, so the deployment to Central will be easier than ever was :-)

It looks great. I'll be waiting for you to upgrade Grizzly. Please let me know when the work is done.

[carryel]

@dmatej Eclipse Parent v1.0.9 doesn't appear to use Central.
It appears that a new approach using Central was applied starting with v2.0.0-M1.
Are you planning to upgrade based on v2.0.0-M1?
Or will you be overriding the profile for each project, like Glassfish or other projects?