Release Maven artifacts and p2 site in the same Maven run

[LorenzoBettini]

Now that the problem with timestamps in OSGI MANIFEST/feature and no timestamps in POMs might be resolved (eclipse/xtext#2135 (comment)), we could be able to deploy to Sonatype and publish the p2 site in the same Maven run: the JARS on Sonatype and the p2 site would be the same. @szarnekow what I said in eclipse/xtext#2135 (comment) doesn't seem to be valid anymore ;)

I don't know if I can work on this right now, because it requires a few adjustments:

• we have a lot of projects, and only a few of them are to be published as Maven artifacts. Currently, this is handled by two separate Maven aggregators. If we want to implement this task, there should be a single Maven aggregator. Most POMs should be modified so that Maven deployment is skipped; to keep things clean, I'd propose the introduction of a sub-parent POM (xtext-no-maven-deploy-parent?) where the deployment is skipped. This should be inherited from most projects, that is, the ones not to be deployed on Sonatype.
• the composite update site should be created during the Maven build

The second point is not strictly essential: it's just to make sure that, if the p2 publishing fails, the Maven artifacts are not deployed. This avoids situations where Maven artifacts are published but the p2 publishing has failed. Of course, this can be resolved by having a dedicated backup job only for p2 publishing.

[szarnekow]

the JARS on Sonatype and the p2 site would be the same

That'd be fantastic!

Would things become more straightforward if we deployed all non-test artifacts to maven-central?

[cdietrich]

Would things become more straightforward if we deployed all non-test artifacts to maven-central?

@szarnekow i assume this will never work cause eclipse ui stuff is not in maven central

[szarnekow]

i assume this will never work cause eclipse ui stuff is not in maven central

D'oh I tend to ignore the sad state of the universe.

[LorenzoBettini]

@cdietrich @szarnekow yes, deploying non-test stuff to Sonatype would simplify things a bit :)

And UI stuff IS on Maven Central https://central.sonatype.com/artifact/org.eclipse.jdt/org.eclipse.jdt.ui/3.28.0

and looking at its POM on that page, looks like they removed version ranges in the current release! It looks like a dream :)

[cdietrich]

And UI stuff IS on Maven Central

is all of our eclipse deps there? (buildship, m2e .... whatever)

[LorenzoBettini]

And UI stuff IS on Maven Central

is all of our eclipse deps there? (buildship, m2e .... whatever)

I don't think so.
However, our UI artifacts would not be as useful as Maven artifacts because they entirely lack the Maven dependency section. Adding dependencies there would require much more work than the intermediate parent POM I mentioned. When I have time, I'd go with the intermediate parent POM. That solution would require just some copy-and-paste in the POM.

OK?

Of course, no one would prevent us from publishing them anyway to Sonatype but, as I said, they wouldn't be useful.

[cdietrich]

i assume c&p the parent or a skip property would be the same amount of work, wont it. @szarnekow which variant would you prefer

[LorenzoBettini]

@cdietrich Since we're using nexus-staging plugin a property won't be enough (see cc5c9a8 to skip the deployment of a few artifacts). The alternative would be not to use the nexus-staging plugin and then manually release staging artifacts from the sonatype website. Currently, do you have to release staging artifacts manually?

[cdietrich]

Currently, do you have to release staging artifacts manually?

yes the process is to close and release with the nexus webinterface (see https://github.com/eclipse/xtext/blob/master/Builds.md#preparing-milestones-and-releases)

[LorenzoBettini]

@cdietrich then we could also decide to do without the nexus staging plugin

[cdietrich]

the question is how the batching works. in the past when thr jenkins was very very slow. the there were not 2 staging repos (one for xtend, one for xtext) but more. how does the staging plugin "batch" the stuff

[LorenzoBettini]

@cdietrich the nexus staging plugin by default does the effective release at the end of the Maven build, so if something goes wrong during the build nothing gets published. Now the Maven build is a single one so everything is easier and safer, if that's what you meant.

Going back to the possibility of doing without the nexus staging plugin, which slightly simplifies the skip of deployment of single projects (without nexus staging, deployment is skipped with a single property): the manual releasing of a staging repository has a few advantages:

• you can have a second thought: you can decide not to release the staged repository
• the staging repository is an effective repository: it can be consumed by properly setting its URI in the POMs repository section.

That's why I was proposing that if we want we can also avoid the nexus staging plugin.

[cdietrich]

@LorenzoBettini the only criteria we in the past descrided not to release was

• the p2 deployment failed
• the close and release in nexus failed
  -i assume the 2nd will be addressed by the staging plugin anyway.

no doing the deploy at the end we might have problems with the infrastructure cause the deploys might be 10 or 20 mins apart wont we? dont know how the default batching in nexus handles this. just remember the problems of the past

[LorenzoBettini]

@cdietrich it's better to keep the default deploy at the end so that it either succeeds completely or fails.

Since the move to the new https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/ (note the "s01"), which we use already, things have improved a lot, and I never saw that fail.

Here's my proposal:

• temporarily remove nexus staging plugin so that we can simulate the release of a milestone on Sonatype; it will be staged and we can remove it if and when we want (we could still use it for integration testing)
• use an intermediate parent pom (I propose xtext-nodeploy-parent) for all the projects not to be deployed on Sonatype: it will allow us to keep in a single place common configurations for things we don't want to deploy as Maven artifacts (e.g., skip the install phase, which would be useless)
• if we decide to go back to nexus staging plugin, we'll have to tweak the skip deployment still in a single place.

[cdietrich]

@LorenzoBettini am ok with that

[LorenzoBettini]

I've applied my proposal #14 (comment)
Once this PR is merged #17 this seems to work.

[LorenzoBettini]

@cdietrich @szarnekow I now have JIRO job https://ci.eclipse.org/xtext/view/Xtext-release/job/xtext-monorepo-full-deploy-nightly/ that deploys Maven snapshots, and the p2 nightly update site (not the official one, this temporary one https://download.eclipse.org/modeling/tmf/xtext/monorepo/updates/nightly/) in the same Maven build (it also uploads/replaces the p2 site in the download area directly during the build via SSH)

[LorenzoBettini]

Closed by #18