maven multi-modules flat project layout not covered by jgitver-maven-plugin

[ebouladier]

1.7.1:

Maven allows flat project structure layout to organize multi-modules projects directories.
In our case, we have all projects directories at the root of the git repository without nesting :

• git workdir
  • bom (declare external dependencies versions)
  • aggregator (declaring modules, used for global build on the developer local machine)
  • parent project (importing bom project, share maven configuration for all other projects)
  • project 1
  • project i ( having parent project as parent, potentially referencing sibling projects)
  • project n

We have several big and old developments that are structured this way, containing tenths of maven projects.

As far as I can understand, the jgitver-maven-plugin uses directory tree structure to identify projects that have to be managed with the calculated version. This approach supposes that the "aggregator" project directory (called multiModuleDirectory in the code) is an ancestor directory of all other projects which version is to be managed by the jgitver plugin.
This is not compatible with the flat directory layout where all projects directories are sibling directories.

Am I wrong saying : given that the goal of this plugin is to calculate a version code, based on the state of the git repository, only projects that are managed in this git repository are eligible to be impacted by the process, whatever is the directory structure of all these projects.
If this assumption is valid, do you think that a more suitable strategy could be implemented to identify projects which version must be managed by the plugin ?

Thank you for your answer and for the work already done.

[McFoggy]

Hello Eric,

jgitver indeed is intended to manage version for projects that share the same version once it is computed from the gitlog.

can you explain in your example how you would expect the versions to be computed for which projects?
how do you release all those projects if they are not fully linked?

[ebouladier]

Hi Matthieu,

All these projects are released in several deliverable artifacts, at a same moment, and sharing a same version. I'm not sure to well understand what you mean by being "fully" linked. There are linked, but it's not related to the way project directories structure is organized. I explain below a strategy that could fulfill our use case, regardless of how we could implement it (I'm working on it). The goal is to eliminate usage of relative positions of projects in the directory structure. I hope to be clear enough.

The principle is: as the calls of the ModelProcessor, we enrich a list of artifacts (groupId, artifactId) which version has to be replaced by the calculated one, and which pom file has to be processed when ModelProcessor is called for it.
Starting from the first pom file being processed, always added to the list, we complete this list with potential other pom's files that has to be processed :
• All pom defined as modules must be processed,
• If a parent definition exists, the pom, corresponding to the defined parent, must be processed only if the project pom and the parent definition are enforced to use a same version. This is the case when the project version is inherited from the parent (project version is not defined), or if both use the same variable, or if parent definition uses ${project.version}.
• Defined dependencies in the processed pom are evaluated the same way has the defined parent. A dependency must be processed if it is enforced that it uses the same version as the project itself.

At the time of the ModelProcessor is called for a pom file, this pom file is processed only if it already belongs to the list. It is assumed that the pom that is passed to the first call of the ModelProcessor is always processed.
Processing a pom means to make the same process as the one described above.

For more exotics use case, I would pass, as a configuration parameter, a list of artifacts that must be processed but cannot be automatically determined by this strategy.

One disadvantage of this approach is that it can exist some situations for which projects must be well ordered in the modules declaration to let the system correctly works. Indeed, the ModelProcessor is called in the order of modules declaration and it's mandatory to process referenced project before projects that reference them.
This could be addressed using the configuration parameter.

Of course, all your comments are welcome, in particular about the feasibility and consistency issue with other real use cases.
I'm going to try to implement this. Let me know if from your opinion this could be of some interest as an optional strategy to the current one.