Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] Maven moving to the next level: the build/consumer pom


On 25-6-2020 02:03:42, Anton Vodonosov <avodonosov@xxxxxxxxx> wrote:

Can this work also allow arbitrary property _expression_ in a module ?
Robert Scholte:
Currently only the ci-friendly version placeholders are supported.


Currently, this practice is discouraged because the deployed pom with property
_expression_ is meaningless.
The flatten-maven-plugin can produce correct poms for deployment,
with all properties resolved; despite maven prints the hardcoded warning
"'version' contains an _expression_ but should be a constant".
Robert Scholte: 
The statement is still that versions should be constants and not expressions. It is likely that this is one of the next things that will be implemented.
This announcement is especially for tools needing to read the new local pom.xml
There's a small set of features added, so they can investigate if it works.
It would be a huge waste of time if we discover that the current implementation makes it impossible for IDEs to embed Maven.


Links on the topic:
http://mail-archives.apache.org/mod_mbox/maven-users/201201.mbox/%3CCA+nPnMyb_W4Ldrg5zTn5NX3F2kcrPXDefS4gjzz3OE0cUy1rXw@xxxxxxxxxxxxxx%3E
https://issues.apache.org/jira/browse/MNG-4715
https://stackoverflow.com/questions/19123013/maven-version-with-a-property/19123130

Why I'm interested in property expressions for versions is because I want to generate
versions automatically as a hash code of all sources and dependencies.

And also skip building of modules whose has-version has not changed.

That way the large multi-module project can vary significantly improve build speed
and reduce the artifact storage consumption. Similar to what build caches
give for gradle and bazel, only a bit simplified, less granular - caching done
on the level of final artifacts, but not for intermediate outputs
(compiled file, generated resources).

If would be very convenient if maven-flatten-plugin become unnecessary
and maven supported property expressions in version spec out of box.
Robert Scholte:
The flatten-maven-plugin was written because there was a direct need for manipulating poms that could not be solved easily inside Maven itself.
This is one step into the right direction.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx


Back to the top