maven tycho load properties file for p2 repo locations - eclipse

Question

I want to have an external properties file with the locations of local p2 mirrors used in build, something like:
mirror.location=/my/mirror/location
I want this to be an external file because I want to use it in maven and also in other scripts and I want to avoid having to duplicate the location in different languages.
I found out that I should use properties-maven-plugin to do that as follows
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>${tycho.version}</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>locations.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
I would then want to use the read property in the repositories url in the same pom file
<repositories>
<repository>
<id>eclipse_mirror</id>
<url>${mirror.location}/eclipse/</url>
<layout>p2</layout>
</repository>
</repositories>
The problem is that Maven/Tycho loads the repositories well before any phase in the lifecycle and prints out this error
[INFO] Computing target platform for MavenProject: ...
[ERROR] Internal error: java.lang.RuntimeException: Invalid repository URL: ${mirror.location}/eclipse/: no protocol: ${mirror.location}/eclipse/ -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: Invalid repository URL: ${mirror.location}/eclipse/
Any clues on how to use a properties file to specify repository urls?

Answer 1

The problem is that Maven/Tycho loads the repositories well before any phase in the lifecycle and prints out this error
This observation is correct. As long as Bug 353889 is not fixed, you cannot use the properties-maven-plugin to manipulate properties whose value Tycho requires during dependency resolution.
That being said, are you aware that you can declare mirrors in Maven’s setting.xml? This is IMHO a better place to declare settings likes mirrors, as you can then ensure that your main build build (as specified in the pom.xml) is self-contained, i.e., doesn't require external knowledge like system properties.
Lastly, note that you can reference environment variables like ${env.HOME} in your settings.xml. If you put your variables in a file and let the shell source it before the mvn invocation, you can re-use that file in other places as well (although it’s not 100% .properties file format).