Guice upgrade to 7.0.0+ #2056

frankbenoit · 2022-04-09T15:02:41Z

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 · 2022-04-09T16:18:06Z

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 · 2022-04-25T11:53:20Z

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 · 2022-04-26T04:47:03Z

@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 · 2022-04-27T10:18:17Z

@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 · 2022-04-27T10:44:39Z

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 · 2022-04-27T12:15:01Z

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 · 2022-04-27T12:17:07Z

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 · 2022-04-27T13:02:08Z

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 · 2022-09-21T05:39:32Z

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 · 2022-09-21T06:21:49Z

@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 · 2022-09-21T06:56:57Z

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.

cdietrich · 2023-04-18T17:57:29Z

the oom issue got merged in guice
google/guice#1510
lets see when this is published

HannesWell · 2023-04-27T07:32:11Z

A new guice release is planned soon (probably guice 6.0), which will also support jakarta.inject (almost completely):
google/guice#1383 (comment)

It will also require guava 31.

cdietrich · 2023-05-02T10:57:52Z

the error_prone dependency does not seem to have proper manifest.
in orbit we exclude it so far i know

@HannesWell is there an option to exclude certain transitives with the maven deps in target feature?

cdietrich · 2023-05-02T11:14:12Z

google/error-prone#2967

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich · 2023-05-02T12:15:35Z

somehow does not work in 202203

14:11:27  [INFO] {osgi.os=macosx, osgi.ws=cocoa, org.eclipse.update.install.features=true, osgi.arch=x86_64}
14:11:27  [ERROR] Cannot resolve project dependencies:
14:11:27  [ERROR]   Software being installed: org.eclipse.xtext.xbase.lib 2.31.0.qualifier
14:11:27  [ERROR]   Missing requirement: com.google.guava 31.1.0.jre requires 'java.package; com.google.common.util.concurrent.internal [1.0.0,2.0.0)' but it could not be found
14:11:27  [ERROR]   Cannot satisfy dependency: org.eclipse.xtext.xbase.lib 2.31.0.qualifier depends on: osgi.bundle; com.google.guava [31.1.0,32.0.0)
14:11:27  [ERROR]

cdietrich · 2023-05-02T12:24:36Z

junit5 tests also make problems https://ci.eclipse.org/xtext/job/xtext/job/cd_guice6x/3/testReport/junit/org.eclipse.xtext.testing.tests.junit5/InjectionExtensionNested2Test$NestedClass/innerTest/

this looks like some non matching guava and guice versions are mixed together when running the test from maven
maybe cause by lsp4j transitive p2 dependency in version <= 0.21.0

[INFO] --- tycho-p2-plugin:3.0.4:dependency-tree (default-cli) @ org.eclipse.xtext.testing.junit5.tests ---
[INFO] org.eclipse.xtext:org.eclipse.xtext.testing.junit5.tests:eclipse-plugin:2.31.0-SNAPSHOT
[INFO] +- org.eclipse.xtext.testing.junit5.tests (2.31.0.qualifier) --> [org.eclipse.xtext:org.eclipse.xtext.testing.junit5.tests:eclipse-plugin:2.31.0-SNAPSHOT]
[INFO]    +- com.google.guava (31.1.0.jre) satisfies osgi.bundle; com.google.guava 31.1.0
[INFO]       +- com.google.guava.failureaccess (1.0.1) satisfies java.package; com.google.common.util.concurrent.internal [1.0.0,2.0.0)
[INFO]    +- com.google.inject (6.0.0.rc1) satisfies osgi.bundle; com.google.inject 6.0.0
[INFO]       +- org.aopalliance (1.0.0.v20220404-1927) satisfies java.package; org.aopalliance.intercept 0.0.0
[INFO]       +- wrapped.com.google.errorprone.error_prone_annotations (2.18.0) satisfies java.package; com.google.errorprone.annotations 0.0.0
[INFO]    +- jakarta.inject.jakarta.inject-api (2.0.1) satisfies java.package; jakarta.inject 2.0.1
[INFO]    +- javax.inject (1.0.0.v20220405-0441) satisfies java.package; javax.inject 1.0.0
[INFO]    +- junit-jupiter-api (5.9.3) satisfies java.package; org.junit.jupiter.api [5.1.0,6.0.0)
[INFO]       +- junit-jupiter-engine (5.9.3) satisfies org.junit.platform.engine; (&(org.junit.platform.engine=junit-jupiter)(version>=5.9.3)(!(version>=6)))
[INFO]          +- junit-platform-launcher (1.9.3) satisfies org.junit.platform.launcher; (&(org.junit.platform.launcher=junit-platform-launcher)(version>=1.9.3)(!(version>=2)))
[INFO]       +- org.opentest4j (1.2.0.v20211018-1956) satisfies java.package; org.opentest4j [1.2.0,2.0.0)
[INFO]    +- junit-jupiter-params (5.9.3) satisfies java.package; org.junit.jupiter.params [5.1.0,6.0.0)
[INFO]    +- junit-platform-commons (1.9.3) satisfies java.package; org.junit.platform.commons.support [1.0.0,2.0.0)
[INFO]    +- junit-platform-engine (1.9.3) satisfies java.package; org.junit.platform.engine [1.0.0,2.0.0)
[INFO]    +- junit-platform-runner (1.9.3) satisfies java.package; org.junit.platform.runner [1.0.0,2.0.0)
[INFO]       +- junit-platform-suite-commons (1.9.3) satisfies java.package; org.junit.platform.suite.commons [1.9.0,2.0.0)
[INFO]       +- org.junit (4.13.2.v20211018-1956) satisfies java.package; org.junit.runner [4.12.0,5.0.0)
[INFO]          +- org.hamcrest.core (1.3.0.v20180420-1519) satisfies osgi.bundle; org.hamcrest.core 1.3.0
[INFO]    +- junit-platform-suite-api (1.9.3) satisfies java.package; org.junit.platform.suite.api [1.0.0,2.0.0)
[INFO]    +- org.apache.log4j (1.2.24.v20221221-2012) satisfies java.package; org.apache.log4j 1.2.24
[INFO]    +- org.eclipse.lsp4j (0.20.1.v20230228-1531) satisfies osgi.bundle; org.eclipse.lsp4j 0.0.0
[INFO]       +- com.google.gson (2.10.1.v20230109-0753) satisfies java.package; com.google.gson [2.9.1,2.11.0)
[INFO]       +- com.google.guava (30.1.0.v20221112-0806) satisfies java.package; com.google.common.base [30.1.0,31.0.0)
[INFO]       +- org.eclipse.xtext.xbase.lib (2.31.0.v20230502-1144) satisfies java.package; org.eclipse.xtext.xbase.lib [2.28.0,3.0.0)
[INFO]    +- org.eclipse.lsp4j.jsonrpc (0.20.1.v20230228-1531) satisfies osgi.bundle; org.eclipse.lsp4j.jsonrpc 0.0.0
[INFO]    +- org.eclipse.xtend.lib (2.31.0.v20230502-1144) satisfies osgi.bundle; org.eclipse.xtend.lib 0.0.0
[INFO]       +- org.eclipse.xtend.lib.macro (2.31.0.v20230502-1144) satisfies osgi.bundle; org.eclipse.xtend.lib.macro 0.0.0
[INFO]    +- org.eclipse.xtext (2.31.0.v20230502-1144) satisfies osgi.bundle; org.eclipse.xtext 0.0.0
[INFO]       +- org.antlr.runtime (3.2.0.v20220404-1927) satisfies osgi.bundle; org.antlr.runtime [3.2.0,3.2.1)
[INFO]       +- org.eclipse.core.runtime (3.27.0.v20230317-0901) satisfies osgi.bundle; org.eclipse.core.runtime 3.24.100
[INFO]          +- org.eclipse.core.contenttype (3.9.0.v20230412-0829) satisfies osgi.bundle; org.eclipse.core.contenttype [3.8.0,4.0.0)
[INFO]          +- org.eclipse.core.jobs (3.14.0.v20230317-0901) satisfies osgi.bundle; org.eclipse.core.jobs [3.13.0,4.0.0)
[INFO]          +- org.eclipse.equinox.app (1.6.200.v20220720-2012) satisfies osgi.bundle; org.eclipse.equinox.app 1.6.0
[INFO]          +- org.eclipse.equinox.preferences (3.10.200.v20230120-0604) satisfies osgi.bundle; org.eclipse.equinox.preferences [3.10.0,4.0.0)
[INFO]             +- org.osgi.service.prefs (1.1.2.202109301733) satisfies osgi.bundle; org.osgi.service.prefs [1.1.0,1.2.0)
[INFO]          +- org.eclipse.equinox.registry (3.11.200.v20220817-1601) satisfies osgi.bundle; org.eclipse.equinox.registry [3.11.0,4.0.0)
[INFO]       +- org.eclipse.emf.common (2.28.0.v20230315-1321) satisfies osgi.bundle; org.eclipse.emf.common 2.24.0
[INFO]       +- org.eclipse.emf.ecore (2.34.0.v20230406-1203) satisfies osgi.bundle; org.eclipse.emf.ecore 2.26.0
[INFO]       +- org.eclipse.emf.ecore.xmi (2.18.0.v20230211-1150) satisfies osgi.bundle; org.eclipse.emf.ecore.xmi 2.16.0
[INFO]       +- org.eclipse.equinox.common (3.17.100.v20230202-1341) satisfies osgi.bundle; org.eclipse.equinox.common 3.16.0
[INFO]       +- org.eclipse.osgi (3.18.400.v20230323-1847) satisfies java.package; org.osgi.framework 0.0.0
[INFO]       +- org.eclipse.xtext.util (2.31.0.v20230502-1144) satisfies osgi.bundle; org.eclipse.xtext.util 0.0.0
[INFO]    +- org.eclipse.xtext.ide (2.31.0.v20230502-1144) satisfies osgi.bundle; org.eclipse.xtext.ide 0.0.0
[INFO]       +- org.eclipse.emf.ecore.change (2.15.0.v20230211-1150) satisfies osgi.bundle; org.eclipse.emf.ecore.change [2.14.0,3.0.0)
[INFO]    +- org.eclipse.xtext.testing (2.31.0.v20230502-1144) satisfies osgi.bundle; org.eclipse.xtext.testing 0.0.0
[INFO] +- org.eclipse.xtext.testing.junit5.tests.source (2.31.0.qualifier) --> [org.eclipse.xtext:org.eclipse.xtext.testing.junit5.tests:eclipse-plugin:2.31.0-SNAPSHOT]

will try to rebase on the lsp4j 0.21.0 branch

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

merks · 2023-05-02T12:33:24Z

I spent a lot of time trying to get this to work. You may wish to read the saga here:

merks/simrel-maven#4

cdietrich · 2023-05-02T13:48:10Z

@LorenzoBettini do you know if there is a way to exclude specific p2 deps from the maven surefire run?

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich · 2023-05-02T14:18:13Z

also mwe has strict dependency to older guava

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich · 2023-06-16T09:58:40Z

did some experiments with guice 7 + guava 32 at https://github.com/eclipse/xtext/tree/cd_testg32guice7

now i try to get it to simrel maven https://github.com/eclipse-oomph/oomph.incubator/pull/1/files

HannesWell · 2023-06-16T17:29:26Z

now i try to get it to simrel maven https://github.com/eclipse-oomph/oomph.incubator/pull/1/files

Just want to mention that with #2207 you would not have to deal with simrel maven and could just add any new version of guice to xtext's TP.

cdietrich · 2023-06-16T17:30:24Z

i know

cdietrich · 2023-06-20T08:10:12Z

@frankbenoit in case you also need assisted inject. can you get in contact with @merks to get it into simrel maven p2 repo

merks · 2023-06-20T08:18:00Z

@cdietrich

What do you guys think needs to be there that isn't currently already there?

cdietrich · 2023-06-20T08:20:46Z

in the old orbit there was also

    <dependency>
      <groupId>com.google.inject.extensions</groupId>
      <artifactId>guice-assistedinject</artifactId>
      <version>5.0.1</version>
    </dependency>

which was not used by Xtext diretly but by Xtext consumers (@frankbenoit )

merks · 2023-06-20T12:33:56Z

There's a 5.1.0 version but it fails during my build because it needs a very restricted version of com.google.common.base

[ERROR] Missing requirement: com.google.inject.assistedinject 5.1.0 requires 'java.package; com.google.common.base [30.1.0,31.0.0)' but it could not be found
[ERROR] Cannot satisfy dependency: org.eclipse.oomph.maven.all.feature.group 4.29.0 depends on: org.eclipse.equinox.p2.iu; com.google.inject.assistedinject [5.1.0,5.1.0]

There are also 6.x and 7.x versions, but they fail the build like this:

[ERROR] Missing requirement: com.google.inject.assistedinject 7.0.0 requires 'java.package; com.google.errorprone.annotations 0.0.0' but it could not be found
[ERROR] Cannot satisfy dependency: org.eclipse.oomph.maven.all.feature.group 4.29.0 depends on: org.eclipse.equinox.p2.iu; com.google.inject.assistedinject [7.0.0,7.0.0]

With both of these, resolution works:

    <dependency>
      <groupId>com.google.inject.extensions</groupId>
      <artifactId>guice-assistedinject</artifactId>
      <version>7.0.0</version>
    </dependency>

    <dependency>
      <groupId>com.google.errorprone</groupId>
      <artifactId>error_prone_annotations</artifactId>
      <version>2.20.0</version>
    </dependency>

So I guess that's what folks want?

cdietrich · 2023-06-20T12:51:41Z

what did you do for normal guava/guice not to need errorprone

merks · 2023-06-20T12:56:16Z

I did nothing. All the dependencies come directly from Maven with the OSGi metadata as specified in the maven-hosted jar:

https://github.com/eclipse-oomph/oomph.incubator/blob/master/maven/tp/Maven.target

I think other places removed the package imports themselves or maybe with some gentle help from @HannesWell

You can follow the links from the report:

https://github.com/eclipse-oomph/oomph.incubator/blob/master/maven/org.eclipse.oomph.maven.generator/report/merged-target/REPORT.md

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

HannesWell · 2023-06-20T17:12:24Z

I think other places removed the package imports themselves or maybe with some gentle help from @HannesWell

Yes, I made the error-prone dependency optional in guice via google/guice#1739, which is included in guice 6 and 7.

For the extensions that still require the annotations, I also contributed proper metadata to error-prone itself via google/error-prone#3903, which is included in the recent error-prone 2.20.0 release. I assume one can use that as a drop-in replacement for 2.19, which guice requires.

which was not used by Xtext diretly but by Xtext consumers (@frankbenoit )

Can't down-stream consumers add the extension to their target-platform by themself via Maven-Targets?
Then Xtext/(Maven-)SimRel/Orbit would not have to take care about that. :)

laeubi · 2023-06-21T09:45:19Z

Yes, I made the error-prone dependency optional in guice via google/guice#1739, which is included in guice 6 and 7.

Making it optional might have not the desired effect one do think, it should instead be scope provided or something like that....

cdietrich · 2023-06-21T09:46:58Z

it should instead be scope provided or something like that

is there such a thing in P2?

laeubi · 2023-06-21T09:50:11Z

is there such a thing in P2?

P2 has nothing to do with maven, and as said "optional" in maven means something completely different than one might think:
https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

Optional dependencies save space and memory. They prevent problematic jars that violate a license agreement or cause classpath issues from being bundled into a WAR, EAR, fat jar, or the like.

this does not makes the dependency "optional" in the sense of that one don't need it to build the project, I think there is more a problem with einter BND, outdated BND or manual crafted manifests, as BND should already detect class only annotations and not include them in the manifest.

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

Signed-off-by: ChUpdate to Guice 7 and Guava 32

cdietrich · 2023-06-25T13:48:21Z

Fixed in 2.32

frankbenoit · 2023-11-23T07:09:14Z

Guice 7 does no more support javax.inject.
This breaks peaberry, which does not know anything about jakarta.
In Eclipse in combination with Xtext and Guice, peaberry might be used often. At least in my projects :-)
Is there a known solution?

cdietrich · 2023-11-23T07:13:42Z

i assume they can install old guices from old orbits

cdietrich mentioned this issue Sep 20, 2022

Java 17 Masterplan, Part I #1982

Closed

25 tasks

cdietrich mentioned this issue Nov 12, 2022

Java 17 Masterplan Part II #2115

Open

16 tasks

This was referenced Apr 7, 2023

How to contribute artifacts directly? merks/simrel-maven#4

Open

Use Maven targets for OSGi compliant artifacts from Maven-Central #2207

Open

cdietrich mentioned this issue Apr 21, 2023

Find better solution for guice circular proxy problem #2430

Closed

cdietrich changed the title ~~Guice upgrade to 5.1.0~~ Guice upgrade to 5.1.0+ Apr 21, 2023

cdietrich added a commit that referenced this issue May 2, 2023

[#2056] experiments with guice 6 rc

bf2650d

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich added a commit that referenced this issue May 2, 2023

[#2056] experiments with guice 6 rc

fe138c3

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich added a commit that referenced this issue May 2, 2023

[#2056] experiments with guice 6 rc

49c662a

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich added a commit that referenced this issue May 2, 2023

[#2056] experiments with guice 6 rc

04045aa

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich added a commit that referenced this issue Jun 15, 2023

[#2056] experiments with guice 6 rc

f6ad4d8

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich mentioned this issue Jun 15, 2023

Update to Guava 32.0.1+ #2101

Closed

cdietrich added a commit that referenced this issue Jun 15, 2023

[#2056] experiments with guice 6 rc

fd959c2

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich added a commit that referenced this issue Jun 15, 2023

[#2056] experiments with guice 6 rc

9cac5f5

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich added a commit that referenced this issue Jun 15, 2023

[#2056] experiments with guice 6 rc

29ce2ba

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich mentioned this issue Jun 19, 2023

Update to Guice 7 and Guava 32 #2707

Merged

cdietrich added this to the Release_2.32 milestone Jun 20, 2023

cdietrich self-assigned this Jun 20, 2023

cdietrich changed the title ~~Guice upgrade to 6.0.0+~~ Guice upgrade to 7.0.0+ Jun 20, 2023

cdietrich added a commit that referenced this issue Jun 20, 2023

[#2056] experiments with guice 6 rc

983a4d9

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich added a commit that referenced this issue Jun 25, 2023

[#2056] experiments with guice 6 rc

5bf59d3

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>

cdietrich added a commit that referenced this issue Jun 25, 2023

[#2056][#2101] Update to Guice 7 and Guava 32

8e6a535

Signed-off-by: ChUpdate to Guice 7 and Guava 32

cdietrich added a commit that referenced this issue Jun 25, 2023

[#2056][#2101] Update to Guice 7 and Guava 32

4954311

Signed-off-by: ChUpdate to Guice 7 and Guava 32

cdietrich closed this as completed Jun 25, 2023

Guice upgrade to 7.0.0+ #2056

Guice upgrade to 7.0.0+ #2056

Comments

frankbenoit commented Apr 9, 2022

cdietrich commented Apr 9, 2022

HannesWell commented Apr 25, 2022 • edited

cdietrich commented Apr 26, 2022 • edited

HannesWell commented Apr 27, 2022 • edited

cdietrich commented Apr 27, 2022 • edited

HannesWell commented Apr 27, 2022 • edited

cdietrich commented Apr 27, 2022 • edited

HannesWell commented Apr 27, 2022

cdietrich commented Sep 21, 2022 • edited

cdietrich commented Sep 21, 2022

merks commented Sep 21, 2022

cdietrich commented Apr 18, 2023

HannesWell commented Apr 27, 2023 • edited

cdietrich commented May 2, 2023 • edited

cdietrich commented May 2, 2023

cdietrich commented May 2, 2023

cdietrich commented May 2, 2023 • edited

merks commented May 2, 2023

cdietrich commented May 2, 2023

cdietrich commented May 2, 2023

cdietrich commented Jun 16, 2023

HannesWell commented Jun 16, 2023

cdietrich commented Jun 16, 2023

cdietrich commented Jun 20, 2023

merks commented Jun 20, 2023

cdietrich commented Jun 20, 2023

merks commented Jun 20, 2023

cdietrich commented Jun 20, 2023

merks commented Jun 20, 2023

HannesWell commented Jun 20, 2023 • edited

laeubi commented Jun 21, 2023

cdietrich commented Jun 21, 2023

laeubi commented Jun 21, 2023

cdietrich commented Jun 25, 2023

frankbenoit commented Nov 23, 2023

cdietrich commented Nov 23, 2023

HannesWell commented Apr 25, 2022 •

edited

cdietrich commented Apr 26, 2022 •

edited

HannesWell commented Apr 27, 2022 •

edited

cdietrich commented Apr 27, 2022 •

edited

HannesWell commented Apr 27, 2022 •

edited

cdietrich commented Apr 27, 2022 •

edited

cdietrich commented Sep 21, 2022 •

edited

HannesWell commented Apr 27, 2023 •

edited

cdietrich commented May 2, 2023 •

edited

cdietrich commented May 2, 2023 •

edited

HannesWell commented Jun 20, 2023 •

edited