Provide documentation for transition from traditional multi-module build

[udalrich]

I have several times looked at using tiles, and then backed away because I was not certain how to transition the existing code.

We have a multi-module build with the traditional (I think) style. At the root is a pom which has many pluginManagement, dependencyManagement, module and profile elements. Intermediate levels have poms which are modules and profiles. At the leaf levels, the poms contain dependency and plugin elements.

There are for me two questions that it would be useful to have answered in the documentation.

1. Is a partial conversion possible? In several projects, running the integration tests involves extracting configuration files from a common location, starting docker containers and then modifying the configuration files to use the docker containers. That is complicated code which currently is duplicated in each project that needs it. It seems a partial conversion that uses a tile(s?) would simplify that, without forcing us to decide to buy in completely to the tile philosophy. (Incremental changes are easier to gain approval for than wholesale rewrites of something that works.)

2. How does on convert an existing multi-module build to use tiles? With dependencyManagement and pluginManagement in the root pom, it is easy to ensure that consistent versions and configurations are used throughout. If I am using a single plugin in three different ways, how do I do that? Do I create a tile that just defines the plugin version, and then three tiles that include that tile and add configuration? Do various properties that are now defined in the root pom stay there, or get moved to a properties tile, or spread among many other tiles? Two sample projects, one before conversion and one after, would be useful, especially if they were complicated enough to be non-trivial and address issues like multiple different uses of a plugin.

[rvowles]

I'll try to address a couple of these issues:

(a) take your dependencies out and put them into pom's that just have dependencies in them. For example - we have composite-logging, composite-jackson, composite-cxf. Then on top of those you can compose combinations if you like - we have a composite-microservice for dependencies we group together to form a basic microservice. Then depend on those instead of representing them in your projects - your projects get composed dependencies that are consistent (like dependencyManagement) and easily identified and upgraded as groups. They also get turned into smaller chunks so only the things that should be in a project are in the project.
(b) if you are doing CD, and use only snapshot versions, changing your composite changes all users of that composite. If you are using releases, use version ranges (always start from 1.1)
(c) Tiles are specific configurations of a plugin, so each tile can define a different plugin and you can bring in many tiles.
(d) if you are using variables to define your versions of things, they are always resolved before tiles kicks in, which is a weirdly annoying part of Maven's lifecycle. Those you have to put in a parent, it is the only remaining thing that requires "inheritance".

[pimsierhuis]

I'm also still struggling with this and the reasoning behind the "Usage of maven-tiles prohibited from multi-module builds where reactor is used as parent."-error.

Let me give my case as an example to clarify. I'm using CI-friendly version numbers, so I need the flatten maven plugin. This would add 20+ lines to the parent-poms of all my projects. So therefore I would like to use a tile with this definition. Given the multi-module restriction, it's impossible to use this tile in my parent-pom and let all modules inherit the plugin-definition from it. So in my understanding, this would require adding the tile individually to all modules, which gives even more redundancy.

Therefore my question is: Can you clarify this rule further (I've read the README and the comment in the code) and is there a way to not have the tile-plugin redundantly in every module but still have some common plugins in all modules?