I want to highlight this again.
**Please do not re-release Maven artifacts with different content.**
On 12/18/18 8:37 PM, Bill Shannon
wrote:
Ideally, a final artifact would be staged at about the same time
as the Eclipse Release Review is submitted. When the Release
Review is complete ~2 weeks later, the final artifact should be
pushed to Maven Central.
All integration testing before that point should use -bXX version
numbers. Once the integration is proven, the version number can
be updated to the final version and the Release Review submitted.
As Romain says, it should be relatively rare that we need to
re-stage an artifact.
Romain Grecourt wrote on 12/18/18
5:07 PM:
On 12/18/18 4:32 PM, Tomas Kraus wrote:
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.
I wasn't pointing fingers, just exposing this problem to a wide
audience.
Please do not take it personally.
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 understand that you want to move forward but the OSSRH staging
retention is a problem that needs to be fixed.
Let it take days and escalate the issue.
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 how Eclipse wants you to do this right ?
IMO this is not a good reason to justify the re-release of Maven
artifacts.
Instead we should expose the impracticality and escalate the
issue.
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.
I disagree.
I would rather allow external snapshots than mis-use Maven to
that extent.
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.
Pom changes can have a significant impact, the dependency tree
is the input for a lot of maven tooling (e.g.
maven-bundle-plugin).
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.
This can be done with 2 things:
- zip up the local staging directory used by the
nexus-maven-plugin and archive it as an artifact in the original
Jenkins job.
- create a job that can fetch that zip and use
nexus-maven-plugin:deploy-staged to re-stage the missing
artifacts.
See https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin#deploy-staged
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.
IMO you are pointing at another process issue.
The projects encapsulation is very strong. Every project gets
their own Jenkins master with their own set of credentials.
This makes sense for some project (glassfish, jersey, metro,
etc), but does not for other much smaller projects (e.g. most
API projects).
There is a lack of common tooling for projects, so far
the release job scripts have been duplicated and flavored many
times.
This leads to inconsistency and bad practices to spread all
over.
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
_______________________________________________
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
_______________________________________________
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
|
