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
