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 eczec...@gmail.com 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
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 stephen.alan.conno...@gmail.com 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 eczec...@gmail.com 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
shade via intermediate modules On 24 September 2012 14:36, Eric Czech e...@nextbigsound.com 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 stephen.alan.conno...@gmail.com 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 eczec...@gmail.com 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
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 e...@nextbigsound.com 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 stephen.alan.conno...@gmail.com 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 eczec...@gmail.com 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
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 rwhee...@artifact-software.com 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 e...@nextbigsound.com 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 stephen.alan.conno...@gmail.com 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 eczec...@gmail.com 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
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 rwhee...@artifact-software.com 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 e...@nextbigsound.com 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 stephen.alan.conno...@gmail.com 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 eczec...@gmail.com 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
On Mon, Sep 24, 2012 at 5:24 PM, Eric Czech e...@nextbigsound.com 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
