maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: maven-ear-plugin silently overrides libraries
Date Fri, 07 Feb 2014 16:04:53 GMT
Exclusions will not help in this case.
Looking through the dependency hierarchy will at least get you to see 
the problem earlier which I think was the nature of your question.

It appears from my brief reading and fun with making servlets run in 
production that classloaders merge classes by name.
Maven does not.

I am a bit surprised that groupId does not count.

If one uses a lot of third -party libraries, it would seem inevitable 
that you could need com.artifact-software:utilities:1.0 at the same time 
as ch.rethab:utilities:1.0 at the same time.
The classloader is not going to cause any problem but if Maven throws 
out one of these as a duplicate, you will be missing classes at run-time.

It is difficult to force everyone to create unique artifactIds unless 
you get rid of the GroupId altogther and make GAV -> <AV> and put the 
group name into the artifactID.

This seems to be a design flaw if it is true.

Ron

On 07/02/2014 9:43 AM, Reto Habl├╝tzel wrote:
> Sure, but exclusions don't do the trick if you need both of them, do 
> they? I am talking about completely independent libraries that happen 
> to have the same artifactId.
>
> Those were actually both libraries of mine and I could obviously fix 
> this issue rather simply, but I was just thinking that it would be 
> helpful to have at least a warning or something from maven - 
> regardless of the IDE.
>
> - Reto
>
>
> On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler 
> <rwheeler@artifact-software.com 
> <mailto:rwheeler@artifact-software.com>> wrote:
>
>     If your IDE supports Maven (Eclipse/STS for example), you will see
>     the conflict in the dependency hierarchy view and you can fix it
>     with the right exclusions.
>
>     It is almost always worth a quick look through the dependency
>     hierarchy view if you use a lot of third party libraries.
>     Not everyone updates their dependencies when they build a
>     shareable library.
>     You can sometimes get some pretty old versions of things dragged
>     in with the latest version of otherwise well-written libraries.
>     Exclusions need to be added to get what you want in your artifacts.
>
>     Ron
>
>
>     On 07/02/2014 9:21 AM, Reto Habl├╝tzel wrote:
>
>         Hi there,
>
>         I built an ear using the maven-ear-plugin (version 2.6).
>
>         The ear is configured such that it includes two libraries into
>         the lib
>         folder, both with the same artifactId as well as the same
>         version, but a
>         different groupId. Now if I simply call 'mvn package' only the
>         first one is
>         included, but no warning whatsoever appears. Only once I turn
>         on debugging
>         (mvn --debug package), I see one subtle message:
>         [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is
>         already up to date
>         at [lib/bar-1.0.jar]
>
>         Wouldn't it make sense to either include the groupId in the
>         filename or at
>         least make a check (that includes the groupId) beforehand if
>         there are any
>         conflicts?
>
>         Cheers,
>         Reto
>
>
>
>     -- 
>     Ron Wheeler
>     President
>     Artifact Software Inc
>     email: rwheeler@artifact-software.com
>     <mailto:rwheeler@artifact-software.com>
>     skype: ronaldmwheeler
>     phone: 866-970-2435, ext 102
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>     <mailto:users-unsubscribe@maven.apache.org>
>     For additional commands, e-mail: users-help@maven.apache.org
>     <mailto:users-help@maven.apache.org>
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message