[jira] Commented: (MWAR-260) Patch to provide new war-overlay type
[ https://jira.codehaus.org/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279045#comment-279045 ] Joerg Schaible commented on MWAR-260: - Why do you need a new packaging type? We do this since years using packaging type jar and add the war as attached artifact with classifier 'webapp'. > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://jira.codehaus.org/browse/MWAR-260 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-260) Patch to provide new war-overlay type
[ https://jira.codehaus.org/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279047#comment-279047 ] Alex Clarke commented on MWAR-260: -- Hi Joerg, Could you clarify what you mean by this? Are you saying that your overlay is set with a packaging type of jar and an additional webapp artifiact is attached that contains the web content? How does the war that wants to use the overlay specify dependencies? Does it need to declare two dependencies for each overlay, one for the jar and one for the webapp type? Is there any documentation or are there examples somewhere of this? Thanks, Alex > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://jira.codehaus.org/browse/MWAR-260 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-262) default value should be false for Servlet level > 2.5 projects
default value should be false for Servlet level > 2.5 projects Key: MWAR-262 URL: https://jira.codehaus.org/browse/MWAR-262 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Fred Bricon Since JavaEE 5, the web.xml deployment descriptor is optional. In this case should default to false. How do we do detect that? - introduce a new or attribute to the configuration, similar to the in maven-ear-plugin and maven-ejb-plugin - check if the project's classpath contains classes fom JavaEE > 5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-260) Patch to provide new war-overlay type
[ https://jira.codehaus.org/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279052#comment-279052 ] Joerg Schaible commented on MWAR-260: - bq. Does it need to declare two dependencies for each overlay, one for the jar and one for the webapp type? Yes. I've recommended it more than once, e.g. here: http://www.mailinglistarchive.com/us...@maven.apache.org/msg58383.html The main problem is IMHO not the declaration of the second artifact, but the proper configuration of the war plugin for each case. # The webapp should have the resulting jar within its WEB-INF/lib and it should not contain anything in WEB-INF/classes. # The assembling webapp must (apart from the declaration of the two dependencies) exclude everything coming from the overlay's WEB-INF/libs, because it calculates its dependencies now on its own. # In a cascading build you have to ensure that you don't inherit unwanted overlays, e.g. webapp A is used as overlay for webapp B which is in turn used as overlay for webapp C. You have to ensure that A is not used directly as overlay again in C, because of the now _visible_ dependency tree. So does your solution address any of this 3 points automatically or do you only spare the declaration of the 2nd artifact? > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://jira.codehaus.org/browse/MWAR-260 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-302) Have a custom packaging type for achetypes
[
https://jira.codehaus.org/browse/ARCHETYPE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279055#comment-279055
]
Hardy Ferentschik commented on ARCHETYPE-302:
-
{quote}
from what I understand, you propose to make the "archetype project" step
disappear, which will streamline the archetype creation from example project
{quote}
correct
{quote}
question: where do you see the archetype descriptor in the example project? how
to have a maven-archetype packaging without disturbing the example project?
(less critical at a first glance: and what about integration tests ?)
{quote}
the archetype descriptor could be in a default location which is excluded from
the final archetype, eg _src/main/archetype_. This could even be configured via
a property.
Regarding the packaging, It would be nice to be able to have an alternative
_pom.xml_ or at least more flexibility to configure the resulting pom. For
example, the dependencies and build configuration is really the core thing I
want to get into the archetype. For things like, description, developer, etc I
would like to be able to override/customize the pom. (Note, I used to not even
specify things like developer and scm in the pom which formed the based for the
archetype, but since the Sonar instance I am deploying into has some pom
validation rules which require these settings.
> Have a custom packaging type for achetypes
> --
>
> Key: ARCHETYPE-302
> URL: https://jira.codehaus.org/browse/ARCHETYPE-302
> Project: Maven Archetype
> Issue Type: New Feature
> Components: Creator
>Reporter: Hardy Ferentschik
>
> Currently if you want to create an archetype from a existing project you need
> a two step process. First you have to run 'mvn archetype:create-from-project'
> and then you have to install/deploy the archetype generated in
> {{target/generated-sources/archetype}}. Wouldn't it be possible to have a new
> packaging type, eg archetype?
> For example, imagine you have an aggregator (multi module) project, where one
> module is supposed to be the template for the archetype. When you
> deploy/release the whole project you would like the archetype creation be
> part of the the 'mvn deploy' or 'mvn release:perform' process. Currently you
> will have to go through the mentioned two step process.
> Thoughts?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (ARCHETYPE-302) Have a custom packaging type for achetypes
[
https://jira.codehaus.org/browse/ARCHETYPE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279055#comment-279055
]
Hardy Ferentschik edited comment on ARCHETYPE-302 at 9/15/11 7:40 AM:
--
{quote}
from what I understand, you propose to make the "archetype project" step
disappear, which will streamline the archetype creation from example project
{quote}
correct
{quote}
question: where do you see the archetype descriptor in the example project? how
to have a maven-archetype packaging without disturbing the example project?
(less critical at a first glance: and what about integration tests ?)
{quote}
the archetype descriptor could be in a default location which is excluded from
the final archetype, eg _src/main/archetype_. This could even be configured via
a property.
Regarding the packaging, It would be nice to be able to have an alternative
_pom.xml_ or at least more flexibility to configure the resulting pom. For
example, the dependencies and build configuration is really the core thing I
want to get into the archetype. For things like, description, developer, etc I
would like to be able to override/customize the pom. (Note, I used to not even
specify things like developer and scm in the pom which formed the based for the
archetype, but since the Sonar instance I am deploying into has some pom
validation rules which require these settings.)
was (Author: esfahan):
{quote}
from what I understand, you propose to make the "archetype project" step
disappear, which will streamline the archetype creation from example project
{quote}
correct
{quote}
question: where do you see the archetype descriptor in the example project? how
to have a maven-archetype packaging without disturbing the example project?
(less critical at a first glance: and what about integration tests ?)
{quote}
the archetype descriptor could be in a default location which is excluded from
the final archetype, eg _src/main/archetype_. This could even be configured via
a property.
Regarding the packaging, It would be nice to be able to have an alternative
_pom.xml_ or at least more flexibility to configure the resulting pom. For
example, the dependencies and build configuration is really the core thing I
want to get into the archetype. For things like, description, developer, etc I
would like to be able to override/customize the pom. (Note, I used to not even
specify things like developer and scm in the pom which formed the based for the
archetype, but since the Sonar instance I am deploying into has some pom
validation rules which require these settings.
> Have a custom packaging type for achetypes
> --
>
> Key: ARCHETYPE-302
> URL: https://jira.codehaus.org/browse/ARCHETYPE-302
> Project: Maven Archetype
> Issue Type: New Feature
> Components: Creator
>Reporter: Hardy Ferentschik
>
> Currently if you want to create an archetype from a existing project you need
> a two step process. First you have to run 'mvn archetype:create-from-project'
> and then you have to install/deploy the archetype generated in
> {{target/generated-sources/archetype}}. Wouldn't it be possible to have a new
> packaging type, eg archetype?
> For example, imagine you have an aggregator (multi module) project, where one
> module is supposed to be the template for the archetype. When you
> deploy/release the whole project you would like the archetype creation be
> part of the the 'mvn deploy' or 'mvn release:perform' process. Currently you
> will have to go through the mentioned two step process.
> Thoughts?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-260) Patch to provide new war-overlay type
[ https://jira.codehaus.org/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279056#comment-279056 ] Alex Clarke commented on MWAR-260: -- Hi Joerg, Thanks for the clarification... in answer to your 3 points: 1) No, overlay's classes end up in WEB-INF/classes as per the currently behaviour. 2) Yes this is catered for as war-overlay doesn't package dependencies into WEB-INF/lib. It assumes that the war packaging will be responsible for creating the final WEB-INF/lib directory. This has the added advantage of keeping overlay artifacts small. 3) I'm not entirely sure what you're getting at here. If projects A & B are war-overlays and project C is a war project. C depends on B and B depends on A then surely both B and A should be overlaid on C? Let me know what you think. Thanks, Alex > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://jira.codehaus.org/browse/MWAR-260 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-612) Error in jasperreport groupId in the plugin Usage page.
Error in jasperreport groupId in the plugin Usage page. Key: MSITE-612 URL: https://jira.codehaus.org/browse/MSITE-612 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: documentation Environment: For a smart usage of the plugin can be better fix, also because not all person can be skilled to fix this. Reporter: luca preziati In the page http://mojo.codehaus.org/jasperreports-maven-plugin/usage.html there is an incorrect value for groupId for jasperReport. The correct one is. net.sf.jasperreports jasperreports 4.1.1 I think it's better to update to current pattern of jasperreport groupId. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5174) Plugin Configuration from Grandparent Not Executed on Grandchild
[
https://jira.codehaus.org/browse/MNG-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-5174.
--
Resolution: Cannot Reproduce
Assignee: Benjamin Bentmann
> Plugin Configuration from Grandparent Not Executed on Grandchild
>
>
> Key: MNG-5174
> URL: https://jira.codehaus.org/browse/MNG-5174
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.2
> Environment: ava version: 1.6.0_24, vendor: Apple Inc.
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac"
>Reporter: Lon Binder
>Assignee: Benjamin Bentmann
>Priority: Blocker
> Attachments: build.log, MNG-5174.zip
>
>
> Summary: The configuration of a plugin in the grandparent of a project,
> whether in or is not properly inherited to
> grandchild.
> To reproduce:
> Setup:
> POM C extends POM B; POM B extends POM A
> POM A includes:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.3
>
>
> copy-dependencies
> package
>
>
> copy-dependencies
>
>
>
> ${project.build.directory}/dependency-libs
>
>
>
>
>
>
>
> ...
> {code}
> Then in the POM C folder execute {{mvn package}}. The plugin does not work.
> If the same configuration is moved or copied to POM B, then the execution in
> POM C's folder is repeated, it works fine.
> The same holds true if the above is moved to POM A's {{}}
> node (and the appropriate {{}} groupId and artifactId are added to
> POM C). It even holds true if you do this and add additional to POM B.
> Unless the full config is in POM B (or POM C) then it will not run from POM C.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5174) Plugin Configuration from Grandparent Not Executed on Grandchild
[
https://jira.codehaus.org/browse/MNG-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-5174:
---
Attachment: MNG-5174.zip
Running {{mvn package -V}} on the attached example project yields:
{noformat}
Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.5.0_22, vendor: Sun Microsystems Inc.
Java home: D:\java\jdk-1.5\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building test 0.1-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.3:copy-dependencies (copy-dependencies) @
test ---
[INFO] junit-3.8.2.jar already exists in destination.
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.565s
[INFO] Finished at: Thu Sep 15 15:08:16 CEST 2011
[INFO] Final Memory: 9M/157M
[INFO]
{noformat}
i.e. the issue cannot be reproduced from the provided information.
> Plugin Configuration from Grandparent Not Executed on Grandchild
>
>
> Key: MNG-5174
> URL: https://jira.codehaus.org/browse/MNG-5174
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.2
> Environment: ava version: 1.6.0_24, vendor: Apple Inc.
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac"
>Reporter: Lon Binder
>Priority: Blocker
> Attachments: build.log, MNG-5174.zip
>
>
> Summary: The configuration of a plugin in the grandparent of a project,
> whether in or is not properly inherited to
> grandchild.
> To reproduce:
> Setup:
> POM C extends POM B; POM B extends POM A
> POM A includes:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.3
>
>
> copy-dependencies
> package
>
>
> copy-dependencies
>
>
>
> ${project.build.directory}/dependency-libs
>
>
>
>
>
>
>
> ...
> {code}
> Then in the POM C folder execute {{mvn package}}. The plugin does not work.
> If the same configuration is moved or copied to POM B, then the execution in
> POM C's folder is repeated, it works fine.
> The same holds true if the above is moved to POM A's {{}}
> node (and the appropriate {{}} groupId and artifactId are added to
> POM C). It even holds true if you do this and add additional to POM B.
> Unless the full config is in POM B (or POM C) then it will not run from POM C.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5174) Plugin Configuration from Grandparent Not Executed on Grandchild
[
https://jira.codehaus.org/browse/MNG-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279062#comment-279062
]
Lon Binder commented on MNG-5174:
-
Just to confirm, Benjamin after seeing your example it immediately became clear
I had a copy/paste error in the {{}} in the parent POM. Sorry
to waste your time.
> Plugin Configuration from Grandparent Not Executed on Grandchild
>
>
> Key: MNG-5174
> URL: https://jira.codehaus.org/browse/MNG-5174
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.2
> Environment: ava version: 1.6.0_24, vendor: Apple Inc.
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac"
>Reporter: Lon Binder
>Assignee: Benjamin Bentmann
>Priority: Blocker
> Attachments: build.log, MNG-5174.zip
>
>
> Summary: The configuration of a plugin in the grandparent of a project,
> whether in or is not properly inherited to
> grandchild.
> To reproduce:
> Setup:
> POM C extends POM B; POM B extends POM A
> POM A includes:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.3
>
>
> copy-dependencies
> package
>
>
> copy-dependencies
>
>
>
> ${project.build.directory}/dependency-libs
>
>
>
>
>
>
>
> ...
> {code}
> Then in the POM C folder execute {{mvn package}}. The plugin does not work.
> If the same configuration is moved or copied to POM B, then the execution in
> POM C's folder is repeated, it works fine.
> The same holds true if the above is moved to POM A's {{}}
> node (and the appropriate {{}} groupId and artifactId are added to
> POM C). It even holds true if you do this and add additional to POM B.
> Unless the full config is in POM B (or POM C) then it will not run from POM C.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-5174) Plugin Configuration from Grandparent Not Executed on Grandchild
[
https://jira.codehaus.org/browse/MNG-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279062#comment-279062
]
Lon Binder edited comment on MNG-5174 at 9/15/11 8:32 AM:
--
Just to confirm, Benjamin after seeing your example it immediately became clear
I had a copy/paste error in the {{}} in the parent POM. Sorry
to waste your time. This is definitely user (me) error.
was (Author: lonbinder):
Just to confirm, Benjamin after seeing your example it immediately became
clear I had a copy/paste error in the {{}} in the parent POM.
Sorry to waste your time.
> Plugin Configuration from Grandparent Not Executed on Grandchild
>
>
> Key: MNG-5174
> URL: https://jira.codehaus.org/browse/MNG-5174
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.2
> Environment: ava version: 1.6.0_24, vendor: Apple Inc.
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac"
>Reporter: Lon Binder
>Assignee: Benjamin Bentmann
>Priority: Blocker
> Attachments: build.log, MNG-5174.zip
>
>
> Summary: The configuration of a plugin in the grandparent of a project,
> whether in or is not properly inherited to
> grandchild.
> To reproduce:
> Setup:
> POM C extends POM B; POM B extends POM A
> POM A includes:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.3
>
>
> copy-dependencies
> package
>
>
> copy-dependencies
>
>
>
> ${project.build.directory}/dependency-libs
>
>
>
>
>
>
>
> ...
> {code}
> Then in the POM C folder execute {{mvn package}}. The plugin does not work.
> If the same configuration is moved or copied to POM B, then the execution in
> POM C's folder is repeated, it works fine.
> The same holds true if the above is moved to POM A's {{}}
> node (and the appropriate {{}} groupId and artifactId are added to
> POM C). It even holds true if you do this and add additional to POM B.
> Unless the full config is in POM B (or POM C) then it will not run from POM C.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5174) Plugin Configuration from Grandparent Not Executed on Grandchild
[
https://jira.codehaus.org/browse/MNG-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279064#comment-279064
]
Benjamin Bentmann commented on MNG-5174:
No need to apologize, but I would like to repeat my request to provide runnable
example projects along with filled issues. They do not only provide as a solid
basis for bug reproduction/analysis but they can also help users to spot
typos/misconfiguration, usually before a committer has a chance to look at the
bug report.
> Plugin Configuration from Grandparent Not Executed on Grandchild
>
>
> Key: MNG-5174
> URL: https://jira.codehaus.org/browse/MNG-5174
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.2
> Environment: ava version: 1.6.0_24, vendor: Apple Inc.
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac"
>Reporter: Lon Binder
>Assignee: Benjamin Bentmann
>Priority: Blocker
> Attachments: build.log, MNG-5174.zip
>
>
> Summary: The configuration of a plugin in the grandparent of a project,
> whether in or is not properly inherited to
> grandchild.
> To reproduce:
> Setup:
> POM C extends POM B; POM B extends POM A
> POM A includes:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.3
>
>
> copy-dependencies
> package
>
>
> copy-dependencies
>
>
>
> ${project.build.directory}/dependency-libs
>
>
>
>
>
>
>
> ...
> {code}
> Then in the POM C folder execute {{mvn package}}. The plugin does not work.
> If the same configuration is moved or copied to POM B, then the execution in
> POM C's folder is repeated, it works fine.
> The same holds true if the above is moved to POM A's {{}}
> node (and the appropriate {{}} groupId and artifactId are added to
> POM C). It even holds true if you do this and add additional to POM B.
> Unless the full config is in POM B (or POM C) then it will not run from POM C.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-153) Usage of copy-resources changes testResources copying behaviour
Usage of copy-resources changes testResources copying behaviour
---
Key: MRESOURCES-153
URL: https://jira.codehaus.org/browse/MRESOURCES-153
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Components: copy
Affects Versions: 2.5, 2.4.2, 2.6
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files\apache-maven-3.0.3\bin\..
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_26\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Myron
Attachments: resources-debug.txt
Create a dummy project, add foo.txt to src/test/resources
do a "mvn clean package"
foo.txt appears in target/test-classes/foo.txt and is not in packaged jar (as
supposed)
Add build step to copy some additonal files to classpath/jar and again do a
"mvn clean package"
{quote}
org.apache.maven.plugins
maven-resources-plugin
2.5
copy-resources
process-resources
src/main/additional
${project.build.outputDirectory}
{quote}
now what happens:
the files in "additional" are copied to target/classes (as supposed) but the
foo.txt AS WELL (not supposed)
target/test-classes is now empty and all the test resources are packaged into
jar
So specifying the copy-resource goal results in an reconfiguration of the
test-resources copy operation?!
[DEBUG] copy C:\Users\myron\workspace\test\src\test\resources\foo.txt to
C:\Users\myron\workspace\test\target\classes\foo.txt
complete debug attached
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPMD-130) excludeRoot doesn't work in site build on multi-module projects
[
https://jira.codehaus.org/browse/MPMD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279111#comment-279111
]
Archimedes Trajano commented on MPMD-130:
-
Same applies for excludes.
Tested on Maven 3.0.3
> excludeRoot doesn't work in site build on multi-module projects
> ---
>
> Key: MPMD-130
> URL: https://jira.codehaus.org/browse/MPMD-130
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Marcel Stör
>
> The parent POM of my multi-module setup says
>
> 1.6
>
> target/generated-sources
>
>
> If I run {{mvn pmd:cpd}} or {{mvn site}} directly on the module that actually
> has generated code the report is as expected. The files in
> {{target/generated-sources}} are ignored. Also, if I run {{mvn pmd:cpd}} at
> root level outside all the modules the report is fine.
> However, if I run {{mvn site}} at root level outside all the modules the
> excludeRoot is ignored.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-260) Patch to provide new war-overlay type
[ https://jira.codehaus.org/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279112#comment-279112 ] Joerg Schaible commented on MWAR-260: - OK, it seems you have a slightly different model in mind. I assume now that a war-overlay project from your proposal generates a war file with a jar file extension, that is only used as an overlay in a real war project. We have actually a different approach. We assemble in our main web application also several other (overlay) web applications i.e. small web applications (modules) that can be used also on their own. Additionally our main web application might be customized in a project and is used there as overlay. Any of those web applications are standard Maven projects producing a jar as main artifact that is also included in the attached web application. As result we have at any time a web application (individual modules, main web application or the customized one) that can be deployed on its own or that can be used again as overlay without loosing the dependency information. bq. C depends on B and B depends on A then surely both B and A should be overlaid on C? No, not in our model. If B excludes or overwrites some web resources of A, you want the B version in C. You don't want to have the changes made in B clobbered (or added) by resources from A in C again. Building C you should not really have to know that A exists and you may have to take care for something. However, this case cannot happen in your model, since you use only overlay-wars for overlays. > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://jira.codehaus.org/browse/MWAR-260 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-325) build-classpath adds a newline character when dependency artifact name starts with letter n
build-classpath adds a newline character when dependency artifact name starts with letter n --- Key: MDEP-325 URL: https://jira.codehaus.org/browse/MDEP-325 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: build-classpath Affects Versions: 2.3, 2.2, 2.1 Reporter: L. Compère Assignee: Brian Fox I'm using a combination of the maven-dependency-plugin and the maven-assembly-plugin to insert a classpath in a filtered resource. It so happens that one of the dependencies to be added to the classpath is "neethi-2.0.4.jar". The build-classpath goal of the dependency plugin writes the following in a file (all on one line): classpath=%MM_ENV_PATH%J/Lib/\httpcore-nio-4.0-beta1.jar;%MM_ENV_PATH%J/Lib/\neethi-2.0.4.jar;%MM_ENV_PATH%J/Lib/\axiom-api-1.2.7.jar;%MM_ENV_PATH%J/Lib/\axiom-dom-1.2.7.jar; When the assembly plugin uses the content of the file generated by the build-classpath goal of the dependency plugin, it translates the \n found in "%MM_ENV_PATH%J/Lib/\neethi-2.0.4.jar;" into a NEWLINE character... causing my classpath to be broken as such (on two lines): %MM_ENV_PATH%J/Lib/\httpcore-nio-4.0-beta1.jar;%MM_ENV_PATH%J/Lib/ eethi-2.0.4.jar;%MM_ENV_PATH%J/Lib/\axiom-api-1.2.7.jar;%MM_ENV_PATH%J/Lib/\axiom-dom-1.2.7.jar; notice how neethi-2.0.4.jar has become eethi-2.0.4.jar Has anyone had such a problem? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3762) Relocation not working for plugins
[
https://jira.codehaus.org/browse/MNG-3762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279117#comment-279117
]
Joakim Erdfelt commented on MNG-3762:
-
Seems to work in Maven 3.x
Here's a test project.
https://github.com/joakime/maven-llama-plugin-relocation
Just build from the top, and use the test-project to see it using the
maven-llama-plugin.
Then uncomment the relocation in maven-llama-plugin/pom.xml, mvn clean install,
and then execute the test-project again.
> Relocation not working for plugins
> --
>
> Key: MNG-3762
> URL: https://jira.codehaus.org/browse/MNG-3762
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_13
> OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix"
>Reporter: Wendy Smoak
> Fix For: Issues to be reviewed for 3.x
>
>
> As discussed on the user list, the relocation pom for the Jetty plugin does
> not seem to work correctly.
> See: http://www.nabble.com/Does-relocation-work-for-plugins--td19618624.html
> To reproduce, create a project from the webapp archetype, and introduce the
> Jetty plugin:
> {noformat}
>
>...
>
>
>org.mortbay.jetty
>maven-jetty-plugin
>7.0.0pre3
>
>
> {noformat}
> Attempting to build the project results in an error:
> {noformat}
> $ mvn install
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building mywebapp Maven Webapp
> [INFO]task-segment: [install]
> [INFO]
>
> Downloading:
> http://repo1.maven.org/maven2/org/mortbay/jetty/maven-jetty-plugin/7.0.0pre3/maven-jetty-plugin-7.0.0pre3.jar
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] A required plugin was not found: Plugin could not be found -
> check that the goal name is correct: Unable to download the artifact
> from any repository
> Try downloading the file manually from the project website.
> Then, install it using the command:
>mvn install:install-file -DgroupId=org.mortbay.jetty
> -DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
> -Dpackaging=maven-plugin -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
>mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
> -DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
> -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url]
> -DrepositoryId=[id]
> org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Mon Sep 22 19:02:01 MST 2008
> [INFO] Final Memory: 3M/7M
> [INFO]
>
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJARSIGNER-19) Make mojo code reusable from another mojo + customize the working directory.
Make mojo code reusable from another mojo + customize the working directory. Key: MJARSIGNER-19 URL: https://jira.codehaus.org/browse/MJARSIGNER-19 Project: Maven 2.x Jar Signer Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: Tony Chemit Priority: Trivial In the webstart-maven-plugin We used the old jarsigner mojo (from the jar plugin). We'd like to use now this plugin as the mojo from the jar plugin is deprecated for this one (see MWEBSTART-149) Moreover, we want to use yet another working directory and at the moment in the mojo this is hardcoed to project.getBasedir(). Here is a patch which fix our needs. Hope this patch will be apply soon, I would really like to use your mojo :) Thanks for your work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJARSIGNER-19) Make mojo code reusable from another mojo + customize the working directory.
[ https://jira.codehaus.org/browse/MJARSIGNER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit updated MJARSIGNER-19: -- Attachment: MJARSIGNER-19.patch > Make mojo code reusable from another mojo + customize the working directory. > > > Key: MJARSIGNER-19 > URL: https://jira.codehaus.org/browse/MJARSIGNER-19 > Project: Maven 2.x Jar Signer Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Tony Chemit >Priority: Trivial > Attachments: MJARSIGNER-19.patch > > > In the webstart-maven-plugin We used the old jarsigner mojo (from the jar > plugin). > We'd like to use now this plugin as the mojo from the jar plugin is > deprecated for this one (see MWEBSTART-149) > Moreover, we want to use yet another working directory and at the moment in > the mojo this is hardcoed to project.getBasedir(). > Here is a patch which fix our needs. > Hope this patch will be apply soon, I would really like to use your mojo :) > Thanks for your work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPDF-51) NoSuchMethodError while calling Maven PDF Plugin via CLI
[
https://jira.codehaus.org/browse/MPDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279126#comment-279126
]
Dan Rollo commented on MPDF-51:
---
It seems v1.2 of the plugin will now work with maven3.0.3. Any ETA on a release
of v1.2 of pdf plugin?
> NoSuchMethodError while calling Maven PDF Plugin via CLI
>
>
> Key: MPDF-51
> URL: https://jira.codehaus.org/browse/MPDF-51
> Project: Maven 2.x PDF Plugin
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: kama@office:~/ws-git/maui$ mvn --version
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /home/kama/tools/maven
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-31-generic", arch: "i386", family: "unix"
>Reporter: Karl Heinz Marbaise
>Assignee: Lukas Theussl
>
> Just called mvn pdf:pdf from the root directory of my Maven project which
> results into the following failure:
> {code}
> kama@office:~/ws-git/maui$ mvn pdf:pdf | tee pdf.log
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building MaUI Test Guide 0.1-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-pdf-plugin:1.1:pdf (default-cli) @ maui ---
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 4.546s
> [INFO] Finished at: Mon May 30 20:17:00 CEST 2011
> [INFO] Final Memory: 13M/144M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf (default-cli) on project
> maui: Execution default-cli of goal
> org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf:
> java.lang.NoSuchMethodError:
> org.apache.maven.plugin.PluginManager.verifyReportPlugin(Lorg/apache/maven/model/ReportPlugin;Lorg/apache/maven/project/MavenProject;Lorg/apache/maven/execution/MavenSession;)Lorg/apache/maven/plugin/descriptor/PluginDescriptor;
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-pdf-plugin:1.1
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/home/kama/.m2/repository/org/apache/maven/plugins/maven-pdf-plugin/1.1/maven-pdf-plugin-1.1.jar
> [ERROR] urls[1] =
> file:/home/kama/.m2/repository/commons-cli/commons-cli/1.0/commons-cli-1.0.jar
> [ERROR] urls[2] =
> file:/home/kama/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
> [ERROR] urls[3] =
> file:/home/kama/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.jar
> [ERROR] urls[4] =
> file:/home/kama/.m2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0.4.3/maven-reporting-impl-2.0.4.3.jar
> [ERROR] urls[5] =
> file:/home/kama/.m2/repository/commons-validator/commons-validator/1.2.0/commons-validator-1.2.0.jar
> [ERROR] urls[6] =
> file:/home/kama/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
> [ERROR] urls[7] =
> file:/home/kama/.m2/repository/commons-digester/commons-digester/1.6/commons-digester-1.6.jar
> [ERROR] urls[8] = file:/home/kama/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar
> [ERROR] urls[9] =
> file:/home/kama/.m2/repository/org/apache/maven/shared/maven-doxia-tools/1.1/maven-doxia-tools-1.1.jar
> [ERROR] urls[10] =
> file:/home/kama/.m2/repository/commons-io/commons-io/1.4/commons-io-1.4.jar
> [ERROR] urls[11] =
> file:/home/kama/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1.1/doxia-logging-api-1.1.1.jar
> [ERROR] urls[12] =
> file:/home/kama/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1.2/doxia-sink-api-1.1.2.jar
> [ERROR] urls[13] =
> file:/home/kama/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.1.2/doxia-module-xdoc-1.1.2.jar
> [ERROR] urls[14] =
> file:/home/kama/.m2/repository/org/apache/maven/doxia/doxia-core/1.1.2/doxia-core-1.1.2.jar
> [ERROR] urls[15] =
> file:/home/kama/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
> [ERROR] urls[16] =
> file:/home/kama/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> [ERROR] urls[17] =
> file:/home/kama/.m2/repository/comm
[jira] Commented: (MDEP-306) 2.2 unpack does not handle space in includes
[ https://jira.codehaus.org/browse/MDEP-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279131#comment-279131 ] Anthony Whitford commented on MDEP-306: --- Just want to add that this remains a problem with version 2.3 too. > 2.2 unpack does not handle space in includes > > > Key: MDEP-306 > URL: https://jira.codehaus.org/browse/MDEP-306 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack >Affects Versions: 2.2 > Environment: Windows XP, Java 6 >Reporter: Anthony Whitford >Assignee: Brian Fox >Priority: Critical > > Upgrading to 2.2 broke my build and I traced the root cause to the fact that > I am calling unpack against a zip file and my includes specifies a filename > pattern with a space in the directory name. This works fine if I roll back > to version 2.1, but 2.2 doesn't do anything (presumably nothing is matching > the includes spec). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-306) 2.2 unpack does not handle space in includes
[
https://jira.codehaus.org/browse/MDEP-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279134#comment-279134
]
Anthony Whitford commented on MDEP-306:
---
I think the problem is this code found in
[DependencyUtil.java|http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin/src/main/java/org/apache/maven/plugin/dependency/utils/DependencyUtil.java]:{code}
//
// clean up configuration string before it can be tokenized
//
public static String cleanToBeTokenizedString( String str )
{
String ret = "";
if ( !StringUtils.isEmpty( str ) )
{
ret = StringUtils.join( StringUtils.split( str ), "," );
}
return ret;
}
{code} I believe the split needs a separator specified (comma) otherwise it
splits on whitespace:{code}
//
// clean up configuration string before it can be tokenized
//
public static String cleanToBeTokenizedString( String str )
{
String ret = "";
if ( !StringUtils.isEmpty( str ) )
{
ret = StringUtils.join( StringUtils.split( str, "," ), "," );
}
return ret;
}
{code}
See
[StringUtils.java|http://plexus.codehaus.org/plexus-utils/apidocs/org/codehaus/plexus/util/StringUtils.html#split(java.lang.String,
java.lang.String)] for more information.
> 2.2 unpack does not handle space in includes
>
>
> Key: MDEP-306
> URL: https://jira.codehaus.org/browse/MDEP-306
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.2
> Environment: Windows XP, Java 6
>Reporter: Anthony Whitford
>Assignee: Brian Fox
>Priority: Critical
>
> Upgrading to 2.2 broke my build and I traced the root cause to the fact that
> I am calling unpack against a zip file and my includes specifies a filename
> pattern with a space in the directory name. This works fine if I roll back
> to version 2.1, but 2.2 doesn't do anything (presumably nothing is matching
> the includes spec).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
