You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Immo Huneke (JIRA)" <ji...@codehaus.org> on 2009/01/03 16:50:20 UTC
[jira] Created: (MNG-3952) Create Deprecation Mechanism for Maven
Artifacts
Create Deprecation Mechanism for Maven Artifacts
------------------------------------------------
Key: MNG-3952
URL: http://jira.codehaus.org/browse/MNG-3952
Project: Maven 2
Issue Type: Improvement
Components: Artifacts and Repositories, General
Affects Versions: 2.0.9
Environment: All
Reporter: Immo Huneke
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
[jira] Commented: (MNG-3952) Create Deprecation Mechanism for Maven
Artifacts
Posted by "Victor Dolirio Ferreira Barbosa (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261832#action_261832 ]
Victor Dolirio Ferreira Barbosa commented on MNG-3952:
------------------------------------------------------
We have this problem too. Our component repository is in a constant update and sometimes we change groupId and/or artifactId. Somtimes we just want to sign an artifact as deprecated because these turned deprecated. Therefore developers who are using these components sometimes get confused with artifacts that is supposed to not be used.
This mechanism will be very usefull.
[]s
> 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
[jira] (MNG-3952) Create Deprecation Mechanism for Maven Artifacts
Posted by "Tony Aiuto (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297184#comment-297184 ]
Tony Aiuto commented on MNG-3952:
---------------------------------
What maven could use is a concept of marking a previous artifact as "deprecation:LABEL" (e.g. 'obsolete' or 'insecure'). Your build will fail if you depend on anything marked with deprecation, but you may continue to if you explicitly add a notation in your dependency block in the pom that says "<allowDeprectaion>obsolete</...>
That gets people to notice the suggested update on a rebuild, but still allows them to shoot their feet if they insist they know what they are doing.
For the Quartz example above, the library owner could add <deprecation><label>moved</lable><description>Renamed to ... See details at http://opensymphony.org/...</....>. When the build fails, the error should include the deprecation description and then the user can decide their right path.
> Create Deprecation Mechanism for Maven Artifacts
> ------------------------------------------------
>
> Key: MNG-3952
> URL: https://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, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3952) Create Deprecation Mechanism for Maven
Artifacts
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter updated MNG-3952:
------------------------------
Fix Version/s: 3.x
> Create Deprecation Mechanism for Maven Artifacts
> ------------------------------------------------
>
> Key: MNG-3952
> URL: http://jira.codehaus.org/browse/MNG-3952
> Project: Maven 2
> Issue Type: Improvement
> Components: Artifacts and Repositories, General
> Affects Versions: 2.0.9
> Environment: All
> Reporter: Immo Huneke
> Fix 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
[jira] Commented: (MNG-3952) Create Deprecation Mechanism for Maven
Artifacts
Posted by "Travis (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MNG-3952) Create Deprecation Mechanism for Maven
Artifacts
Posted by "Adrian Cole (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269331#action_269331 ]
Adrian Cole commented on MNG-3952:
----------------------------------
in jclouds, we are using artifact ids for libraries bound to cloud provider offerings. they sometimes rename these, so being able to gracefully deprecate a name would be helpful.
ex. org.jclouds.provider/bluelock-vcdirector -> bluelock-vcd-lab
> 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