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.

  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

duplicates

Bug - A problem which impairs or prevents the functions of the product. MNG-3057 properties not expanded in generated POMs when building A/B/C nested projects

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MNG-2971 Variables are not replaced into installed pom file

  • Major - Major loss of function.
  • Reopened - This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.
is related to

Improvement - An improvement or enhancement to an existing feature or task. MNG-624 automatic parent versioning

  • Blocker - Blocks development and/or testing work, production could not run
  • In Progress - This issue is being actively worked on at the moment by the assignee.

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.
Hide
Permalink
Gustavo Chaves added a comment -

Forcing the use of a specific naming convention for properties would force users to change their already chosen property names.

Another approach would be to pass via a parameter the list of properties that should be substituted upon installation.

Show
Gustavo Chaves added a comment - Forcing the use of a specific naming convention for properties would force users to change their already chosen property names. Another approach would be to pass via a parameter the list of properties that should be substituted upon installation.
Hide
Permalink
Ivan Bondarenko added a comment -

Want it too. Currently this can be more or less achieved by maven-resources-plugin in conjunction with 'pomFile' param of maven-install-plugin, but this is very ugly approach.

Btw the same for maven-deploy-plugin. I wonder why these two plugins are not children of one common abstract parent - a lot of logic is just duplicated and issues are the same.

Show
Ivan Bondarenko added a comment - Want it too. Currently this can be more or less achieved by maven-resources-plugin in conjunction with 'pomFile' param of maven-install-plugin, but this is very ugly approach. Btw the same for maven-deploy-plugin. I wonder why these two plugins are not children of one common abstract parent - a lot of logic is just duplicated and issues are the same.

People

  • Assignee:
    Unassigned
    Reporter:
    Stefan Armbruster
Vote (18)
Watch (18)

Dates

  • Created:
    Updated: