Possibility to just flatten CI-friendly properties?

[Antibrumm]

Hi

I just found the flatten plugin while trying to adapt the CI-friendly versioning approach. As the maven project we are building is supposed to be used as a library I will have to flatten the version before installing the pom(s). So i tried to integrate the flatten-plugin and, if I did not miss something, there is no possibility to limit the properties that should be flattened. Is this correct?

From what I was able to understand and achieve I saw that all properties are flattened and several cleanup processes ran. I'm searching for a solution where we can fix the versions of the project for redistribution but keep intact any other dynamic resolutions.

Namely only the revision property:

<version>1.0.0.${revision}</version>

But ignoring other dependency versions like:

<properties><spring-version>4.3.6</spring-version></properties>

I think this makes more sense for the case Continuous Deployment, efficiently replacing the maven-release-plugin.

Is this already possible or is there any plan to bring such a feature?

[pavel-hp]

I think if maven started follow this way (support dynamic properties in version) they have to complete their solution within deploy properly pom.xml (with version replacement) to repository.

[khmarbaise]

The idea of the flatten plugin in this case is to create a final consumer pom which has no properties at all and can be used directly and there should be not left any kind of build information. The properties are a kind of information from the build time.

@Antibrumm Maybe you can give an example project and describe what you like to have ? Maybe I misunderstand a thing here...

[Antibrumm]

Hi, thanks for the comments.

Basically I came from the Maven CI Friendly Versioning page here: https://maven.apache.org/maven-ci-friendly.html

They finally "allow" certain variables inside the <version> tag, i.e. maven is not logging warnings anymore and it seems to be an acceptable solution.

They explicitly mention the flatten-maven-plugin, so I tried that approach.
First I've tried to just use the ${revision} without flattening. The result is that the pom.xml is deployed as-is into the maven repository. The version is still a variable. So, only using the revision variable by itself renders the deployed pom useless for any further use.
Then I've added the flatten plugin and, yes!, the version is now correct. But, no!, all other properties have been flattened :)

Let's imagine a library like Spring(-boot). After a release the final pom should contain the given version in the <parent> section and on itself, but other included libraries should not be flattened. (Tell me if that's not clear)

I understand that the initial idea of the flatten plugin is to fully inline properties, but probably there could be another goal, ci-flatten, to just touch the three special variables? ${revision}, ${sha} and ${changelist}. At least that was my first thought.
You could even go further and include/exclude properties to flatten.

I have now managed to do something using my copy-maven-plugin and a groovy-script, but If i could do this with one plugin that would be awesome.

The advantage of the flatten-maven-plugin is that this works in a single build-cycle. In my case I checkout, run maven -Pprepare-ci-release to transform the poms and the launch maven deploy scm:tag, and finally drop the workspace.

[michaeltecourt]

Our use case is not to create a final consumer pom which has no properties at all, it is to fix a broken Maven feature. IDK why the maven folks left that feature half-baked, allowing us to deploy broken POMs.

[lasselindqvist]

I have a fix (a new flattenMode called flattenVersionOnly) for this and will contribute the changes as a pull request hopefully soon.

[lasselindqvist]

The pull request related to this can be found here: #74
Please let me know if I should change it to follow some specific format.

[hohwille]

resolved with PR #77 that has been merged.

[hohwille]

This has been released, but it is not working properly (e.g. parent version not resolved) nor documented. Seems I was too optimistic in my review when merging #77.

[lasselindqvist]

This has been released, but it is not working properly (e.g. parent version not resolved) nor documented. Seems I was too optimistic in my review when merging #77.

The issues mentioned should mostly be the same as they are in other modes. Things like problems with resolving when using profiles, dependency management sections and command line vs. properties variable definitions.