Maven 2 & 3

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
  • Component/s: Artifacts and Repositories, General
  • 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).

Attachments

  1. Text File
    MNG-3151-maven-2.0.x.patch
    15/Aug/07 11:01 PM
    19 kB
    James William Dumay
  2. Text File
    MNG-3151-maven-2.1.x.patch
    23/Aug/07 8:21 PM
    20 kB
    James William Dumay

Issue Links

This issue is depended upon by:
MSOURCES-20 Allow Source plugin to specify alternate DistributionManagement Major Open
MASSEMBLY-231 Allow Assembly plugin to specify alternate DistributionManagement Major Closed
MJAVADOC-142 Allow JavaDoc plugin to specify alternate DistributionManagement Major Closed
MDEPLOY-61 Artifact's getRepository() value used when deploying attached artifacts Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
James William Dumay added a comment -

Adding patch for trunk.

Show
James William Dumay added a comment - Adding patch for trunk.
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.