[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
[
http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Updated: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
[
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] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
[
http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: (MWAR-116) The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
[
http://jira.codehaus.org/browse/MWAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=143847#action_143847
]
Dave Sinclair commented on MWAR-116:
Pardon me, I got it to work. I had tried the @s around the
{artifact.artifactId}, but after looking at the source I realize it should be
only @[EMAIL PROTECTED] My bad! Thanks
The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
Key: MWAR-116
URL: http://jira.codehaus.org/browse/MWAR-116
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-1
Reporter: Chris Moesel
Assignee: Olivier Lamy
Fix For: 2.1-alpha-2
Attachments: mwar_93_webapp.zip
I've tried using the new outputFileNameMapping feature (MWAR-93) by adding
the following to my POM:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.1-alpha-1-SNAPSHOT/version
configuration
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
/configuration
/plugin
This results in really oddly named files in my web-inf/lib now. A typical
example:
org.springframework-mywebapp.null
So, the resulting files are really mapped more like: ${groupId of the
dependency}-${artifactId of my war module}.null
I've attached an example Maven 2 project that demonstrates this. Just run
mvn package and look at the result in target.
--
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: (MWAR-116) The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
[
http://jira.codehaus.org/browse/MWAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=143798#action_143798
]
Dave Sinclair commented on MWAR-116:
I have 2.1-alpha-2-SNAPSHOT and am still seeing this problem. Here is the
section from my pom. Any ideas?
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.1-alpha-2-SNAPSHOT/version
configuration
archiveClassestrue/archiveClasses
outputFileNameMapping${artifact.artifactId}.${artifact.extension}/outputFileNameMapping
filters
filtersrc/main/filters/${wile.filter.properties}/filter
/filters
webResources
webResource
directory${basedir}/src/main/webapp/WEB-INF/directory
includes
includebeans.xml/include
includeweb.xml/include
/includes
targetPathWEB-INF/targetPath
filteringtrue/filtering
/webResource
/webResources
/configuration
/plugin
The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
Key: MWAR-116
URL: http://jira.codehaus.org/browse/MWAR-116
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-1
Reporter: Chris Moesel
Assignee: Olivier Lamy
Fix For: 2.1-alpha-2
Attachments: mwar_93_webapp.zip
I've tried using the new outputFileNameMapping feature (MWAR-93) by adding
the following to my POM:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.1-alpha-1-SNAPSHOT/version
configuration
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
/configuration
/plugin
This results in really oddly named files in my web-inf/lib now. A typical
example:
org.springframework-mywebapp.null
So, the resulting files are really mapped more like: ${groupId of the
dependency}-${artifactId of my war module}.null
I've attached an example Maven 2 project that demonstrates this. Just run
mvn package and look at the result in target.
--
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
