org.apache.jasper.glassfish and com.sun.el versions have gone backwards

[jonahgraham]

IMHO this is a bad idea - this maven artifact is actually from Orbit, and indeed from a much older version of Orbit which means that it has old (and now out of date) signatures. For this bundle (and the com.sun.el one too) the version number has gone backwards too.

eclipse.platform.releng.aggregator/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target

Lines 254 to 255 in 9f0ce1b

	<artifactId>org.apache.jasper.glassfish</artifactId>
	<version>2.2.2.v201112011158</version>

The initial change to this was done in PR #367 - prior to that this was the version info:

eclipse.platform.releng.aggregator/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target

Lines 140 to 141 in 0d26ffe

	<unit id="org.apache.jasper.glassfish" version="2.2.2.v201501141630"/>
	<unit id="org.apache.jasper.glassfish.source" version="2.2.2.v201501141630"/>

[merks]

It's a bad idea that all users will notice when they install or update to these things because this dialog will come up:

Note the trust-inspiring expired indication suggesting that some thing is really quite wrong and questionable.

[merks]

@jonahgraham I'm not sure that both have gone backwards.

I see this in the history when previously pulled from Orbit:

      <unit id="com.sun.el" version="2.2.0.v201303151357"/>
      <unit id="com.sun.el.source" version="2.2.0.v201303151357"/>

      <unit id="org.apache.jasper.glassfish" version="2.2.2.v201501141630"/>
      <unit id="org.apache.jasper.glassfish.source" version="2.2.2.v201501141630"/>

and this now when pulled from Maven:

			  <dependency>
				  <groupId>org.eclipse.jetty.orbit</groupId>
				  <artifactId>com.sun.el</artifactId>
				  <version>2.2.0.v201303151357</version>
				  <type>jar</type>
			  </dependency>
			  <dependency>
				  <groupId>org.eclipse.jetty.orbit</groupId>
				  <artifactId>org.apache.jasper.glassfish</artifactId>
				  <version>2.2.2.v201112011158</version>
				  <type>jar</type>
			  </dependency>

So glassfish is clearly an older version now, but these look the same:

• https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2022-06/202206151000/index/com.sun.el_2.2.0.v201303151357.html
• https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2022-06/202206151000/index/com.sun.el_2.2.0.v201303151357.html

Though it also has very old certificate signature and also results in a prompt.

I don't think a newer version of com.sun.el exists:

[jonahgraham]

I think you are correct that el hasn't gone backwards by version number, but it has gone backwards by contents. This is because Orbit resigned lots of bundles without changing their qualifier in the past. Which means that they have identical contents, but the jar is different due to different signatures. AFAICT the signature of the el bundle in the last release was OK because it came from a resigned Orbit repo. See Bug 553288 Comment 2

[merks]

@jonahgraham

So if we reverted these changes (whose only purpose is to eliminate mapping rules from the *.aggr) the problem I'm seeing would likely go away, right?

@akurtakov

I'll do the work for this, if we can avoid this degrading into a very long discussion. Okay?

[jonahgraham]

@jonahgraham

So if we reverted these changes (whose only purpose is to eliminate mapping rules from the *.aggr) the problem I'm seeing would likely go away, right?

I think so - i.e. if these bundles are pulled from the this repo

eclipse.platform.releng.aggregator/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target

Lines 86 to 90 in 1ba1ece

	<!-- This is the last build of the CVS sourced Orbit repository - this was a subrepo of the recommended Orbit
	for 2022-03. Due to Bug 568936 this is not included in 2022-06 recommended Orbit repos and beyond.
	The intention is to migrate the above (where possible) to newer sources, such as pulling from
	maven central. -->
	<repository location="https://download.eclipse.org/tools/orbit/downloads/drops/R20201118194144/repository/"/>

we should be good to go.

(Sorry, I didn't understand the mapping rules part of your comment.)

[merks]

This is used for publishing to Maven:

https://github.com/eclipse-platform/eclipse.platform.releng/blob/master/publish-to-maven-central/SDK4Mvn.aggr

If you look at the history, you'll see it evolving:

https://github.com/eclipse-platform/eclipse.platform.releng/commits/master/publish-to-maven-central/SDK4Mvn.aggr

You'll also find that this PR is stalled:

eclipse-platform/eclipse.platform.releng#71

I've been trying to keep this file correct, but I guess it does not need to be correct until the release...

[jonahgraham]

Thanks for the extra info - I had mistakenly assumed the simrel .aggr file.

[akurtakov]

@akurtakov

I'll do the work for this, if we can avoid this degrading into a very long discussion. Okay?

Go on with this one . I dislike long discussions and it's more than clear that the move to maven and shipping uptodate deps will not happen over night and there will be steps back needed.

[merks]

@jonahgraham

Even with the changes from the PR, I still get this prompt:

Looking at that bundle in the previous release

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.24/R-4.24-202206070700/index/com.sun.el_2.2.0.v201303151357.html

And the current one:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.25-I-builds/https___download.eclipse.org_eclipse_updates_4.25-I-builds_I20220815-1800/com.sun.el_2.2.0.v201303151357.html

They both have this same very old root certificate:

This problem will not go away without a new version signed with a newer certificate, except if there is also a PGP signature as supported by this recent change:

eclipse-equinox/p2#121

That would at least help with the installer...

BTW, the report shows quite a few versions going backwards:

https://download.eclipse.org/eclipse/downloads/drops4/I20220815-1800/buildlogs/reporeports/reports/versionChecks.html

[akurtakov]

Let's not touch these as they don't cause issues AFAICT.

[merks]

Yes, I'm not suggesting must revisit these yet again. But in hindsight, we'd probably have been better to switch to a Maven version when a newer Maven version became available rather than all these backwards moving versions...

[akurtakov]

Ideally, our build scripts should be enhanced so such builds are not published to the composite repo much like what happens when there are comparator errors. But this is yet another fight too low in the list. If this starts with next stream we will be sure things always move in the right direction.

[akurtakov]

I consider this one in decent enough state to close it.