Maven
  1. Maven
  2. MNG-3151

Allow plugins that attach artifacts to specify deployment locations

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.8
    • Fix Version/s: None
    • Labels:
      None
    • Number of attachments :
      2

      Description

      The following patch allows plugins to specify Distribution Management relating to their attached artifacts.

      This is useful in large Java shops where, depending on the type of artifact (Javadoc, source, assembly, etc)m you may want to deploy these artifacts to different repositories (eg public and private).

      1. MNG-3151-maven-2.0.x.patch
        19 kB
        James William Dumay
      2. MNG-3151-maven-2.1.x.patch
        20 kB
        James William Dumay

        Issue Links

          Activity

          Hide
          James William Dumay added a comment -

          Patch contains functional implementation of this issue.

          The Artifact setRepository() and getRepository() have had their usage changed so that depending on the context of their use, they are either the ArtifactRepository that they originate from (eg, dependency) or where their destination will be when the Artifact is deployed.

          Show
          James William Dumay added a comment - Patch contains functional implementation of this issue. The Artifact setRepository() and getRepository() have had their usage changed so that depending on the context of their use, they are either the ArtifactRepository that they originate from (eg, dependency) or where their destination will be when the Artifact is deployed.
          Hide
          Brett Porter added a comment -

          I took a look at this yesterday and it seems like the right way to go. Will take another look and apply shortly.

          Show
          Brett Porter added a comment - I took a look at this yesterday and it seems like the right way to go. Will take another look and apply shortly.
          Hide
          Maria Odea Ching added a comment -

          I got test failures from DefaultMavenProjectHelperTest due to NPEs in AttachedArtifact.getVersion() so the patch wasn't applied. Also, the patch needs to be updated to trunk. Thanks!

          Show
          Maria Odea Ching added a comment - I got test failures from DefaultMavenProjectHelperTest due to NPEs in AttachedArtifact.getVersion() so the patch wasn't applied. Also, the patch needs to be updated to trunk. Thanks!
          Hide
          Jason van Zyl added a comment -

          I'm not sure this is really something we want to encourage. Why would you want to separate the javadoc, and sources from the original artifact?

          Show
          Jason van Zyl added a comment - I'm not sure this is really something we want to encourage. Why would you want to separate the javadoc, and sources from the original artifact?
          Hide
          James William Dumay added a comment -

          Adding patch for trunk.

          Show
          James William Dumay added a comment - Adding patch for trunk.
          Hide
          Brett Porter added a comment -

          Not applied following objections on dev@maven.apache.org list.

          If you need this feature, or have a similar use case that could help build a solution - please comment and vote for it.

          Show
          Brett Porter added a comment - Not applied following objections on dev@maven.apache.org list. If you need this feature, or have a similar use case that could help build a solution - please comment and vote for it.
          Hide
          Jason van Zyl added a comment -

          This is just such a bad idea. We can't compensate for poor internal infrastructure. It's easy to separate logical views using Apache rewrite rules, or a repository manager. I doubt anyone will convince me this is a actually a good idea. How, for example, would the IDE integration get the sources or javadocs for a particular artifact if these were all deployed in different locations? Then this would involve yet another mapping to unify all the attached artifacts. It's just a rat hole. -1.

          Show
          Jason van Zyl added a comment - This is just such a bad idea. We can't compensate for poor internal infrastructure. It's easy to separate logical views using Apache rewrite rules, or a repository manager. I doubt anyone will convince me this is a actually a good idea. How, for example, would the IDE integration get the sources or javadocs for a particular artifact if these were all deployed in different locations? Then this would involve yet another mapping to unify all the attached artifacts. It's just a rat hole. -1.
          Hide
          Foo Fers added a comment -

          Get off your high horse van Zyl and stop spruking Nexus in this forum.

          Show
          Foo Fers added a comment - Get off your high horse van Zyl and stop spruking Nexus in this forum.
          Hide
          Jason van Zyl added a comment -

          Has nothing to do with Nexus really, the idea is just flawed because it creates a disconnection between primary artifact and its secondary artifacts. But this is a perfect case where an organization that has a requirement for this can maintain these patches themselves and then the support costs are where they belong. These patches are really not generally useful.

          This feature being implemented generally would be generally harmful. This will not be implemented in Maven, at least in this form, as it doesn't provide a working solution for client code to function in the same way that it does now. These patches handle the the case for the deployment but says nothing about the consumption especially where all IDE integration and many IDE related plugins rely on being able to calculate the location of secondary artifacts based on the primary artifact.

          Show
          Jason van Zyl added a comment - Has nothing to do with Nexus really, the idea is just flawed because it creates a disconnection between primary artifact and its secondary artifacts. But this is a perfect case where an organization that has a requirement for this can maintain these patches themselves and then the support costs are where they belong. These patches are really not generally useful. This feature being implemented generally would be generally harmful. This will not be implemented in Maven, at least in this form, as it doesn't provide a working solution for client code to function in the same way that it does now. These patches handle the the case for the deployment but says nothing about the consumption especially where all IDE integration and many IDE related plugins rely on being able to calculate the location of secondary artifacts based on the primary artifact.

            People

            • Assignee:
              Unassigned
              Reporter:
              James William Dumay
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: