[jira] Moved: (MNG-2878) NPE when run with Maven 2.1-SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Massol moved MCHECKSTYLE-72 to MNG-2878:
Affects Version/s: (was: 2.2)
2.1-alpha-1
Complexity: Intermediate
Key: MNG-2878 (was: MCHECKSTYLE-72)
Project: Maven 2 (was: Maven 2.x Checkstyle Plugin)
> NPE when run with Maven 2.1-SNAPSHOT
>
>
> Key: MNG-2878
> URL: http://jira.codehaus.org/browse/MNG-2878
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.1-alpha-1
> Environment: Maven 2.1 built from trunk on 15 March 2007, 10:00AM
> Checkstyle plugin built from trunk on 15 March 2007, 11:20
>Reporter: Vincent Massol
>
> I get:
> {code}
> [INFO] An error has occurred in Checkstyle report generation.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred
> in Checkstyle report generation.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:524)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:862)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:699)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:440)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:419)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:271)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:238)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:146)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:303)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:907)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:369)
> 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
> occurred in Checkstyle report generation.
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:79)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:598)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:499)
> ... 20 more
> Caused by: java.lang.NullPointerException
> at java.io.Reader.(Reader.java:61)
> at java.io.InputStreamReader.(InputStreamReader.java:55)
> at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:248)
> at org.codehaus.plexus.util.IOUtil.toString(IOUtil.java:307)
> at org.codehaus.plexus.util.IOUtil.toString(IOUtil.java:295)
> at
> org.apache.maven.reporting.AbstractMavenReport.getSiteDescriptor(AbstractMavenReport.java:134)
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:70)
> ... 22 more
> {code}
> The POM I used:
> {code}
>
>
>
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>
>
> com.xpn.xwiki
> xwiki-build-verifications
> 1.0-SNAPSHOT
>
>
>
>
> **/Api.java,
> **/xmlrpc/Attachment.java,
> **/xmlrpc/SpaceSummary.java,
> **/ViewAction.java,
> **/ZipExplorer*.java,
> **/content/**/*.java,
> **/XWikiMessageTool.java
>
>
>
>
>
> {code}
> Thanks
> -Vin
[jira] Updated: (MNG-2878) NPE when run with Maven 2.1-SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Massol updated MNG-2878:
Fix Version/s: 2.1-alpha-1
- I've moved this from the checkstyle plugin as it works in Maven 2.0.5 but
fails with 2.1-SNAPSHOT.
- I wasn't sure what "affects" version I should put
- Jason asked me to put a fix for of 2.1-alpha-1
> NPE when run with Maven 2.1-SNAPSHOT
>
>
> Key: MNG-2878
> URL: http://jira.codehaus.org/browse/MNG-2878
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.1-alpha-1
> Environment: Maven 2.1 built from trunk on 15 March 2007, 10:00AM
> Checkstyle plugin built from trunk on 15 March 2007, 11:20
>Reporter: Vincent Massol
> Fix For: 2.1-alpha-1
>
>
> I get:
> {code}
> [INFO] An error has occurred in Checkstyle report generation.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred
> in Checkstyle report generation.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:524)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:862)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:699)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:440)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:419)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:271)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:238)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:146)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:303)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:907)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:369)
> 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
> occurred in Checkstyle report generation.
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:79)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:598)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:499)
> ... 20 more
> Caused by: java.lang.NullPointerException
> at java.io.Reader.(Reader.java:61)
> at java.io.InputStreamReader.(InputStreamReader.java:55)
> at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:248)
> at org.codehaus.plexus.util.IOUtil.toString(IOUtil.java:307)
> at org.codehaus.plexus.util.IOUtil.toString(IOUtil.java:295)
> at
> org.apache.maven.reporting.AbstractMavenReport.getSiteDescriptor(AbstractMavenReport.java:134)
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:70)
> ... 22 more
> {code}
> The POM I used:
> {code}
>
>
>
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>
>
> com.xpn.xwiki
> xwiki-build-verifications
> 1.0-SNAPSHOT
>
>
>
>
> **/Api.java,
> **/xmlrpc/Attachment.java,
> **/xmlrpc/SpaceSummary.java,
> **/ViewAction.java,
> **/ZipExplorer*.java,
> **/content/**/*.java,
> **/XWikiMessageTool.java
>
>
>
>
>
> {code}
> Tha
[jira] Updated: (MECLIPSE-213) more jee support for wtp
[ http://jira.codehaus.org/browse/MECLIPSE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard van Nieuwenhoven updated MECLIPSE-213: -- Attachment: maven-eclipse-plugin-2.3-CFC-2007-03-08.patch this is the patch that i use to * create eclipse- only manifests * to define the eclipse lib directory equal to the maven ear lib directory * to generate the project names as artifact names (including version) * to generate a WTP able application.xml to activate the extentions add: * -Declipse.wtpmanifest=true * -Declipse.wtpapplicationxml=true * -Declipse.addVersionToProjectName=true > more jee support for wtp > > > Key: MECLIPSE-213 > URL: http://jira.codehaus.org/browse/MECLIPSE-213 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8 >Reporter: Richard van Nieuwenhoven > Attachments: maven-eclipse-plugin-2.3-CFC-2007-03-08.patch, > maven-eclipse-plugin-R494407.patch > > > I tried the new release 2.3 of the eclipse plugin and noteted that not alle > of my paches where included. > I re-pached the 2.3 version again this time i made my changes configurable so > they can be turned on and off. > my changes: > - prohibit dupicate entries in the classpath > provided system paths in combination with log4j/commons-logging/xerces > can easely create such problems > - system paths are only included in ears and war when they are inside the > project >bether behavior would be to exclude all system paths because the war and > ear plugin also ignore these > - an application.xml specialy for eclipse-wtp >this makes wtp ears function correctly it includes the eclipse project > modules instead of the maven generated jars > - manifest generation for wtp >wtp needs manifest files, but not the ones maven creates because they have > version names for all modules etc >this generates a wtp manifest that will be in a ons eclipse source > directory that is ignored my maven itself > use the parameters -Declipse.wtpmanifest=true > -Declipse.wtpapplicationxml=true to acivate the patch. > The manifest generator could be combined with the RadManifestWriter in the > future, they are almost the same. > regards, > Ritchie -- 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: (MECLIPSE-213) more jee support for wtp
[ http://jira.codehaus.org/browse/MECLIPSE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard van Nieuwenhoven updated MECLIPSE-213: -- Attachment: maven-eclipse-plugin-2.3-PATCH-2007-03-08.tgz This is the pre build version of the patch for anyone who wants to try it. > more jee support for wtp > > > Key: MECLIPSE-213 > URL: http://jira.codehaus.org/browse/MECLIPSE-213 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8 >Reporter: Richard van Nieuwenhoven > Attachments: maven-eclipse-plugin-2.3-CFC-2007-03-08.patch, > maven-eclipse-plugin-2.3-PATCH-2007-03-08.tgz, > maven-eclipse-plugin-R494407.patch > > > I tried the new release 2.3 of the eclipse plugin and noteted that not alle > of my paches where included. > I re-pached the 2.3 version again this time i made my changes configurable so > they can be turned on and off. > my changes: > - prohibit dupicate entries in the classpath > provided system paths in combination with log4j/commons-logging/xerces > can easely create such problems > - system paths are only included in ears and war when they are inside the > project >bether behavior would be to exclude all system paths because the war and > ear plugin also ignore these > - an application.xml specialy for eclipse-wtp >this makes wtp ears function correctly it includes the eclipse project > modules instead of the maven generated jars > - manifest generation for wtp >wtp needs manifest files, but not the ones maven creates because they have > version names for all modules etc >this generates a wtp manifest that will be in a ons eclipse source > directory that is ignored my maven itself > use the parameters -Declipse.wtpmanifest=true > -Declipse.wtpapplicationxml=true to acivate the patch. > The manifest generator could be combined with the RadManifestWriter in the > future, they are almost the same. > regards, > Ritchie -- 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: (MECLIPSE-107) Dependency Version Incorrectly Taken from DependencyManagement
[
http://jira.codehaus.org/browse/MECLIPSE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90243
]
Damien Lecan commented on MECLIPSE-107:
---
I checked out last source code of maven-eclipse-plugin, svn revision 494359
Fix doesn't work :
- neither on my real projects,
- nor on dmtest.zip provided test case
- nor on MECLIPSE-107-maven-eclipse-plugin-20061211-1200.patch provided test
case too.
Debug logs on dmtest.zip provided with this bug :
{noformat}...
[INFO] Reactor build order:
[INFO] Unnamed - com.stephenduncanjr:dmtest:pom:1.0-SNAPSHOT
[INFO] Unnamed - com.stephenduncanjr:dmtest-child:jar:1.0-SNAPSHOT
...
[DEBUG]
org.apache.maven.plugins:maven-eclipse-plugin:maven-plugin:2.4-SNAPSHOT:runtime
(selected for runtime)
...
[INFO] [eclipse:eclipse]
[DEBUG] com.stephenduncanjr:dmtest-child:jar:1.0-SNAPSHOT (selected for null)
[DEBUG] log4j:log4j:jar:1.2.13:compile (applying version: 1.2.8;)
[DEBUG] log4j:log4j:jar:1.2.8:compile (selected for compile)
...
{noformat}
In com.stephenduncanjr:dmtest-child, log4j:log4j:jar:1.2.13 should have been
used, but the plugin still wants to select version 1.2.8.
In the .classpath file of child module, I get that :
{noformat}
{noformat}
> Dependency Version Incorrectly Taken from DependencyManagement
> --
>
> Key: MECLIPSE-107
> URL: http://jira.codehaus.org/browse/MECLIPSE-107
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: dependency resolution
>Affects Versions: 2.2
>Reporter: Stephen Duncan Jr
>Priority: Critical
> Attachments: dmtest.zip,
> MECLIPSE-107-maven-eclipse-plugin-20061211-1200.patch
>
>
> The version used when generating .classpath is taken from
> dependencyManagement even though the child pom sets the dependency version,
> which should override what is in dependencyManagement. This is a regression
> from the correct behaviour in 2.1.
> The attached project demonstrates the problem. The .classpath file generated
> for the "child" project should specify log4j-1.2.13, but instead specifies
> 1.28.
--
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-203) support more than one release pattern via new goal release:branch
[ http://jira.codehaus.org/browse/MRELEASE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90245 ] Joerg Buchberger commented on MRELEASE-203: --- - WORKAROUND: specify version only in root POM to avoid version tag adaption hell, because only one version tag needs to be incremented to prepare for next iteration > support more than one release pattern via new goal release:branch > - > > Key: MRELEASE-203 > URL: http://jira.codehaus.org/browse/MRELEASE-203 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5, 2.0 > Environment: irrelevant >Reporter: Joerg Buchberger > > - CURRENT BEHAVIOUR: > maven currently seems to support only this one release pattern well: > *_feature branches_* > develop towards release in trunk; prepare it by tagging, then release from > that tag; continue for next iteration in trunk (+pom version tags are nicely > updated+), while some or most features are done in branches > - DESIRABLE IMPROVEMENT: > alternative patterns or customizations such as *_release branches_* should be > available: > develop features in trunk and rarely use feature branches; begin release > phase by branching, then work towards release in branch, while continuing for > next iteration in trunk (+currently pom version tag hell, when doing this > manually+); prepare by tagging from branch, then release from tag > this could be achieved by offering a new goal release:branch, that creates a > branch from trunk, updates *the trunk* poms for next iteration and stores > some properties in the branch, so that upon release:prepare from *the > branch*, the user can opt out preparations for next iteration on the branch > - loosely related to following issues: > -- [branch instead of tag|http://jira.codehaus.org/browse/MRELEASE-179] > -- [branch during prepare|http://jira.codehaus.org/browse/MRELEASE-170] -- 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: (NMAVEN-19) Dependency resolution and Maven integration (site, deploy)
Dependency resolution and Maven integration (site, deploy) -- Key: NMAVEN-19 URL: http://jira.codehaus.org/browse/NMAVEN-19 Project: NMaven Issue Type: Wish Reporter: Alexandre Garcia Attachments: components.patch First of all Shane, we really appreciate your effort. We tried to complement your packaging lifecycles in order to test site and deploy The Maven plugins site and deploy use the standard Maven artefact layout: ArtefactId-Version.dll We were able to use mvn site after renaming accordingly installed artefacts in the local repo ($reports is not expanded though). We rebuilt NMaven after altering NMaven\plugins\maven-compile-plugin\src\main\resources\META-INF\plexus\components.xml to include the deploy phase in the packaging lifecycles. The deploy phase is successful but is once again maven style. Unfortunately, the deployed artefacts cannot be downloaded because NMaven dependency resolution doesnot include the version suffix and hence doesnot find the artefact on the remote repo. More generally, i wish NMaven could adopt default Maven style artefact layout or a mixed mode for GAC dependencies. We attach the modified components.xml -- 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-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90251
]
Phil Webb commented on WAGON-73:
Are there any updates to this?
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
> Assigned To: Joakim Erdfelt
>Priority: Critical
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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: (MECLIPSE-107) Dependency Version Incorrectly Taken from DependencyManagement
[ http://jira.codehaus.org/browse/MECLIPSE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90253 ] Arnaud Heritier commented on MECLIPSE-107: -- ok, thanks for your feedback. I'll add your test case in our tests and I'll fix it this WE. > Dependency Version Incorrectly Taken from DependencyManagement > -- > > Key: MECLIPSE-107 > URL: http://jira.codehaus.org/browse/MECLIPSE-107 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.2 >Reporter: Stephen Duncan Jr >Priority: Critical > Attachments: dmtest.zip, > MECLIPSE-107-maven-eclipse-plugin-20061211-1200.patch > > > The version used when generating .classpath is taken from > dependencyManagement even though the child pom sets the dependency version, > which should override what is in dependencyManagement. This is a regression > from the correct behaviour in 2.1. > The attached project demonstrates the problem. The .classpath file generated > for the "child" project should specify log4j-1.2.13, but instead specifies > 1.28. -- 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: (MASSEMBLY-191) IncompatibleClassChangeError thrown when invoking the plugin
IncompatibleClassChangeError thrown when invoking the plugin
Key: MASSEMBLY-191
URL: http://jira.codehaus.org/browse/MASSEMBLY-191
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Assembly 2.2: trunk (20050316)
Reporter: Stephane Nicoll
I have a very basic assembly file that throws the following exception;
{noformat}
java.lang.IncompatibleClassChangeError
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:74)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:253)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
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)
{noformat}
The assembly is the following
{code:xml}
bundle
zip
false
src/main/ant
build.xml
target/${artifactId}-${version}.jar
runner-lib
{code}
My profile is as follows
{code:xml}
bundle
performRelease
true
org.apache.maven.plugins
maven-assembly-plugin
2.2-SNAPSHOT
src/assembly/bundle.xml
bundle-samples
package
attached
{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: (MANTLR-12) setting custom security manager might fail in embedded environment
[
http://jira.codehaus.org/browse/MANTLR-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90265
]
Jason van Zyl commented on MANTLR-12:
-
This patch doesn't work for me with a clean checkout and applying. I get an
error with the security manager.
> setting custom security manager might fail in embedded environment
> --
>
> Key: MANTLR-12
> URL: http://jira.codehaus.org/browse/MANTLR-12
> Project: Maven 2.x Antlr Plugin
> Issue Type: Bug
>Reporter: Milos Kleint
> Attachments: ANTLR-12.patch
>
>
> when the antlr plugin is run in embedded environment, eg. in netbeans IDE
> integration, it cannot be taken for granted that the setting of new security
> manager will succeed.
> [antlr:generate {execution: default}]
> [INFO]grammar: /space/src/hudson/main/core/src/main/grammar/crontab.g
> [INFO]
> [ERROR]FATAL ERROR
> [INFO]
> [INFO]null
> [INFO]
> [INFO]Trace
> java.lang.SecurityException
> at
> org.netbeans.TopSecurityManager.checkSetSecurityManager(TopSecurityManager.java:351)
> at
> org.netbeans.TopSecurityManager.checkPermission(TopSecurityManager.java:315)
> at java.lang.System.setSecurityManager0(System.java:273)
> at java.lang.System.setSecurityManager(System.java:264)
> at
> org.apache.maven.plugin.antlr.AntlrPlugin.execute(AntlrPlugin.java:99)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:417)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:610)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:551)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:530)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:309)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:276)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:760)
> at
> org.codehaus.mevenide.netbeans.execute.MavenJavaExecutor.run(MavenJavaExecutor.java:257)
> at
> org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:129)
> [INFO]
--
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: (MGPG-4) Invalid signature on installed or deployed POM
[ http://jira.codehaus.org/browse/MGPG-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes closed MGPG-4. Resolution: Fixed This does not occur when using Maven 2.0.5, it does with 2.0.4 > Invalid signature on installed or deployed POM > -- > > Key: MGPG-4 > URL: http://jira.codehaus.org/browse/MGPG-4 > Project: Maven 2.x GPG Plugin > Issue Type: Bug >Reporter: Jeremy Boynes > > The signature on the POM installed in the local or remote repo is bad. The > one on the pom in the target directory is good. Presumably the plugin should > be signing the regenerated POM rather than the original. -- 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: (MAVENUPLOAD-1424) Bundle for jets3t-0.5.0
Bundle for jets3t-0.5.0 --- Key: MAVENUPLOAD-1424 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1424 Project: maven-upload-requests Issue Type: Task Reporter: Ben Hale A java library for accessing the Amazon S3 service. -- 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: (NMAVEN-19) Dependency resolution and Maven integration (site, deploy)
[ http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90268 ] Shane Isbell commented on NMAVEN-19: Alexandre, just to clarify the request: do you just need the site and deploy functionality to work (say with the existing ArtifactId.dll format) or do you also need support for the ArtifactId-Version.dll convention itself? > Dependency resolution and Maven integration (site, deploy) > -- > > Key: NMAVEN-19 > URL: http://jira.codehaus.org/browse/NMAVEN-19 > Project: NMaven > Issue Type: Wish >Reporter: Alexandre Garcia > Attachments: components.patch > > > First of all Shane, we really appreciate your effort. > We tried to complement your packaging lifecycles in order to test site and > deploy > The Maven plugins site and deploy use the standard Maven artefact layout: > ArtefactId-Version.dll > We were able to use mvn site after renaming accordingly installed artefacts > in the local repo ($reports is not expanded though). > We rebuilt NMaven after altering > NMaven\plugins\maven-compile-plugin\src\main\resources\META-INF\plexus\components.xml > to include the deploy phase in the packaging lifecycles. > The deploy phase is successful but is once again maven style. > Unfortunately, the deployed artefacts cannot be downloaded because NMaven > dependency resolution doesnot include the version suffix and hence doesnot > find the artefact on the remote repo. > More generally, i wish NMaven could adopt default Maven style artefact layout > or a mixed mode for GAC dependencies. > We attach the modified components.xml -- 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: (MAVENUPLOAD-1409) An Open Source Java csv library under commercial-friendly license... committed to changing the world, one comma at a time...
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1409. --- Resolution: Fixed it's there http://repo1.maven.org/maven2/net/sf/opencsv/opencsv/1.7/ > An Open Source Java csv library under commercial-friendly license... > committed to changing the world, one comma at a time... > - > > Key: MAVENUPLOAD-1409 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1409 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jörn Guy Süß > Assigned To: Carlos Sanchez > Attachments: not found.png > > > http://itee.uq.edu.au/~jgsuess/temp/opencsv-1.7-bundle.jar > http://opencsv.sourceforge.net/ > http://blogs.bytecode.com.au/glen > opencsv is a very simple csv (comma-separated values) parser library for > Java. It was developed because all of current csv parsers I've come across > don't have commercial-friendly licenses. Please upload! -- 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: (MAVENUPLOAD-1395) Maven-jlex is a maven plugin for jlex, a lexical analyzer generator for Java.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1395. --- Assignee: Carlos Sanchez Resolution: Fixed > Maven-jlex is a maven plugin for jlex, a lexical analyzer generator for Java. > - > > Key: MAVENUPLOAD-1395 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1395 > Project: maven-upload-requests > Issue Type: Task >Reporter: Kevin Conaway > Assigned To: Carlos Sanchez > > http://maven-jlex.sourceforge.net/maven-jlex-plugin-1.0-bundle.jar > http://maven-jlex.sourceforge.net/ > http://maven-jlex.sourceforge.net/team-list.html > Maven-jlex is a maven plugin for jlex, a lexical analyzer generator for Java. > It allows users to integreate the generation of lexical analyzers into the > maven build lifecycle -- 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: (MAVENUPLOAD-1424) Bundle for jets3t-0.5.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90271 ] Carlos Sanchez commented on MAVENUPLOAD-1424: - unfortunately they don't own jets3t.org, so i would use net.java.dev.jets3t as groupId > Bundle for jets3t-0.5.0 > --- > > Key: MAVENUPLOAD-1424 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1424 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ben Hale > > A java library for accessing the Amazon S3 service. -- 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: (MAVENUPLOAD-1424) Bundle for jets3t-0.5.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90272 ] Ben Hale commented on MAVENUPLOAD-1424: --- Even though it doesn't match the package naming of the classes? > Bundle for jets3t-0.5.0 > --- > > Key: MAVENUPLOAD-1424 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1424 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ben Hale > > A java library for accessing the Amazon S3 service. -- 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: (MAVENUPLOAD-1220) Upload mx4j 3.0.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90273 ] Carlos Sanchez commented on MAVENUPLOAD-1220: - For the graph http://www.jroller.com/page/carlossg?entry=analyzing_jar_dependencies I'm gonna upload just the ones you need * mx4j:mx4j * mx4j:mx4j-remote and let other people provide poms if they want for the others now the question that you probably know if you use them is, when you use mx4j-remote do you need also mx4j ? yes -> add the dependency probably -> add the dependency sometimes -> add the dependency with true definitely no -> no dependencies > Upload mx4j 3.0.2 > - > > Key: MAVENUPLOAD-1220 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1220 > Project: maven-upload-requests > Issue Type: Task >Reporter: Kevan Miller > Assigned To: Carlos Sanchez > Attachments: dep.png > > > The mx4j project has created a service release of mx4j. This release fixes > problems found in Geronimo testing. > I'm not a developer on mx4j, but have exchanged notes with Simone Bordet (who > is). He requested that I submit the upload request. > These new poms and jars mirror the 3.0.1 mx4j poms and jars already on > ibiblio. -- 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: (MAVENUPLOAD-1423) HtmlUnit 1.11 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1423. --- Assignee: Carlos Sanchez Resolution: Fixed > HtmlUnit 1.11 upload request > > > Key: MAVENUPLOAD-1423 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1423 > Project: maven-upload-requests > Issue Type: Task >Reporter: Marc Guillemot > Assigned To: Carlos Sanchez > > http://htmlunit.sourceforge.net/htmlunit-1.11-bundle.jar > Team members, including myself: > http://htmlunit.sourceforge.net/team-list.html > http://sourceforge.net/project/memberlist.php?group_id=47038 -- 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-198) Maven Relese taggs with version number, but dots are not supported in CVS
[ http://jira.codehaus.org/browse/MRELEASE-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90275 ] Klaus Brunner commented on MRELEASE-198: This is a quite annoying bug. Apparently somebody has provided a patch a while ago (see duplicate MRELEASE-110), but there's no new release of the plugin yet. > Maven Relese taggs with version number, but dots are not supported in CVS > - > > Key: MRELEASE-198 > URL: http://jira.codehaus.org/browse/MRELEASE-198 > Project: Maven 2.x Release Plugin > Issue Type: Wish >Affects Versions: 2.0-beta-4 > Environment: Linux >Reporter: Max Berger >Priority: Minor > > Dear developers, > I was trying to release a project that was stored in CVS and had the version > 2.9.3. The release-plugin tried to tag the release using that version and > failed terribly, I had to manually set the tag to 2-9-3. > It would be nice if the plugin could avoid illegal tag names. > as the project has been moved to svn this is no longer an issue for me, but > the general issue remains. > Max -- 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: (MECLIPSE-227) mvn eclipse:eclipse for pom should create a .project file
[ http://jira.codehaus.org/browse/MECLIPSE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90276 ] Max Bowsher commented on MECLIPSE-227: -- Personally, I find the fact that it does not create a .project file to be an advantage. It means that I can easily import a multiproject tree into Eclipse just by pointing it at the root directory and letting it discover all the .project files. If there was a .project in the packaging=pom directories, it would not recurse into them. > mvn eclipse:eclipse for pom should create a .project > file > > > Key: MECLIPSE-227 > URL: http://jira.codehaus.org/browse/MECLIPSE-227 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: all >Reporter: THURNER rupert > > mvn eclipse:eclipse for pom should create a .project > file. > currently it does nothing. this is especially annoying if using parent poms > with other poms in subdirectories, see also description on > http://maven.apache.org/guides/mini/guide-ide-eclipse.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] Commented: (MWAR-82) setting archiveClasses to true create the jar in WEB-INF/lib but does not remove WEB-INF/classes
[
http://jira.codehaus.org/browse/MWAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90278
]
Piotr Tabor commented on MWAR-82:
-
What commands have you been using to generate your war ?
I have an idea that the scenario was:
"
org.apache.maven.plugins
maven-war-plugin
*false*
"
then:
mvn package
after that user changed in pom.xml to: *true*
then:
mvn package
In effect the final zzz.war constains both: classes and zzz.jar.
It is reason of the target/zzz directory, which constains zzz classes ofter
first "mvn package",
and zzz.jar after the second "mvn package".
Instead the second "mvn package" the user should use "mvn clean package", to
run the
war plugin on an empty target/zzz dir.
If the scenario is true - I think that this issue is not a bug.
> setting archiveClasses to true create the jar in WEB-INF/lib but does not
> remove WEB-INF/classes
>
>
> Key: MWAR-82
> URL: http://jira.codehaus.org/browse/MWAR-82
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Reporter: Sebastien Brunot
>
> This bug has been explained on the maven users mailing list:
> Hi Sebastien
> It seems to be a bug.
> In the code [1] we have :
> if ( archiveClasses )
> {
> createJarArchive( libDirectory );
> }
> else
> {
> copyDirectoryStructureIfModified( classesDirectory,
> webappClassesDirectory );
> }
> The content of the classes directory is never removed (neither in
> createJarArchive nor somewhere else).
> Can you create an issue please ?
> Thx
> Arnaud
> [1]
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java?revision=471624
> Sebastien Brunot wrote:
> >
> > Hi all,
> >
> > i've got a war project which pom build section contains the following
> > statements:
> >
> >
> >
> > org.apache.maven.plugins
> > maven-war-plugin
> >
> >
> >
> >war
> >
> >
> >true
> >
> >
> >
> >
> >
> > As a result, all the classes and resources from my war project are
> > packaged in a jar that is copied in the WEB-INF/lib directory of the
> > war artifact.
> >
> > But i don't understand why the war artifact still contains copy of the
> > classes and resources under WEB-INF/classes... Does anybody think that
> > i've misconfigured the war plugin ?
> >
> > Thanks for your help,
> >
> > Sebastien
> >
> >
> --
> View this message in context:
> http://www.nabble.com/Configuring-war-plugin-for-using-a-jar-instead-of-WEB-INF-classes-tf2589199s177.html#a7219855
> Sent from the Maven - Users mailing list archive at Nabble.com.
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
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-2879) Thousands of [WARNING] Component returned which is not the same manager.
Thousands of [WARNING] Component returned which is not the same manager. Key: MNG-2879 URL: http://jira.codehaus.org/browse/MNG-2879 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.5, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0 Reporter: Brian Fox It happens when processing resources, mostly for war projects although I'm not 100% positive it's only wars. We see one of these warnings apparently for every file processed because sometimes there are just a few and sometimes there are 1000s correlating to the number of files in the project. So far it only happens on dual-core machines although not every time. It smells of a multithreading issue. This issue has already been fixed in PLX-287. This MNG issue is to try and get that fix into 2.0.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] Updated: (MNG-2879) Thousands of [WARNING] Component returned which is not the same manager.
[ http://jira.codehaus.org/browse/MNG-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2879: --- Assignee: Jason van Zyl Fix Version/s: 2.0.6 > Thousands of [WARNING] Component returned which is not the same manager. > > > Key: MNG-2879 > URL: http://jira.codehaus.org/browse/MNG-2879 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5 >Reporter: Brian Fox > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > > It happens when processing resources, mostly for war projects although I'm > not 100% positive it's only wars. We see one of these warnings apparently for > every file processed because sometimes there are just a few and sometimes > there are 1000s correlating to the number of files in the project. So far it > only happens on dual-core machines although not every time. It smells of a > multithreading issue. > This issue has already been fixed in PLX-287. This MNG issue is to try and > get that fix into 2.0.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] Created: (NMAVEN-20) NUnit Report Generation
NUnit Report Generation --- Key: NMAVEN-20 URL: http://jira.codehaus.org/browse/NMAVEN-20 Project: NMaven Issue Type: New Feature Reporter: Shane Isbell Priority: Minor The site generation should include NUnit reports. -- 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-80) Classifier in jar file name is removed once assembled into war file
[ http://jira.codehaus.org/browse/MWAR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90281 ] Piotr Tabor commented on MWAR-80: - It is still true. When configuration is: " zzz ... fine true as a result we will get: zzz-fine.war but also: *zzz-fine.war/WEB-INF/lib/zzz.jar* It is probably "by design". So I think that there are two possibilities: a) to add to documentation comment about it and close the bug b) to add new parameter - for example bad which will create: *zzz-fine.war/WEB-INF/lib/zzz-bad.jar*. If it's useful (actually I don't see any use case for that stuff), I can prepare a patch. > Classifier in jar file name is removed once assembled into war file > --- > > Key: MWAR-80 > URL: http://jira.codehaus.org/browse/MWAR-80 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: Maven 2.0.4, JDK 1.5, maven-war-plugin version 2.0 >Reporter: Andreas Guther > > We use the Maven classifier to distinguish between different jar files of the > same version build for different purposes. An example would be the > classifier used for TestNG to distinguish between jdk15 and jdk14 jar files. > I noticed that the jar file (for example test-1.0-classifier.jar) ends up in > the WEB-INF/lib folder with the classifier removed (i.e. following the > example test.1.0.jar). > This is unexpected and confusing. Since there is very little documentation > about the expected behavior while using classifiers, it is not clear if this > is intenionally or a bug. > If intenionally, it should be mentioned in the maven-war-plugin > documentation. Maybe in that case it would be an enhancement to configure if > the classifier should be preserved or removed. > However, the current behavior is undocumented and unexpected. -- 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: (MWAR-82) setting archiveClasses to true create the jar in WEB-INF/lib but does not remove WEB-INF/classes
[
http://jira.codehaus.org/browse/MWAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MWAR-82.
---
Assignee: Stephane Nicoll
Resolution: Cannot Reproduce
Piotr is right, it's not a bug. Behavior runs as expected if you're starting
from a clean build.
> setting archiveClasses to true create the jar in WEB-INF/lib but does not
> remove WEB-INF/classes
>
>
> Key: MWAR-82
> URL: http://jira.codehaus.org/browse/MWAR-82
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Reporter: Sebastien Brunot
> Assigned To: Stephane Nicoll
>
> This bug has been explained on the maven users mailing list:
> Hi Sebastien
> It seems to be a bug.
> In the code [1] we have :
> if ( archiveClasses )
> {
> createJarArchive( libDirectory );
> }
> else
> {
> copyDirectoryStructureIfModified( classesDirectory,
> webappClassesDirectory );
> }
> The content of the classes directory is never removed (neither in
> createJarArchive nor somewhere else).
> Can you create an issue please ?
> Thx
> Arnaud
> [1]
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java?revision=471624
> Sebastien Brunot wrote:
> >
> > Hi all,
> >
> > i've got a war project which pom build section contains the following
> > statements:
> >
> >
> >
> > org.apache.maven.plugins
> > maven-war-plugin
> >
> >
> >
> >war
> >
> >
> >true
> >
> >
> >
> >
> >
> > As a result, all the classes and resources from my war project are
> > packaged in a jar that is copied in the WEB-INF/lib directory of the
> > war artifact.
> >
> > But i don't understand why the war artifact still contains copy of the
> > classes and resources under WEB-INF/classes... Does anybody think that
> > i've misconfigured the war plugin ?
> >
> > Thanks for your help,
> >
> > Sebastien
> >
> >
> --
> View this message in context:
> http://www.nabble.com/Configuring-war-plugin-for-using-a-jar-instead-of-WEB-INF-classes-tf2589199s177.html#a7219855
> Sent from the Maven - Users mailing list archive at Nabble.com.
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
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: (MWAR-63) Online available docu (corresponds to 2.0.2) is not in sync with released version 2.0.1 on ibiblio
[ http://jira.codehaus.org/browse/MWAR-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-63. --- Assignee: Stephane Nicoll Resolution: Won't Fix Fix Version/s: (was: 2.1) 2.0.2 2.0.2 was released. > Online available docu (corresponds to 2.0.2) is not in sync with released > version 2.0.1 on ibiblio > -- > > Key: MWAR-63 > URL: http://jira.codehaus.org/browse/MWAR-63 > Project: Maven 2.x War Plugin > Issue Type: Task >Reporter: Chris Wewerka > Assigned To: Stephane Nicoll >Priority: Critical > Fix For: 2.0.2 > > > The documentation of the plugin (especially > http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html) > refers to features only available in versions of the plugin which are not > yet deployed (2.0.2 and later) on ibiblio. This is very misleading. Example: > the property 'targetPath' > If you try to access the source code and build the plugin by yourself, you'll > notice that the version was already raised to 2.1-SNAPSHOT. > Will the 2.0.2 never be released? -- 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-77) calls to DirectoryScanner.setBasedir(String) fail in embedded environment
[ http://jira.codehaus.org/browse/MWAR-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90285 ] Stephane Nicoll commented on MWAR-77: - Milos, how can we reproduce this one easily? Using the eclipse plugin? > calls to DirectoryScanner.setBasedir(String) fail in embedded environment > - > > Key: MWAR-77 > URL: http://jira.codehaus.org/browse/MWAR-77 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.1 > Environment: maven embedded (2.1-SNAPSHOT) in mevenide/netbeans 2.2 >Reporter: Milos Kleint >Priority: Critical > > when the user declares a resource with relative path, eg. > >org.apache.maven.plugins >maven-war-plugin >2.0 > > > > >resource/files >true > >**/*bak > > > > > > then the build fails to process the resource correctly. I've traced that back > to the DirectoryScanner.setBasedir(String) method which will not construct a > path relative to the pom file, but to the directory where the IDE was started. -- 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-83) transitive dependency on POM artifact not respected
[ http://jira.codehaus.org/browse/MWAR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90286 ] Stephane Nicoll commented on MWAR-83: - I don't follow. If B has a compiled scope, it should be there. > transitive dependency on POM artifact not respected > --- > > Key: MWAR-83 > URL: http://jira.codehaus.org/browse/MWAR-83 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Frank Cornelis > > When I build a WAR with the following dependencies: > A (scope provided, type pom) -> B (scope compile, type jar) > C (scope runtime, type jar) -> B (scope compile, type jar) > then B gets included under WEB-INF/lib which I think it should not be. I use > the provided pom artifact A to represent the dependencies provided by my > container. -- 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: (MDEP-47) Ability to have an includes/excludes feature on the dependency:unpack goal.
[ http://jira.codehaus.org/browse/MDEP-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90287 ] Stephane Nicoll commented on MDEP-47: - I can help on this one if needed Brian. Let me know. > Ability to have an includes/excludes feature on the dependency:unpack goal. > --- > > Key: MDEP-47 > URL: http://jira.codehaus.org/browse/MDEP-47 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature >Reporter: Paul Shemansky > Assigned To: Brian Fox >Priority: Minor > Fix For: 2.0-alpha-3 > > > Perhaps there is another solution that I'm overlooking, and if so... I > apologize, but in the dependency-maven-plugin's dependency:unpack goal, it > would be quite convenient to have an option to have an includes/excludes > capability which did pattern matched unpack resolutions. I.E. : > > > *.class > > > *.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] Closed: (MWAR-77) calls to DirectoryScanner.setBasedir(String) fail in embedded environment
[ http://jira.codehaus.org/browse/MWAR-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-77. --- Resolution: Duplicate duplicate of MWAR-79 > calls to DirectoryScanner.setBasedir(String) fail in embedded environment > - > > Key: MWAR-77 > URL: http://jira.codehaus.org/browse/MWAR-77 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.1 > Environment: maven embedded (2.1-SNAPSHOT) in mevenide/netbeans 2.2 >Reporter: Milos Kleint >Priority: Critical > > when the user declares a resource with relative path, eg. > >org.apache.maven.plugins >maven-war-plugin >2.0 > > > > >resource/files >true > >**/*bak > > > > > > then the build fails to process the resource correctly. I've traced that back > to the DirectoryScanner.setBasedir(String) method which will not construct a > path relative to the pom file, but to the directory where the IDE was started. -- 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-78) War overlay can overwrite files in dependant war artifact
[ http://jira.codehaus.org/browse/MWAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90289 ] Stephane Nicoll commented on MWAR-78: - I am not sure that overriding should occur because of a timestamp. This will result in highly unpredictable builds. Instead, we should provide an order for the overlay mechansim so that users could specify in which order to overlay should happen. I will close this one as won't fix. Please comment if you have any comments/remarks. > War overlay can overwrite files in dependant war artifact > - > > Key: MWAR-78 > URL: http://jira.codehaus.org/browse/MWAR-78 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Brian Reilly > Assigned To: Stephane Nicoll > Attachments: maven-war-plugin-2.0.1-overlay-bug.diff > > > Suppose there is a war artifact A that is depended on by war artifact B. If > they contain files with the same name in src/main/webapp and the timestamp in > A is more recent than the timestamp in B, the file from A will be used. I > don't know if it's officially stated in the docs, but I think the intention > is that files in B should always win regardless of timestamp. > I've attached a diff (based on the maven-war-plugin-2.0.1 tag) that adds a > test case to WarExplodedMojoTest.java to demonstrate the problem. > The cause seems to be the use of copyFileIfModified in > AbstractWarMojo.copyDependentWarContents(). I'm not sure why this should be > done (except in the case of trying to avoid triggering a hot redeploy, which > doesn't apply to all files). > The diff also includes changes to AbstractWarMojo.java that fix the test > failures. I've created a copyFile method that is a clone of > copyFileIfModified without the timestamp check. That method is then used in > copyDependentWarContents instead. Additionally, I pulled in the !new File( > warSourceDirectory, files[j] ).exists() check from trunk. Lastly, I had to > change copyResources(File, File) to use copyFile as well in order to get the > tests to pass. > There may be other places where copyFileIfModified could be replaced with > copyFile, but I haven't done an extensive audit of every place where > copyFileIfModified is being used. > I also modified the last condition of testExplodedWarMergeWarUpdated because > it seemed incorrect to me and the fix that I made necessitated it. The test > was explicitly making sure that the version of org/sample/company/test.jsp > from simple-updated.war remained even after changing the dependency back to > simple.war. Put another way, the result of the last test would be different > depending on whether or not `mvn clean` is run after each dependency change. -- 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: (MWAR-78) War overlay can overwrite files in dependant war artifact
[ http://jira.codehaus.org/browse/MWAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-78. --- Resolution: Won't Fix > War overlay can overwrite files in dependant war artifact > - > > Key: MWAR-78 > URL: http://jira.codehaus.org/browse/MWAR-78 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Brian Reilly > Assigned To: Stephane Nicoll > Attachments: maven-war-plugin-2.0.1-overlay-bug.diff > > > Suppose there is a war artifact A that is depended on by war artifact B. If > they contain files with the same name in src/main/webapp and the timestamp in > A is more recent than the timestamp in B, the file from A will be used. I > don't know if it's officially stated in the docs, but I think the intention > is that files in B should always win regardless of timestamp. > I've attached a diff (based on the maven-war-plugin-2.0.1 tag) that adds a > test case to WarExplodedMojoTest.java to demonstrate the problem. > The cause seems to be the use of copyFileIfModified in > AbstractWarMojo.copyDependentWarContents(). I'm not sure why this should be > done (except in the case of trying to avoid triggering a hot redeploy, which > doesn't apply to all files). > The diff also includes changes to AbstractWarMojo.java that fix the test > failures. I've created a copyFile method that is a clone of > copyFileIfModified without the timestamp check. That method is then used in > copyDependentWarContents instead. Additionally, I pulled in the !new File( > warSourceDirectory, files[j] ).exists() check from trunk. Lastly, I had to > change copyResources(File, File) to use copyFile as well in order to get the > tests to pass. > There may be other places where copyFileIfModified could be replaced with > copyFile, but I haven't done an extensive audit of every place where > copyFileIfModified is being used. > I also modified the last condition of testExplodedWarMergeWarUpdated because > it seemed incorrect to me and the fix that I made necessitated it. The test > was explicitly making sure that the version of org/sample/company/test.jsp > from simple-updated.war remained even after changing the dependency back to > simple.war. Put another way, the result of the last test would be different > depending on whether or not `mvn clean` is run after each dependency change. -- 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-76) Allow Axis2 archives (.aar files) to be imported into WEB-INF/services directory
[ http://jira.codehaus.org/browse/MWAR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-76: Affects Version/s: 2.0.2 Fix Version/s: 2.0.3 > Allow Axis2 archives (.aar files) to be imported into WEB-INF/services > directory > > > Key: MWAR-76 > URL: http://jira.codehaus.org/browse/MWAR-76 > Project: Maven 2.x War Plugin > Issue Type: Wish >Affects Versions: 2.0.2 >Reporter: John Pfeifer > Assigned To: Stephane Nicoll > Fix For: 2.0.3 > > Attachments: AbstractWarMojo.java > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I have recently been working with axis2 and have found the need to import > axis2 archive files (.aar extension) into the WEB-INF/services directory. I > have made the changes to the maven war plugin source and they work great. -- 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: (MWAR-75) Documentation bugs on http://maven.apache.org/plugins/maven-war-plugin/usage.html
[ http://jira.codehaus.org/browse/MWAR-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-75. --- Assignee: Stephane Nicoll Resolution: Fixed Fix Version/s: 2.0.3 Applied, thanks. > Documentation bugs on > http://maven.apache.org/plugins/maven-war-plugin/usage.html > - > > Key: MWAR-75 > URL: http://jira.codehaus.org/browse/MWAR-75 > Project: Maven 2.x War Plugin > Issue Type: Bug >Reporter: Bernhard Wellhöfer > Assigned To: Stephane Nicoll > Fix For: 2.0.3 > > > The documentation at > http://maven.apache.org/plugins/maven-war-plugin/usage.html has three bugs: > * The current maven-war-plugin version is 2.0.1. > > > /sample/servlet/container/deploy/directory > > > * The webAppDirectory XML element is never closed. A / is missing. > * The webAppDirectory XML element is miss spelled. webappDirectory is > correct. -- 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] Deleted: (MWAR-74) Can this be configurable? See my comment on the above issue
[ http://jira.codehaus.org/browse/MWAR-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll deleted MWAR-74: > Can this be configurable? See my comment on the above issue > --- > > Key: MWAR-74 > URL: http://jira.codehaus.org/browse/MWAR-74 > Project: Maven 2.x War Plugin > Issue Type: Sub-task >Reporter: Douglas Ferguson > -- 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: (MWAR-71) 2.0 works, 2.0-beta-2 does not
[ http://jira.codehaus.org/browse/MWAR-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-71. --- Assignee: Stephane Nicoll Resolution: Cannot Reproduce I am not sure this will be applicable anymore. Please reopen if you still have the issue with the latest released version (2.0.2) > 2.0 works, 2.0-beta-2 does not > -- > > Key: MWAR-71 > URL: http://jira.codehaus.org/browse/MWAR-71 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: Mac OS X >Reporter: Ed Burns > Assigned To: Stephane Nicoll > Attachments: code.bugreport.tar.gz > > > I have a multi-module build. > This is present in the build output when I do mvn from within the submodule > [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-war-plugin:2.0:war' > --> > [DEBUG] (s) classesDirectory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/classes > [DEBUG] (f) filters = [] > [DEBUG] (f) outputDirectory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target > [DEBUG] (f) primaryArtifact = true > [DEBUG] (s) project = [EMAIL PROTECTED] > [DEBUG] (f) warName = jsf-simple-partial-update > [DEBUG] (s) warSourceDirectory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/src/main/webapp > [DEBUG] (s) directory = src/main/java > [DEBUG] (s) targetPath = WEB-INF > [DEBUG] (s) directory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/../sunbrand/src/main/webapp > [DEBUG] (f) webResources = [Lorg.apache.maven.model.Resource;@392356 > [DEBUG] (s) webappDirectory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/jsf-simple-partial-update > [DEBUG] (f) workDirectory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/war/work > [DEBUG] -- end configuration -- > but this present when I run the build from the top level > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-war-plugin:2.0-beta-2:war' --> > [DEBUG] (s) classesDirectory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/classes > [DEBUG] (f) outputDirectory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target > [DEBUG] (s) project = [EMAIL PROTECTED] > [DEBUG] (f) warName = jsf-simple-partial-update > [DEBUG] (s) warSourceDirectory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/src/main/webapp > [DEBUG] (s) webappDirectory = > /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/jsf-simple-partial-update > [DEBUG] -- end configuration -- > I would think the behaviour would be the same regardless of which > version of the maven-war-plugin is pulled in. -- 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-70) If property archiveClasses is set to true then war plugin should use this jar instead of creating a new one
[ http://jira.codehaus.org/browse/MWAR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90292 ] Stephane Nicoll commented on MWAR-70: - I don't follow. If your project has a war packaging this won't happen and I think it's more a hack that a clean improvement. Am I missing something? > If property archiveClasses is set to true then war plugin should use this jar > instead of creating a new one > --- > > Key: MWAR-70 > URL: http://jira.codehaus.org/browse/MWAR-70 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: WinXp, Java5 >Reporter: Martin Zeltner > Assigned To: Stephane Nicoll > > I had a look at the source code of today's svn trunk and saw that the jar is > created individually. I suggest to check first if there is already a created > jar (created by maven-jar-plugin) and use this if it exists. In this case you > can benefit from the power of the maven-jar-plugin (edit manifest for > example). > Cheers, > Martin -- 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-78) War overlay can overwrite files in dependant war artifact
[ http://jira.codehaus.org/browse/MWAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90293 ] Brian Reilly commented on MWAR-78: -- I think either my report was misunderstood or I'm misunderstanding the response. This problem isn't about choosing which file to take from multiple war overlays. It's about whether to use a file from a war overlay or from the project depending on that war. I agree that overrides should not depend on a timestamp. The problem that I reported was the result of code that does use timestamp checks. The patch that I attached removes the timestamp check for the case that I ran into. I should note that there are other uses of copyFileIfModified() in that file that I did not review to see if they should also be changed. Also, I haven't checked to see if the code has changed since I reported the bug. In general, the code seemed backwards to me. It was copying the current project's files and then trying to choose the right files to copy from the dependency (which is where the timestamp check seemed to come in, though even that doesn't quite make sense). A safer way to do it would be to copy the files from the dependency and then copy the current project's files on top, replacing anything that existed in the dependency. > War overlay can overwrite files in dependant war artifact > - > > Key: MWAR-78 > URL: http://jira.codehaus.org/browse/MWAR-78 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Brian Reilly > Assigned To: Stephane Nicoll > Attachments: maven-war-plugin-2.0.1-overlay-bug.diff > > > Suppose there is a war artifact A that is depended on by war artifact B. If > they contain files with the same name in src/main/webapp and the timestamp in > A is more recent than the timestamp in B, the file from A will be used. I > don't know if it's officially stated in the docs, but I think the intention > is that files in B should always win regardless of timestamp. > I've attached a diff (based on the maven-war-plugin-2.0.1 tag) that adds a > test case to WarExplodedMojoTest.java to demonstrate the problem. > The cause seems to be the use of copyFileIfModified in > AbstractWarMojo.copyDependentWarContents(). I'm not sure why this should be > done (except in the case of trying to avoid triggering a hot redeploy, which > doesn't apply to all files). > The diff also includes changes to AbstractWarMojo.java that fix the test > failures. I've created a copyFile method that is a clone of > copyFileIfModified without the timestamp check. That method is then used in > copyDependentWarContents instead. Additionally, I pulled in the !new File( > warSourceDirectory, files[j] ).exists() check from trunk. Lastly, I had to > change copyResources(File, File) to use copyFile as well in order to get the > tests to pass. > There may be other places where copyFileIfModified could be replaced with > copyFile, but I haven't done an extensive audit of every place where > copyFileIfModified is being used. > I also modified the last condition of testExplodedWarMergeWarUpdated because > it seemed incorrect to me and the fix that I made necessitated it. The test > was explicitly making sure that the version of org/sample/company/test.jsp > from simple-updated.war remained even after changing the dependency back to > simple.war. Put another way, the result of the last test would be different > depending on whether or not `mvn clean` is run after each dependency change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MWAR-78) War overlay can overwrite files in dependant war artifact
[ http://jira.codehaus.org/browse/MWAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll reopened MWAR-78: - Sorry I misunderstood the issue. > War overlay can overwrite files in dependant war artifact > - > > Key: MWAR-78 > URL: http://jira.codehaus.org/browse/MWAR-78 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Brian Reilly > Assigned To: Stephane Nicoll > Attachments: maven-war-plugin-2.0.1-overlay-bug.diff > > > Suppose there is a war artifact A that is depended on by war artifact B. If > they contain files with the same name in src/main/webapp and the timestamp in > A is more recent than the timestamp in B, the file from A will be used. I > don't know if it's officially stated in the docs, but I think the intention > is that files in B should always win regardless of timestamp. > I've attached a diff (based on the maven-war-plugin-2.0.1 tag) that adds a > test case to WarExplodedMojoTest.java to demonstrate the problem. > The cause seems to be the use of copyFileIfModified in > AbstractWarMojo.copyDependentWarContents(). I'm not sure why this should be > done (except in the case of trying to avoid triggering a hot redeploy, which > doesn't apply to all files). > The diff also includes changes to AbstractWarMojo.java that fix the test > failures. I've created a copyFile method that is a clone of > copyFileIfModified without the timestamp check. That method is then used in > copyDependentWarContents instead. Additionally, I pulled in the !new File( > warSourceDirectory, files[j] ).exists() check from trunk. Lastly, I had to > change copyResources(File, File) to use copyFile as well in order to get the > tests to pass. > There may be other places where copyFileIfModified could be replaced with > copyFile, but I haven't done an extensive audit of every place where > copyFileIfModified is being used. > I also modified the last condition of testExplodedWarMergeWarUpdated because > it seemed incorrect to me and the fix that I made necessitated it. The test > was explicitly making sure that the version of org/sample/company/test.jsp > from simple-updated.war remained even after changing the dependency back to > simple.war. Put another way, the result of the last test would be different > depending on whether or not `mvn clean` is run after each dependency change. -- 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: (CONTINUUM-515) Add a wait page when adding a project
[ http://jira.codehaus.org/browse/CONTINUUM-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-515: --- Attachment: CONTINUUM-515 add missing changes in projectGroupSummary.jsp. > Add a wait page when adding a project > - > > Key: CONTINUUM-515 > URL: http://jira.codehaus.org/browse/CONTINUUM-515 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Reporter: Emmanuel Venisse > Fix For: 1.1-alpha-2 > > Attachments: CONTINUUM-515, CONTINUUM-515 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-1419) Upload FreeMarker 2.3.9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] fabrizio giustina reopened MAVENUPLOAD-1419: This should probably be also tracked on MEV but since this is a concrete example I am going to discuss it here: uploading a new version and relocating *that version only* will substantially break any build where transitive deps use the new different groupId. With this concrete example, when I have freemarker:freemarker:2.3.8 in my build and a transitive deps starts using org.freemarker:freemarker:2.3.9 my build will be broken by a duplicate dependency (both jars will end up in my war). Having a groupId which is only partially relocated is something that should never be allowed. We have two options: - relocate any existing versions together (but this means that only people which delete their local copy will see the change) - stop relocating at all when a version already exists! Since the relocation concept has always been broken by the fact that maven has no way for check for relocations automatically, probably the second option is better. Due to relocations or duplicate artifacts in different groupIds the repository is recently becoming less consistent than ever :/ please, never close an upload/relocation request if the relocation has been applied consistently... at least any version in freemarker:freemarker should now be relocated to org:freemarker:freemarker > Upload FreeMarker 2.3.9 > --- > > Key: MAVENUPLOAD-1419 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1419 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mirko Nasato > Assigned To: Carlos Sanchez > -- 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: (MPLUGIN-29) Upgrade to maven-plugin-tools 2.1
Upgrade to maven-plugin-tools 2.1 - Key: MPLUGIN-29 URL: http://jira.codehaus.org/browse/MPLUGIN-29 Project: Maven 2.x Plugin Plugin Issue Type: Task Affects Versions: 2.2 Reporter: Dennis Lundberg Assigned To: Dennis Lundberg Fix For: 2.3 This adds support for new annotations: - @since for mojos - @implementation for parameters -- 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: (MPLUGIN-29) Upgrade to maven-plugin-tools 2.1
[ http://jira.codehaus.org/browse/MPLUGIN-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MPLUGIN-29. -- Resolution: Fixed > Upgrade to maven-plugin-tools 2.1 > - > > Key: MPLUGIN-29 > URL: http://jira.codehaus.org/browse/MPLUGIN-29 > Project: Maven 2.x Plugin Plugin > Issue Type: Task >Affects Versions: 2.2 >Reporter: Dennis Lundberg > Assigned To: Dennis Lundberg > Fix For: 2.3 > > > This adds support for new annotations: > - @since for mojos > - @implementation for parameters -- 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: (MAVENUPLOAD-1419) Upload FreeMarker 2.3.9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1419. --- Resolution: Fixed please move the discussion to the mailing list > Upload FreeMarker 2.3.9 > --- > > Key: MAVENUPLOAD-1419 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1419 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mirko Nasato > Assigned To: Carlos Sanchez > -- 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: (MAVENUPLOAD-1419) Upload FreeMarker 2.3.9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90307 ] Carlos Sanchez commented on MAVENUPLOAD-1419: - seems that the pom was wrong, i fixed the modelversion > Upload FreeMarker 2.3.9 > --- > > Key: MAVENUPLOAD-1419 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1419 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mirko Nasato > Assigned To: Carlos Sanchez > -- 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: (MAVENUPLOAD-1220) Upload mx4j 3.0.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90308 ] Jason Dillon commented on MAVENUPLOAD-1220: --- Okay, I'm fine with just getting mx4j:mx4j and mx4j:mx4j-remote up. I believe that mx4j:mx4j is there now, we just need mx4j:mx4j-remote. Its been years since I had to deal with any of the mx4j code... so I am going to say that mx4j:mx4j-remote *probably* depends on mx4j:mx4j... I think that is fairly safe. > Upload mx4j 3.0.2 > - > > Key: MAVENUPLOAD-1220 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1220 > Project: maven-upload-requests > Issue Type: Task >Reporter: Kevan Miller > Assigned To: Carlos Sanchez > Attachments: dep.png > > > The mx4j project has created a service release of mx4j. This release fixes > problems found in Geronimo testing. > I'm not a developer on mx4j, but have exchanged notes with Simone Bordet (who > is). He requested that I submit the upload request. > These new poms and jars mirror the 3.0.1 mx4j poms and jars already on > ibiblio. -- 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: (MASSEMBLY-191) IncompatibleClassChangeError thrown when invoking the plugin
[
http://jira.codehaus.org/browse/MASSEMBLY-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MASSEMBLY-191.
Resolution: Fixed
fixed. The issue was plexus-archiver 1.0-alpha-8, which pulled in
plexux-component-api (which defines Logger, in addition to
plexus-container-default-1.0-alpha-9's version).
I added an exclusion for plexus-component-api to the dependency on
plexus-archiver, and all's well again.
> IncompatibleClassChangeError thrown when invoking the plugin
>
>
> Key: MASSEMBLY-191
> URL: http://jira.codehaus.org/browse/MASSEMBLY-191
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Assembly 2.2: trunk (20050316)
>Reporter: Stephane Nicoll
> Assigned To: John Casey
>
> I have a very basic assembly file that throws the following exception;
> {noformat}
> java.lang.IncompatibleClassChangeError
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:74)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:253)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> 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)
> {noformat}
> The assembly is the following
> {code:xml}
>
> bundle
>
> zip
>
> false
>
>
> src/main/ant
>
>
> build.xml
>
>
>
>
>
>
> target/${artifactId}-${version}.jar
> runner-lib
>
>
>
> {code}
> My profile is as follows
> {code:xml}
>
> bundle
>
>
> performRelease
> true
>
>
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-SNAPSHOT
>
>
>
> src/assembly/bundle.xml
>
>
>
>
> bundle-samples
> package
>
> attached
>
>
>
>
>
>
>
> {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: (MASSEMBLY-191) IncompatibleClassChangeError thrown when invoking the plugin
[
http://jira.codehaus.org/browse/MASSEMBLY-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-191:
-
Fix Version/s: 2.2
> IncompatibleClassChangeError thrown when invoking the plugin
>
>
> Key: MASSEMBLY-191
> URL: http://jira.codehaus.org/browse/MASSEMBLY-191
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Assembly 2.2: trunk (20050316)
>Reporter: Stephane Nicoll
> Assigned To: John Casey
> Fix For: 2.2
>
>
> I have a very basic assembly file that throws the following exception;
> {noformat}
> java.lang.IncompatibleClassChangeError
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:74)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:253)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> 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)
> {noformat}
> The assembly is the following
> {code:xml}
>
> bundle
>
> zip
>
> false
>
>
> src/main/ant
>
>
> build.xml
>
>
>
>
>
>
> target/${artifactId}-${version}.jar
> runner-lib
>
>
>
> {code}
> My profile is as follows
> {code:xml}
>
> bundle
>
>
> performRelease
> true
>
>
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-SNAPSHOT
>
>
>
> src/assembly/bundle.xml
>
>
>
>
> bundle-samples
> package
>
> attached
>
>
>
>
>
>
>
> {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: (MASSEMBLY-169) Document new elements in the assembly descriptor as "Since 2.2"
[ http://jira.codehaus.org/browse/MASSEMBLY-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-169. Assignee: John Casey Resolution: Fixed applied, thanks. > Document new elements in the assembly descriptor as "Since 2.2" > --- > > Key: MASSEMBLY-169 > URL: http://jira.codehaus.org/browse/MASSEMBLY-169 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Wendy Smoak > Assigned To: John Casey >Priority: Blocker > Fix For: 2.2 > > Attachments: assembly-since-2.2.patch > > > The assembly.html page includes elements introduced after the 2.1 release. > These need to be documented as "Since 2.2" to avoid confusion. > (Another option would be for modello:xdoc to generate something based on the > in the model.) -- 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: (MASSEMBLY-164) "Unrecognised tag: 'unpackOptions' " error in unpackOptions tag in the dependencySet
[ http://jira.codehaus.org/browse/MASSEMBLY-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-164. Assignee: John Casey Resolution: Fixed > "Unrecognised tag: 'unpackOptions' " error in unpackOptions tag in the > dependencySet > - > > Key: MASSEMBLY-164 > URL: http://jira.codehaus.org/browse/MASSEMBLY-164 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: version 2.1 of maven-assembly-plugin > maven version 2.0.4 > java version 1.5.0_07 > Windows XP version 5.1.2600 >Reporter: Tom McGee > Assigned To: John Casey >Priority: Blocker > Fix For: 2.2 > > > I'm using version 2.1 of maven-assembly-plugin. > The documentaion on the assembly saids I can have unpackOptions tag in the > dependencySet but I get an "Unrecognised tag: 'unpackOptions' " error. > Here's the stack trace: > org.apache.maven.lifecycle.LifecycleExecutionException: Error reading > descriptor > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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 reading > descriptor > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.getAssembly(AbstractAssemblyMojo.java:839) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.getAssembly(AbstractAssemblyMojo.java:814) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.readAssemblies(AbstractAssemblyMojo.java:742) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:233) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: > Unrecognised tag: 'unpackOptions' (position: START_TAG seen ...\r\n > \r\n >... @11:23) > at > org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.parseDependencySet(AssemblyXpp3Reader.java:638) > at > org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.parseAssembly(AssemblyXpp3Reader.java:456) > at > org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.read(AssemblyXpp3Reader.java:1717) > at > org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.read(AssemblyXpp3Reader.java:1728) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.getAssembly(AbstractAssemblyMojo.java:829) > ... 21 more > The pom: > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > play.ejb > play-ejb > jar > 1.0-SNAPSHOT > play-ejb > http://maven.apache.org > > > org.springframework > spring > 2.0 > compile > > > junit > junit > 3.8.1 > test > > > > > > > > maven-assembly-plugin > > > assembly > package >
[jira] Closed: (MASSEMBLY-173) inside a tag is interpreted as decimal, not octal
[ http://jira.codehaus.org/browse/MASSEMBLY-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-173. Resolution: Fixed I've replaced all instances of Integer.parseInt( x, 8 ) with Integer.decode( x ).intValue() in all cases where file or directory modes are handled, and then deployed the result. > inside a tag is interpreted as decimal, not octal > --- > > Key: MASSEMBLY-173 > URL: http://jira.codehaus.org/browse/MASSEMBLY-173 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: Mac OS X 10.4.8 (8L2127) Intel > Maven version: 2.0.4 >Reporter: Lars Sonchocky-Helldorf > Fix For: 2.2 > > > If I want to use the tag inside a tag I have to resort to > decimal numbers. This doesn't happen inside the tags. As example > some snipped from a Assembly Descriptor I currently use: > > > target/MDEditor-fat.jar > 0493 > > > > > deploy/Euro1 > keep > / > > **/*.sh > > 0755 > > > deploy/Euro1 > keep > / > > **/*.sh > > 0644 > > -- 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
