[jira] Closed: (DOXIASITETOOLS-39) Velocity > 1.5 can't parse default-site.vm
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig closed DOXIASITETOOLS-39. Resolution: Fixed Fix Version/s: 1.2 This has fixed the Gump build of doxia-site-renderer. It won't help with the other problems until the Maven plugins Cactus and other projects use have been updated, but this is not your business. As for the "fix version", I assumed trunk is going to be 1.2 one day. Thanks Lukas > Velocity > 1.5 can't parse default-site.vm > -- > > Key: DOXIASITETOOLS-39 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Doc renderer, Site renderer >Affects Versions: 1.0, 1.1 >Reporter: Stefan Bodewig >Priority: Minor > Fix For: 1.2 > > > This is an issue detected by Gump which runs Maven builds but replaces > dependencies with the trunk versions of things built by Gump rather than the > version a project asks for. > The Cargo build - see > http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html > - fails because Velocity doesn't like the line > #set ( $documentHeader = "" ) > because \" is not an escape sequence for Velocity (anymore?). > I've taken this to the velocity list - > http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e > - and received the feedback that backslash > escaping was not supported - and likely never has been - and you should > either use single > quotes inside the double quotes or use something like > #set( $Q = '"' ) > #set ( $documentHeader = " I realize that it probably works for you right now using Velocity 1.5, that's > why I used Improvement rather than bug as category. Still it may be worth to > find a solution that works for the version of Velocity you want to use as > well as future versions. -- 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] Created: (SUREFIRE-635) System properties are not reported in xml files
System properties are not reported in xml files --- Key: SUREFIRE-635 URL: http://jira.codehaus.org/browse/SUREFIRE-635 Project: Maven Surefire Issue Type: Improvement Components: xml generation Affects Versions: 2.5 Environment: Maven 2.2.1 Reporter: Michael Hinterseher Priority: Minor Calling Maven with system properties like "mvn test -Dmaven.test.failure.ignore=true -Dmaven.test.error.ignore=true" do show up in the generated xml files. Either there should be a single entry like or one per system property In the second case it would make sense to rename the tag to system_property to differentiate from regular properties. -- 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] Created: (MNG-4760) Way to activate profile based on Maven version
Way to activate profile based on Maven version -- Key: MNG-4760 URL: http://jira.codehaus.org/browse/MNG-4760 Project: Maven 2 & 3 Issue Type: New Feature Components: Profiles Affects Versions: 3.0-beta-2 Environment: n/a Reporter: Anders Hammar A profile activation that checks the version of Maven being used would be good. For example, the site plugin requires a different version when Maven 3 is used. Currently, this is done through a profile that activates based on teh fact that the basedir expression is only recognized by Maven 3.x, which is IMO a not-so-pretty solution. (See https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+and+site+plugin#Maven3.xandsiteplugin-Usingmavensiteplugin2.xwithMaven2.xandmavensiteplugin3.xwithMaven3.x) -- 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: (DOXIA-402) Multi-module project with .confluence content does not work
[ http://jira.codehaus.org/browse/DOXIA-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-402. --- Resolution: Not A Bug Assignee: Lukas Theussl > Multi-module project with .confluence content does not work > --- > > Key: DOXIA-402 > URL: http://jira.codehaus.org/browse/DOXIA-402 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.1.3 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_20 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac" >Reporter: Nathan Sowatskey >Assignee: Lukas Theussl >Priority: Blocker > Attachments: apt-site-test.zip, confluence-site-test.zip > > > There are two projects attached. > The apt-site-test has the parent content in apt format. When building a > multi-module project the content in the apt-site-test appears as expected. > The confluence-site-test has the parent content in confluence format. That > content does not appear as expected. Instead a generic "about" page is > created. -- 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: (DOXIASITETOOLS-39) Velocity > 1.5 can't parse default-site.vm
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIASITETOOLS-39: Fix Version/s: (was: 1.2) 1.1.4 Assignee: Lukas Theussl Current trunk is 1.1.4-snap so I changed the fix for. Don't know if/when we will release 1.2. Thanks! > Velocity > 1.5 can't parse default-site.vm > -- > > Key: DOXIASITETOOLS-39 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Doc renderer, Site renderer >Affects Versions: 1.0, 1.1 >Reporter: Stefan Bodewig >Assignee: Lukas Theussl >Priority: Minor > Fix For: 1.1.4 > > > This is an issue detected by Gump which runs Maven builds but replaces > dependencies with the trunk versions of things built by Gump rather than the > version a project asks for. > The Cargo build - see > http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html > - fails because Velocity doesn't like the line > #set ( $documentHeader = "" ) > because \" is not an escape sequence for Velocity (anymore?). > I've taken this to the velocity list - > http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e > - and received the feedback that backslash > escaping was not supported - and likely never has been - and you should > either use single > quotes inside the double quotes or use something like > #set( $Q = '"' ) > #set ( $documentHeader = " I realize that it probably works for you right now using Velocity 1.5, that's > why I used Improvement rather than bug as category. Still it may be worth to > find a solution that works for the version of Velocity you want to use as > well as future versions. -- 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] Created: (SUREFIRE-636) Wrong plugin parameter documentation for includes and excludes
Wrong plugin parameter documentation for includes and excludes -- Key: SUREFIRE-636 URL: http://jira.codehaus.org/browse/SUREFIRE-636 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Reporter: Eric Lewis Priority: Minor The documentation for the plugin parameters includes (http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#includes) and excludes (http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#excludes) states that it expects a "List of patterns (separated by commas) used to specify the tests that should be included/excluded in testing." However, that's not the case, as shown in http://maven.apache.org/plugins/maven-surefire-plugin/examples/inclusion-exclusion.html -- 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] Created: (WAGON-311) NPE and CommandExecutionException when creating directory over SSH
NPE and CommandExecutionException when creating directory over SSH
--
Key: WAGON-311
URL: http://jira.codehaus.org/browse/WAGON-311
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 1.0-beta-6
Environment: launching maven from PC under Windows XP
remote is under Linux Redhat 4
Reporter: David Pilato
Priority: Critical
When deploying site with mvn site:deploy on multi module project, I get really
often (about 90%) the following error :
[INFO]
[INFO] Building BANACO - Projet principal (POM)
[INFO]task-segment: [site:deploy]
[INFO]
[INFO] [site:deploy {execution: default-cli}]
scp://cdxlan025.douane:22/var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/
- Session: Opened
Executing command: mkdir -p
/var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/.
scp://cdxlan025.douane:22/var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/
- Session: Disconnecting
scp://cdxlan025.douane:22/var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/
- Session: Disconnected
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error uploading site
Embedded error: Error performing commands for file transfer
java.lang.NullPointerException
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading site
at
org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:229)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.wagon.TransferFailedException: Error performing
commands for file transfer
at
org.apache.maven.wagon.providers.ssh.ScpHelper.putDirectory(ScpHelper.java:232)
at
org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.putDirectory(AbstractJschWagon.java:360)
at
org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:215)
... 19 more
Caused by: org.apache.maven.wagon.CommandExecutionException: Cannot execute
remote command: mkdir -p
/var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/.
at
org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.executeCommand(AbstractJschWagon.java:326)
at
org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.executeCommand(AbstractJschWagon.java:379)
at
org.apache.maven.wagon.providers.ssh.ScpHelper.putDirectory(ScpHelper.java:228)
... 21 more
Caused by: com.jcraft.jsch.JSchException: java.lang.NullPointerException
at com.jcraft.jsch.Channel.connect(Channel.java:205)
[jira] Created: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect
Plugin-level dependency scope causes some plugin classpaths to be incorrect --- Key: MNG-4761 URL: http://jira.codehaus.org/browse/MNG-4761 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories, Plugins and Lifecycle Affects Versions: 3.0-beta-1, 2.2.1 Reporter: John Casey Attachments: obscured-nearer-dep.zip Plugin-level dependencies should use RUNTIME scope at all times. Using any other scope may alter the weighting given to the subgraph-choice algorithm used in transitive dependency resolution. Plugin-level dependencies use compile scope by default. When transitive resolution takes place, compile scope takes precedence over runtime scope, causing the transitive dependency sub-graph of the plugin-level dependency to be activated over those of the plugin itself. This happens even when the plugin's transitive dep is NEARER to the top level than the one brought in by that plugin-level dependency itself. The result is that when a dep that's farther away is chosen over a nearer one, it can then be disabled by Maven choosing to disable its parent dep (the one that brought it in) in another part of the transitive resolution process. This is a very subtle case where Maven is doing the wrong thing. The attached test case should make it clearer. -- 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: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect
[ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4761: Affects Version/s: 3.0-beta-2 > Plugin-level dependency scope causes some plugin classpaths to be incorrect > --- > > Key: MNG-4761 > URL: http://jira.codehaus.org/browse/MNG-4761 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2 >Reporter: John Casey > Attachments: obscured-nearer-dep.zip > > > Plugin-level dependencies should use RUNTIME scope at all times. Using any > other scope may alter the weighting given to the subgraph-choice algorithm > used in transitive dependency resolution. > Plugin-level dependencies use compile scope by default. When transitive > resolution takes place, compile scope takes precedence over runtime scope, > causing the transitive dependency sub-graph of the plugin-level dependency to > be activated over those of the plugin itself. > This happens even when the plugin's transitive dep is NEARER to the top level > than the one brought in by that plugin-level dependency itself. > The result is that when a dep that's farther away is chosen over a nearer > one, it can then be disabled by Maven choosing to disable its parent dep (the > one that brought it in) in another part of the transitive resolution process. > This is a very subtle case where Maven is doing the wrong thing. The attached > test case should make it clearer. -- 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: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect
[ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4761: Patch Submitted: [Yes] > Plugin-level dependency scope causes some plugin classpaths to be incorrect > --- > > Key: MNG-4761 > URL: http://jira.codehaus.org/browse/MNG-4761 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2 >Reporter: John Casey > Attachments: MNG-4761-mvn3b2.patch, obscured-nearer-dep.zip > > > Plugin-level dependencies should use RUNTIME scope at all times. Using any > other scope may alter the weighting given to the subgraph-choice algorithm > used in transitive dependency resolution. > Plugin-level dependencies use compile scope by default. When transitive > resolution takes place, compile scope takes precedence over runtime scope, > causing the transitive dependency sub-graph of the plugin-level dependency to > be activated over those of the plugin itself. > This happens even when the plugin's transitive dep is NEARER to the top level > than the one brought in by that plugin-level dependency itself. > The result is that when a dep that's farther away is chosen over a nearer > one, it can then be disabled by Maven choosing to disable its parent dep (the > one that brought it in) in another part of the transitive resolution process. > This is a very subtle case where Maven is doing the wrong thing. The attached > test case should make it clearer. -- 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: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect
[ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4761: Attachment: MNG-4761-mvn3b2.patch Patch to force all plugin-level dependencies to use scope: runtime. We could probably use a debug statement showing this scope being managed to runtime, but the patch works. > Plugin-level dependency scope causes some plugin classpaths to be incorrect > --- > > Key: MNG-4761 > URL: http://jira.codehaus.org/browse/MNG-4761 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2 >Reporter: John Casey > Attachments: MNG-4761-mvn3b2.patch, obscured-nearer-dep.zip > > > Plugin-level dependencies should use RUNTIME scope at all times. Using any > other scope may alter the weighting given to the subgraph-choice algorithm > used in transitive dependency resolution. > Plugin-level dependencies use compile scope by default. When transitive > resolution takes place, compile scope takes precedence over runtime scope, > causing the transitive dependency sub-graph of the plugin-level dependency to > be activated over those of the plugin itself. > This happens even when the plugin's transitive dep is NEARER to the top level > than the one brought in by that plugin-level dependency itself. > The result is that when a dep that's farther away is chosen over a nearer > one, it can then be disabled by Maven choosing to disable its parent dep (the > one that brought it in) in another part of the transitive resolution process. > This is a very subtle case where Maven is doing the wrong thing. The attached > test case should make it clearer. -- 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: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect
[ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4761: Attachment: MNG-4761-mvn3b2.reformatted.patch Fixed to remove unrelated reformats. > Plugin-level dependency scope causes some plugin classpaths to be incorrect > --- > > Key: MNG-4761 > URL: http://jira.codehaus.org/browse/MNG-4761 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2 >Reporter: John Casey >Assignee: John Casey > Attachments: MNG-4761-mvn3b2.patch, > MNG-4761-mvn3b2.reformatted.patch, obscured-nearer-dep.zip > > > Plugin-level dependencies should use RUNTIME scope at all times. Using any > other scope may alter the weighting given to the subgraph-choice algorithm > used in transitive dependency resolution. > Plugin-level dependencies use compile scope by default. When transitive > resolution takes place, compile scope takes precedence over runtime scope, > causing the transitive dependency sub-graph of the plugin-level dependency to > be activated over those of the plugin itself. > This happens even when the plugin's transitive dep is NEARER to the top level > than the one brought in by that plugin-level dependency itself. > The result is that when a dep that's farther away is chosen over a nearer > one, it can then be disabled by Maven choosing to disable its parent dep (the > one that brought it in) in another part of the transitive resolution process. > This is a very subtle case where Maven is doing the wrong thing. The attached > test case should make it clearer. -- 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: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect
[ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4761: Fix Version/s: 3.0-beta-3 > Plugin-level dependency scope causes some plugin classpaths to be incorrect > --- > > Key: MNG-4761 > URL: http://jira.codehaus.org/browse/MNG-4761 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2 >Reporter: John Casey >Assignee: John Casey > Fix For: 3.0-beta-3 > > Attachments: MNG-4761-mvn3b2.patch, > MNG-4761-mvn3b2.reformatted.patch, obscured-nearer-dep.zip > > > Plugin-level dependencies should use RUNTIME scope at all times. Using any > other scope may alter the weighting given to the subgraph-choice algorithm > used in transitive dependency resolution. > Plugin-level dependencies use compile scope by default. When transitive > resolution takes place, compile scope takes precedence over runtime scope, > causing the transitive dependency sub-graph of the plugin-level dependency to > be activated over those of the plugin itself. > This happens even when the plugin's transitive dep is NEARER to the top level > than the one brought in by that plugin-level dependency itself. > The result is that when a dep that's farther away is chosen over a nearer > one, it can then be disabled by Maven choosing to disable its parent dep (the > one that brought it in) in another part of the transitive resolution process. > This is a very subtle case where Maven is doing the wrong thing. The attached > test case should make it clearer. -- 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] Created: (MRELEASE-588) Improve snapshot dependency handling of parent artifacts
Improve snapshot dependency handling of parent artifacts
Key: MRELEASE-588
URL: http://jira.codehaus.org/browse/MRELEASE-588
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: prepare
Affects Versions: 2.0
Reporter: Elliot Metsger
This builds on the patch in MRELEASE-583, where the user is prompted for the
release version of snapshot dependencies.
However, when the snapshot dependency to be resolved is the parent artifact of
the project being released, the version supplied by the user is not used in the
transformed release version of the pom.
For example, I want to release the following:
{code}
org.dataconservancy
project-pom
1.0.0-SNAPSHOT
org.dataconservancy
parent-pom
1.0.0-SNAPSHOT
...
{code}
If I have MRELEASE-583 applied, I go through the snapshot resolution dialog:
{code}
There are still some remaining snapshot dependencies.: Do you want to resolve
them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project
Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :
Resolve Project Dependency Snapshots.: 'org.dataconservancy:parent-pom' set to
release? (yes/no) yes: : yes
What is the release version? 1.0.0: : 1.0.0-test
{code}
The resulting release pom doesn't use 1.0.0-test as the parent version. It
uses 1.0.0:
{code}
org.dataconservancy
project-pom
1.0.0-test
org.dataconservancy
parent-pom
1.0.0
...
{code}
--
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: (MRELEASE-588) Improve snapshot dependency handling of parent artifacts
[
http://jira.codehaus.org/browse/MRELEASE-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliot Metsger updated MRELEASE-588:
Attachment: Dependency_handling_of_parent_artifacts.patch
The attached patch updates the rewriteParent method of AbstractRewritePomsPhase
to use the dependency version supplied by the user.
maven-release-manager tests pass, and the maven-release-plugin tests and ITs
pass.
> Improve snapshot dependency handling of parent artifacts
>
>
> Key: MRELEASE-588
> URL: http://jira.codehaus.org/browse/MRELEASE-588
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
>Affects Versions: 2.0
>Reporter: Elliot Metsger
> Attachments: Dependency_handling_of_parent_artifacts.patch
>
>
> This builds on the patch in MRELEASE-583, where the user is prompted for the
> release version of snapshot dependencies.
> However, when the snapshot dependency to be resolved is the parent artifact
> of the project being released, the version supplied by the user is not used
> in the transformed release version of the pom.
> For example, I want to release the following:
> {code}
>
> org.dataconservancy
> project-pom
> 1.0.0-SNAPSHOT
>
> org.dataconservancy
> parent-pom
> 1.0.0-SNAPSHOT
>
> ...
>
> {code}
> If I have MRELEASE-583 applied, I go through the snapshot resolution dialog:
> {code}
> There are still some remaining snapshot dependencies.: Do you want to resolve
> them now? (yes/no) no: : yes
> Dependency type to resolve,: specify the selection number ( 0:All 1:Project
> Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :
> Resolve Project Dependency Snapshots.: 'org.dataconservancy:parent-pom' set
> to release? (yes/no) yes: : yes
> What is the release version? 1.0.0: : 1.0.0-test
> {code}
> The resulting release pom doesn't use 1.0.0-test as the parent version. It
> uses 1.0.0:
> {code}
>
> org.dataconservancy
> project-pom
> 1.0.0-test
>
> org.dataconservancy
> parent-pom
> 1.0.0
>
> ...
>
> {code}
--
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: (SUREFIRE-630) maven surefire plugin with parallels skips all tests when one test has @Ignore annotation (on mac os)
[
http://jira.codehaus.org/browse/SUREFIRE-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
alex fanshawe closed SUREFIRE-630.
--
Resolution: Fixed
Fix Version/s: 2.6
Passing with @Ignore at class and method level.
Tested against http://svn.apache.org/repos/asf/maven/surefire/tags/surefire-2.6
> maven surefire plugin with parallels skips all tests when one test has
> @Ignore annotation (on mac os)
> -
>
> Key: SUREFIRE-630
> URL: http://jira.codehaus.org/browse/SUREFIRE-630
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.5
> Environment: Using Java version: 1.5
> Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)
> Java version: 1.5.0_22
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "i386" Family: "unix"
>Reporter: alex fanshawe
> Fix For: 2.6
>
>
> using parallels on tests with @Ignore, ignores all test in the entire tests
> package.
> the test directory has 2 tests in it, one of them has @Ignore.
> here's our sample from the pom:
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> classes
>
>
>
> here's the mvn out put, without parallel and with:
> [INFO] Compiling 2 source files to
> /Users/dev/trunk/netstream/test-parallel/target/test-classes
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Concurrency config is {parallel=classes,
> configurableParallelComputerPresent=false}
> [INFO] Surefire report directory:
> /Users/dev/trunk/netstream/test-parallel/target/surefire-reports
> ---
> T E S T S
> ---
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> and with parallel commented out.
> [INFO] Compiling 2 source files to
> /Users/dev/trunk/netstream/test-parallel/target/test-classes
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> /Users/dev/trunk/netstream/test-parallel/target/surefire-reports
> ---
> T E S T S
> ---
> Running jackal.FirstTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.073 sec
> Running jackal.SecondTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec <<<
> FAILURE!
> Results :
> Failed tests:
> test(jackal.SecondTest)
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 1
--
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: (MRELEASE-583) Better Snapshot Dependency Handling
[ http://jira.codehaus.org/browse/MRELEASE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231688#action_231688 ] Elliot Metsger commented on MRELEASE-583: - I built on this patch in MRELEASE-588. When the dependency being resolved is the parent project, the user-supplied version is ignored when writing out the release pom; MRELEASE-588 updates AbstractRewritePomsPhase to include the resolved dependencies when re-writing the element of the release pom. > Better Snapshot Dependency Handling > --- > > Key: MRELEASE-583 > URL: http://jira.codehaus.org/browse/MRELEASE-583 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0 >Reporter: nicola sinapsi > Attachments: better-snapshot-dependency.patch > > > The plugin has a simple snapshot dependency resolution mechanism. > When a snapshot dependency is found, it allows for setting it to release... > but it does not allows to choice the release version to use: > > Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set > to release? (yes/no) yes: : yes > What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: : > > in this case the versions are: > current: 2.1.2-SNAPSHOT > release: 2.1.2 > next: 2.1.3-SNAPSHOT > The problem is that the only allowed development version is 2.1.3-SNAPSHOT > (the value between the parentheses), hence the only allowed release version > is 2.1.2. > Notably, you cannot specify an OLDER relase (such as 2.1.1): this means you > are forced to release the dependency (you cannot use an already released > version). > It would be better to ask for the release version to use, and then set the > snapshot as the release following the release version specified by the user: > > Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set > to release? (yes/no) yes: : yes > What is the release version? 2.1.2: : 2.3.0 > > in this case the versions are: > current: 2.1.2-SNAPSHOT > release: 2.3.0 > next: 2.3.1-SNAPSHOT > The plugin suggests to set the release version to 2.1.2, but the user can > choice another version, eventually an already released version. -- 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: (WAGON-311) NPE and CommandExecutionException when creating directory over SSH
[
http://jira.codehaus.org/browse/WAGON-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231697#action_231697
]
Dennis Lundberg commented on WAGON-311:
---
What version of Maven and the Site Plugin are you using?
> NPE and CommandExecutionException when creating directory over SSH
> --
>
> Key: WAGON-311
> URL: http://jira.codehaus.org/browse/WAGON-311
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 1.0-beta-6
> Environment: launching maven from PC under Windows XP
> remote is under Linux Redhat 4
>Reporter: David Pilato
>Priority: Critical
>
> When deploying site with mvn site:deploy on multi module project, I get
> really often (about 90%) the following error :
> [INFO]
>
> [INFO] Building BANACO - Projet principal (POM)
> [INFO]task-segment: [site:deploy]
> [INFO]
>
> [INFO] [site:deploy {execution: default-cli}]
> scp://cdxlan025.douane:22/var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/
> - Session: Opened
> Executing command: mkdir -p
> /var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/.
> scp://cdxlan025.douane:22/var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/
> - Session: Disconnecting
> scp://cdxlan025.douane:22/var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/
> - Session: Disconnected
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error uploading site
> Embedded error: Error performing commands for file transfer
> java.lang.NullPointerException
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading
> site
> at
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:229)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Error performing
> commands for file transfer
> at
> org.apache.maven.wagon.providers.ssh.ScpHelper.putDirectory(ScpHelper.java:232)
> at
> org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.putDirectory(AbstractJschWagon.java:360)
> at
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:215)
> ... 19 more
> Caused by: org.apache.maven.wagon.CommandExecutionException: Cannot execute
> remote command: mkdir -p
> /var/jboss/server/archiva/deploy/CID-PORTAIL-DEV.war/site/banaco/1.2.1-SNAPSHOT/.
> at
> org.apache.maven.wagon.providers.ssh.js
[jira] Commented: (SUREFIRE-329) Support for JUNIT extensions
[
http://jira.codehaus.org/browse/SUREFIRE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231703#action_231703
]
Matheus Cabral commented on SUREFIRE-329:
-
This issue is vital to the survival of JUnit. TestNG already supports groups
and JUnit now supports too. So why don't implement it?
> Support for JUNIT extensions
>
>
> Key: SUREFIRE-329
> URL: http://jira.codehaus.org/browse/SUREFIRE-329
> Project: Maven Surefire
> Issue Type: Wish
> Components: Junit 4.x support
>Reporter: Anuj Kathuria
> Fix For: Backlog
>
>
> Is there any plan to support using JUNIT extensions such as
> @Category,@PreRequisite with Maven2 SureFire plugin?
> The JUNIT EXTENSION URL:
> http://www.junitext.org/
> We would like to specify the categories to run via a configurable option in
> the maven surefire plugin that supports JUNIT extensions
> See example Java Code: The following runs only tests with Category - Z.
> //In JUnit4
> JUnitCore core = new JUnitCore();
> // use for categories special listener, give some statistics
> core.addListener(new CategoryTextListener(System.out));
> Request req = Request.aClass(SpcfTest.class);
> core.run(req.filterWith(new CategoryFilter("Z")));
--
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: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect
[ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-4761. --- Resolution: Fixed Fix Version/s: 2.2.2 all scopes EXCEPT system will be forced to runtime for plugin-level dependencies. > Plugin-level dependency scope causes some plugin classpaths to be incorrect > --- > > Key: MNG-4761 > URL: http://jira.codehaus.org/browse/MNG-4761 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.2.2, 3.0-beta-3 > > Attachments: MNG-4761-mvn3b2.patch, > MNG-4761-mvn3b2.reformatted.patch, obscured-nearer-dep.zip > > > Plugin-level dependencies should use RUNTIME scope at all times. Using any > other scope may alter the weighting given to the subgraph-choice algorithm > used in transitive dependency resolution. > Plugin-level dependencies use compile scope by default. When transitive > resolution takes place, compile scope takes precedence over runtime scope, > causing the transitive dependency sub-graph of the plugin-level dependency to > be activated over those of the plugin itself. > This happens even when the plugin's transitive dep is NEARER to the top level > than the one brought in by that plugin-level dependency itself. > The result is that when a dep that's farther away is chosen over a nearer > one, it can then be disabled by Maven choosing to disable its parent dep (the > one that brought it in) in another part of the transitive resolution process. > This is a very subtle case where Maven is doing the wrong thing. The attached > test case should make it clearer. -- 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: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect
[
http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231708#action_231708
]
Benjamin Bentmann commented on MNG-4761:
For future reference, the failing test scenario centeres around the following
dirty tree for the plugin depencencies:
{noformat}
plugin
+- override:0.1:compile
| \- middle:0.1:compile<---\
| \- required:0.1:compile<---\ |
+- direct:0.1:runtime(a)|
| +- required:0.1:runtime <---/ |
| \- middle:0.1:runtime<- (b)
| \- required:0.1:runtime |
\- middle:0.2:runtime <---/
{noformat}
During resolution of conflict (a), the node {{required:0.1:runtime}} will be
disabled in favor of {{required:0.1:compile}}, although the runtime-scope
dependency is nearer, i.e. Maven's usual conflict resolution strategy of
nearest-wins is violated here. When conflict (b) is resolved, all
{{middle:0.1:*}} nodes including their children will be disabled, thereby
completely losing {{required:0.1}} on the plugin class path.
So while using runtime scope for the project-level plugin dependencies
workarounds the problem, the issue remains for ordinary project dependency
resolution. I wonder if it got filled already.
> Plugin-level dependency scope causes some plugin classpaths to be incorrect
> ---
>
> Key: MNG-4761
> URL: http://jira.codehaus.org/browse/MNG-4761
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Plugins and Lifecycle
>Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.2.2, 3.0-beta-3
>
> Attachments: MNG-4761-mvn3b2.patch,
> MNG-4761-mvn3b2.reformatted.patch, obscured-nearer-dep.zip
>
>
> Plugin-level dependencies should use RUNTIME scope at all times. Using any
> other scope may alter the weighting given to the subgraph-choice algorithm
> used in transitive dependency resolution.
> Plugin-level dependencies use compile scope by default. When transitive
> resolution takes place, compile scope takes precedence over runtime scope,
> causing the transitive dependency sub-graph of the plugin-level dependency to
> be activated over those of the plugin itself.
> This happens even when the plugin's transitive dep is NEARER to the top level
> than the one brought in by that plugin-level dependency itself.
> The result is that when a dep that's farther away is chosen over a nearer
> one, it can then be disabled by Maven choosing to disable its parent dep (the
> one that brought it in) in another part of the transitive resolution process.
> This is a very subtle case where Maven is doing the wrong thing. The attached
> test case should make it clearer.
--
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: (MWAR-184) FATAL ERROR - XPP3 pull parser library not present. Specify another driver.
[
http://jira.codehaus.org/browse/MWAR-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MWAR-184:
-
Fix Version/s: (was: 2.1)
2.1-beta-2
> FATAL ERROR - XPP3 pull parser library not present. Specify another driver.
> -
>
> Key: MWAR-184
> URL: http://jira.codehaus.org/browse/MWAR-184
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-1
>Reporter: Matthew Corby-Eaglen
>Assignee: Stephane Nicoll
> Fix For: 2.1-beta-2
>
>
> building my project from a master build pom
> {noformat}
> These will use the artifact files already in the core ClassRealm instead, to
> allow them to be included in PluginDescriptor.getArtifacts().
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-war-plugin:2.1-alpha-1:war' -->
> [DEBUG] (s) archiveClasses = false
> [DEBUG] (s) cacheFile =
> /data/cruisecontrol/projects/MavenBuildModule-2-2-36/VcCasinoCapi/target/war/work/webapp-cache.xml
> [DEBUG] (s) classesDirectory =
> /data/cruisecontrol/projects/MavenBuildModule-2-2-36/VcCasinoCapi/target/classes
> [DEBUG] (s) filters = []
> [DEBUG] (f) outputDirectory =
> /data/cruisecontrol/projects/MavenBuildModule-2-2-36/VcCasinoCapi/target
> [DEBUG] (f) primaryArtifact = true
> [DEBUG] (s) project = MavenProject: com.vcint:VcCasinoCapi:2.2.36-SNAPSHOT
> @ /data/cruisecontrol/projects/MavenBuildModule-2-2-36/VcCasinoCapi/pom.xml
> [DEBUG] (s) useCache = true
> [DEBUG] (f) warName = VcCasinoCapi
> [DEBUG] (s) warSourceDirectory =
> /data/cruisecontrol/projects/MavenBuildModule-2-2-36/VcCasinoCapi/src/main/webapp
> [DEBUG] (s) webappDirectory =
> /data/cruisecontrol/projects/MavenBuildModule-2-2-36/VcCasinoCapi/target/VcCasinoCapi
> [DEBUG] (s) workDirectory =
> /data/cruisecontrol/projects/MavenBuildModule-2-2-36/VcCasinoCapi/target/war/work
> [DEBUG] -- end configuration --
> [INFO] [war:war]
> [INFO] Packaging webapp
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] XPP3 pull parser library not present. Specify another driver. For
> example: new XStream(new DomDriver())
> [INFO]
>
> [DEBUG] Trace
> java.lang.IllegalArgumentException: XPP3 pull parser library not present.
> Specify another driver. For example: new XStream(new DomDriver())
> at
> com.thoughtworks.xstream.io.xml.XppDriver.loadLibrary(XppDriver.java:42)
> at
> com.thoughtworks.xstream.io.xml.XppDriver.createReader(XppDriver.java:29)
> at com.thoughtworks.xstream.XStream.fromXML(XStream.java:781)
> at
> org.apache.maven.plugin.war.util.WebappStructureSerializer.fromXml(WebappStructureSerializer.java:48)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:346)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:317)
> at
> org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:166)
> at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>
[jira] Updated: (MWAR-158) Overlaying breaks configuration of webXml with a fatal error
[ http://jira.codehaus.org/browse/MWAR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MWAR-158: - Fix Version/s: (was: 2.1) 2.1-beta-2 > Overlaying breaks configuration of webXml with a fatal error > > > Key: MWAR-158 > URL: http://jira.codehaus.org/browse/MWAR-158 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-1 > Environment: Maven 2.0.9 > SuSE Linux 10.3 > java version "1.5.0_09" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03) > Java HotSpot(TM) Server VM (build 1.5.0_09-b03, mixed mode) >Reporter: Michael Heß >Assignee: Stephane Nicoll >Priority: Critical > Fix For: 2.1-beta-2 > > Attachments: webXmlBug.tar.gz > > > When using overlays, it is no longer possible to use the webXml configuration > value. The following exception is thrown: > [INFO] [war:war] > [INFO] Packaging webapp > [INFO] Assembling webapp[webXmlBug] in > [/home/mhe/workspace_spielwiese/webXmlBug/target/webXmlBug] > [INFO] Processing war project > OverlayPackagingTask performPackaging overlay.getTargetPath() null[INFO] > Processing overlay[ id de.ordix.webXmlBug:overlay] > [INFO] Unpacking overlay[ id de.ordix.webXmlBug:overlay] > [INFO] Expanding: > /home/mhe/.m2/repository/de/ordix/webXmlBug/overlay/1.0-SNAPSHOT/overlay-1.0-SNAPSHOT.war > into > /home/mhe/workspace_spielwiese/webXmlBug/target/war/work/de.ordix.webXmlBug/overlay > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Should not happen, path[WEB-INF/web.xml] is flagged as being > registered but was not found. > [INFO] > > [INFO] Trace > java.lang.IllegalStateException: Should not happen, path[WEB-INF/web.xml] is > flagged as being registered but was not found. > at > org.apache.maven.plugin.war.util.WebappStructure.getOwner(WebappStructure.java:157) > at > org.apache.maven.plugin.war.util.WebappStructure.registerFile(WebappStructure.java:105) > at > org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:140) > [...] > I have attached a testcase, which reproduces the problem. Just build overlay > and webXmlBug with "mvn clean install". > (I know the testcase is synthetic. If you want a "real world" scenario, just > replace the resources-copy step with e.g. jsp-precompiling.) -- 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: (MWAR-209) modelEncoding com.thoughtworks.xstream.mapper.CannotResolveClassException
[ http://jira.codehaus.org/browse/MWAR-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MWAR-209: - Fix Version/s: (was: 2.1) > modelEncoding com.thoughtworks.xstream.mapper.CannotResolveClassException > - > > Key: MWAR-209 > URL: http://jira.codehaus.org/browse/MWAR-209 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-beta-1 > Environment: Mac OS X 10.5, Java HotSpot(TM) 64-Bit Server VM (build > 11.3-b02-83, mixed mode) >Reporter: Benjamin Reed >Assignee: Stephane Nicoll > Attachments: model-failure.zip > > > I get the same error as MWAR-191, a CannotResolveClassException using Maven > 2.2.0 and the maven 2.x WAR plugin. > Originally we were getting the maven war plugin 2.1-alpha-2 because of some > other build environment stuff, but I've tried forcing it to 2.1-beta-1 for > this build and it still happens. If I force it to the 2.0.2 plugin, it > passes building. > Attached is mvn -X output using the 2.1-beta-1 WAR plugin. -- 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] Created: (MSITE-495) project.getDependencyArtifacts() returns null under forked multimodule report execution
project.getDependencyArtifacts() returns null under forked multimodule report execution --- Key: MSITE-495 URL: http://jira.codehaus.org/browse/MSITE-495 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 3.0-beta-1 Environment: Apache Maven 3.0-beta-2 (r983206; 2010-08-07 07:00:51-0400) Java version: 1.6.0_17 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" Reporter: Brian Jackson Attachments: test.zip Running 'mvn install site' on the attached multimodule project results in the following exception: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site (default-site) on project test: failed to get Reports: Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on project a: Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile failed. NullPointerException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site (default-site) on project test: failed to get Reports at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:152) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:86) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:58) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:252) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:100) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:443) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:166) at org.apache.maven.cli.MavenCli.main(MavenCli.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: failed to get Reports at org.apache.maven.plugins.site.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:225) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:208) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:105) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:144) ... 19 more Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on project a: Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:160) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:254) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:179) at org.apache.maven.plugins.site.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:210) ... 23 more Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:119) at org.apache.maven.lifecycle.internal.MojoExecutor
[jira] Updated: (MWAR-197) war:manifest does not add "manifestEntries" to generated manifest
[
http://jira.codehaus.org/browse/MWAR-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MWAR-197:
-
Description:
Team: As stated in the summary, the manifest goal doesnt seem to add any of the
manifestEntries to the generated manifest. Here is a testcase that I added to
the project which exposes the issue
{code:xml}
war-plugin-test
maven-war-plugin
${basedir}/target/test-classes/unit/manifest/manifest-with-custom-attrs/src/main
true
true
true
2.0
{code}
Expected: "Custom-Version" is expected in the manifest. But it not present in
the generated manifest
Actual:
Manifest-Version: 1.0
Created-By: Apache Maven
Built-By: nageshs
Build-Jdk: 1.6.0_07
Specification-Title: Test Project
Specification-Version: 0.0-Test
Specification-Vendor: Test Name
Implementation-Title: Test Project
Implementation-Version: 0.0-Test
Implementation-Vendor-Id: org.apache.maven.plugin.test
Implementation-Vendor: Test Name
I'm also attaching a fix along with a unit test to test the presence of the
custom manifest entry.
After the fix all tests pass and the "Custom-Version" is also included in the
manifest.
was:
Team: As stated in the summary, the manifest goal doesnt seem to add any of the
manifestEntries to the generated manifest. Here is a testcase that I added to
the project which exposes the issue
war-plugin-test
maven-war-plugin
${basedir}/target/test-classes/unit/manifest/manifest-with-custom-attrs/src/main
true
true
true
2.0
Expected: "Custom-Version" is expected in the manifest. But it not present in
the generated manifest
Actual:
Manifest-Version: 1.0
Created-By: Apache Maven
Built-By: nageshs
Build-Jdk: 1.6.0_07
Specification-Title: Test Project
Specification-Version: 0.0-Test
Specification-Vendor: Test Name
Implementation-Title: Test Project
Implementation-Version: 0.0-Test
Implementation-Vendor-Id: org.apache.maven.plugin.test
Implementation-Vendor: Test Name
I'm also attaching a fix along with a unit test to test the presence of the
custom manifest entry.
After the fix all tests pass and the "Custom-Version" is also included in the
manifest.
> war:manifest does not add "manifestEntries" to generated manifest
> -
>
> Key: MWAR-197
> URL: http://jira.codehaus.org/browse/MWAR-197
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2, 2.1-alpha-1, 2.1-alpha-2, 2.1-beta-1
>Reporter: Nagesh Susarla
> Attachments: unit_test_to_add.patch, WarManifestMojo.patch
>
>
> Team: As stated in the summary, the manifest goal doesnt seem to add any of
> the manifestEntries to the generated manifest. Here is a testcase that I
> added to the project which exposes the issue
> {code:xml}
>
> war-plugin-test
>
>
>
> maven-war-plugin
>
>implementation="org.apache.maven.plugin.war.stub.MavenProjectBasicStub"/>
>
>
> ${basedir}/target/test-classes/unit/manifest/manifest-with-custom-attrs/src/main
>
>
> true
>
> true
>
> true
>
>
> 2.0
>
>
>
>
>
>
>
> {code}
> Expected: "Custom-Version" is expected in the manifest. But it not present in
> the generated manifest
> Actual:
> Manifest-Version: 1.0
> Created-By: Apache Maven
> Built-By: nageshs
> Build-Jdk: 1.6.0_07
> Specification-Title: Test Project
> Specification-Version: 0.0-Test
> Specification-Vendor: Test Name
> Implementation-Title: Test Project
> Implementation-Version: 0.0-Test
> Implementation-Vendor-Id: org.apache.maven.plugin.test
> Implementation-Vendor: Test Name
> I'm also attaching a fix along with a unit test to test the presence of the
> custom manifest entry.
> After the fix all tests pass and the "Custom-Version" is also included in the
> manifest.
--
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: (MSITE-495) project.getDependencyArtifacts() returns null under forked multimodule report execution
[ http://jira.codehaus.org/browse/MSITE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231715#action_231715 ] Dennis Lundberg commented on MSITE-495: --- The stack trace indicates an NPE in the AspectJ Plugin. Shall I move this issue over there? > project.getDependencyArtifacts() returns null under forked multimodule report > execution > --- > > Key: MSITE-495 > URL: http://jira.codehaus.org/browse/MSITE-495 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0-beta-1 > Environment: Apache Maven 3.0-beta-2 (r983206; 2010-08-07 > 07:00:51-0400) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" >Reporter: Brian Jackson > Attachments: test.zip > > > Running 'mvn install site' on the attached multimodule project results in the > following exception: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site (default-site) on > project test: failed to get Reports: Failed to execute goal > org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on project a: > Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile > failed. NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site > (default-site) on project test: failed to get Reports > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:152) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:86) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:58) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:252) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:100) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:443) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:166) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: failed to get > Reports > at > org.apache.maven.plugins.site.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:225) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:208) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:105) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:144) > ... 19 more > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on > project a: Execution default of goal > org.codehaus.mojo:aspectj-maven-plugin:1.3:compile failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:160) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) > at > org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:254) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:179) > at > org.apa
[jira] Commented: (MSITE-495) project.getDependencyArtifacts() returns null under forked multimodule report execution
[ http://jira.codehaus.org/browse/MSITE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231716#action_231716 ] Brian Jackson commented on MSITE-495: - mvn compile and install work fine, its when the AspectJ plugin is run during the forked process (forked because of the Javadoc report) that it fails. That's why I reported it here, since the root cause seems to be in how site 3.x is forking the process. But you know better than I, I just wanted to make sure it was reported. > project.getDependencyArtifacts() returns null under forked multimodule report > execution > --- > > Key: MSITE-495 > URL: http://jira.codehaus.org/browse/MSITE-495 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0-beta-1 > Environment: Apache Maven 3.0-beta-2 (r983206; 2010-08-07 > 07:00:51-0400) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" >Reporter: Brian Jackson > Attachments: test.zip > > > Running 'mvn install site' on the attached multimodule project results in the > following exception: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site (default-site) on > project test: failed to get Reports: Failed to execute goal > org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on project a: > Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile > failed. NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site > (default-site) on project test: failed to get Reports > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:152) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:86) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:58) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:252) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:100) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:443) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:166) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: failed to get > Reports > at > org.apache.maven.plugins.site.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:225) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:208) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:105) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:144) > ... 19 more > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on > project a: Execution default of goal > org.codehaus.mojo:aspectj-maven-plugin:1.3:compile failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:160) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) > at > org.apa
[jira] Commented: (MSITE-495) project.getDependencyArtifacts() returns null under forked multimodule report execution
[ http://jira.codehaus.org/browse/MSITE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231717#action_231717 ] Brian Jackson commented on MSITE-495: - To be clear, AjcHelper.java:70 is a call to MavenProject.getDependencyArtifacts() which is erroneously returning null during the forked process even though @requiresDependencyResolution is declared by the AjcCompileMojo. > project.getDependencyArtifacts() returns null under forked multimodule report > execution > --- > > Key: MSITE-495 > URL: http://jira.codehaus.org/browse/MSITE-495 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0-beta-1 > Environment: Apache Maven 3.0-beta-2 (r983206; 2010-08-07 > 07:00:51-0400) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" >Reporter: Brian Jackson > Attachments: test.zip > > > Running 'mvn install site' on the attached multimodule project results in the > following exception: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site (default-site) on > project test: failed to get Reports: Failed to execute goal > org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on project a: > Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile > failed. NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site > (default-site) on project test: failed to get Reports > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:152) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:86) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:58) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:252) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:100) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:443) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:166) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: failed to get > Reports > at > org.apache.maven.plugins.site.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:225) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:208) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:105) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:144) > ... 19 more > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on > project a: Execution default of goal > org.codehaus.mojo:aspectj-maven-plugin:1.3:compile failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:160) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) > at > org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:254) > at > org
[jira] Commented: (MSITE-495) project.getDependencyArtifacts() returns null under forked multimodule report execution
[ http://jira.codehaus.org/browse/MSITE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231719#action_231719 ] Dennis Lundberg commented on MSITE-495: --- Thanks for clarifying Brian. We'll leave it here for now. > project.getDependencyArtifacts() returns null under forked multimodule report > execution > --- > > Key: MSITE-495 > URL: http://jira.codehaus.org/browse/MSITE-495 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0-beta-1 > Environment: Apache Maven 3.0-beta-2 (r983206; 2010-08-07 > 07:00:51-0400) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" >Reporter: Brian Jackson > Attachments: test.zip > > > Running 'mvn install site' on the attached multimodule project results in the > following exception: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site (default-site) on > project test: failed to get Reports: Failed to execute goal > org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on project a: > Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile > failed. NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site > (default-site) on project test: failed to get Reports > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:152) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:86) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:58) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:252) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:100) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:443) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:166) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: failed to get > Reports > at > org.apache.maven.plugins.site.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:225) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:208) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:105) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:144) > ... 19 more > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on > project a: Execution default of goal > org.codehaus.mojo:aspectj-maven-plugin:1.3:compile failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:160) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) > at > org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:254) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:179) > at > org.apache.maven.plugins.site.DefaultMave
[jira] Closed: (MWAR-197) war:manifest does not add "manifestEntries" to generated manifest
[
http://jira.codehaus.org/browse/MWAR-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MWAR-197.
Resolution: Fixed
Fix Version/s: 2.1-beta-2
Assignee: Dennis Lundberg
Fixed in [r984603|http://svn.apache.org/viewvc?view=revision&revision=984603].
Thanks for the patches!
> war:manifest does not add "manifestEntries" to generated manifest
> -
>
> Key: MWAR-197
> URL: http://jira.codehaus.org/browse/MWAR-197
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2, 2.1-alpha-1, 2.1-alpha-2, 2.1-beta-1
>Reporter: Nagesh Susarla
>Assignee: Dennis Lundberg
> Fix For: 2.1-beta-2
>
> Attachments: unit_test_to_add.patch, WarManifestMojo.patch
>
>
> Team: As stated in the summary, the manifest goal doesnt seem to add any of
> the manifestEntries to the generated manifest. Here is a testcase that I
> added to the project which exposes the issue
> {code:xml}
>
> war-plugin-test
>
>
>
> maven-war-plugin
>
>implementation="org.apache.maven.plugin.war.stub.MavenProjectBasicStub"/>
>
>
> ${basedir}/target/test-classes/unit/manifest/manifest-with-custom-attrs/src/main
>
>
> true
>
> true
>
> true
>
>
> 2.0
>
>
>
>
>
>
>
> {code}
> Expected: "Custom-Version" is expected in the manifest. But it not present in
> the generated manifest
> Actual:
> Manifest-Version: 1.0
> Created-By: Apache Maven
> Built-By: nageshs
> Build-Jdk: 1.6.0_07
> Specification-Title: Test Project
> Specification-Version: 0.0-Test
> Specification-Vendor: Test Name
> Implementation-Title: Test Project
> Implementation-Version: 0.0-Test
> Implementation-Vendor-Id: org.apache.maven.plugin.test
> Implementation-Vendor: Test Name
> I'm also attaching a fix along with a unit test to test the presence of the
> custom manifest entry.
> After the fix all tests pass and the "Custom-Version" is also included in the
> manifest.
--
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-215) class file JAR inconsistency (archiveClasses and attachClasses options)
[
http://jira.codehaus.org/browse/MWAR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231722#action_231722
]
Dennis Lundberg commented on MWAR-215:
--
Usually when we change the behavior of a feature, the old behavior is the
default. If someone wants the new behavior the need to change their
configuration. That way we maintain backwards compatibility. So option 2 is
what we want.
> class file JAR inconsistency (archiveClasses and attachClasses options)
> ---
>
> Key: MWAR-215
> URL: http://jira.codehaus.org/browse/MWAR-215
> Project: Maven 2.x WAR Plugin
> Issue Type: Improvement
>Affects Versions: 2.1-beta-1
>Reporter: Neeme Praks
> Attachments: maven-WAR-plugin-classes.patch
>
>
> Copy-paste from
> http://article.gmane.org/gmane.comp.jakarta.turbine.maven.devel/94789
> {quote}
> I have a couple of issues with the current WAR plugin and the way it
> packages class files in JAR files (archiveClasses and attachClasses
> configuration options), as these two options work independently of each
> other:
> * archiveClasses moves all class files (and related resources) from
> "classes" directory to JAR file inside WEB-INF/lib directory
> * attachClasses creates a new JAR file in "target" directory from same
> set of files and attaches it to the Maven project with some qualifier
> (by default it uses "classes" qualifier)
> When we deploy artifacts to Maven repository, this results in two
> different JAR files being deployed: one inside WAR and the other
> separate from WAR.
> Problems with this approach:
> * two different JAR files with different MD5/SHA1 checksums.
> * the naming convention for these two JAR files is different
> These issues really start to snag you when you need to perform updates
> after the initial deploy of the WAR. Consider the following scenario:
> * development team hands WAR artifact over to deployment team for deployment
> * development team needs to give an update to the webapp code (the
> dependencies have not changed). One approach is to give the whole WAR
> again, but a more reasonable approach would be to give only JAR file, as
> it contains all the changes and dependent JARs have not changed.
> Whole-WAR-approach becomes especially problematic, when the update needs
> to be uploaded over slow network links and you are in a hurry. However,
> giving only JAR file presents us with some problems:
> # there is no easy way to check the currently deployed webapp JAR
> version, as the checksum of the embedded JAR file does not match any
> other JAR file in the Maven repository.
> # as the naming convention differs, it is going to confuse the
> deployment team
> Solution to this mess? Unify the way "archiveClasses" and
> "attachClasses" functionalities work, so they would operate on the same
> JAR file. The way this would work:
> * if "archiveClasses" option is specified, it moves all class files to
> JAR file inside WEB-INF/lib directory (same as before). It would use the
> same naming convention as regular Maven JAR artifacts, with some qualifier.
> * if "attachClasses" option is specified, it attaches that same JAR
> file (as created in previous point) to the Maven project.
> * if "attachClasses" is specified, but no "archiveClasses" - nothing
> happens. Or maybe we should then implicitly turn on also the
> "archiveClasses" option?
> This has some implications for backwards compatibility:
> * naming convention of the embedded JAR file is changed
> * the attached JAR file is no longer created in the "target"
> directory, next to the WAR file (it is now attached directly from
> WEB-INF/lib directory)
> {quote}
--
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: (MWAR-167) Final manifest not written to exploded location
[ http://jira.codehaus.org/browse/MWAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MWAR-167: - Patch Submitted: [Yes] > Final manifest not written to exploded location > --- > > Key: MWAR-167 > URL: http://jira.codehaus.org/browse/MWAR-167 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-1 >Reporter: Paul Benedict >Priority: Minor > Attachments: mvn167-with-it.diff, patch.diff > > > When I open up my generated WAR file, the Manifest file contains all the > entries I specified. This is correct. However, when I look into the exploded > location, it's just the file I had in my project to begin with. > The exploded Manifest should be updated with the final contents. -- 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: (MWAR-205) A useDefaultExcludes=false option, like the assembly plugin has.
[
http://jira.codehaus.org/browse/MWAR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MWAR-205:
-
Description:
I'd like to be able to have a 'development' profile which I configure to
_include_ all versioning files. I'm dealing with complicated overlays, and
sometimes it's simply easiest to fix a jsp or so directly on the spot where it
is deployed, on the test-server or so, and check it in from there too.
Probably I could also change our habits or so, and find some way of working
which is more or less handy too, but for the moment I have no idea how that
would go, and everything would work just fine if the 'useDefaultExcludes'
feature can be disabled with a configuration option.
I tried to implement it myself, and am attaching a patch, which includes such
an option.
{code:xml}
org.apache.maven.plugins
maven-war-plugin
2.1-beta-2-SNAPSHOT
false
{code}
was:
I'd like to be able to have a 'development' profile which I configure to
_include_ all versioning files. I'm dealing with complicated overlays, and
sometimes it's simply easiest to fix a jsp or so directly on the spot where it
is deployed, on the test-server or so, and check it in from there too.
Probably I could also change our habits or so, and find some way of working
which is more or less handy too, but for the moment I have no idea how that
would go, and everything would work just fine if the 'useDefaultExcludes'
feature can be disabled with a configuration option.
I tried to implement it myself, and am attaching a patch, which includes such
an option.
org.apache.maven.plugins
maven-war-plugin
2.1-beta-2-SNAPSHOT
false
> A useDefaultExcludes=false option, like the assembly plugin has.
>
>
> Key: MWAR-205
> URL: http://jira.codehaus.org/browse/MWAR-205
> Project: Maven 2.x WAR Plugin
> Issue Type: New Feature
>Affects Versions: 2.1-beta-1
> Environment: Linux, tomcat6.
>Reporter: Michiel Meeuwissen
> Attachments: useDefaultExcludes.patch
>
>
> I'd like to be able to have a 'development' profile which I configure to
> _include_ all versioning files. I'm dealing with complicated overlays, and
> sometimes it's simply easiest to fix a jsp or so directly on the spot where
> it is deployed, on the test-server or so, and check it in from there too.
> Probably I could also change our habits or so, and find some way of working
> which is more or less handy too, but for the moment I have no idea how that
> would go, and everything would work just fine if the 'useDefaultExcludes'
> feature can be disabled with a configuration option.
> I tried to implement it myself, and am attaching a patch, which includes such
> an option.
> {code:xml}
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.1-beta-2-SNAPSHOT
>
> false
>
>
> {code}
--
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: (SUREFIRE-321) Run tests in alphabetical order
[ http://jira.codehaus.org/browse/SUREFIRE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231723#action_231723 ] Rafael Chaves commented on SUREFIRE-321: +1 We have seen tests running at different order on the same machine and that completely breaks expectations about repeatability, which are paramount to automated testing. Isolation issues in test cases become impossible to address. > Run tests in alphabetical order > --- > > Key: SUREFIRE-321 > URL: http://jira.codehaus.org/browse/SUREFIRE-321 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Daniel Beland >Priority: Minor > Fix For: Backlog > > Attachments: SUREFIRE-243.patch, SUREFIRE-321.patch > > > It would be nice if the tests were run in alphabetical order (with complete > package name). > So all tests in a package run in order and same things for each packages. > It just makes it easier to know where we currently are in the tests and makes > it easier to estimate how long it will take before the tests finish to run. -- 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] Created: (MWAR-230) archive configuration ignored for unpacked war
archive configuration ignored for unpacked war
--
Key: MWAR-230
URL: http://jira.codehaus.org/browse/MWAR-230
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-2
Reporter: Benson Margulies
I have added configuration information to my POM to add an entry to my WAR's
manifest.
And, indeed, it appears correctly in the manifest in the .war file.
However, there is also an unpacked war that is delivered by default. It also
has a manifest, and that manifest does not include my extra entry.
Since all of this results from the default execution from
war I don't see where else I should have to add this
configuration.
{code}
org.apache.maven.plugins
maven-war-plugin
true
${buildNumber}
com.basistech.jug
gate-home
gate-home
zip
WEB-INF
{code}
--
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-230) archive configuration ignored for unpacked war
[
http://jira.codehaus.org/browse/MWAR-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231728#action_231728
]
Benson Margulies commented on MWAR-230:
---
2.1-beta-1 doesn't deliver an unpacked MANIFEST.MF at all. It would be better,
in my opinion, if it deliver a correct one.
> archive configuration ignored for unpacked war
> --
>
> Key: MWAR-230
> URL: http://jira.codehaus.org/browse/MWAR-230
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-2
>Reporter: Benson Margulies
>
> I have added configuration information to my POM to add an entry to my WAR's
> manifest.
> And, indeed, it appears correctly in the manifest in the .war file.
> However, there is also an unpacked war that is delivered by default. It also
> has a manifest, and that manifest does not include my extra entry.
> Since all of this results from the default execution from
> war I don't see where else I should have to add this
> configuration.
> {code}
>
> org.apache.maven.plugins
> maven-war-plugin
>
>
>
>true
>
>
>${buildNumber}
>
>
>
>
>com.basistech.jug
>gate-home
>gate-home
>zip
>WEB-INF
>
>
>
>
> {code}
--
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: (MRELEASE-318) Release plugin throws NullPointerException when using version range for dependency
[ http://jira.codehaus.org/browse/MRELEASE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231734#action_231734 ] Elliot Metsger commented on MRELEASE-318: - Is there an update on this issue? I just got hit with this bug using Maven 2.2.1 and Release plugin version 2.0. Grrr. > Release plugin throws NullPointerException when using version range for > dependency > -- > > Key: MRELEASE-318 > URL: http://jira.codehaus.org/browse/MRELEASE-318 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-7 >Reporter: David Hoffer >Priority: Blocker > Attachments: MNG-3351-unittest.patch, MNG-3351.zip, > MNG-3351_dependency_poms.zip, simple-test-case-console-log.txt, > simple-testcase.zip > > > After upgrading to 2.0.8 I find that the release plugin throws NPE if any > dependency uses version range. > I have one dependency with version range [1.0,2.0) the > rest are test scope with fixed version. > Here is the crash stack trace: > java.lang.NullPointerException: version was null for > com.xrite:xrite-colorlib-api > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > [13:42:05]: at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > [13:42:05]: at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [13:42:05]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [13:42:05]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597) > [13:42:05]: at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > [13:42:05]: at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > It seems the reason version is null is that the call to > selectVersionFromNewRangeIfAvailable() assumes that > versionRange.getRecommendedVersion() will always return non-null, else it > sets the version to null! However during the release:prepare phase this is > not true, see the output: > [13:42:04]: [INFO] [release:prepare] > [13:42:04]: [INFO] Verifying that there are no local modifications... > [13:42:04]: [INFO] Executing: svn --non-interactive status > [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843 > [13:42:05]: [INFO] Checking dependencies and plugins for snapshots ... > [13:42:05]: TEST!!! version=null > [13:42:05]: TEST!!! versionRange=[1.0,2.0) > [13:42:05]: TEST!!! getRecommendedVersion=null > TEST!!! Lines are my test code so I could see what is going on here. --
[jira] Commented: (MWAR-230) archive configuration ignored for unpacked war
[
http://jira.codehaus.org/browse/MWAR-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231738#action_231738
]
Dennis Lundberg commented on MWAR-230:
--
What do you mean when you say "an unpacked war" is delivered? Where is it
delivered?
There is a goal that can create a manifest for you called "war:manifest", is
that something that you can use? I fixed MWAR-197 yesterday related to manifest
entries not working for "war:manifest".
> archive configuration ignored for unpacked war
> --
>
> Key: MWAR-230
> URL: http://jira.codehaus.org/browse/MWAR-230
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-2
>Reporter: Benson Margulies
>
> I have added configuration information to my POM to add an entry to my WAR's
> manifest.
> And, indeed, it appears correctly in the manifest in the .war file.
> However, there is also an unpacked war that is delivered by default. It also
> has a manifest, and that manifest does not include my extra entry.
> Since all of this results from the default execution from
> war I don't see where else I should have to add this
> configuration.
> {code}
>
> org.apache.maven.plugins
> maven-war-plugin
>
>
>
>true
>
>
>${buildNumber}
>
>
>
>
>com.basistech.jug
>gate-home
>gate-home
>zip
>WEB-INF
>
>
>
>
> {code}
--
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
