Open CarstenWickner opened 2 years ago
Just following up on this as I seem to have missed it. Looking at the chain of the code the relative path is preserved in the Parent
model class, and we're just reusing that instance when we reattach it to the end of the inheritance chain - so this should work.
I wonder if removing the <version>1.0</version>
from your parent declaration makes any difference - it may be that Maven is taking the version number in preference, and looking it up in a remote/local repository as it's not in any reactor?
I'll pull those two pom's out into a CI test to add into the project and give it a try in the morning.
I have added a bit of extra logging there to cover/document the relative path in the mean time as part of testing:
[INFO] --- tiles-maven-plugin: Injecting 1 tiles as intermediary parent artifacts for com.test:civersion-tiletest-ciparent...
[INFO] Mixed 'com.test:civersion-tiletest-ciparent:0.1.0-SNAPSHOT' with tile 'com.test:civersion-tiletest-tile2:1' as its new parent.
[INFO] Mixed 'com.test:civersion-tiletest-tile2:1' with original parent 'com.test:civersion-tiletest-parent3:0.1.0-SNAPSHOT' via ../parent3/pom.xml as its new top level parent.
We have separated one of our projects into two
pom.xml
files and make use of the<parent>/<relativePath>
property.A simple but technical "main"
pom.xml
, that is properly versioned and checked-in:a local parent POM (which is auto-generated in the CI process), containing all the things we want to include in the
war
artifact:When running a local build, one ends up with:
In our CI environment, we workaround this issue by first installing the parent POM locally before running the main build:
In a local IDE/build scenario, this extra step is a hassle. Is there a way to respect the parent's
<relativePath>
instead of attempting to take it from the (possibly outdated) local/remote repository?