Re: [ee4j-build] Maven re-releases

[Tomas Kraus <tomas.kraus@xxxxxxxxxx>]

Hi Romain,

your proposal is nice is nice, but it must be implemented first. Currently you just come to your office in the morning trying to move on with your tasks and you get stuck after 1st attempt to build something. The only way for quick fix is to restart release job. Our whole team was in this situation on Monday morning so we decided to fis this using this dirty way. Otherwise we could just go home.

There won't be much projects which have at least job to rebuild existing tag. I know about a single one from some 50 projects I 'm watching from time to time. And it's there because I made it today after discussion with Tom. :)

So the other option was to stop working on EE4J projects and wait for someone to implement jobs to rebuild existing tag. It would take days.

I would also like to do things properly. ...but we have no promoted builds, no automatic integration jobs, no promoted repo on OSSRH.. .we just have to manually update version, build it and file set of PRs witch every single version update. Just imagine this sample (already discussed JTA API): They change version. We have JPA API dependency, EclipseLink dependency, Metro dependencies (not just one) amd all those things go into GF. So to avoid JTA transitive dependencies mess in GF, you would like all those projects to share a single one -> imagine how long it will take to manually update all of them and do manual reviews and merge, re-release all those projects again under a new version and finally put everything into GF. No, you don't want to to this.

That's why I think that even existing release rebuild in staging is still fine when it's done from EE4J_8 branch which shall contain no significant code changes (new features, etc.) against last java.net release. I see it as dirty thing, but still an acceptable tradeoff.

The only acceptable changes in EE4J_8 are bug fixes and modifications to adopt Eclipse environment and requirements => those are just pom changes in most cases.

But yes, we shall stop doing it at some point to make integrartion testing more stable.

It would great if you find a way how to restage deleted artifacts to OSSRH. We can stop doing those bad things after that. But until this is done, we still need some way to fix this problem quickly - currently rebuilding it from EE4J_8 head.

I can put my script to rebuild artifact from git tag to wiky, but it will take 2 weeks for all projects to implement it and it will generate additional workload.

Tomas

Dne 18.12.18 v 23:59 Romain Grecourt napsal(a):

Folks,

Re-releasing Maven artifacts (or overwrite) has been a common practice within EE4J projects.
I believe this is mainly due to the release scripts and Jenkins jobs that make it too easy to re-run the release for a particular version.

This is a bad Maven practice and should be avoided as much as possible. We should only do this for very specific use cases where a version gap is not acceptable.
E.g. an API with a final version has a bug, we can re-release it while it is still in OSSRH staging.

Releasing a project with a final version where a gap is not acceptable should be done with extra caution. This means the integration has been tested before hand very carefully.
If there is a development cycle, intermediate versions (e.g. 1.0-bXX or whatever qualifier fits) can be used, in such case a version gap is acceptable and maven releases may be done carelessly.

Re-releasing something already integrated in other projects can creates issues that are not associated with a git commit. (i.e the build could start failing without a change).
This is like having the drawbacks of external snapshots without the benefits.
Note that it also forces purging various Maven caches and mirrors which can be quite tricky.

There is also the issue of the retention period of OSSRH staging. Staging repositories will be automatically deleted after 1 month. This used to be 2 weeks but we got Sonatype to extend it to 1 month.
This is unfortunately very impractical. IMO this calls for Eclipse to engage with Sonatype in order to have our own dedicated nexus gateway, similar to maven.java.net.

The retention period is also why some projects have been re-released. AFAIK the current workaround is to re-run the release job with the same version.
If the release is triggered off of a development branch (e.g. EE4J_8) then the re-released artifacts may have different content.

Even if triggered from the release tag the artifacts will have a different fingerprints. While it's not as big of an issue, this may have bad side effects with things that are re-bundled (e.g. GlassFish zip distributions).
Instead of rebuilding the Maven artifacts that are missing, we should provide a way to re-release existing artifacts. E.g. archive the artifacts on Jenkins and have a way to re-stage them to OSSRH.

Thanks,
Romain



_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-build