Maven 2.x Resources Plugin

Filtering ${foo.file} evaluates to in full path to pom.xml

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.2
  • Fix Version/s: 2.3
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows XP, Maven 2.0.2
  • Number of attachments :
    2

Description

If an unresolved variable is encountered, the plugin simply does not replace the variable in the target file.
If this unresolved variable however ends in ".file}" it will evaluate to a file object that targets the current pom. This results in the replacement being the complete path to that pom (in the 2.1 version of the plugin this results in a ClassCastException).

The workaround is, of course, not to filter the affected files.
Though this will not work if other variables in the affected files do need to be replaced.

Issue Links

This issue is duplicated by:
MRESOURCES-65 filtered resources contains incorrect content Major Closed
MRESOURCES-56 use (and release) the maven-filtering component Critical Closed
This issue relates to:
MWAR-133 Filtering issue: wrong replacement of properties by values from MavenProject object Major Closed
This issue depends upon:
MSHARED-60 Filtering ${foo.file} evaluates to in full path to pom.xml Critical Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Vincent Cornet added a comment -

This issue occurs with unresolved variables ending not only in ".file", but also in ".version", ".url", or any other available property of "$pom".

Show
Vincent Cornet added a comment - This issue occurs with unresolved variables ending not only in ".file", but also in ".version", ".url", or any other available property of "$pom".
Hide
Permalink
Eric Bottard added a comment -

I would suggest raising the priority of this bug as it can have very nasty side effects, for example when using velocity templates.

It would also be nice to have the possibility to
1- Use other delimiters for properties (ie not only @@ or ${})
2- De-activate the ${} delimiters

Show
Eric Bottard added a comment - I would suggest raising the priority of this bug as it can have very nasty side effects, for example when using velocity templates. It would also be nice to have the possibility to 1- Use other delimiters for properties (ie not only @@ or ${}) 2- De-activate the ${} delimiters
Hide
Permalink
Arnaud Lucas added a comment -

This is an important bug and should not be considered minor. This prevents me from using resource filtering and makes me duplicate files, modifying them with hard-coded values as a workaround for this bug.

I am just asking for a stricter evaluation of properties so that Maven leaves alone properties it can not replace.

Show
Arnaud Lucas added a comment - This is an important bug and should not be considered minor. This prevents me from using resource filtering and makes me duplicate files, modifying them with hard-coded values as a workaround for this bug. I am just asking for a stricter evaluation of properties so that Maven leaves alone properties it can not replace.
Hide
Permalink
Erik Post added a comment -

IMHO the priority of this issue is not minor. It makes it impossible to use resource files that use properties ending in .name (for example) that will be replaced at runtime by custom code.

Show
Erik Post added a comment - IMHO the priority of this issue is not minor. It makes it impossible to use resource files that use properties ending in .name (for example) that will be replaced at runtime by custom code.
Hide
Permalink
Erik Post added a comment -

I've attached a patch that fixes the problem for me. In ReflectionProperties.java, the call to ReflectionValueExtractor.evaluate now includes a third parameter with value false so that the first component of the key is not stripped. All unit tests pass.

Show
Erik Post added a comment - I've attached a patch that fixes the problem for me. In ReflectionProperties.java, the call to ReflectionValueExtractor.evaluate now includes a third parameter with value false so that the first component of the key is not stripped. All unit tests pass.
Hide
Permalink
Brett Okken added a comment -

This has been open for quite some time. I also agree that it is not a "minor" issue. Can we get a fix or an idea of when/if it will be addressed?

Show
Brett Okken added a comment - This has been open for quite some time. I also agree that it is not a "minor" issue. Can we get a fix or an idea of when/if it will be addressed?
Hide
Permalink
Olivier Lamy added a comment -

The issue I see with this patch is the backward comp

The following content :
pomVersionWithoutPomDot=${version}
pomVersionWithPomDot=${pom.version}
is currently interpolated to :
pomVersionWithoutPomDot=1.0-SNAPSHOT
pomVersionWithPomDot=1.0-SNAPSHOT
With the patch :
pomVersionWithoutPomDot=1.0-SNAPSHOT
pomVersionWithPomDot=${pom.version}
Show
Olivier Lamy added a comment - The issue I see with this patch is the backward comp 
The following content :
pomVersionWithoutPomDot=${version}
pomVersionWithPomDot=${pom.version}
is currently interpolated to :
pomVersionWithoutPomDot=1.0-SNAPSHOT
pomVersionWithPomDot=1.0-SNAPSHOT
With the patch :
pomVersionWithoutPomDot=1.0-SNAPSHOT
pomVersionWithPomDot=${pom.version}
Hide
Permalink
Anj added a comment - - edited

I agree, this is an important issue. Thankyou Erik for the patch, it worked a treat.

However I had to spoof a local maven "release" of this plugin to allow me to release my dependent project (~ shudder ~).

Show
Anj added a comment - - edited I agree, this is an important issue. Thankyou Erik for the patch, it worked a treat. However I had to spoof a local maven "release" of this plugin to allow me to release my dependent project (~ shudder ~).
Hide
Permalink
Marcello Teodori added a comment -

hit by this bug when using a ${anytexthere.name} property, the side effect of this bug are so big it should be patched as soon as possible

Show
Marcello Teodori added a comment - hit by this bug when using a ${anytexthere.name} property, the side effect of this bug are so big it should be patched as soon as possible
Hide
Permalink
Stephane Nicoll added a comment -

Olivier,

See linked issue. The maven filtering component fixes the issue. Is there any plan to switch the resources plugin to the maven filtering component? If so, we would a fix for free.

If not, can we backport easily what you've done there? This bug is pretty bad ...

Show
Stephane Nicoll added a comment - Olivier, See linked issue. The maven filtering component fixes the issue. Is there any plan to switch the resources plugin to the maven filtering component? If so, we would a fix for free. If not, can we backport easily what you've done there? This bug is pretty bad ...
Hide
Permalink
Olivier Lamy added a comment -

The branch is here https://svn.apache.org/repos/asf/maven/plugins/branches/MRESOURCES-56/.
I just want to release the maven-filtering component and merge this branch to the trunk.

Show
Olivier Lamy added a comment - The branch is here https://svn.apache.org/repos/asf/maven/plugins/branches/MRESOURCES-56/. I just want to release the maven-filtering component and merge this branch to the trunk.
Hide
Permalink
Dave Sinclair added a comment -

I have a fix that addresses the issue, passes the unit tests and handles the backwards comp issue. I have attached the modified ReflectionProperties.java

Show
Dave Sinclair added a comment - I have a fix that addresses the issue, passes the unit tests and handles the backwards comp issue. I have attached the modified ReflectionProperties.java
Hide
Permalink
Stephane Nicoll added a comment -

see the linked issue. it is already fixed, we need to integrate the new maven filtering shared component.

Show
Stephane Nicoll added a comment - see the linked issue. it is already fixed, we need to integrate the new maven filtering shared component.
Hide
Permalink
Stephane Nicoll added a comment -

See MRESOURCES-56

Show
Stephane Nicoll added a comment - See MRESOURCES-56
Hide
Permalink
Dave Sinclair added a comment -

My bad. I misunderstood one of the previous posts. Any idea when it will be integrated?

Show
Dave Sinclair added a comment - My bad. I misunderstood one of the previous posts. Any idea when it will be integrated?
Hide
Permalink
Olivier Lamy added a comment -

The issue was marked fixed only because maven-filtering component fixes the ClassCastException.
But if you have a property 

fileValue=${foo.file}

If this is not found in properties files, project.build.filters, project.properties and mavenSession.executionProperties, you will have ${foo.file} interpolated with the pom full path.

Show
Olivier Lamy added a comment - The issue was marked fixed only because maven-filtering component fixes the ClassCastException. But if you have a property 
fileValue=${foo.file}
If this is not found in properties files, project.build.filters, project.properties and mavenSession.executionProperties, you will have ${foo.file} interpolated with the pom full path.
Hide
Permalink
Stephane Nicoll added a comment -

I can't reproduce this with the war plugin and a filtered web resource. What am I missing?

Show
Stephane Nicoll added a comment - I can't reproduce this with the war plugin and a filtered web resource. What am I missing?
Hide
Permalink
Olivier Lamy added a comment -

IMHO the it MWAR-133 is false.
There is a file filtered.properties which contains app.version=${node.version}.
The it pom has a property called node.version but if you remone this property the result file will have the value : app.version= the pom version

Show
Olivier Lamy added a comment - IMHO the it MWAR-133 is false. There is a file filtered.properties which contains app.version=${node.version}. The it pom has a property called node.version but if you remone this property the result file will have the value : app.version= the pom version
Hide
Permalink
Benjamin Bentmann added a comment -

Shouldn't we change MavenProjectValueSource to only filter POM values if the expression starts with pom. or project.? It's currently aliasing all of the following expressions

  • version
  • pom.version
  • foo.version

to the POM version which doesn't seem right to me.

Show
Benjamin Bentmann added a comment - Shouldn't we change MavenProjectValueSource to only filter POM values if the expression starts with pom. or project.? It's currently aliasing all of the following expressions
  • version
  • pom.version
  • foo.version
to the POM version which doesn't seem right to me.
Hide
Permalink
Olivier Lamy added a comment -

Yup that's what I'm doing. to fix MSHARED-60.

Show
Olivier Lamy added a comment - Yup that's what I'm doing. to fix MSHARED-60.
Hide
Permalink
Olivier Lamy added a comment -

fixed in rev 692744

Show
Olivier Lamy added a comment - fixed in rev 692744

People

Vote (14)
Watch (13)

Dates

  • Created:
    Updated:
    Resolved:
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.