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

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

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

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.

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.

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.

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?

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}

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 ~).

hit by this bug when using a $

property, the side effect of this bug are so big it should be patched as soon as possible

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 ...

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.

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

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

See MRESOURCES-56

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

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 $

interpolated with the pom full path.

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

IMHO the it MWAR-133 is false.
There is a file filtered.properties which contains app.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

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.

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

fixed in rev 692744