You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Marshall Schor <ms...@schor.com> on 2008/05/28 22:44:10 UTC

Tools to help analyze to see if multiple versions of artifacts is a problem

I recently deleted my local maven repository, and ran a build of one of 
my projects.  In looking into what got downloaded by maven into the 
local repository, I found many cases were multiple versions of the same 
artifact were downloaded.

This may represent an issue, or not.  Is there any tooling I can run 
that will help me discover if some of the POMs (it's a multi-module 
project) need updating re: dependencies?  I guess I want to weed out 
things like:

My pom depends on artifact A, version 1.1.1, and artifact B (which, in 
turn depends on artifact A, version 1.0.0);  the actual build puts in 
version 1.1.1 of "A" which implements the same API as 1.0.0 for backward 
compatibility.  This seems like a "normal" thing that might happen a 
lot, and would not be "fixable" by me if I didn't "own" artifact B.

Thanks for any guidance here.

-Marshall


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


Re: Tools to help analyze to see if multiple versions of artifacts is a problem

Posted by simon <si...@chello.at>.
On Wed, 2008-05-28 at 16:44 -0400, Marshall Schor wrote:
> I recently deleted my local maven repository, and ran a build of one of 
> my projects.  In looking into what got downloaded by maven into the 
> local repository, I found many cases were multiple versions of the same 
> artifact were downloaded.
> 
> This may represent an issue, or not.  Is there any tooling I can run 
> that will help me discover if some of the POMs (it's a multi-module 
> project) need updating re: dependencies?  I guess I want to weed out 
> things like:
> 
> My pom depends on artifact A, version 1.1.1, and artifact B (which, in 
> turn depends on artifact A, version 1.0.0);  the actual build puts in 
> version 1.1.1 of "A" which implements the same API as 1.0.0 for backward 
> compatibility.  This seems like a "normal" thing that might happen a 
> lot, and would not be "fixable" by me if I didn't "own" artifact B.
> 
> Thanks for any guidance here.

First, check whether what was downloaded really was the dependency, or
just the pom. If it's just the pom, it isn't an issue. Maven really
shouldn't be downloading jars for two different versions of a lib -
except in the case where it is a maven *plugin* that needed that jar,
not your code. Not sure how to tell what purpose a jar was downloaded
for..

The command "mvn dependency:tree" is wonderful for analysing what's
actually going on with dependency resolution.

I don't see what the problem is in your example though. Maven won't
guarantee that everything is compatible; it can't because sometimes a
version-number change means an API change and sometimes it does not. It
just gives a good starting point, then you run your unit tests and other
QA procedures to verify that everything works well together. If it
doesn't, then you adjust your top-level pom to override specific lib
versions to resolve the issues.

In your example, it would not be right to fail the build. B quite likely
*does* work ok with A version 1.1.1. The only way to know for sure is to
run your app.

If B really doesn't work with anything other than 1.0.x, and knows it
for sure, then it can declare its dependency on A as "[1.0,1.1)". But
generally libs don't do that because when they are released they don't
know what the upper bound of acceptable versions is. And that's ok;
proper testing will pick up any problems.

Regards,
Simon


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