[MRESOLVER-397] Deprecate Guice integration

[cstamas]

Lowering the provided instantiation support from 3 to 2, to lower resources for maintenance all these.

SL is about to be dropped, Guice same. Users should either use Sisu or use the new Supplier.

---

https://issues.apache.org/jira/browse/MRESOLVER-397

[gnodet]

Lowering the provided instantiation support from 3 to 2, to lower resources for maintenance all these.

SL is about to be dropped, Guice same. Users should either use Sisu or use the new Supplier.

https://issues.apache.org/jira/browse/MRESOLVER-397

Sisu is using guice anyway... Are there any Sisu specific things that would prevent the resolver to be used by any jsr-330 implementation ?

[cstamas]

Yes, Sisu is built on "top" of Guice, and offers two-way passage, basically whoever uses Guice should be able to use Resolver by just throwing Sisu JAR in there as well.

As for "any jsr-330 implementation", am really unsure.

Anyway, the point of whole effort is:

• either use Resolver w/ Sisu as Maven does
• if you cannot/don't want/whatever, use the Supplier introduced in https://issues.apache.org/jira/browse/MRESOLVER-387

We have no resources to maintain several integrations that we are not even sure, are they used or not. We should offer only 2, one DI/Sisu and one "pure java" (supplier) and done.

[basil]

Hi @cstamas, we are currently relying on this deprecated functionality in the Jenkins Acceptance Test Harness (ATH), a Guice-based project that also uses Maven Resolver to fetch Jenkins plugins for tesitng purposes. The relevant functionality is here: https://github.com/jenkinsci/acceptance-test-harness/blob/9b7b87da2b1d5873876d156756f8849b26fcbc16/src/main/java/org/jenkinsci/test/acceptance/utils/aether/AetherModule.java

Thank you very much for including this note:

This class is about to be dropped in 2.0.0 release. Use Sisu or use Maven Resolver Supplier to get Resolver instances.

However, I am not sure whether Sisu or Maven Resolver Supplier would be better for our use case. Since we are already using Guice, would Sisu be the preferred migration path? And if so, are there any examples you could point to?

[cstamas]

Given you use Guice already, Sisu is "just" +300KB (if using no_asm and you provide ASM), or +500KB extra dependency. If you can live with that, I'd say "go with Sisu".

@basil can you point me at some building instructions where I can test some ideas for migration?

[basil]

@cstamas This is a test framework, so the added Sisu dependency would be fine for us. Thanks for confirming that Sisu is the preferred migration path for heavy Guice users. As far as building instructions, https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/DOCKER.md is the best place to start. For testing Guice integration, you could probably even avoid Docker and simply use e.g. run.sh firefox latest -Dtest=plugins.AntPluginTest#autoInstallAnt.

[cstamas]

@basil something along these lines? jenkinsci/acceptance-test-harness#1733