[
http://jira.codehaus.org/browse/MNG-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231838#action_231838
]
Travis commented on MNG-3952:
-----------------------------
This has been quite a problem for us. We end using the maven-enforcer-plugin
to globally ban "deprecated" dependencies or group ids. An example is quartz.
Quartz's group id used to be "quartz", then was changed to "opensymphony" and
again was changed to "org.opensymphony.quartz" and is currently
"org.quartz-scheduler". Using an old dependency because a group id/artifact id
is just one problem. An even more hideous problem is when maven resolves
multiples of the same artifact because an artifact's group id has changed. The
old groupid & new groupid may be both be transitive dependencies. Along with
deprecation, maven should have some concept of synonym dependencies where maven
wont think that renames are completely different things. Also, it would be
good if the central repository could set forth some rules about uploading
artifacts that depend on deprecated artifacts - possibly not allowing it, or at
least discouraging it.
Here is a small snippet from our enforcer configuration that highlights the
problem:
<!-- renamed (decrecated) groupids -->
<exclude>struts</exclude>
<exclude>wss4j</exclude>
<exclude>acegisecurity</exclude>
<exclude>xstream</exclude>
<exclude>uk.ltd.getahead</exclude>
<exclude>jdom</exclude>
<exclude>groovy</exclude>
<exclude>bouncycastle</exclude>
<exclude>quartz</exclude>
<exclude>org.opensymphony.quartz</exclude>
<exclude>opensymphony:quartz</exclude>
Synonym dependencies could be taken a step further where multiple
implementations exist for the same api. Think genronimo servlet versus
javax.servlet or commons-logging versus jcl-over-slf4j. If maven had a way to
track synonym dependencies then at the very least spit out warnings like:
Warning: javax.servlet:servlet-api:2.5:jar and
org.apache.geronimo.specs:geronimo-servlet_2.5_spec:1.2:jar are both found at
compile scope but only one is needed.
Any thoughts?
> Create Deprecation Mechanism for Maven Artifacts
> ------------------------------------------------
>
> Key: MNG-3952
> URL: http://jira.codehaus.org/browse/MNG-3952
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories, General
> Affects Versions: 2.0.9
> Environment: All
> Reporter: Immo Huneke
> Fix For: Issues to be reviewed for 3.x
>
>
> An example of the sort of problem that developers currently encounter can be
> seen at
> http://blog.jonasbandi.net/2008/12/using-jpa-and-hibernate-with-maven.html. I
> have encountered similar problems in the past, e.g. trying to decide which
> version of a plugin is the current one or being unaware that an artifact I
> was using in a build had been superseded by another with a different groupId
> and artifactId.
> I feel that Maven lacks a deprecation mechanism that would make it obvious to
> everyone that they're using something out of date. The problem is that once
> an artifact (other than a snapshot) has been published, it is never supposed
> to change thereafter. But it shouldn't be impossible to devise a mechanism
> for adding deprecation and redirection to the associated metadata. It would
> then be possible for the dependency resolver to display a warning whenever a
> deprecated artifact was used in a build, either as a plugin or as a library.
--
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
