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

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

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>

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

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

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.

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.

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

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.

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?

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.