Maven
  1. Maven
  2. MNG-3952

Create Deprecation Mechanism for Maven Artifacts

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 2.0.9
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      All
    • 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

        Brett Porter made changes -
        Field Original Value New Value
        Fix Version/s 3.x [ 13145 ]
        Hide
        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
        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
        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
        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.
        Show
        Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
        Hide
        Jason van Zyl added a comment -

        Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

        Show
        Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.
        Jason van Zyl made changes -
        Resolution Incomplete [ 4 ]
        Status Open [ 1 ] Closed [ 6 ]
        Paul Benedict made changes -
        Fix Version/s Issues to be reviewed for 3.x [ 13145 ]
        Hide
        Archimedes Trajano added a comment -

        Maven does have it, but whether central takes advantage of it or not I haven't tested as of yet. To date I haven't found an example of this working.

        http://maven.apache.org/ref/3.2.2/maven-model/maven.html#class_distributionManagement

        relocation

        groupId String The group ID the artifact has moved to.
        artifactId String The new artifact ID of the artifact.
        version String The new version of the artifact.
        message String An additional message to show the user about the move, such as the reason.

        This allows you to redirect to a different groupId/artifactId and version. Though they don't have a specific facility to say "don't even try to use this anymore".

        Show
        Archimedes Trajano added a comment - Maven does have it, but whether central takes advantage of it or not I haven't tested as of yet. To date I haven't found an example of this working. http://maven.apache.org/ref/3.2.2/maven-model/maven.html#class_distributionManagement relocation groupId String The group ID the artifact has moved to. artifactId String The new artifact ID of the artifact. version String The new version of the artifact. message String An additional message to show the user about the move, such as the reason. This allows you to redirect to a different groupId/artifactId and version. Though they don't have a specific facility to say "don't even try to use this anymore".
        Hide
        Archimedes Trajano added a comment -

        I guess I can try to deprecate using the above mechanism my net.trajano.project:java-project since I don't think anyone should use it anymore and see what happens.

        Show
        Archimedes Trajano added a comment - I guess I can try to deprecate using the above mechanism my net.trajano.project:java-project since I don't think anyone should use it anymore and see what happens.

          People

          • Assignee:
            Unassigned
            Reporter:
            Immo Huneke
          • Votes:
            21 Vote for this issue
            Watchers:
            19 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: