maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (MNG-3952) Create Deprecation Mechanism for Maven Artifacts
Date Thu, 12 Aug 2010 18:26:32 GMT

    [ 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

        

Mime
View raw message