AW: Dealing with .jars that have overlapping .classes

[Christofer Dutz]

We use the Tattletale Maven Plugin to scan our applications to finde such 
overlaps: http://docs.jboss.org/tattletale/userguide/1.2/en-US/html/maven.html

Chris


Von: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> im Auftrag von Curtis 
Rueden <ctrue...@wisc.edu>
Gesendet: Freitag, 22. April 2016 21:03
An: Maven Users List
Betreff: Re: Dealing with .jars that have overlapping .classes

Hi Kevin,

My projects handles it as follows:

1) Death to uber-JARs; use component JARs whenever they exist. If they
don't exist, consider forking the project to create them, or at least
shading the embedded dependencies. (E.g.:
https://github.com/scijava/jython-shaded)

2) Use excludes to avoid bogus transitive dependencies. For example, no one
should depend on xml-apis, since those classes come with Java. But lots of
projects do. So just exclude xml-apis:xml-apis in your dependencyManagement
section for all afflicted projects. Probably also xalan:xalan, maybe
xerces, etc.

3) Contact project maintainers upstream to inform them when you find these
situations. Many build systems simply do not alert the maintainers that
anything like this is happening. So they may just be clueless (though
Stephen Colbourne is pretty awesome—I would be surprised if he doesn't know
about the joda overlap in this case... but still, may as well ask about
it). E.g.: we had one dependency where the project's gradle build system
was putting *two copies of each class* into the final JAR artifact! Guess
how much maven-enforcer-plugin liked that? :-)

4) Finally, if you have to do it, just add some class excludes to your
maven-enforcer-configuration. Especially for cases like joda, chances are
the two copies of the classes are identical, so having both on the
classpath will work just fine, pragmatically.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Fri, Apr 22, 2016 at 1:23 PM, Kevin Burton <bur...@spinn3r.com> wrote:

> We have a rather complex classpath in our app... sometimes maven computes
> the wrong classpath because one package changes classpath order and has a
> dependency on an earlier jar.
>
> To avoid this we usually analyze our classpath between builds and our
> builds break if a classpath change isn't approved.
>
> One of the BIG problems here is when we get overlapping classes.
>
> Right now this is happening with joda time and joda convert.  WE have about
> 10 classes that are in both .jars.
>
> First. It seems irresponsible for project maintainers to release artifacts
> like this. If there are shared .classes just publish a new -core artifact.
>
> Just being pragmatic.. I'm not sure the BEST way to handle this.
>
> One strategy is to make sure that each lib is the LATEST .. but sometimes
> that's not possible.
>
> How do you guys handle this?
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Dealing with .jars that have overlapping .classes

[Christofer Dutz]

Here I could re-phrase my request to extend the dependencyManagement with the 
ability to add "includes". Cause when dealing with these uber-jars I always 
have to add a set of excludes and would like to have some replacement includes 
... sort of:

dependencyManagement
dependency-x
exludes 
crappy-uber-jar
includes
the individual jars that make up the uber-jar

So I don't have to rely on all users knowing that if they reference 
"dependency-x" they have to manually include all the individual jars (and no 
... a pom handling this is not practical, cause I usually search for jars 
providing a given class and not poms referencing jars that provide a class ;-) )

Chris



Von: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> im Auftrag von Curtis 
Rueden <ctrue...@wisc.edu>
Gesendet: Freitag, 22. April 2016 21:03
An: Maven Users List
Betreff: Re: Dealing with .jars that have overlapping .classes

Hi Kevin,

My projects handles it as follows:

1) Death to uber-JARs; use component JARs whenever they exist. If they
don't exist, consider forking the project to create them, or at least
shading the embedded dependencies. (E.g.:
https://github.com/scijava/jython-shaded)

2) Use excludes to avoid bogus transitive dependencies. For example, no one
should depend on xml-apis, since those classes come with Java. But lots of
projects do. So just exclude xml-apis:xml-apis in your dependencyManagement
section for all afflicted projects. Probably also xalan:xalan, maybe
xerces, etc.

3) Contact project maintainers upstream to inform them when you find these
situations. Many build systems simply do not alert the maintainers that
anything like this is happening. So they may just be clueless (though
Stephen Colbourne is pretty awesome—I would be surprised if he doesn't know
about the joda overlap in this case... but still, may as well ask about
it). E.g.: we had one dependency where the project's gradle build system
was putting *two copies of each class* into the final JAR artifact! Guess
how much maven-enforcer-plugin liked that? :-)

4) Finally, if you have to do it, just add some class excludes to your
maven-enforcer-configuration. Especially for cases like joda, chances are
the two copies of the classes are identical, so having both on the
classpath will work just fine, pragmatically.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Fri, Apr 22, 2016 at 1:23 PM, Kevin Burton <bur...@spinn3r.com> wrote:

> We have a rather complex classpath in our app... sometimes maven computes
> the wrong classpath because one package changes classpath order and has a
> dependency on an earlier jar.
>
> To avoid this we usually analyze our classpath between builds and our
> builds break if a classpath change isn't approved.
>
> One of the BIG problems here is when we get overlapping classes.
>
> Right now this is happening with joda time and joda convert.  WE have about
> 10 classes that are in both .jars.
>
> First. It seems irresponsible for project maintainers to release artifacts
> like this. If there are shared .classes just publish a new -core artifact.
>
> Just being pragmatic.. I'm not sure the BEST way to handle this.
>
> One strategy is to make sure that each lib is the LATEST .. but sometimes
> that's not possible.
>
> How do you guys handle this?
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Dealing with .jars that have overlapping .classes

[Curtis Rueden]

Hi Kevin,

My projects handles it as follows:

1) Death to uber-JARs; use component JARs whenever they exist. If they
don't exist, consider forking the project to create them, or at least
shading the embedded dependencies. (E.g.:
https://github.com/scijava/jython-shaded)

2) Use excludes to avoid bogus transitive dependencies. For example, no one
should depend on xml-apis, since those classes come with Java. But lots of
projects do. So just exclude xml-apis:xml-apis in your dependencyManagement
section for all afflicted projects. Probably also xalan:xalan, maybe
xerces, etc.

3) Contact project maintainers upstream to inform them when you find these
situations. Many build systems simply do not alert the maintainers that
anything like this is happening. So they may just be clueless (though
Stephen Colbourne is pretty awesome—I would be surprised if he doesn't know
about the joda overlap in this case... but still, may as well ask about
it). E.g.: we had one dependency where the project's gradle build system
was putting *two copies of each class* into the final JAR artifact! Guess
how much maven-enforcer-plugin liked that? :-)

4) Finally, if you have to do it, just add some class excludes to your
maven-enforcer-configuration. Especially for cases like joda, chances are
the two copies of the classes are identical, so having both on the
classpath will work just fine, pragmatically.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Fri, Apr 22, 2016 at 1:23 PM, Kevin Burton  wrote:

> We have a rather complex classpath in our app... sometimes maven computes
> the wrong classpath because one package changes classpath order and has a
> dependency on an earlier jar.
>
> To avoid this we usually analyze our classpath between builds and our
> builds break if a classpath change isn't approved.
>
> One of the BIG problems here is when we get overlapping classes.
>
> Right now this is happening with joda time and joda convert.  WE have about
> 10 classes that are in both .jars.
>
> First. It seems irresponsible for project maintainers to release artifacts
> like this. If there are shared .classes just publish a new -core artifact.
>
> Just being pragmatic.. I'm not sure the BEST way to handle this.
>
> One strategy is to make sure that each lib is the LATEST .. but sometimes
> that's not possible.
>
> How do you guys handle this?
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
>

Re: Dealing with .jars that have overlapping .classes

[Aldrin Leal]

Use a dependencyManagement section in order to declare the versions we
really need.

Create intermediary jars using shade in cases we really need both versions
of the same jar

Use the DOES-NOT-EXIST trick

for dependencies meant to completely wipe

--
-- Aldrin Leal,  / http://about.me/aldrinleal

On Fri, Apr 22, 2016 at 1:23 PM, Kevin Burton  wrote:

> We have a rather complex classpath in our app... sometimes maven computes
> the wrong classpath because one package changes classpath order and has a
> dependency on an earlier jar.
>
> To avoid this we usually analyze our classpath between builds and our
> builds break if a classpath change isn't approved.
>
> One of the BIG problems here is when we get overlapping classes.
>
> Right now this is happening with joda time and joda convert.  WE have about
> 10 classes that are in both .jars.
>
> First. It seems irresponsible for project maintainers to release artifacts
> like this. If there are shared .classes just publish a new -core artifact.
>
> Just being pragmatic.. I'm not sure the BEST way to handle this.
>
> One strategy is to make sure that each lib is the LATEST .. but sometimes
> that's not possible.
>
> How do you guys handle this?
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
>

Dealing with .jars that have overlapping .classes

[Kevin Burton]

We have a rather complex classpath in our app... sometimes maven computes
the wrong classpath because one package changes classpath order and has a
dependency on an earlier jar.

To avoid this we usually analyze our classpath between builds and our
builds break if a classpath change isn't approved.

One of the BIG problems here is when we get overlapping classes.

Right now this is happening with joda time and joda convert.  WE have about
10 classes that are in both .jars.

First. It seems irresponsible for project maintainers to release artifacts
like this. If there are shared .classes just publish a new -core artifact.

Just being pragmatic.. I'm not sure the BEST way to handle this.

One strategy is to make sure that each lib is the LATEST .. but sometimes
that's not possible.

How do you guys handle this?

-- 

We’re hiring if you know of any awesome Java Devops or Linux Operations
Engineers!

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile