Allow artifact aliases
----------------------
Key: MNG-3058
URL: http://jira.codehaus.org/browse/MNG-3058
Project: Maven 2
Issue Type: New Feature
Components: POM
Reporter: Dimitry Voytenko
The unfortunate fact is that there's a number of different artifacts that
essentially mean the same thing.
For instance:
- javax.servlet:jsp-api vs javax.servlet.jsp:jsp-api
- commons-logging:commons-logging vs commons-logging:commons-logging-api
The number of such artifacts is only growing, increasing the ambiguity.
One way to deal with this situations could be by introducing "aliases" for
artifacts. This would be a way to tell Maven that two artifacts basically mean
the same thing. Such an alias-artifact could be deployed in the entierprise
repository to help resolve ambiguities within a single workshop.
For instance, we've been using "berkeleydb:je" artifact for some time, but now,
since acquisition by Oracle, some tool vendors use
"com.sleepycat.berkleydb:bdbje" and other names. These, in turn, mean the same
thing, but from the Maven's standpoint they're completely different, so if one
library referred to "berkeleydb:je:2.1.30" and the other referred to
"com.sleepycat.berkleydb:bdbje:3.1.0" the WAR (for instance) will endup with
two jars "je_2_1_30.jar" and "bdbje_3_1_0.jar", and further which of this will
be used is unknown. Here, if there was a way to specify that
com.sleepycat.berkleydb:bdbje == berkeleydb:je, Maven would simply pick
whichever has a higher version, thus removing the ambiguity w/o manual
intervention.
I understand, this could somewhat complicate current Maven's artifact
resolution (which was perfectly simple so far), but it could also help to deal
with mounting addressing issues.
--
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
