So what's the status on this? Shall I create a ticket?
On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler <rwhee...@artifact-software.com>wrote: > 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:rwhee...@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: rwhee...@artifact-software.com >> <mailto:rwhee...@artifact-software.com> >> >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> <mailto:users-unsubscr...@maven.apache.org> >> >> For additional commands, e-mail: users-h...@maven.apache.org >> <mailto:users-h...@maven.apache.org> >> >> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
