Guice upgrade to 7.0.0+

[frankbenoit]

At is listed in Guice 5.1.0, they fixed issues to support Java 17.
https://github.com/google/guice/wiki/Guice510

First step would be to bring it onto Eclipse Orbit.
If there is not yet such an activity already, I can do that receipt again.
@cdietrich a CQ is needed, i guess.

[cdietrich]

hi, i dont know about cq. in doubt you can ask on the emo mailing list
but i have doubts i can work on this at all.
cause i have to deal with all the orbit cvs fallout until end of M3

[HannesWell]

With the upcoming 2022-06 release Eclipse-platform fully supports to obtain dependencies directly from Maven-Central:
https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html

If the Guice jars contain a OSGi compliant MANIFEST.MF Orbit can be skipped.

[cdietrich]

@HannesWell no it cant, cause there is no solution for oomph and tycho 1.7
nor have i any idea what needs to be setup for signing

[HannesWell]

@HannesWell no it cant, cause there is no solution for oomph and tycho 1.7

What Eclipse-Platform is doing is to include the I-Build repo (which includes all dependencies) in their Oomph setup, which contains those dependencies.
Effectively a p2-repo is build by Maven/Tycho that includes the Maven-Central dependencies and the Oomph setup then fetches those dependencies from that repo.
Although this is a bit cumbersome (it requires a successful nightly build to make the Oomph setup work) it is at least an already working solution. To me it looks like this would be feasible with the nightly-build repo of xtext too.
But indeed it would be simpler if it were possible to reference a target-file in an Oomph targlet.

Aren't you planning to update to Tycho 2.7.2?

nor have i any idea what needs to be setup for signing

That's the good thing: Nothing. The PGP-signature should be understood by P2 just like jar-signatures.

Another point is that XText should make sure licences are vetted correctly. But also for this task GitHub workflows for Maven exist that can be copied:
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/.github/workflows/licensecheck.yml
But IIRC this also requires a recent Tycho version.

[cdietrich]

we dont want to use our old builds in oomph. oomph also has to work with older target platform, so we cannot use platform i-builds there.

and we use tycho 1.7 for older versions / java 8 and tycho 2.7 only for build against latest.
i have no idea what steps are necessary to get java 8 / onxygen running with tycho 2.7

what i dont understand:
why not move the maven p2 stuff to tycho.

[HannesWell]

we dont want to use our old builds in oomph. oomph also has to work with older target platform, so we cannot use platform i-builds there.

and we use tycho 1.7 for older versions / java 8 and tycho 2.7 only for build against latest. i have no idea what steps are necessary to get java 8 / onxygen running with tycho 2.7

Understand. With this requirement, especially using Tycho 1.x (which will likely wont get updates to support that), I don't see another solution than having a p2 repo from which you can get the new version. As far as I understand it the plan is to make Orbit obsolete where possible, so the Orbit maintainers maybe first will reject a request to include Guice with a reference to the improved situation to improve bundls. However I think it is not the goal to let projects create their own p2-mirrors. On the other hand Orbit would then only have to mirror the maven artifacts into a p2-repo.

Or do new releases of Xtext also target older versions of the Eclipse-Platform? If so you would still require a jar-signed version of Guice, wouldn't you?

what i dont understand: why not move the maven p2 stuff to tycho.

Which part to you mean exactly?
Tycho uses many parts of p2 and acts as bridge to build p2 provisioned Eclipse Applications and Repos with Maven and can resolve dependencies from Maven and p2-repos. Therefore the places where each code is located seem to be reasonable.

[cdietrich]

we support platform back to oxygen and java 8,11 and 17 (partially)
i mean instead of using bnd to package stuff to orbit to use the thing that platform uses at orbit.
then everybody can use orbit as used and has not to fight with the new tycho features
so instead of having 20 project with no people to do the same fight on their own
to do it once at orbit

and i have zeroclue about jar vs pgp signing and what is verified where and how

[HannesWell]

we support platform back to oxygen and java 8,11 and 17 (partially)

That's a long history. Then I suspect you need jarsigned dependencies. Unless it is acceptable that consumers get warnings about unsigned content when installing xtext (respectively Guice) into older platforms.

i mean instead of using bnd to package stuff to orbit to use the thing that platform uses at orbit.

I never contributes to orbit so don't know the exact details how Orbit works but AFAICT it basically re-creates the jars from (for example) Maven-Central using the original class files but adds a custom Manifest (if necessary) with partially Eclipse-custom metadata and performs own jar-signing. On the other hand when using Tycho to mirror Maven artifacts into a P2 repo (like you did in https://github.com/xtext/xtext-orbit-replacement) it just copies to jar into a new folder structure and creates a corresponding artifact/content.xml metadata, if that artifact has a OSGi compliant MANIFEST. If not Tycho (like M2E) uses BND-tools to generate one suitable MANIFEST. So in the end that process is likely not that different to what Orbit is/was doing already.

Maybe Orbit is already leveraging Tycho in this way, as I have not yet looked into the details of the Orbit process.

then everybody can use orbit as used and has not to fight with the new tycho features
so instead of having 20 project with no people to do the same fight on their own
to do it once at orbit

Yes that is not ideal.

and i have zeroclue about jar vs pgp signing and what is verified where and how

I'm not an expert either. Basically these are two different techniques to very the integrity and creator of a jar. The former is can be used with tools build into the JDK the latter one is mandatory to publish artifacts to Maven-Central (I suspect they choose that technique because you don't need a jarsigning certificate from a Certification-authority which usually costs some money).

Btw. if you want to proceed with https://github.com/xtext/xtext-orbit-replacement you maybe want to add the eclipse-jarsigner-plugin to ensure all jars in the repo are jarsigned. In M2E we do that as well:
https://github.com/eclipse-m2e/m2e-core/blob/342a148d91473a2bb7f4c186635936ccb277eb61/org.eclipse.m2e.repository/pom.xml#L42

However as you said this should not be done by each project individually. So I suggest to ask Orbit to include the new Guice.
@frankbenoit do you want to continue to create a receipt?

[cdietrich]

the current orbit manifest has [30.1,31)
but we might also update to guava 31 #2101
https://github.com/google/guice/issues/1642

@frankbenoit do you know if this can be fixed in bnd at orbit?

[cdietrich]

@merks do you still have the report where one can see what depends on what so that we can see who else not related to xtext uses guice?

[merks]

These are all users with requirements that are satisfied by only one available version:

Most would be satisfied also with a version < 6.0.

Note that if you install a SimRel IDE using the Oomph link here:

https://ci.eclipse.org/simrel/

You can open the simrel.aggran and view this information for the current state the SimRel contributions.