[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [epp-dev] EPP 2022-09 M1
|
Jonah,
I fix the problem in the aggregator (a *.pack.gz is no longer
processable by the latest p2 but the aggregator was treating it as
the canonical artifact instead of the *.jar as it should), built
a new version of staging using the fixed aggregator, and promoted
staging to:
https://download.eclipse.org/releases/2022-09/202207151001
Note the 202207151001 versus
202207151000.
I also changed the script that composes the release composite
such that it only contains the (one) most recent child, so the
broken 202207151000 will not be in the composite when
it's made visible later today as scheduled.
While testing the installer, I made the mistake of creating an
installation that uses Java 11 and of course the tm4e bundles
don't start in that case. So I changed all the product
definitions to require Java 17:
https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/194724
The train also contains some really old content so that these
certificate prompts come up for such very old certificates:
When installing everything, I see wiring problems that appear to
be caused by multiple versions of com.google.inject (two versions
on the train) and com.google.gson (three versions on the train).
In particular these failures:
I'll need to investigate these further.
But if you see your project above, it's better to use the latest
version to avoid this possible installation configuration with
multiple versions:
We're doing poorly on duplicates with this now:
And this in 2022-06:
And as we see above, this can and does lead to wiring problems in
some cases...
Regards,
Ed
On 15.07.2022 02:52, Jonah Graham
wrote:
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/epp-dev