${project.parent.groupId} resolution doesn't work

[skingsland]

Let's say you have a pom who's parent pom's groupId is com.a, and you're using a tile with a different groupId, e.g. com.b:

<tile>com.b:my-tile:1.0</tile>

Maven tiles is smart enough to make sure the project's groupId is set correctly, so ${project.groupId} will be resolved to com.a. However it doesn't do this for the parent project's groupId, so ${project.parent.groupId} resolves to the tile's groupId instead of the parent pom's groupId.

Here's an example to illustrate this:

    <parent>
        <!-- This parent pom groupId is what I'd expect to be returned from ${project.parent.groupId} -->
        <groupId>com.a</groupId>
        <artifactId>my-parent</artifactId>
        <version>1.0</version>
    </parent>

    <artifactId>my-child</artifactId>
    <version>1.0</version>

    <build>
        <plugins>
            <plugin>
                <groupId>io.repaint.maven</groupId>
                <artifactId>tiles-maven-plugin</artifactId>
                <version>2.15</version>
                <extensions>true</extensions>
                <configuration>
                    <tiles>
                        <!-- note that this groupId is different from the pom's parent groupId -->
                        <tile>com.b:my-tile:1.0</tile>
                    </tiles>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <dependency>
            <!-- This is the bug; maven resolves this variable to the *tile's* groupId, i.e. "com.b", and not the parent pom's groupId of "com.a" -->
            <groupId>${project.parent.groupId}</groupId>
            <artifactId>another-child</artifactId>
            <version>1.0</version>
        </dependency>
    </dependencies>

[talios]

On 4 Jul 2019, at 2:38, Steve Kingsland wrote: Maven tiles is smart enough to make sure the project's `groupId` is [set correctly](<https://github.com/repaint-io/maven-tiles/blob/70ccc6aba28d98cf40a567d7e77ab0c0a5b4c82d/src/main/groovy/io/repaint/maven/tiles/TilesMavenLifecycleParticipant.groovy#L607>), so `${project.groupId}`will be resolved to `com.a`.  _However_  it doesn't do this for the parent project's groupId, so `${project.parent.groupId}` resolves to the tile's parent groupId instead of the parent pom's groupId.

Tiles is (currently) only filling in the groupId/version in the current projects model to that of a declared parent *when absent*, which is why `project.groupId` actually has a value. The way tiles works is by injecting parents, so `project.parent.groupId` as a property reflects the shape of the model. We _could_ tho set some additional properties for things like `tiledProject.parent.groupId`, `tiledProject.parent.artifact`, and `tiledProject.parent.version`. Maybe...

…

--- "The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." &mdash; Mark Reinhold. Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt

[skingsland]

We could tho set some additional properties for things like tiledProject.parent.groupId, tiledProject.parent.artifact, and tiledProject.parent.version.

Do you see any downside (regression risk, added complexity, etc.) to doing this, or is it just having the time to make the code change? (which is mostly adding/updating tests, I'm guessing?)