[
http://jira.codehaus.org/browse/MNG-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=184951#action_184951
]
Joerg Schaible commented on MNG-4257:
-------------------------------------
@Brian: Actually there is really an issue with this! Please have a look at all
the discussion regarding naming schemes on commons-dev on what to do about
upcoming commons releases (e.g. like commons-lang-3.0) that will make use of
the JDK 5, improve and optimize API itself and drop all the old deprecated
stuff. Basically we agreed that we will release a version that can be used
side-by-side with a jar from the commons-lang-2.x series (well, we have no real
choice here, the library is used in a lot of deps), but the current naming
scheme will force us to name the next version with something along to
org.apache.commons:commons-lang3:3.x.
> Add the possibility to have 2 dependencies with the same groupId:artifactId
> but not the same version
> ----------------------------------------------------------------------------------------------------
>
> Key: MNG-4257
> URL: http://jira.codehaus.org/browse/MNG-4257
> Project: Maven 2
> Issue Type: New Feature
> Reporter: Alexandre Navarro
> Assignee: Brian Fox
>
> Add the possibility to have 2 dependencies with the same groupId:artifactId
> but not the same version.
> For instance, when you have two versions of a jar with a refactoring of a
> package like dozer 4 and 5.
> In my application, I use dozer 5 but I have a dependency which uses dozer 4.
> As maven considers by default all libs are ascendant compatibility, I don't
> have dozer 4 in my classpath and so my depency does not work.
> It can be useful to force not to resolve some conflict.
> I don't think it is possible to do that with maven.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
