Maven Install Plugin
  1. Maven Install Plugin
  2. MINSTALL-50

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. MNG-maven-install.patch
        12 kB
        Stefan Armbruster
      2. MNG-maven-install.patch
        11 kB
        Stefan Armbruster

        Issue Links

          Activity

          Samuel Vetsch made changes -
          Field Original Value New Value
          Link This issue is depended upon by MNG-2971 [ MNG-2971 ]
          Hide
          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
          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
          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.
          Stefan Armbruster made changes -
          Attachment MNG-maven-install.patch [ 34617 ]
          Henrik Brautaset Aronsen made changes -
          Link This issue is related to MNG-624 [ MNG-624 ]
          Hide
          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 .
          Benjamin Bentmann made changes -
          Link This issue duplicates MNG-3057 [ MNG-3057 ]
          Dennis Lundberg made changes -
          Component/s install:install [ 13801 ]
          Hide
          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
          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
          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
          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.
          Robert Scholte made changes -
          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.
          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.

            People

            • Assignee:
              Unassigned
              Reporter:
              Stefan Armbruster
            • Votes:
              18 Vote for this issue
              Watchers:
              18 Start watching this issue

              Dates

              • Created:
                Updated: