Reputation: 8606
So I have something like:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-1</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-properties</goal>
</goals>
<configuration>
<files>
<file>${user.home}/build.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
and I have distributionManagement
like:
<distributionManagement>
<repository>
<id>local-repo</id>
<url>file:///${deploy.dir}/${project.artifactId}</url>
</repository>
</distributionManagement>
I don't have a remote repository, that is why I am doing it using file:///
${deploy.dir}
is a property from the build.properties
file and it will not take the value for that property.
Why?
Upvotes: 3
Views: 6515
Reputation: 14951
Mark's answer is probably the way to go, and is what I'm doing to switch between our production and test instances of our remote repository. Per a discussion I found it sounds like you can load properties for use in later plugin configurations, but core maven model elements like <distributionManagement>
only have properties interpreted on initial load of the POM.
(Moving comment to answer per OP request.)
Upvotes: 2
Reputation: 77971
I'd suggest using build profiles to manage multiple distribution targets. For example:
<profiles>
<profile>
<id>repo1</id>
<distributionManagement>
<repository>
<id>repo1-release</id>
<url>http://.......</url>
</repository>
</distributionManagement>
</profile>
<profile>
<id>repo2</id>
<distributionManagement>
<repository>
<id>repo2-release</id>
<url>http://.......</url>
</repository>
</distributionManagement>
</profile>
..
</profiles>
When calling the deploy goal you can choose the destination by activating the profile:
mvn -Prepo1 clean deploy
Upvotes: 5