Cannot update tile.xml with maven-versions-plugins

[drekbour]

I wanted to maven-versions-plugin auto update on the tile.xml ...

mvn -f tile.xml versions:update-properties 

... but find that we cannot do this without adding Maven-mandatory properties ...

    <modelVersion>4.0.0</modelVersion>
    <groupId>boo</groupId>
    <artifactId>yaa</artifactId>
    <version>1.0-SNAPSHOT</version>

... which then need removing because :validate rejects them. As a one-off this is acceptable but I was trying to automate the tiles equivalent of using my.company:internal-bom:pom:LATEST to hold the floating set of last-released <dependencyManagement> across an internal software stack (do tell if there's a more sensible solution here)

Given tiles simply isn't involved in that invocation the only solutions I imagine are:

1 (optionally) make the validation failure into a warning 2 validate a "magic" placeholder GAV used only for such purposes?

(*) this all presumes tiles-only extension syntax is used in tile.xml

[rvowles]

Dependency management isn't done in tiles if that is a question? Only plugin management, we typically use composite poms (poms which contain only dependencies, and which are typically grouped by logical subset, e.g. logging, your web stack, your DI stack, etc).

[drekbour]

Ok. Leaving aside anything relating to dependencyManagement - there's a lot of helpful stuff versions:* can do for us. How can tiles help to apply this when the pertinent content is now in a tile.xml

[talios]

That being said - management of plugins can't AFAIK be handled via the composite model @rvowles uses.

In my own case - we use properties for plugin versions in our tiles, which can be overridden in the consuming project with whatever means you want.

This is the same mechanism used by the kemitix-maven-tiles project ( which uses Github's dependabot ) which you can see an example of here: https://github.com/kemitix/kemitix-maven-tiles/pull/287/commits

[drekbour]

That's quite the workaround. If I understand, the pom.xml has roughly the same content (- <configuration> etc) as tile.xml just so its <properties> can be worked on by versions:update-properties. The tile then uses resource filtering to pick up those properties from the pom.

Functional but ... 2x everything in a library designed for DRY ...

[rvowles]

Yikes. I agree!

[rvowles]

In theory the version update mechanism seems a good one, but the time you are operating on is raw. From our perspective it would only make sense if we pre stripped that section from the pom before merging.

[drekbour]

What about a mojo that merges the tile into itself (likely fairly easy) and then merges changes back into the tile (maybe not so easy)

mvn maven-tiles-plugin:apply-to-self versions:update-properties

Simpler first step might be to limit feedback to only <properties> of the pom.xml (to be used via filtering)