jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2 & 3
  • MNG-2553

Maven Local Settings Model should allow configuration of distributions (distributionManagement)

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 2.0.4
  • Fix Version/s: None
  • Component/s: Settings
  • Labels:
    None
  • Complexity:
    Intermediate

Description

There is a good use case where this would be very useful.

E.g. I develop a plugin in mojo-sandbox and want to test it in an environment other than the one that I developed it on (e.g. a computer at work). I check out the plugin to this, build and then want to deploy to another repository (e..g a company's internal repository). I don't want to fiddle with the pom.xml of the plugin, just refer to a profile in settings.xml.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Jimisola Laursen added a comment - 07/Sep/06 3:50 PM

I forgot to say that these should of course be a under a profile and hence also exist in profiles.xml.

Show
Jimisola Laursen added a comment - 07/Sep/06 3:50 PM I forgot to say that these should of course be a under a profile and hence also exist in profiles.xml.
Hide
Permalink
Chandra Patni added a comment - 29/Nov/06 7:03 PM

We also have a same repository for all projects. However, we don't want to specify URL in pom.xml. For instance we have some users on Apple/Linux who use file server using a different method.

<distributionManagement>
<repository>
<id>myrepository</id>
<url>file://X:/</url>
</repository>
</distributionManagement>

Show
Chandra Patni added a comment - 29/Nov/06 7:03 PM We also have a same repository for all projects. However, we don't want to specify URL in pom.xml. For instance we have some users on Apple/Linux who use file server using a different method. <distributionManagement> <repository> <id>myrepository</id> <url>file://X:/</url> </repository> </distributionManagement>
Hide
Permalink
Marcos Silva Pereira added a comment - 24/Jan/07 10:15 AM

We also have the same problem here. Solve this problem will be so useful.

Show
Marcos Silva Pereira added a comment - 24/Jan/07 10:15 AM We also have the same problem here. Solve this problem will be so useful.
Hide
Permalink
Brian Fox added a comment - 05/Mar/08 9:19 PM

This can currently be handled using the new deploy plugin's altDeploymentRepository

Show
Brian Fox added a comment - 05/Mar/08 9:19 PM This can currently be handled using the new deploy plugin's altDeploymentRepository
Hide
Permalink
Julien HENRY added a comment - 24/Jul/09 9:21 AM

The hack provided by Brian doesn't work with site deployment location.

On my CI platform I would like to be able to override distributionManagement of all projects whatever is the value in pom.xml.

Show
Julien HENRY added a comment - 24/Jul/09 9:21 AM The hack provided by Brian doesn't work with site deployment location. On my CI platform I would like to be able to override distributionManagement of all projects whatever is the value in pom.xml.
Hide
Permalink
Rogan Creswick added a comment - 27/Aug/09 3:03 PM

We've worked around this by moving the repository details to settings.xml as properties:

<settings>
...
   <profiles>
      <profile>
         ...
         <properties>
            <releases.url>http://10.0.0.20:8081/nexus/content/repositories/releases</releases.url>
            <snapshots.url>http://10.0.0.20:8081/nexus/content/repositories/snapshots</snapshots.url>
          </properties>
      </profile>
      ...
   </profiles>
   ...
</settings>

then, in the pom:

<distributionManagement>
    <snapshotRepository>
      <id>snapshots</id>
      <name>Snapshots</name>
      <url>${snapshots.url}</url>
    </snapshotRepository>
    <repository>
      <id>releases</id>
      <name>Releases</name>
      <url>${releases.url}</url>
    </repository>
  </distributionManagement>

It's not ideal, but at least external users can define those properties in a local settings.xml, or override them in a parent pom (I believe) and maven can still be used for non-deploy tasks even if they aren't defined.

Show
Rogan Creswick added a comment - 27/Aug/09 3:03 PM We've worked around this by moving the repository details to settings.xml as properties:
<settings>
...
   <profiles>
      <profile>
         ...
         <properties>
            <releases.url>http://10.0.0.20:8081/nexus/content/repositories/releases</releases.url>
            <snapshots.url>http://10.0.0.20:8081/nexus/content/repositories/snapshots</snapshots.url>
          </properties>
      </profile>
      ...
   </profiles>
   ...
</settings>
then, in the pom:
<distributionManagement>
    <snapshotRepository>
      <id>snapshots</id>
      <name>Snapshots</name>
      <url>${snapshots.url}</url>
    </snapshotRepository>
    <repository>
      <id>releases</id>
      <name>Releases</name>
      <url>${releases.url}</url>
    </repository>
  </distributionManagement>
It's not ideal, but at least external users can define those properties in a local settings.xml, or override them in a parent pom (I believe) and maven can still be used for non-deploy tasks even if they aren't defined.
Hide
Permalink
Jason van Zyl added a comment - 29/Dec/09 8:02 PM

Use the property scheme we use in our Hudson grid as a best practice.

Show
Jason van Zyl added a comment - 29/Dec/09 8:02 PM Use the property scheme we use in our Hudson grid as a best practice.
Hide
Permalink
Bruno Bieth added a comment - 27/Mar/10 7:05 PM - edited

Would be nice to have more than a vague pointer : "property scheme we use". I suppose I should know who are "we", what "we" build, where "we"'s projects are stored and guessing which version should be appropriate (I guess using the comment date). Eventually I should end up on a pom, which I'll have to go through in order to understand the "best practice".

And BTW why has it been resolved to WON'T FIX ? I believe this is a valid use case and I haven't found any explanation regarding this decision.

Show
Bruno Bieth added a comment - 27/Mar/10 7:05 PM - edited Would be nice to have more than a vague pointer : "property scheme we use". I suppose I should know who are "we", what "we" build, where "we"'s projects are stored and guessing which version should be appropriate (I guess using the comment date). Eventually I should end up on a pom, which I'll have to go through in order to understand the "best practice". And BTW why has it been resolved to WON'T FIX ? I believe this is a valid use case and I haven't found any explanation regarding this decision.
Hide
Permalink
Tom Eugelink added a comment - 05/Jun/10 1:27 AM

It is interesting indeed to see it was marked "Won't fix"; I was just looking for exactly this.
If I can configure in settings.xml a single repository to get stuff from, why can't I configure a single repository to put stuff in?

Show
Tom Eugelink added a comment - 05/Jun/10 1:27 AM It is interesting indeed to see it was marked "Won't fix"; I was just looking for exactly this. If I can configure in settings.xml a single repository to get stuff from, why can't I configure a single repository to put stuff in?
Hide
Permalink
Brian Fox added a comment - 19/Jun/10 6:41 AM

This is simply not how it was designed to work, and there is a perfectly valid use case for this already, that's why it's marked won't fix. If you want to see an example, take a look at the Maven and Apache parent poms: http://svn.apache.org/repos/asf/maven/pom/trunk/

<distributionManagement>
    <!-- Site omitted - each project must provide their own -->
    <repository>
      <id>apache.releases.https</id>
      <name>Apache Release Distribution Repository</name>
      <url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
    </repository>
    <snapshotRepository>
      <id>apache.snapshots.https</id>
      <name>${distMgmtSnapshotsName}</name>
      <url>${distMgmtSnapshotsUrl}</url>
    </snapshotRepository>
  </distributionManagement>
  <properties>
    <distMgmtSnapshotsName>Apache Development Snapshot Repository</distMgmtSnapshotsName>
    <distMgmtSnapshotsUrl>https://repository.apache.org/content/repositories/snapshots</distMgmtSnapshotsUrl>
  </properties>

Here we use a property in the distributionManagement section, and define a default value for the property in the same pom so that it's always complete. However for CI systems, we define a new value for the property in the settings that that overrides the pom. We have done this intentionally only for snapshots in our case as we don't want people to accidentally release somewhere else.

This is what you want to do and it can already be done in the current design.

Show
Brian Fox added a comment - 19/Jun/10 6:41 AM This is simply not how it was designed to work, and there is a perfectly valid use case for this already, that's why it's marked won't fix. If you want to see an example, take a look at the Maven and Apache parent poms: http://svn.apache.org/repos/asf/maven/pom/trunk/
<distributionManagement>
    <!-- Site omitted - each project must provide their own -->
    <repository>
      <id>apache.releases.https</id>
      <name>Apache Release Distribution Repository</name>
      <url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
    </repository>
    <snapshotRepository>
      <id>apache.snapshots.https</id>
      <name>${distMgmtSnapshotsName}</name>
      <url>${distMgmtSnapshotsUrl}</url>
    </snapshotRepository>
  </distributionManagement>
  <properties>
    <distMgmtSnapshotsName>Apache Development Snapshot Repository</distMgmtSnapshotsName>
    <distMgmtSnapshotsUrl>https://repository.apache.org/content/repositories/snapshots</distMgmtSnapshotsUrl>
  </properties>
Here we use a property in the distributionManagement section, and define a default value for the property in the same pom so that it's always complete. However for CI systems, we define a new value for the property in the settings that that overrides the pom. We have done this intentionally only for snapshots in our case as we don't want people to accidentally release somewhere else. This is what you want to do and it can already be done in the current design.

People

  • Assignee:
    Unassigned
    Reporter:
    Jimisola Laursen
Vote (27)
Watch (22)

Dates

  • Created:
    07/Sep/06 3:46 PM
    Updated:
    19/Jun/10 6:41 AM
    Resolved:
    29/Dec/09 8:02 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.