I don't think we want to remove the ability to have a non-shaded Guava (and
have that as the default), but if it's possible to build both at once, and
if Maven supports a way of saying: "Hey, every time my dependency tree
depends of Guice, instead use this <other Guava-shaded version of it>", I
see no particular problem with that.

Assuming both are possible and unless Stuart or someone else has a strong
reason why allowing this is a bad idea, I'd be happy to accept a PR for it.

Note that I wouldn't want to do this for *all* the dependencies. We don't
want to get back into the habit of needing to rerelease Guice whenever a
dependency has a new version, even if that version is backwards compatible.
This is particularly true for ASM.

sam


On Thu, Dec 9, 2021, 8:54 AM Piotr Morgwai Kotarbinski <morg...@gmail.com>
wrote:

> Hi,
> I don't exactly understand what you mean by "anyone who wants to shade in
> Guava can still do that". If you mean "anyone can make their own build of
> Guice", then it's quite a burden: you need to maintain a private maven repo
> only for this modified build of Guice for lifetime (at least for the
> lifetime of your project), rebuild it each time a new upstream Guice
> version is released etc...
> If you have something else in mind, then please kindly elaborate when you
> have a moment: maybe I'm missing some nice and easy solution ;-)
>
> OTOH, maven-shade-plugin also has `shadedArtifactAttached` and
> `shadedClassifierName` flags which allow to build and deploy both jars at
> once (with and without shaded+relocated+minimized Guava). This way it would
> be easy for everyone, right?
>
> Cheers!
>
> On Thursday, December 9, 2021 at 7:43:43 PM UTC+7 mcc...@gmail.com wrote:
>
>> You'll find that while it saves some space it will still pull in a lot of
>> Guava, which is the main reason why Guice stopped shading it in for
>> everyone.
>>
>> With the current setup anyone who wants to shade in Guava can still do
>> that, while everyone else is free to use a common Guava library without the
>> bloat.
>>
>> One compromise could be to add a "guice-all" module to the build which
>> puts Guice and its implementation dependencies into an uber jar.
>>
>> (Although if there's a security issue in the version of Guava shaded in
>> then you'd then need to wait for a new release of Guice vs. shading it
>> yourself.)
>>
>>
>> On Thu, 9 Dec 2021 at 12:04, Piotr Morgwai Kotarbinski <mor...@gmail.com>
>> wrote:
>>
>>> hmm, it's just come to me that maybe it's possible to achieve the same
>>> result without a need for guice-guava, using only maven-shade-plugin's
>>> filters and  "minimizeJar" option: in theory it should exactly include only
>>> classes that the project actually uses:
>>> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#minimizeJar
>>> (which makes me wonder why wasn't it used in the first place back when
>>> Guava was shaded...)
>>>
>>> On Thursday, December 9, 2021 at 2:10:57 PM UTC+7 Piotr Morgwai
>>> Kotarbinski wrote:
>>>
>>>> Unfortunately I think that the part "get the PR accepted"  is the main
>>>> blocker here: I doubt google would be interested in such change: internally
>>>> they build everything from HEAD of each dependency each time (or at least
>>>> they used to), so versioning is not an issue for them. On top of this, they
>>>> use Guice for almost every piece of Java code (again, at least they used
>>>> to), so I'm afraid they will view any change that does not solve some of
>>>> *their* problems as an unnecessary risk. On top of on top of this add
>>>> general unresponsiveness of google to issues and PRs on Guice github repo,
>>>> so even just starting a discussion what could possibly be an acceptable
>>>> solution from google's point of view may turn impossible.
>>>> As a consequence, anyone undertaking such task will risk all of his
>>>> work to never be accepted (or even considered) due to these "political"
>>>> reasons regardless of his solution's quality and usefulness for non-google
>>>> users :(
>>>>
>>>> At least for the sake of this conversation, let's try to discuss
>>>> possible approaches nevertheless:
>>>> - duplicating Guava's functionality directly into Guice is an ugly
>>>> solution, introduces maintenance problems and IMO should NOT be ever
>>>> accepted.
>>>> - putting Guava's functionality required by Guice into a separate lib
>>>> (let's call it "guice-guava") and creating in Guice's pom an additional
>>>> profile that uses this lib (shaded and relocated) instead of Guava: this
>>>> way Guice code stays pure, but this new lib has exactly the same problems
>>>> as described in the previous point.
>>>> - creating guice-guava by including Guava as its submodule and linking
>>>> from `src/main/java` to a subset of java files in guice-guava submodule
>>>> folder (hence including only necessary classes in guice-guava) may be
>>>> reasonable solution. Whether it's actually feasible depends how deep is the
>>>> dependency graph of Guava classes required by Guice.
>>>>
>>>> Cheers!
>>>>
>>>> On Friday, December 3, 2021 at 3:31:40 AM UTC+7 Brian Pontarelli wrote:
>>>>
>>>>> I agree 100%.
>>>>>
>>>>> My offer of a bounty still stands. Seriously. Happy to discuss actual
>>>>> numbers, but it would definitely be worth it for us to pay a good rate to
>>>>> get this fixed. FusionAuth would be the corporate sponsor of this effort 
>>>>> in
>>>>> case anyone is interested.
>>>>>
>>>>> — Brian
>>>>>
>>>>> On Nov 19, 2021, at 1:35 PM, Piotr Morgwai Kotarbinski <
>>>>> mor...@gmail.com> wrote:
>>>>>
>>>>> IMO, if a lib breaks backwards compatibility so often as Guava, it
>>>>> must be shaded: otherwise conflicts are unavoidable. The real problem is
>>>>> that Guava is too big as mentioned before. The right solution IMO would be
>>>>> to split it to smaller sub-libs. This way shading a small part that Guice
>>>>> depends on, would not be a problem anymore.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> On Monday, April 5, 2021 at 9:43:26 PM UTC+7 Brian Pontarelli wrote:
>>>>>
>>>>>> I understand why it would be best to leave Guava out of shading, but
>>>>>> it really causes issues because of the way that Guava manages releases 
>>>>>> and
>>>>>> versioning. The fact that it is on major version 27 while many projects 
>>>>>> are
>>>>>> using version 10 is an issue. Every time a library upgrades Guava, we are
>>>>>> all just hoping that it doesn’t break out entire classpath at runtime due
>>>>>> to some incompatible change. And manually shading everything in our
>>>>>> classpath for every upgrade is not feasible (hence the reason we are
>>>>>> removing Guava deps whenever possible).
>>>>>>
>>>>>> I’d be willing to provide a bounty if someone is willing to remove
>>>>>> Guava completely and can get the PR accepted.
>>>>>>
>>>>>> — Brian
>>>>>>
>>>>>> On Mar 14, 2021, at 4:57 PM, Stuart McCulloch <mcc...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On Fri, 19 Feb 2021 at 18:44, Brian Pontarelli <br...@pontarelli.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I’d be interested in this as well since we will be upgrading to Java
>>>>>>> 17 for FusionAuth once it is released.
>>>>>>>
>>>>>>> And not to hijack, but will it be possible to remove Guava and all
>>>>>>> shaded deps?
>>>>>>>
>>>>>>
>>>>>> In the latest release (5.0.1) the CGLIB dependency has been removed
>>>>>> leaving ASM as the only shaded dependency - because it's shaded it
>>>>>> shouldn't conflict with other versions on your classpath.
>>>>>>
>>>>>> Guava used to be shaded as well, but this caused overhead for users
>>>>>> who were also using Guava elsewhere in their application. It also made it
>>>>>> harder to pick up Guava fixes in-between releases of Guice. So it's now a
>>>>>> direct dependency that people can decide to shade themselves if they want
>>>>>> to use different versions on their classpath.
>>>>>>
>>>>>> Removing Guava completely would be a big undertaking - it's not part
>>>>>> of the public API, but the internals use it for caches and multimap 
>>>>>> support.
>>>>>>
>>>>>> Guava is a great example of how not to manage a library and it keeps
>>>>>>> rolling major versions that break compatibility. Tons of libraries uses
>>>>>>> different versions and regularly break our classpath. We are slowly 
>>>>>>> yanking
>>>>>>> libraries in FusionAuth that use CGLIB, ASM, and Guava. It would be 
>>>>>>> awesome
>>>>>>> if Guice could yank those deps. Ideally, Guice would have no deps 
>>>>>>> (except
>>>>>>> javax.inject) and just be a drop in lib.
>>>>>>>
>>>>>>> — Brian
>>>>>>>
>>>>>>> On Feb 19, 2021, at 11:05 AM, Peter Burka <pe...@quux.net> wrote:
>>>>>>>
>>>>>>> Java 17 will be released later this year, and will be the first long
>>>>>>> term support (LTS) OpenJDK version since Java 11 in 2018. I imagine that
>>>>>>> Guice 5 will add support for Java 17, however the current beta version 
>>>>>>> does
>>>>>>> not work on Java 17 early-access as it includes an out-of-date shaded
>>>>>>> version of ASM.
>>>>>>>
>>>>>>> What is the anticipated schedule for releasing Guice 5? Will it be
>>>>>>> available before Java 17? Will there be any additional beta releases 
>>>>>>> before
>>>>>>> GA?
>>>>>>>
>>>>>>> Are there any plans to update Guice 4 with Java 17 support, too?
>>>>>>>
>>>>>>> Thank you!
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "google-guice" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to google-guice...@googlegroups.com.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/google-guice/88f24d78-f0b0-4633-881b-44deb050610fn%40googlegroups.com
>>>>>>> <https://groups.google.com/d/msgid/google-guice/88f24d78-f0b0-4633-881b-44deb050610fn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "google-guice" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to google-guice...@googlegroups.com.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/google-guice/AF183807-C0A0-4C3B-8C23-6B93F89D4BA9%40pontarelli.com
>>>>>>> <https://groups.google.com/d/msgid/google-guice/AF183807-C0A0-4C3B-8C23-6B93F89D4BA9%40pontarelli.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "google-guice" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to google-guice...@googlegroups.com.
>>>>>>
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/google-guice/CAMr6Z4%3DLAU4QDiH_gvJ%2BtMm1SpWDhdpPcZ6GB3oqm%3Dnm%2Bc%2BtNQ%40mail.gmail.com
>>>>>> <https://groups.google.com/d/msgid/google-guice/CAMr6Z4%3DLAU4QDiH_gvJ%2BtMm1SpWDhdpPcZ6GB3oqm%3Dnm%2Bc%2BtNQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "google-guice" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to google-guice...@googlegroups.com.
>>>>>
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/google-guice/1eb953bf-675b-4d09-8dea-00c38db8a7f4n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/google-guice/1eb953bf-675b-4d09-8dea-00c38db8a7f4n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>>
>>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "google-guice" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-guice...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-guice/ee3eea18-a9ea-4a21-9ff8-8d2a496e511en%40googlegroups.com
>>> <https://groups.google.com/d/msgid/google-guice/ee3eea18-a9ea-4a21-9ff8-8d2a496e511en%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-guice+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-guice/8717c4c2-7c53-47af-aee1-012b788b5d6an%40googlegroups.com
> <https://groups.google.com/d/msgid/google-guice/8717c4c2-7c53-47af-aee1-012b788b5d6an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-guice+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-guice/CAJEBNUdxUqwM2Y7DFHkMknhhrfdyzkTrjuCJ4SBGRBZj0YWHLQ%40mail.gmail.com.

Reply via email to