You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Martin Onis (JIRA)" <ji...@codehaus.org> on 2006/06/22 13:25:40 UTC
[jira] Created: (MRESOURCES-20) Filtering ${foo.file} evaluates to
in full path to pom.xml
Filtering ${foo.file} evaluates to in full path to pom.xml
----------------------------------------------------------
Key: MRESOURCES-20
URL: http://jira.codehaus.org/browse/MRESOURCES-20
Project: Maven 2.x Resources Plugin
Type: Bug
Versions: 2.2
Environment: Windows XP, Maven 2.0.2
Reporter: Martin Onis
Priority: Minor
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MRESOURCES-20) Filtering ${foo.file} evaluates to
in full path to pom.xml
Posted by "Olivier Lamy (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Olivier Lamy updated MRESOURCES-20:
-----------------------------------
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.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Dave Sinclair (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147151#action_147151 ]
Dave Sinclair commented on MRESOURCES-20:
-----------------------------------------
My bad. I misunderstood one of the previous posts. Any idea when it will be integrated?
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Dave Sinclair (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147146#action_147146 ]
Dave Sinclair commented on MRESOURCES-20:
-----------------------------------------
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
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147232#action_147232 ]
Benjamin Bentmann commented on MRESOURCES-20:
---------------------------------------------
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.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Arnaud Lucas (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=comments#action_74186 ]
Arnaud Lucas commented on MRESOURCES-20:
----------------------------------------
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.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRESOURCES-20) Filtering ${foo.file} evaluates to
in full path to pom.xml
Posted by "Dave Sinclair (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Sinclair updated MRESOURCES-20:
------------------------------------
Attachment: ReflectionProperties.java
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRESOURCES-20) Filtering ${foo.file} evaluates to
in full path to pom.xml
Posted by "Olivier Lamy (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Olivier Lamy closed MRESOURCES-20.
----------------------------------
Resolution: Fixed
fixed in rev [692744|http://svn.apache.org/viewvc?rev=692744&view=rev]
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRESOURCES-20) Filtering ${foo.file} evaluates to
in full path to pom.xml
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephane Nicoll closed MRESOURCES-20.
-------------------------------------
Resolution: Duplicate
Fix Version/s: 2.3
See MRESOURCES-56
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147229#action_147229 ]
Stephane Nicoll commented on MRESOURCES-20:
-------------------------------------------
I can't reproduce this with the war plugin and a filtered web resource. What am I missing?
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Olivier Lamy (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125529 ]
Olivier Lamy commented on MRESOURCES-20:
----------------------------------------
The issue I see with this patch is the backward comp
{code}
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}
{code}
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Brett Okken (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115529 ]
Brett Okken commented on MRESOURCES-20:
---------------------------------------
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?
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRESOURCES-20) Filtering ${foo.file}
evaluates to in full path to pom.xml
Posted by "Anj (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133710#action_133710 ]
anj747 edited comment on MRESOURCES-20 at 5/6/08 10:51 AM:
--------------------------------------------------------
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 ~).
was (Author: anj747):
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~).
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRESOURCES-20) Filtering ${foo.file} evaluates to
in full path to pom.xml
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephane Nicoll updated MRESOURCES-20:
--------------------------------------
Priority: Critical (was: Minor)
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Critical
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Eric Bottard (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=comments#action_68322 ]
Eric Bottard commented on MRESOURCES-20:
----------------------------------------
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
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Type: Bug
> Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Anj (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133710#action_133710 ]
Anj commented on MRESOURCES-20:
-------------------------------
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*.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147147#action_147147 ]
Stephane Nicoll commented on MRESOURCES-20:
-------------------------------------------
see the linked issue. it is already fixed, we need to integrate the new maven filtering shared component.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Erik Post (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=comments#action_81257 ]
Erik Post commented on MRESOURCES-20:
-------------------------------------
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.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Vincent Cornet (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=comments#action_68320 ]
Vincent Cornet commented on MRESOURCES-20:
------------------------------------------
This issue occurs with unresolved variables ending not only in ".file", but also in ".version", ".url", or any other available property of "$pom".
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Type: Bug
> Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Olivier Lamy (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147233#action_147233 ]
Olivier Lamy commented on MRESOURCES-20:
----------------------------------------
Yup that's what I'm doing. :-) to fix MSHARED-60.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Marcello Teodori (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=142165#action_142165 ]
Marcello Teodori commented on MRESOURCES-20:
--------------------------------------------
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
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRESOURCES-20) Filtering ${foo.file}
evaluates to in full path to pom.xml
Posted by "Anj (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133710#action_133710 ]
anj747 edited comment on MRESOURCES-20 at 5/6/08 10:51 AM:
--------------------------------------------------------
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~).
was (Author: anj747):
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*.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRESOURCES-20) Filtering ${foo.file} evaluates to
in full path to pom.xml
Posted by "Erik Post (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=all ]
Erik Post updated MRESOURCES-20:
--------------------------------
Attachment: MRESOURCES-20.patch
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.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Priority: Minor
> Attachments: MRESOURCES-20.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates
to in full path to pom.xml
Posted by "Olivier Lamy (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147230#action_147230 ]
Olivier Lamy commented on MRESOURCES-20:
----------------------------------------
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
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MRESOURCES-20) Filtering ${foo.file} evaluates to
in full path to pom.xml
Posted by "Olivier Lamy (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Olivier Lamy reopened MRESOURCES-20:
------------------------------------
The issue was marked fixed only because maven-filtering component fixes the ClassCastException.
But if you have a property
{code}
fileValue=${foo.file}
{code}
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.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> ----------------------------------------------------------
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
> Reporter: Martin Onis
> Assignee: Olivier Lamy
> Priority: Critical
> Fix For: 2.3
>
> Attachments: MRESOURCES-20.patch, ReflectionProperties.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira