[#MINSTALL-50] provide property filtering on .pom files placed in local repo - jira.codehaus.org

Maven 2.x Install Plugin

provide property filtering on .pom files placed in local repo

Created: 03/Mar/08 07:53 AM Updated: 04/Jun/09 02:15 AM

Component/s:

install:install

Affects Version/s:

2.3

Fix Version/s:

None

Time Tracking:

Not Specified

File Attachments:

MNG-maven-install.patch (12 kB)
2.

MNG-maven-install.patch (11 kB)

Environment:

independent

Issue Links:

Duplicate

This issue duplicates:

~~MNG-3057~~ properties not expanded in generated POMs when building A/B/C nested projects

Related

This issue is related to:

MNG-624 automatic parent versioning

dependent

This issue is depended upon by:

MNG-2971 Variables are not replaced into installed pom file

Testcase included:	yes
Patch Submitted:	Yes

Description

« Hide

When maven installs an artifact, it's pom is also copied into the artifact's directory. Unfortunately, if the pom contains a property reference (e.g. ${myprop}), this will not be replaced upon copying the pom file.
I've created a patch for the install plugin that switches on property filtering by setting a mojo parameter "filteringEnabled". Since this defaults to "false", backward compatibility is kept 100%.

Some implementation notes:

the dirty work is done in FilteredProjectArtifactMetadata.java, the property resolution code has been inspired by ResourcesMojo.
I've added a unit test, that replaces ${basedir} with the value of a system property.
since "svn diff" does not handle binary files, src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar is not included in the patch. This file is the same as
src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar

Since my knowledge of Maven API is more than limited, there might be a more elegant way to provide this feature ... but it works! I'd be happy to see this in a future release of maven.

Sort Order:

[ Permalink | « Hide ]

Samuel Vetsch added a comment - 18/Apr/08 02:48 AM - edited

Is there a reason why you do not apply this filtering to artifacts of type "pom" ?

[ Permalink | « Hide ]

Stefan Armbruster added a comment - 21/Apr/08 02:39 AM

No, filtering type "pom" was not necessary for my use case. That's why I missed this one. Feel free to change it.

[ Permalink | « Hide ]

Stefan Armbruster added a comment - 19/May/08 08:13 AM - edited

Uploaded a updated version of patch, please use only the latest one. Following Samuel's request, property resolution also occurs in pom-type artifacts.

[ Permalink | « Hide ]

Henrik Brautaset Aronsen added a comment - 19/Aug/08 02:21 AM

~~MNG-3057~~ also has a patch for this issue. And it's being worked on in MNG-624.

[ Permalink | « Hide ]

Oumar Aziz OUATTARA added a comment - 04/Jun/09 02:15 AM

Hi,

I would like to see this feature implemented in Maven. However, the request doesn't take into account one use case that I am having.
It's valid to want to have some properties not filtered in a pom.xml , while having some others filtered.
You can imagine that in the same file, I would like to use a property called ${java.home} and another one called '${my.version}'

* ${my.version} is to be set when publishing the artifact.
* ${java.home} is platform dependent. so I don't want to set it to a static value.

So my guess is, there should be a way to distinguish properties that we want to change when publishing from the others. We can use for that a naming scheme. Let's say that :

for backward compatibility, everything that is of the form '\${[a-zA-Z0-9\._-]+}' is a property that we don't want to filter
and '\${m2filtered.[a-zA-Z0-9_-]+}' is a property that we want to change.

But this could create a regression on some projects which named their properties with the chosen prefix.

Another option would be to define a new naming of properties like '#{[a-zA-Z0-9\._-]+}' that would be filtered. But I guess, this would impact a lot more than install and deploy plugins. It would be more maven-core.