Maven 2 & 3

Create Deprecation Mechanism for Maven Artifacts

Details

  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

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.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Travis added a comment -

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?

Show
Travis added a comment - 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?
Hide
Permalink
Victor Dolirio Ferreira Barbosa added a comment -

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

Show
Victor Dolirio Ferreira Barbosa added a comment - 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
Hide
Permalink
Adrian Cole added a comment -

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

Show
Adrian Cole added a comment - 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
Hide
Permalink
Tony Aiuto added a comment -

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.

Show
Tony Aiuto added a comment - 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.

People

  • Assignee:
    Unassigned
    Reporter:
    Immo Huneke
Vote (19)
Watch (16)

Dates

  • Created:
    Updated: