The plugin Steven mentioned works better than anything I've seen for finding duplicates. All the Maven plugins that came originally from Ning and moved into Basepom are of good quality. It's not often I say something is good.
On Jan 20, 2015, at 8:19 AM, Curtis Rueden <[email protected]> wrote: > Hi Kevin, > >> The main situation I see is when the artifact and group ID differ … > > The Maven Enforcer Plugin is the "first party" plugin solution. The rule > you want, banDuplicateClasses, is part of the Mojo project's Extra Enforcer > Rules: > > http://mojo.codehaus.org/extra-enforcer-rules/banDuplicateClasses.html > > Regards, > Curtis > > On Mon, Jan 19, 2015 at 8:37 PM, Steven Schlansker < > [email protected]> wrote: > >> This is exactly the situation that the plugin I referenced resolves :) >> https://github.com/basepom/duplicate-finder-maven-plugin >> >> On Jan 19, 2015, at 8:47 AM, Adrien Rivard <[email protected]> >> wrote: >> >>> Then you need to explicitely exclude one of them. Eclipse can help for >> that >>> via the pom editor in the dependency Hierarchy tab. >>> >>> On Mon, Jan 19, 2015 at 9:24 AM, Kevin Burton <[email protected]> >> wrote: >>> >>>> The main situation I see is when the artifact and group ID differ … >>>> >>>> so an older version of jdom used just jdom and the newer version used >>>> org.jdom and then I ended up with both :) >>>> >>>> On Sun, Jan 18, 2015 at 10:31 PM, Adrien Rivard < >> [email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> if youre artifacts have the same artifactId/groupId/type/classifier it >>>>> should'nt happen,Maven should pick only one of the two. If one of >>>>> the artifactId/groupId/type/classifier is not the same, it could happen >>>>> because it's not the same jar for maven. >>>>> >>>>> >>>>> On Mon, Jan 19, 2015 at 4:32 AM, Steven Schlansker < >>>>> [email protected]> wrote: >>>>> >>>>>> Check out >>>>>> https://github.com/basepom/duplicate-finder-maven-plugin >>>>>> >>>>>> On Jan 18, 2015, at 6:12 PM, Kevin Burton <[email protected]> wrote: >>>>>> >>>>>>> It looks like I’ve accidentally ended up in a situation where I have >>>>>>> duplicate class names in separate .jars with different versions. >>>>>>> >>>>>>> So I’ll have Foo.class in foo-1.0.0.jar and foo-3.0.0.jar … >>>>>>> >>>>>>> Shouldn’t Maven fail in this scenario? IE assert that you have >>>>>> conflicting >>>>>>> dependencies and that you should resolve them by hand. >>>>>>> >>>>>>> This usually happens with two projects (usually an older one) depends >>>>> on >>>>>> an >>>>>>> older version of a library. >>>>>>> >>>>>>> I may be foolishly using a few older libs which, while stable, don’t >>>>>> really >>>>>>> work with some of their more modern dependencies. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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> >>>>>>> <http://spinn3r.com> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Adrien Rivard >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> 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> >>>> <http://spinn3r.com> >>>> >>> >>> >>> >>> -- >>> Adrien Rivard >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
