Maven 2.x Install Plugin

provide property filtering on .pom files placed in local repo

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.3
  • Fix Version/s: None
  • Component/s: install:install
  • Labels:
    None
  • Environment:
    independent
  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    2

Description

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.

Attachments

  1. Text File
    MNG-maven-install.patch
    19/May/08 8:13 AM
    12 kB
    Stefan Armbruster
  2. Text File
    MNG-maven-install.patch
    03/Mar/08 7:53 AM
    11 kB
    Stefan Armbruster

Issue Links

This issue duplicates:
MNG-3057 properties not expanded in generated POMs when building A/B/C nested projects Major Closed
This issue is related to:
MNG-624 automatic parent versioning Blocker In Progress
This issue is depended upon by:
MNG-2971 Variables are not replaced into installed pom file Major Reopened

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Samuel Vetsch added a comment - - edited

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

Show
Samuel Vetsch added a comment - - edited Is there a reason why you do not apply this filtering to artifacts of type "pom" ?
Hide
Permalink
Stefan Armbruster added a comment -

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

Show
Stefan Armbruster added a comment - No, filtering type "pom" was not necessary for my use case. That's why I missed this one. Feel free to change it.
Hide
Permalink
Stefan Armbruster added a comment - - 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.

Show
Stefan Armbruster added a comment - - 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.
Hide
Permalink
Henrik Brautaset Aronsen added a comment -

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

Show
Henrik Brautaset Aronsen added a comment - MNG-3057 also has a patch for this issue. And it's being worked on in MNG-624.
Hide
Permalink
Oumar Aziz OUATTARA added a comment -

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.

Show
Oumar Aziz OUATTARA added a comment - 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.
Hide
Permalink
Marla Bonar added a comment -

Instead of something like '\${m2filtered.[a-zA-Z0-9_-]+}', you could do something along the lines of the existing ${somevar} syntax works as is, but $${somevar} signals that "somevar" needs to be resolved.

Show
Marla Bonar added a comment - Instead of something like '\${m2filtered.[a-zA-Z0-9_-]+}', you could do something along the lines of the existing ${somevar} syntax works as is, but $${somevar} signals that "somevar" needs to be resolved.

People

Vote (10)
Watch (12)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.