Deploy batch compiler milestones to maven central

[laeubi]

Now that batch-compiler is a separate jar/project it would be great to at least deploy MILESTONES of the single jar to maven central, e.g. we can't ship Java 21 support unless the december release with Tycho what is a bit annoying.

So is there really any compelling reason to not do it (beside of we never did it before)?

WDYT @merks @iloveeclipse @akurtakov

[merks]

I think shipping non-released non-SNAPSHOT versions of potentially still buggy ecj versions to Maven central is probably not a good idea. Certainly one would need to pay more attention to the version qualifier being published because the released versions are published without a qualifier:

https://repo1.maven.org/maven2/org/eclipse/jdt/ecj/

[laeubi]

because the released versions are published without a qualifier

It is quite usual to have M(ilestone) or R(elease)C(andiatate) version on maven central see for example:

https://stackoverflow.com/questions/3687208/what-does-m1-mean-in-a-maven-repository

[laeubi]

@iloveeclipse @akurtakov any progress here or anything we can do to push it forward? Given that important bugfixes and changes regarding Java 21 after the 2023-12 release but still these can't be used in a convenient way e.g. to be included in an upcoming Tycho 4.0.5 release.

[akurtakov]

I haven't done anything on the topic nor even looked into it TBH.

[iloveeclipse]

I have no problems to deploy M1, M2, M3 or RC versions to maven, but I have no clue what need to be done in general form release management point of view and especially to make sure it is clearly recognized as not stable version.

[laeubi]

I have no clue what need to be done in general form release management point of view

In general we already have a script that deploy something to central and we have the credentials we even have instructions how to build the compiler with a special version here:

eclipse.jdt.core/Jenkinsfile

Line 32 in 33ad538

mvn clean install -f org.eclipse.jdt.core.compiler.batch -DlocalEcjVersion=99.99 -Dmaven.repo.local=$WORKSPACE/.m2/repository -DcompilerBaselineMode=disable -DcompilerBaselineReplace=none

So practically mvn clean deploy -f org.eclipse.jdt.core.compiler.batch -DlocalEcjVersion=<current version>-M1 -DcompilerBaselineMode=disable -DcompilerBaselineReplace=none could be enough (I can try to help with any issues that arise here!)

especially to make sure it is clearly recognized as not stable version.

A usual pattern is to add -M<number> ( = milestone) or -RC<number> (= Release candiates) or even -alpha<number> to the version to indicate this and maven has special handling for that, so it more to decide what best reproduces the intended state.

[merks]

It is possible to "simply use" the SNAPSHOTS for those on the Java 21 bleeding edge?

https://repo.eclipse.org/content/repositories/eclipse-snapshots/org/eclipse/jdt/ecj/3.37.0-SNAPSHOT/

Those are updated daily so will always include the latest bug fix (and the latest regression). And they already exist so one has to do anything.

[laeubi]

It is possible to "simply use" the SNAPSHOTS for those on the Java 21 bleeding edge?

Maybe for a local build/project scope but not for a release

1. repo.eclipse is not a standard repository for maven
2. SNAPSHOT dependencies are not allowed for a release to maven central (for obvious reasons)

[merks]

I don't want to belabor the point, but here are my concerns:

• We don't so much in the way of testing the m1, m2, m3 milestones so publishing some semi-arbitrary version of ecj to maven central is okay but it's of a somewhat more questionable quality.
• Having a tycho release explicitly depending on a milestone version of a compiler seems highly questionable.

I would personally not feel so comfortable to discover that when upgrade to a new release of Tycho that I'm using a milestone quality version of ecj. That better be made really clear to the consumers because I would want to wait for a release that depends on releases...

[laeubi]

We don't so much in the way of testing the m1, m2, m3 milestones so publishing some semi-arbitrary version of ecj to maven central is okay but it's of a somewhat more questionable quality.

I would say having it on central alone does not improve the quality (where I don't have a reason to complain by the way), but broaden the audience that is able to easily test it. e.g. with Tycho it is already possible to try it out with a newer (or older ecj) but it is a bit inconvenient with a snapshot in general.

If there are undiscovered regressions its for me more a matter of missing text-coverage.

Having a tycho release explicitly depending on a milestone version of a compiler seems highly questionable.

It could also just be an instruction in the release notes (as we have of today) how to use such milestone ECJ for people needing higher java versions, also the Tycho snapshot builds can already include a milestone to have wider test-audience (but we need a stable release there as well).

[iloveeclipse]

I also see that having more testers can only improve quality by early feedback. Whoever uses unstable versions should be aware about possible "side effects".
Since we are buiding SDK with nightly ECJ snapshots we found already few regressions in compiler before they were discovered in milestones, so broadening audience will hopefully have even bigger effect, as platform itself is very conservative in using latest Java features, so we are only testing with our own (limited set of) regression tests here.

[merks]

I also see that having more testers can only improve quality by early feedback. Whoever uses unstable versions should be aware about possible "side effects".

Yes, making it more widely available for testing can only be a good thing. The versioning qualifier scheme generally should and does make people aware. The point I'm trying to make is that when I use a released version Tycho am I actually made aware that I am in fact providing early feedback/testing for an unreleased version of ecj? Probably not...

In any case, none of these things are my decisions to make and I've said enough already. 😜

[HannesWell]

Broadening the audience of testers is definitely good, but I also agree that users should be aware that they are using a pre-release version. So the suggestion to let people configure that ecj pre-release version explcitly sounds like a good compromize. IIRC that's basically a special configuration of the tycho-compiler-plugin, isn't it? If it's not trivial it is probably a good idea to have documentation about that (if it not already exists).

And as long as the ecj-bundle still uses the usual date-based qualifier in their Bundle-Version updates should still be possible.

[laeubi]

I added a new section to the FAQ: https://github.com/eclipse-tycho/tycho/wiki/Frequently-asked-questions#how-do-i-use-a-different-compiler-version