You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Reto Hablützel <re...@rethab.ch> on 2014/02/07 15:21:54 UTC
maven-ear-plugin silently overrides libraries
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
Re: maven-ear-plugin silently overrides libraries
Posted by Stephane Nicoll <st...@gmail.com>.
I confirm that the use case you mention is supposed to work transparently.
This most likely looks like a bug.
Thanks for reporting this.
S.
On Fri, Feb 7, 2014 at 3:21 PM, Reto Hablützel <re...@rethab.ch> 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
>
Re: maven-ear-plugin silently overrides libraries
Posted by Jörg Schaible <jo...@gmx.de>.
Robert Scholte wrote:
> Hi,
>
> See
> http://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html
> for custom filename mapping.
Hmmm, IIRC the war plugin will automatically prepend the groupId for all
jars with clashing name.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-ear-plugin silently overrides libraries
Posted by Reto Hablützel <re...@rethab.ch>.
Hi Robert,
this sure is an option but only once you know where all those
ClassNotFoundExceptions are coming from. I would like to avoid them in the
first place ;)
- Reto
On Fri, Feb 7, 2014 at 3:43 PM, Robert Scholte <rf...@apache.org> wrote:
> Hi,
>
> See http://maven.apache.org/plugins/maven-ear-plugin/
> examples/customize-file-name-mapping.html for custom filename mapping.
>
> Robert
>
> Op Fri, 07 Feb 2014 15:21:54 +0100 schreef Reto Hablützel <
> rethab@rethab.ch>:
>
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven-ear-plugin silently overrides libraries
Posted by Robert Scholte <rf...@apache.org>.
Hi,
See
http://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html
for custom filename mapping.
Robert
Op Fri, 07 Feb 2014 15:21:54 +0100 schreef Reto Hablützel
<re...@rethab.ch>:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-ear-plugin silently overrides libraries
Posted by Reto Hablützel <re...@rethab.ch>.
Thank you, Anders.
I reported the issue: http://jira.codehaus.org/browse/MEAR-180
- Reto
On Fri, Feb 14, 2014 at 7:52 AM, Anders Hammar <an...@hammar.net> wrote:
> You need to create an account at Codehaus Xircles. Go to
> http://jira.codehaus.org and there is more info in the top left hand
> gadget/box.
>
> /Anders
>
>
> On Fri, Feb 14, 2014 at 7:46 AM, Reto Hablützel <re...@rethab.ch> wrote:
>
> > Is JIRA open for public registration / issue creation? I could not find a
> > link to sign up..
> >
> > Anyways, I attached a sample project. Please follow these steps to
> > recreate the issue (btw. I think the whole naming thing is also a problem
> > if you are referencing two ejbs with the same artifactId and version):
> >
> > Install 'utilities' project in 'collections':
> > collections/utilities> mvn install
> >
> > Install 'utilities' project in 'email':
> > email/utilities> mvn install
> >
> > Package 'ear' project:
> > ear> mvn package
> >
> > Look at contents of ear and notice how only one jar is included:
> > ear> unzip -v target/ear-1.0.0.ear
> >
> > Now use the debug flag to see why only one gets included:
> > ear> mvn --debug clean package
> >
> > Partial output:
> > [INFO] Copying artifact [jar:ch.rethab.email:utilities:1.0.0] to
> > [utilities-1.0.0.jar]
> > [DEBUG] Skipping artifact [jar:ch.rethab.collections:utilities:1.0.0],
> > as it is already up to date at [utilities-1.0.0.jar]
> >
> >
> >
> >
> > On Thu, Feb 13, 2014 at 7:32 PM, Baptiste Mathus <bmathus@batmat.net
> >wrote:
> >
> >> That's the way to go. Even more if you're able to attach a test project.
> >> One report without report is far less likely to be worked on.
> >> Cheers
> >> Le 13 févr. 2014 14:06, "Reto Hablützel" <re...@rethab.ch> a écrit :
> >>
> >> > So what's the status on this? Shall I create a ticket?
> >> >
> >> >
> >> > On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler
> >> > <rw...@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 <ma...@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
> >> > >> <ma...@artifact-software.com>
> >> > >>
> >> > >> skype: ronaldmwheeler
> >> > >> phone: 866-970-2435, ext 102
> >> > >>
> >> > >>
> >> > >>
> >> > ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> > >> <ma...@maven.apache.org>
> >> > >>
> >> > >> For additional commands, e-mail: users-help@maven.apache.org
> >> > >> <ma...@maven.apache.org>
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > > --
> >> > > Ron Wheeler
> >> > > President
> >> > > Artifact Software Inc
> >> > > email: rwheeler@artifact-software.com
> >> > > skype: ronaldmwheeler
> >> > > phone: 866-970-2435, ext 102
> >> > >
> >> > >
> >> >
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
Re: maven-ear-plugin silently overrides libraries
Posted by Anders Hammar <an...@hammar.net>.
You need to create an account at Codehaus Xircles. Go to
http://jira.codehaus.org and there is more info in the top left hand
gadget/box.
/Anders
On Fri, Feb 14, 2014 at 7:46 AM, Reto Hablützel <re...@rethab.ch> wrote:
> Is JIRA open for public registration / issue creation? I could not find a
> link to sign up..
>
> Anyways, I attached a sample project. Please follow these steps to
> recreate the issue (btw. I think the whole naming thing is also a problem
> if you are referencing two ejbs with the same artifactId and version):
>
> Install 'utilities' project in 'collections':
> collections/utilities> mvn install
>
> Install 'utilities' project in 'email':
> email/utilities> mvn install
>
> Package 'ear' project:
> ear> mvn package
>
> Look at contents of ear and notice how only one jar is included:
> ear> unzip -v target/ear-1.0.0.ear
>
> Now use the debug flag to see why only one gets included:
> ear> mvn --debug clean package
>
> Partial output:
> [INFO] Copying artifact [jar:ch.rethab.email:utilities:1.0.0] to
> [utilities-1.0.0.jar]
> [DEBUG] Skipping artifact [jar:ch.rethab.collections:utilities:1.0.0],
> as it is already up to date at [utilities-1.0.0.jar]
>
>
>
>
> On Thu, Feb 13, 2014 at 7:32 PM, Baptiste Mathus <bm...@batmat.net>wrote:
>
>> That's the way to go. Even more if you're able to attach a test project.
>> One report without report is far less likely to be worked on.
>> Cheers
>> Le 13 févr. 2014 14:06, "Reto Hablützel" <re...@rethab.ch> a écrit :
>>
>> > So what's the status on this? Shall I create a ticket?
>> >
>> >
>> > On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler
>> > <rw...@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 <ma...@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
>> > >> <ma...@artifact-software.com>
>> > >>
>> > >> skype: ronaldmwheeler
>> > >> phone: 866-970-2435, ext 102
>> > >>
>> > >>
>> > >>
>> > ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > >> <ma...@maven.apache.org>
>> > >>
>> > >> For additional commands, e-mail: users-help@maven.apache.org
>> > >> <ma...@maven.apache.org>
>> > >>
>> > >>
>> > >>
>> > >
>> > > --
>> > > Ron Wheeler
>> > > President
>> > > Artifact Software Inc
>> > > email: rwheeler@artifact-software.com
>> > > skype: ronaldmwheeler
>> > > phone: 866-970-2435, ext 102
>> > >
>> > >
>> >
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: maven-ear-plugin silently overrides libraries
Posted by Reto Hablützel <re...@rethab.ch>.
Is JIRA open for public registration / issue creation? I could not find a
link to sign up..
Anyways, I attached a sample project. Please follow these steps to recreate
the issue (btw. I think the whole naming thing is also a problem if you are
referencing two ejbs with the same artifactId and version):
Install 'utilities' project in 'collections':
collections/utilities> mvn install
Install 'utilities' project in 'email':
email/utilities> mvn install
Package 'ear' project:
ear> mvn package
Look at contents of ear and notice how only one jar is included:
ear> unzip -v target/ear-1.0.0.ear
Now use the debug flag to see why only one gets included:
ear> mvn --debug clean package
Partial output:
[INFO] Copying artifact [jar:ch.rethab.email:utilities:1.0.0] to
[utilities-1.0.0.jar]
[DEBUG] Skipping artifact [jar:ch.rethab.collections:utilities:1.0.0], as
it is already up to date at [utilities-1.0.0.jar]
On Thu, Feb 13, 2014 at 7:32 PM, Baptiste Mathus <bm...@batmat.net> wrote:
> That's the way to go. Even more if you're able to attach a test project.
> One report without report is far less likely to be worked on.
> Cheers
> Le 13 f�vr. 2014 14:06, "Reto Habl�tzel" <re...@rethab.ch> a �crit :
>
> > So what's the status on this? Shall I create a ticket?
> >
> >
> > On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler
> > <rw...@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 <ma...@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
> > >> <ma...@artifact-software.com>
> > >>
> > >> skype: ronaldmwheeler
> > >> phone: 866-970-2435, ext 102
> > >>
> > >>
> > >>
> > ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >> <ma...@maven.apache.org>
> > >>
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > >> <ma...@maven.apache.org>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Ron Wheeler
> > > President
> > > Artifact Software Inc
> > > email: rwheeler@artifact-software.com
> > > skype: ronaldmwheeler
> > > phone: 866-970-2435, ext 102
> > >
> > >
> >
>
Re: maven-ear-plugin silently overrides libraries
Posted by Baptiste Mathus <bm...@batmat.net>.
That's the way to go. Even more if you're able to attach a test project.
One report without report is far less likely to be worked on.
Cheers
Le 13 févr. 2014 14:06, "Reto Hablützel" <re...@rethab.ch> a écrit :
> So what's the status on this? Shall I create a ticket?
>
>
> On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler
> <rw...@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 <ma...@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
> >> <ma...@artifact-software.com>
> >>
> >> skype: ronaldmwheeler
> >> phone: 866-970-2435, ext 102
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> <ma...@maven.apache.org>
> >>
> >> For additional commands, e-mail: users-help@maven.apache.org
> >> <ma...@maven.apache.org>
> >>
> >>
> >>
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwheeler@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
>
Re: maven-ear-plugin silently overrides libraries
Posted by Reto Hablützel <re...@rethab.ch>.
So what's the status on this? Shall I create a ticket?
On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler
<rw...@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 <ma...@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
>> <ma...@artifact-software.com>
>>
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> <ma...@maven.apache.org>
>>
>> For additional commands, e-mail: users-help@maven.apache.org
>> <ma...@maven.apache.org>
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: maven-ear-plugin silently overrides libraries
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
> <ma...@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
> <ma...@artifact-software.com>
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: maven-ear-plugin silently overrides libraries
Posted by Reto Hablützel <re...@rethab.ch>.
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
<rw...@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
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven-ear-plugin silently overrides libraries
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org