Re: Guava artifact version issues
On Mon, Sep 24, 2012 at 5:24 PM, Eric Czech wrote: > Thanks Ron but no unfortunately, they're not upwards compatible. > Entire classes are renamed or removed in later versions so artifacts > using the old version definitely can't just use the new one. Only for @Beta classes/methods (which you shouldn't use in a library / code designed to be reused by others) or after a 18-months deprecation notice: https://code.google.com/p/guava-libraries/wiki/PhilosophyExplained#Iteration. It might be that r09 didn't follow those rules though… (note that r09 is almost 18 months old, so if a project depends on r09 and used things that were deprecated in that version, it could very well no longer run with 13.0.1) > Having our own guava artifact with the code from 13.0.1 means that we > can use that version *internally* and external libraries can use > whatever version they are specified as needing. > > Shading definitely seems like a better generic way to deal with this > but I'm still not totally sure how to do it. > > Stephen, by intermediate modules do you mean create projects for each > guava version, add the guava version as a dependency, give it a unique > shading, and then point all dependent projects at those "intermediate" > projects instead of directly at the guava artifacts? I believe he meant creating an "intermediate project A" module that depends on "project A" and relocates guava r09, so that it doesn't conflict with your own use of Guava (13.0.1) in "project B" (which would obviously depend on "intermediate project A" instead of "project A". The "intermediate project A" artifact would contain both "project A" classes modified to reference relocated Guava classes, and the relocated Guava classes. Other dependencies could be left as transitive dependencies. Or you could create a "relocated Guava" module for your own use. I'd rather go with the former though, as the conflicts could potentially be resolved when updating "project A", in which case you simply remove the "intermediate project A" so that both "project A" and "project B" code use the same Guava version, and you don't have to change your code. -- Thomas Broyer /tɔ.ma.bʁwa.je/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Guava artifact version issues
On 24/09/2012 11:24 AM, Eric Czech wrote: Thanks Ron but no unfortunately, they're not upwards compatible. Entire classes are renamed or removed in later versions so artifacts using the old version definitely can't just use the new one. Having our own guava artifact with the code from 13.0.1 means that we can use that version *internally* and external libraries can use whatever version they are specified as needing. Shading definitely seems like a better generic way to deal with this but I'm still not totally sure how to do it. Stephen, by intermediate modules do you mean create projects for each guava version, add the guava version as a dependency, give it a unique shading, and then point all dependent projects at those "intermediate" projects instead of directly at the guava artifacts? Sounds like a Facade design pattern? On Mon, Sep 24, 2012 at 10:04 AM, Ron Wheeler wrote: Is there no upward compatibility? Can projects A and B execute using Guava 13.0.1? Usually, you just exclude the lower versions in the dependency specification for the third party library and run with the highest version. If Guava is not upwards compatible and the third party libraries use different but incompatible methods (ie x=guavamethod1(); return "QUIT" in version r09 and x=guavamethod1(); returns "EXIT" in version 13 and project A is looking for "QUIT", how will having your own version of Guava help? If this is not the case then running with just 13.0.1 should do the job. "Exclude" is your friend. Ron On 24/09/2012 9:48 AM, Stephen Connolly wrote: shade via intermediate modules On 24 September 2012 14:36, Eric Czech wrote: Thank you, that's exactly what I was looking for. Is there a way to shade versions of an artifact in a particular way? For example, if projects A and B depend on Guava r09 and projects C and D depend on Guava 13.0.1, how can I make sure that each is referencing the correctly shaded version when they're built into a jar? On Mon, Sep 24, 2012 at 8:55 AM, Stephen Connolly wrote: Maven shade plugin can relocate all the classes into a different package for you in minutes of config and seconds of build time On 24 September 2012 13:43, Eric Czech wrote: Hi everyone, I'm continually running into issues with Guava dependencies where the version of Guava we use is inconsistent with the version used by some other third-party library or several third-party artifacts referenced in our projects use incompatible versions. I'm considering getting the source code for the version of Guava we use and just building it into a new artifact with a slightly different package namespace (all the packages would start with com.custom.google or something like that). Is there a better way to go about this in general? Thanks in advance! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Guava artifact version issues
Thanks Ron but no unfortunately, they're not upwards compatible. Entire classes are renamed or removed in later versions so artifacts using the old version definitely can't just use the new one. Having our own guava artifact with the code from 13.0.1 means that we can use that version *internally* and external libraries can use whatever version they are specified as needing. Shading definitely seems like a better generic way to deal with this but I'm still not totally sure how to do it. Stephen, by intermediate modules do you mean create projects for each guava version, add the guava version as a dependency, give it a unique shading, and then point all dependent projects at those "intermediate" projects instead of directly at the guava artifacts? On Mon, Sep 24, 2012 at 10:04 AM, Ron Wheeler wrote: > Is there no upward compatibility? > Can projects A and B execute using Guava 13.0.1? > > Usually, you just exclude the lower versions in the dependency specification > for the third party library and run with the highest version. > > If Guava is not upwards compatible and the third party libraries use > different but incompatible methods > (ie x=guavamethod1(); return "QUIT" in version r09 and x=guavamethod1(); > returns "EXIT" in version 13 and project A is looking for "QUIT", how will > having your own version of Guava help? > If this is not the case then running with just 13.0.1 should do the job. > "Exclude" is your friend. > > Ron > > > On 24/09/2012 9:48 AM, Stephen Connolly wrote: >> >> shade via intermediate modules >> >> On 24 September 2012 14:36, Eric Czech wrote: >> >>> Thank you, that's exactly what I was looking for. >>> >>> Is there a way to shade versions of an artifact in a particular way? >>> For example, if projects A and B depend on Guava r09 and projects C >>> and D depend on Guava 13.0.1, how can I make sure that each is >>> referencing the correctly shaded version when they're built into a >>> jar? >>> >>> On Mon, Sep 24, 2012 at 8:55 AM, Stephen Connolly >>> wrote: Maven shade plugin can relocate all the classes into a different package for you in minutes of config and seconds of build time On 24 September 2012 13:43, Eric Czech wrote: > Hi everyone, > > I'm continually running into issues with Guava dependencies where the > version of Guava we use is inconsistent with the version used by some > other third-party library or several third-party artifacts referenced > in our projects use incompatible versions. > > I'm considering getting the source code for the version of Guava we > use and just building it into a new artifact with a slightly different > package namespace (all the packages would start with com.custom.google > or something like that). > > Is there a better way to go about this in general? > > Thanks in advance! > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Guava artifact version issues
Is there no upward compatibility? Can projects A and B execute using Guava 13.0.1? Usually, you just exclude the lower versions in the dependency specification for the third party library and run with the highest version. If Guava is not upwards compatible and the third party libraries use different but incompatible methods (ie x=guavamethod1(); return "QUIT" in version r09 and x=guavamethod1(); returns "EXIT" in version 13 and project A is looking for "QUIT", how will having your own version of Guava help? If this is not the case then running with just 13.0.1 should do the job. "Exclude" is your friend. Ron On 24/09/2012 9:48 AM, Stephen Connolly wrote: shade via intermediate modules On 24 September 2012 14:36, Eric Czech wrote: Thank you, that's exactly what I was looking for. Is there a way to shade versions of an artifact in a particular way? For example, if projects A and B depend on Guava r09 and projects C and D depend on Guava 13.0.1, how can I make sure that each is referencing the correctly shaded version when they're built into a jar? On Mon, Sep 24, 2012 at 8:55 AM, Stephen Connolly wrote: Maven shade plugin can relocate all the classes into a different package for you in minutes of config and seconds of build time On 24 September 2012 13:43, Eric Czech wrote: Hi everyone, I'm continually running into issues with Guava dependencies where the version of Guava we use is inconsistent with the version used by some other third-party library or several third-party artifacts referenced in our projects use incompatible versions. I'm considering getting the source code for the version of Guava we use and just building it into a new artifact with a slightly different package namespace (all the packages would start with com.custom.google or something like that). Is there a better way to go about this in general? Thanks in advance! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Guava artifact version issues
shade via intermediate modules On 24 September 2012 14:36, Eric Czech wrote: > Thank you, that's exactly what I was looking for. > > Is there a way to shade versions of an artifact in a particular way? > For example, if projects A and B depend on Guava r09 and projects C > and D depend on Guava 13.0.1, how can I make sure that each is > referencing the correctly shaded version when they're built into a > jar? > > On Mon, Sep 24, 2012 at 8:55 AM, Stephen Connolly > wrote: > > Maven shade plugin can relocate all the classes into a different package > > for you in minutes of config and seconds of build time > > > > On 24 September 2012 13:43, Eric Czech wrote: > > > >> Hi everyone, > >> > >> I'm continually running into issues with Guava dependencies where the > >> version of Guava we use is inconsistent with the version used by some > >> other third-party library or several third-party artifacts referenced > >> in our projects use incompatible versions. > >> > >> I'm considering getting the source code for the version of Guava we > >> use and just building it into a new artifact with a slightly different > >> package namespace (all the packages would start with com.custom.google > >> or something like that). > >> > >> Is there a better way to go about this in general? > >> > >> Thanks in advance! > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Guava artifact version issues
Thank you, that's exactly what I was looking for. Is there a way to shade versions of an artifact in a particular way? For example, if projects A and B depend on Guava r09 and projects C and D depend on Guava 13.0.1, how can I make sure that each is referencing the correctly shaded version when they're built into a jar? On Mon, Sep 24, 2012 at 8:55 AM, Stephen Connolly wrote: > Maven shade plugin can relocate all the classes into a different package > for you in minutes of config and seconds of build time > > On 24 September 2012 13:43, Eric Czech wrote: > >> Hi everyone, >> >> I'm continually running into issues with Guava dependencies where the >> version of Guava we use is inconsistent with the version used by some >> other third-party library or several third-party artifacts referenced >> in our projects use incompatible versions. >> >> I'm considering getting the source code for the version of Guava we >> use and just building it into a new artifact with a slightly different >> package namespace (all the packages would start with com.custom.google >> or something like that). >> >> Is there a better way to go about this in general? >> >> Thanks in advance! >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Guava artifact version issues
Maven shade plugin can relocate all the classes into a different package for you in minutes of config and seconds of build time On 24 September 2012 13:43, Eric Czech wrote: > Hi everyone, > > I'm continually running into issues with Guava dependencies where the > version of Guava we use is inconsistent with the version used by some > other third-party library or several third-party artifacts referenced > in our projects use incompatible versions. > > I'm considering getting the source code for the version of Guava we > use and just building it into a new artifact with a slightly different > package namespace (all the packages would start with com.custom.google > or something like that). > > Is there a better way to go about this in general? > > Thanks in advance! > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
