[jira] Commented: (MNG-3728) ERROR: JAVA_HOME is set to an invalid directory.... even when the JAVA_HOME is set correctly
[
http://jira.codehaus.org/browse/MNG-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145993#action_145993
]
Benjamin Bentmann commented on MNG-3728:
bq. JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2
The JAVA_HOME variable is expected to point to a single directory only, it is
not meant to be a list of multiple paths. Out of curiosity, could you point us
to the documentation that suggested to set JAVA_HOME that way.
bq. 2.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;
Again, a single directory spec shouldn't end with a separator like ";"
bq. 3.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03\
Although the trailing back slash is not necessary, this should work. I just
tried
{noformat}
JAVA_HOME=M:\harmony jdk-629320\
{noformat}
by myself and encountered no problems. Could you provide more diagnostic output
from Maven for this case?
> ERROR: JAVA_HOME is set to an invalid directory even when the JAVA_HOME
> is set correctly
> -
>
> Key: MNG-3728
> URL: http://jira.codehaus.org/browse/MNG-3728
> Project: Maven 2
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 2.0.9
> Environment: Windows Vista
>Reporter: adevroy
>
> ERROR: JAVA_HOME is set to an invalid directory.
> JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation
> My JAVA_HOME is set perfectly ( i checked java.exe set on C:\Program
> Files\Java\jdk1.6.0_03\bin\) JAI and JMF all working ... javac and rest of
> the commands also work so i guess i good with it.
> i tried the following options:
> 1.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2
> 2.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;
> 3.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03\
> 4.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2;
> I put JAVA_HOME in both user enviroment variables and system one still didn't
> work.
> I copy pasted the path from the browser so i can't be wrong in that.
> I have nothing more to try ... any Idea's ?
--
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: (MSHARED-55) NLP IF no fileset directory specified.
[ http://jira.codehaus.org/browse/MSHARED-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petar Tahchiev updated MSHARED-55: -- Attachment: mshared55-ver.1.txt I have made a new version of the patch, because I noticed a few problems with the old one. Please use MSHARED-55-ver1 patch. > NLP IF no fileset directory specified. > -- > > Key: MSHARED-55 > URL: http://jira.codehaus.org/browse/MSHARED-55 > Project: Maven Shared Components > Issue Type: Bug > Components: file-management > Environment: all >Reporter: Petar Tahchiev > Attachments: massembly-342.txt, mshared55-ver.1.txt > > > Hi guys I have created a patch for the MASSEMBLY-342 that should be applied > to FileSetManager. This patch fixes a but that can arise if you make > assemblies and in your assembly-descriptor you have filesets that don't > specify directory. > For further info please look here: > http://jira.codehaus.org/browse/MASSEMBLY-342 -- 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: (MSHARED-55) NLP IF no fileset directory specified.
[ http://jira.codehaus.org/browse/MSHARED-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petar Tahchiev updated MSHARED-55: -- Attachment: mshared55-ver1-testcase.txt Here is a junit test-case that tests if we specify a fileset with no directory that we get nothing included. > NLP IF no fileset directory specified. > -- > > Key: MSHARED-55 > URL: http://jira.codehaus.org/browse/MSHARED-55 > Project: Maven Shared Components > Issue Type: Bug > Components: file-management > Environment: all >Reporter: Petar Tahchiev > Attachments: massembly-342.txt, mshared55-ver.1.txt, > mshared55-ver1-testcase.txt > > > Hi guys I have created a patch for the MASSEMBLY-342 that should be applied > to FileSetManager. This patch fixes a but that can arise if you make > assemblies and in your assembly-descriptor you have filesets that don't > specify directory. > For further info please look here: > http://jira.codehaus.org/browse/MASSEMBLY-342 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3728) ERROR: JAVA_HOME is set to an invalid directory.... even when the JAVA_HOME is set correctly
[ http://jira.codehaus.org/browse/MNG-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146005#action_146005 ] adevroy commented on MNG-3728: -- 1.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2 The JAVA_HOME variable is expected to point to a single directory only, it is not meant to be a list of multiple paths. Out of curiosity, could you point us to the documentation that suggested to set JAVA_HOME that way. I didn't do it my self when i installed JAI it added the path automatically .. i didn't even knew that it was there till the time maven started showing problem ( i didn't knew it was illegal :) ) 2.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03; Again, a single directory spec shouldn't end with a separator like ";" i remove it and maven worked !! 3.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03\ Although the trailing back slash is not necessary, this should work. I just tried Yes it works i retried it ... i guess i had tried with the earlier version of maven this format ... must have failed cos of that !! and thanks a lot ...first for again getting me started and second telling me JAVA_HOME can't have multiple paths > ERROR: JAVA_HOME is set to an invalid directory even when the JAVA_HOME > is set correctly > - > > Key: MNG-3728 > URL: http://jira.codehaus.org/browse/MNG-3728 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.9 > Environment: Windows Vista >Reporter: adevroy > > ERROR: JAVA_HOME is set to an invalid directory. > JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2 > Please set the JAVA_HOME variable in your environment to match the > location of your Java installation > My JAVA_HOME is set perfectly ( i checked java.exe set on C:\Program > Files\Java\jdk1.6.0_03\bin\) JAI and JMF all working ... javac and rest of > the commands also work so i guess i good with it. > i tried the following options: > 1.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2 > 2.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03; > 3.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03\ > 4.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2; > I put JAVA_HOME in both user enviroment variables and system one still didn't > work. > I copy pasted the path from the browser so i can't be wrong in that. > I have nothing more to try ... any Idea's ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3728) ERROR: JAVA_HOME is set to an invalid directory.... even when the JAVA_HOME is set correctly
[ http://jira.codehaus.org/browse/MNG-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] adevroy closed MNG-3728. Resolution: Not A Bug Fix Version/s: 2.0.9 > ERROR: JAVA_HOME is set to an invalid directory even when the JAVA_HOME > is set correctly > - > > Key: MNG-3728 > URL: http://jira.codehaus.org/browse/MNG-3728 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.9 > Environment: Windows Vista >Reporter: adevroy > Fix For: 2.0.9 > > > ERROR: JAVA_HOME is set to an invalid directory. > JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2 > Please set the JAVA_HOME variable in your environment to match the > location of your Java installation > My JAVA_HOME is set perfectly ( i checked java.exe set on C:\Program > Files\Java\jdk1.6.0_03\bin\) JAI and JMF all working ... javac and rest of > the commands also work so i guess i good with it. > i tried the following options: > 1.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2 > 2.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03; > 3.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03\ > 4.) JAVA_HOME = C:\Program Files\Java\jdk1.6.0_03;C:\jai-1_1_2; > I put JAVA_HOME in both user enviroment variables and system one still didn't > work. > I copy pasted the path from the browser so i can't be wrong in that. > I have nothing more to try ... any Idea's ? -- 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: (MJAVADOC-214) test javadoc goal uses incorrect dependency classpath
test javadoc goal uses incorrect dependency classpath - Key: MJAVADOC-214 URL: http://jira.codehaus.org/browse/MJAVADOC-214 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Brett Porter according to this report: http://www.nabble.com/JavaDoc-Report-crashes-with-TestNG-tp19139379p19158787.html The test javadoc goal is not using the test classpath dependencies. -- 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: (MSOURCES-33) provide configuration
[ http://jira.codehaus.org/browse/MSOURCES-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146019#action_146019 ] René Zanner commented on MSOURCES-33: - I want to exclude metadata files created by my version control system (Serena Dimensions, by the way) from the sources jar. This is not possible at the moment since the "sources" plugin is missing the tags known from the "jar" plugin, for instance. > provideconfiguration > > > Key: MSOURCES-33 > URL: http://jira.codehaus.org/browse/MSOURCES-33 > Project: Maven 2.x Source Plugin > Issue Type: Wish >Reporter: jianwu > -- 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: (MSHADE-40) manifest data is lost when the shaded result is a classifier.
manifest data is lost when the shaded result is a classifier.
-
Key: MSHADE-40
URL: http://jira.codehaus.org/browse/MSHADE-40
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: benson margulies
I ran into problem with duplicate classes when I tried to use the shaded output
of one project as an input to another shaded project, and they shared a
dependency.
So, I turned on the classifier feature, so that the second project could
consume the unshaded version of the first one.
And all is well, except that the Main-class: manifest attribute does not show
up in the shaded jar.
This works fine when I don't turn on the classifier. here's the POM-piece of
note.
org.apache.maven.plugins
maven-shade-plugin
1.1
true
excedrin-common-${common.version}
package
shade
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2398) attached artifacts (such as assemblies) are not resolved in the workspace when running 'package' phase
[ http://jira.codehaus.org/browse/MNG-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146053#action_146053 ] Piotr Oktaba commented on MNG-2398: --- I have similar problem. During release goals 'clean verify' are called. When one artifact depends on another attached artifact release fails due to unsatisfied dependency. Workaround is to call goals 'clean install' from maven-release-plugin. However, maven should properly resolved that artifacts. > attached artifacts (such as assemblies) are not resolved in the workspace > when running 'package' phase > -- > > Key: MNG-2398 > URL: http://jira.codehaus.org/browse/MNG-2398 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.4 > Environment: Running of Mac OSX 10.4 >Reporter: Matt Brozowski >Priority: Blocker > Fix For: 2.0.11 > > Attachments: attached-artifact-bug.tar.gz, > maven-project-2.0.4-patch.txt > > > I have attached a sample project. > submoduleA creates an attached artifact (a tar.gz assembly) which submoduleB > depends on. > When running: > mvn package > The attached artifact cannot be resolved from the workspace but tries the > repos instead, yet when running: > > This problems makes using attached artifacts very 'risky' because it could be > running 'old' 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] Created: (MRELEASE-377) Missing releaseVersion parameter in release:branch goal
Missing releaseVersion parameter in release:branch goal --- Key: MRELEASE-377 URL: http://jira.codehaus.org/browse/MRELEASE-377 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-8 Reporter: Nicolas Coquelet Can you add the releaseVersion paramater in the BranchReleaseMojo of the2.0-beta8 release ? The MapVersionPhase can already use it after fixing MRELEASE-173. Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-377) Missing releaseVersion parameter in release:branch goal
[ http://jira.codehaus.org/browse/MRELEASE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Coquelet updated MRELEASE-377: -- Attachment: MRELEASE-377-maven-release.patch a small patch ... > Missing releaseVersion parameter in release:branch goal > --- > > Key: MRELEASE-377 > URL: http://jira.codehaus.org/browse/MRELEASE-377 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-8 >Reporter: Nicolas Coquelet > Attachments: MRELEASE-377-maven-release.patch > > > Can you add the releaseVersion paramater in the BranchReleaseMojo of > the2.0-beta8 release ? > The MapVersionPhase can already use it after fixing MRELEASE-173. > Thanks -- 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-3729) Maven 2.0.10-RC10 fails with NPE on assembly:assembly
Maven 2.0.10-RC10 fails with NPE on assembly:assembly
-
Key: MNG-3729
URL: http://jira.codehaus.org/browse/MNG-3729
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.10
Environment: Mac OS X 10.5.4
Reporter: Thorsten Möller
Attachments: bin.xml, pom.xml
Multi-module project fails with NPE on assembly:assembly (assembly plugin used
2.2-beta-1; 2.2-beta-2 can not be used because of
http://jira.codehaus.org/browse/MASSEMBLY-314 bug)
Command used was "mvn clean install assembly:assembly eclipse:eclipse".
Same configuration (see attached POM) works with Maven 2.0.9. Below you will
find relevant excerpt from the build trace.
Note: Some internal/irrelevant information were removed from attached POM.
Additionally, assembly descriptor of default assembly is attached.
Best regards,
Thorsten
[INFO]
[INFO] Building OSIRIS Next
[INFO]task-segment: [assembly:assembly] (aggregator-style)
[INFO]
[INFO] Preparing assembly:assembly
[INFO]
[INFO] Building OSIRIS Next
[INFO]
[INFO] [enforcer:enforce {execution: enforce-maven}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1032)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
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)
[INFO]
[INFO] Total time: 55 minutes 18 seconds
[INFO] Finished at: Mon Aug 25 17:18:11 CEST 2008
[INFO] Final Memory: 36M/126M
[INFO] -
[jira] Commented: (MNG-3729) Maven 2.0.10-RC10 fails with NPE on assembly:assembly
[
http://jira.codehaus.org/browse/MNG-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146064#action_146064
]
Benjamin Bentmann commented on MNG-3729:
The latest RC is RC11:
http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/
Could you check if it suffers from this, too?
> Maven 2.0.10-RC10 fails with NPE on assembly:assembly
> -
>
> Key: MNG-3729
> URL: http://jira.codehaus.org/browse/MNG-3729
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.10
> Environment: Mac OS X 10.5.4
>Reporter: Thorsten Möller
> Attachments: bin.xml, pom.xml
>
>
> Multi-module project fails with NPE on assembly:assembly (assembly plugin
> used 2.2-beta-1; 2.2-beta-2 can not be used because of
> http://jira.codehaus.org/browse/MASSEMBLY-314 bug)
> Command used was "mvn clean install assembly:assembly eclipse:eclipse".
> Same configuration (see attached POM) works with Maven 2.0.9. Below you will
> find relevant excerpt from the build trace.
> Note: Some internal/irrelevant information were removed from attached POM.
> Additionally, assembly descriptor of default assembly is attached.
> Best regards,
> Thorsten
> [INFO]
>
> [INFO] Building OSIRIS Next
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building OSIRIS Next
> [INFO]
>
> [INFO] [enforcer:enforce {execution: enforce-maven}]
> [INFO] [tools:copy-legal-files {execution: install-legal-files}]
> [INFO] [site:attach-descriptor]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
>
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1032)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
[jira] Commented: (MNG-3729) Maven 2.0.10-RC10 fails with NPE on assembly:assembly
[
http://jira.codehaus.org/browse/MNG-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146067#action_146067
]
Thorsten Möller commented on MNG-3729:
--
Same exception also with RC11:
[INFO]
[INFO] Building OSIRIS Next
[INFO]task-segment: [assembly:assembly] (aggregator-style)
[INFO]
[INFO] Preparing assembly:assembly
[INFO]
[INFO] Building OSIRIS Next
[INFO]
[INFO] [enforcer:enforce {execution: enforce-maven}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:675)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:538)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1187)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1030)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:626)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:538)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1187)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1025)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:626)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:551)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:521)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:369)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
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)
[INFO]
[INFO] Total time: 7 minutes 33 seconds
[INFO] Finished at: Tue Aug 26 18:24:29 CEST 2008
[INFO] Final Memory: 42M/126M
[INFO]
> Maven 2.0.10-RC10 fails with NPE on assembly:assembly
> -
>
> Key: MNG-3729
> URL: http://jira.codehaus.org/browse/MNG-3729
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.10
> Environment: Mac OS X 10.5.4
>Reporter: Thorsten Möller
> Attachments: bin.xml, pom.xml
>
>
> Multi-module project fails with NPE on assembly:assembly (assembly plugin
> used 2.2-beta-1; 2.2-beta-2 can not be used because of
> http://jira.codehaus.org/browse/MASSEMBLY-314 bug)
> Command used was "mvn clean install assembly:assembly eclipse:eclipse".
> Same configuration (se
[jira] Updated: (MNG-3729) Maven 2.0.10-RC10 fails with NPE on assembly:assembly
[
http://jira.codehaus.org/browse/MNG-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3729:
Fix Version/s: 2.0.10
> Maven 2.0.10-RC10 fails with NPE on assembly:assembly
> -
>
> Key: MNG-3729
> URL: http://jira.codehaus.org/browse/MNG-3729
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.10
> Environment: Mac OS X 10.5.4
>Reporter: Thorsten Möller
> Fix For: 2.0.10
>
> Attachments: bin.xml, pom.xml
>
>
> Multi-module project fails with NPE on assembly:assembly (assembly plugin
> used 2.2-beta-1; 2.2-beta-2 can not be used because of
> http://jira.codehaus.org/browse/MASSEMBLY-314 bug)
> Command used was "mvn clean install assembly:assembly eclipse:eclipse".
> Same configuration (see attached POM) works with Maven 2.0.9. Below you will
> find relevant excerpt from the build trace.
> Note: Some internal/irrelevant information were removed from attached POM.
> Additionally, assembly descriptor of default assembly is attached.
> Best regards,
> Thorsten
> [INFO]
>
> [INFO] Building OSIRIS Next
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building OSIRIS Next
> [INFO]
>
> [INFO] [enforcer:enforce {execution: enforce-maven}]
> [INFO] [tools:copy-legal-files {execution: install-legal-files}]
> [INFO] [site:attach-descriptor]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
>
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1032)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
> 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.
[jira] Updated: (MECLIPSE-318) test classes and resources need to be first in .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MECLIPSE-318: --- Affects Version/s: 2.4 > test classes and resources need to be first in .classpath file > -- > > Key: MECLIPSE-318 > URL: http://jira.codehaus.org/browse/MECLIPSE-318 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Core : Dependencies resolution and build path >Affects Versions: 2.4 >Reporter: Jim Sellers > > They have changed the core dependancy resolution to be "tests first". I'm > assuming that the plug-in will need to be changed to reflect this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3729) Maven 2.0.10-RC10 fails with NPE on assembly:assembly
[
http://jira.codehaus.org/browse/MNG-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146070#action_146070
]
John Casey commented on MNG-3729:
-
Unfortunately this just isn't enough information to debug the problem. Do you
have a SVN location I could check out to grab this build and give it a try? Or,
if it's proprietary, could you at least re-run the build above with the -X
command-line flag, and post that output? I'm not sure what's causing the
project (probably a forked-execution clone of the project in question) is
null...
> Maven 2.0.10-RC10 fails with NPE on assembly:assembly
> -
>
> Key: MNG-3729
> URL: http://jira.codehaus.org/browse/MNG-3729
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.10
> Environment: Mac OS X 10.5.4
>Reporter: Thorsten Möller
> Fix For: 2.0.10
>
> Attachments: bin.xml, pom.xml
>
>
> Multi-module project fails with NPE on assembly:assembly (assembly plugin
> used 2.2-beta-1; 2.2-beta-2 can not be used because of
> http://jira.codehaus.org/browse/MASSEMBLY-314 bug)
> Command used was "mvn clean install assembly:assembly eclipse:eclipse".
> Same configuration (see attached POM) works with Maven 2.0.9. Below you will
> find relevant excerpt from the build trace.
> Note: Some internal/irrelevant information were removed from attached POM.
> Additionally, assembly descriptor of default assembly is attached.
> Best regards,
> Thorsten
> [INFO]
>
> [INFO] Building OSIRIS Next
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building OSIRIS Next
> [INFO]
>
> [INFO] [enforcer:enforce {execution: enforce-maven}]
> [INFO] [tools:copy-legal-files {execution: install-legal-files}]
> [INFO] [site:attach-descriptor]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
>
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1032)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
> at sun.refl
[jira] Commented: (MNG-3729) Maven 2.0.10-RC10 fails with NPE on assembly:assembly
[
http://jira.codehaus.org/browse/MNG-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146071#action_146071
]
John Casey commented on MNG-3729:
-
I tried to reproduce this issue using the maven-core build and the information
given above, but unfortunately it didn't work. I'm not sure what the difference
is in execution environment, but if you could produce an archived test project
setup that will display the error, I'm happy to continue debugging.
> Maven 2.0.10-RC10 fails with NPE on assembly:assembly
> -
>
> Key: MNG-3729
> URL: http://jira.codehaus.org/browse/MNG-3729
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.10
> Environment: Mac OS X 10.5.4
>Reporter: Thorsten Möller
> Fix For: 2.0.10
>
> Attachments: bin.xml, pom.xml
>
>
> Multi-module project fails with NPE on assembly:assembly (assembly plugin
> used 2.2-beta-1; 2.2-beta-2 can not be used because of
> http://jira.codehaus.org/browse/MASSEMBLY-314 bug)
> Command used was "mvn clean install assembly:assembly eclipse:eclipse".
> Same configuration (see attached POM) works with Maven 2.0.9. Below you will
> find relevant excerpt from the build trace.
> Note: Some internal/irrelevant information were removed from attached POM.
> Additionally, assembly descriptor of default assembly is attached.
> Best regards,
> Thorsten
> [INFO]
>
> [INFO] Building OSIRIS Next
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building OSIRIS Next
> [INFO]
>
> [INFO] [enforcer:enforce {execution: enforce-maven}]
> [INFO] [tools:copy-legal-files {execution: install-legal-files}]
> [INFO] [site:attach-descriptor]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
>
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1032)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.Nat
[jira] Work started: (MASSEMBLY-298) Includes/Excludes within are ignored
[ http://jira.codehaus.org/browse/MASSEMBLY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MASSEMBLY-298 started by John Casey. > Includes/Excludes within are ignored > > > Key: MASSEMBLY-298 > URL: http://jira.codehaus.org/browse/MASSEMBLY-298 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Maven 2.0.8, Intel Mac 10.5, JDK 5.0 >Reporter: Nathaniel Harward >Assignee: John Casey > Fix For: 2.2-beta-3 > > Attachments: module-set-assembly-phase.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > I have the following snippet in my assembly descriptor which does not work: > --snip-- > > > my:module > > > true > > > META-INF/** > > **/.do_not_remove > > > > / > 644 > 755 > > > --snip-- > Debug output shows: > --snip-- > [DEBUG] includes: > **/* > [DEBUG] excludes: > none > --snip-- > I believe the problem is at line 271/272 of ModuleSetAssemblyPhase (in the > 2.2-beta-2 revision, anyway) -- it calls "task.setUnpack( binaries.isUnpack() > );" but does not set the unpack options (if present), hence they are ignored > :( > Patch is attached, and works just fine in my case above. -- 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-298) Includes/Excludes within are ignored
[ http://jira.codehaus.org/browse/MASSEMBLY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-298: - Assignee: John Casey Remaining Estimate: 0 minutes Original Estimate: 0 minutes > Includes/Excludes within are ignored > > > Key: MASSEMBLY-298 > URL: http://jira.codehaus.org/browse/MASSEMBLY-298 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Maven 2.0.8, Intel Mac 10.5, JDK 5.0 >Reporter: Nathaniel Harward >Assignee: John Casey > Fix For: 2.2-beta-3 > > Attachments: module-set-assembly-phase.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > I have the following snippet in my assembly descriptor which does not work: > --snip-- > > > my:module > > > true > > > META-INF/** > > **/.do_not_remove > > > > / > 644 > 755 > > > --snip-- > Debug output shows: > --snip-- > [DEBUG] includes: > **/* > [DEBUG] excludes: > none > --snip-- > I believe the problem is at line 271/272 of ModuleSetAssemblyPhase (in the > 2.2-beta-2 revision, anyway) -- it calls "task.setUnpack( binaries.isUnpack() > );" but does not set the unpack options (if present), hence they are ignored > :( > Patch is attached, and works just fine in my case above. -- 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: (MECLIPSE-318) test classes and resources need to be first in .classpath file
[
http://jira.codehaus.org/browse/MECLIPSE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MECLIPSE-318.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.5.2
Fixed in [r689226|http://svn.apache.org/viewvc?view=rev&revision=689226]. The
generated {{.classpath}} is now in sync with the behavior of the executing
Maven. I.e. if run by Maven 2.0.8+, test classes come first, if run by older
Maven versions, main classes come first.
> test classes and resources need to be first in .classpath file
> --
>
> Key: MECLIPSE-318
> URL: http://jira.codehaus.org/browse/MECLIPSE-318
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Jim Sellers
>Assignee: Benjamin Bentmann
> Fix For: 2.5.2
>
>
> They have changed the core dependancy resolution to be "tests first". I'm
> assuming that the plug-in will need to be changed to reflect this.
--
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-318) test classes and resources need to be first in .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146087#action_146087 ] Jim Sellers commented on MECLIPSE-318: -- Thank you. ;-) > test classes and resources need to be first in .classpath file > -- > > Key: MECLIPSE-318 > URL: http://jira.codehaus.org/browse/MECLIPSE-318 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Core : Dependencies resolution and build path >Affects Versions: 2.4 >Reporter: Jim Sellers >Assignee: Benjamin Bentmann > Fix For: 2.5.2 > > > They have changed the core dependancy resolution to be "tests first". I'm > assuming that the plug-in will need to be changed to reflect this. -- 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: (ARCHETYPE-188) achetype:create-from-project goal does not generate new groupId and artifactId for new archetype
[ http://jira.codehaus.org/browse/ARCHETYPE-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raphaël Piéroni closed ARCHETYPE-188. - Resolution: Fixed Fix Version/s: 2.0-alpha-4 Fixed since revision 689249 > achetype:create-from-project goal does not generate new groupId and > artifactId for new archetype > > > Key: ARCHETYPE-188 > URL: http://jira.codehaus.org/browse/ARCHETYPE-188 > Project: Maven Archetype > Issue Type: Bug > Components: Plugin >Affects Versions: 2.0-alpha-3 > Environment: Maven version: 2.0.9 > Java version: 1.6.0_06 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Trent Rosenbaum > Fix For: 2.0-alpha-4 > > > The 'archetype:create-from-project' goal when used does not generate the > correct values for the groupId and the artifactId of the new archetype being > created. > Instead the values from the original maven structured project serialized into > the new pom.xml for the newly generated archetype. This means that the new > archetype when installed within the artifact repository will occupy the space > of the original project. The original project values are are used during the > creation process regardless of whether the user has specified to use the > plugin through interactive mode. > I started out with a new maven project generated from the quickstart > archetype. The pom.xml file contained the following values > groupId: com.mycompany.example > artifactId: myapp > I executed > mvn archetype:create-from-project -Dinteractive=true > The 'archetype:create-from-project' goal reported the following values back > to me > archetype.groupId=com.mycompany.example > archetype.artifactId=myapp-archetype > archetype.version=1.0-SNAPSHOT > version=1.0-SNAPSHOT > package=com.mycompany.example.myapp > groupId=com.mycompany.example > artifactId=myapp > I expected to see a newly generated archetype project with the following > value within the pom.xml file > groupId: com.mycompany.example > artifactId: myapp-archetype > Instead I was left with a generated archetype that contained a pom.xml file > with the following values > groupId: com.mycompany.example > artifactId: myapp > No matter how I interact with the plugin goal I cannot pass through the > correct value for the groupId and artifactId elements. I have even tried > adding additional properties with the same keys with the aim of overwriting > the generated values. This still resulted in an incorrect pom.xml. After > generation I had to manually change the values before running 'mvn install'. -- 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-388) Correct classpath ordering in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146093#action_146093
]
Benjamin Bentmann commented on MECLIPSE-388:
The ordering of test vs main classes has been fixed in MECLIPSE-318, remaining
is the ordering of dependencies. Interesting are these source comments:
{code:java}
// TODO if (..magic property equals orderDependencies..)
// TODO get the right comparator depending on
orderDependencies={name,nearness..};
{code}
Not yet sure how to interpret these.
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: http://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Priority: Critical
> Attachments: MECLIPSE-388-it-test.patch, MECLIPSE-388.patch,
> MECLIPSE-388.patch
>
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
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-388) Correct classpath ordering in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146094#action_146094
]
Arnaud Heritier commented on MECLIPSE-388:
--
dependencies order is a problem, but having the good list of dependencies is
more important I think : MECLIPSE-472
I think we have to review all the mechanism of dependencies to sanitize it.
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: http://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Priority: Critical
> Attachments: MECLIPSE-388-it-test.patch, MECLIPSE-388.patch,
> MECLIPSE-388.patch
>
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
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: (MJAVADOC-214) test javadoc goal uses incorrect dependency classpath
[ http://jira.codehaus.org/browse/MJAVADOC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146095#action_146095 ] Tan Quach commented on MJAVADOC-214: I am getting these same errors, however here is some additional information: When I run "mvn javadoc:test-javadoc" from within either a standalone project or sub-module project that has test sources, it works fine. When I run "mvn javadoc:test-javadoc" from a parent project, it fails when it gets to the sub-module. > test javadoc goal uses incorrect dependency classpath > - > > Key: MJAVADOC-214 > URL: http://jira.codehaus.org/browse/MJAVADOC-214 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Brett Porter > > according to this report: > http://www.nabble.com/JavaDoc-Report-crashes-with-TestNG-tp19139379p19158787.html > The test javadoc goal is not using the test classpath dependencies. -- 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-298) Includes/Excludes within are ignored
[ http://jira.codehaus.org/browse/MASSEMBLY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-298. Resolution: Fixed > Includes/Excludes within are ignored > > > Key: MASSEMBLY-298 > URL: http://jira.codehaus.org/browse/MASSEMBLY-298 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Maven 2.0.8, Intel Mac 10.5, JDK 5.0 >Reporter: Nathaniel Harward >Assignee: John Casey > Fix For: 2.2-beta-3 > > Attachments: module-set-assembly-phase.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > I have the following snippet in my assembly descriptor which does not work: > --snip-- > > > my:module > > > true > > > META-INF/** > > **/.do_not_remove > > > > / > 644 > 755 > > > --snip-- > Debug output shows: > --snip-- > [DEBUG] includes: > **/* > [DEBUG] excludes: > none > --snip-- > I believe the problem is at line 271/272 of ModuleSetAssemblyPhase (in the > 2.2-beta-2 revision, anyway) -- it calls "task.setUnpack( binaries.isUnpack() > );" but does not set the unpack options (if present), hence they are ignored > :( > Patch is attached, and works just fine in my case above. -- 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: (MASSEMBLY-298) Includes/Excludes within are ignored
[ http://jira.codehaus.org/browse/MASSEMBLY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146097#action_146097 ] Antony Stubbs commented on MASSEMBLY-298: - Cheers! Do you think you found the reason why it wasn't working from my POM configuration? > Includes/Excludes within are ignored > > > Key: MASSEMBLY-298 > URL: http://jira.codehaus.org/browse/MASSEMBLY-298 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Maven 2.0.8, Intel Mac 10.5, JDK 5.0 >Reporter: Nathaniel Harward >Assignee: John Casey > Fix For: 2.2-beta-3 > > Attachments: module-set-assembly-phase.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > I have the following snippet in my assembly descriptor which does not work: > --snip-- > > > my:module > > > true > > > META-INF/** > > **/.do_not_remove > > > > / > 644 > 755 > > > --snip-- > Debug output shows: > --snip-- > [DEBUG] includes: > **/* > [DEBUG] excludes: > none > --snip-- > I believe the problem is at line 271/272 of ModuleSetAssemblyPhase (in the > 2.2-beta-2 revision, anyway) -- it calls "task.setUnpack( binaries.isUnpack() > );" but does not set the unpack options (if present), hence they are ignored > :( > Patch is attached, and works just fine in my case above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-298) Includes/Excludes within are ignored
[ http://jira.codehaus.org/browse/MASSEMBLY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146100#action_146100 ] phillme edited comment on MASSEMBLY-298 at 8/26/08 6:28 PM: - Hi Antony. I do not know if this will help you but maybe http://maven.apache.org/plugins/maven-assembly-plugin/usage.html can point you in a right direction. Regards, Phillip was (Author: phillme): Hi Antony. I do not know if this will help you but maybe http://maven.apache.org/plugins/maven-assembly-plugin/usage.html can point you in a right direction. > Includes/Excludes within are ignored > > > Key: MASSEMBLY-298 > URL: http://jira.codehaus.org/browse/MASSEMBLY-298 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Maven 2.0.8, Intel Mac 10.5, JDK 5.0 >Reporter: Nathaniel Harward >Assignee: John Casey > Fix For: 2.2-beta-3 > > Attachments: module-set-assembly-phase.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > I have the following snippet in my assembly descriptor which does not work: > --snip-- > > > my:module > > > true > > > META-INF/** > > **/.do_not_remove > > > > / > 644 > 755 > > > --snip-- > Debug output shows: > --snip-- > [DEBUG] includes: > **/* > [DEBUG] excludes: > none > --snip-- > I believe the problem is at line 271/272 of ModuleSetAssemblyPhase (in the > 2.2-beta-2 revision, anyway) -- it calls "task.setUnpack( binaries.isUnpack() > );" but does not set the unpack options (if present), hence they are ignored > :( > Patch is attached, and works just fine in my case above. -- 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: (MASSEMBLY-298) Includes/Excludes within are ignored
[ http://jira.codehaus.org/browse/MASSEMBLY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146100#action_146100 ] Phillip Merensky commented on MASSEMBLY-298: Hi Antony. I do not know if this will help you but maybe http://maven.apache.org/plugins/maven-assembly-plugin/usage.html can point you in a right direction. > Includes/Excludes within are ignored > > > Key: MASSEMBLY-298 > URL: http://jira.codehaus.org/browse/MASSEMBLY-298 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Maven 2.0.8, Intel Mac 10.5, JDK 5.0 >Reporter: Nathaniel Harward >Assignee: John Casey > Fix For: 2.2-beta-3 > > Attachments: module-set-assembly-phase.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > I have the following snippet in my assembly descriptor which does not work: > --snip-- > > > my:module > > > true > > > META-INF/** > > **/.do_not_remove > > > > / > 644 > 755 > > > --snip-- > Debug output shows: > --snip-- > [DEBUG] includes: > **/* > [DEBUG] excludes: > none > --snip-- > I believe the problem is at line 271/272 of ModuleSetAssemblyPhase (in the > 2.2-beta-2 revision, anyway) -- it calls "task.setUnpack( binaries.isUnpack() > );" but does not set the unpack options (if present), hence they are ignored > :( > Patch is attached, and works just fine in my case above. -- 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: (MASSEMBLY-298) Includes/Excludes within are ignored
[ http://jira.codehaus.org/browse/MASSEMBLY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146104#action_146104 ] Antony Stubbs commented on MASSEMBLY-298: - nono, ah, I don't think I'm making myself clear. With my POM, the assembly plugin runs - the problem is, with this patch applied, when i ran the assembly plugin using the pom instead of the command line "mvn clean package assembly:directory", the include/exclude fix did not take affect. > Includes/Excludes within are ignored > > > Key: MASSEMBLY-298 > URL: http://jira.codehaus.org/browse/MASSEMBLY-298 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Maven 2.0.8, Intel Mac 10.5, JDK 5.0 >Reporter: Nathaniel Harward >Assignee: John Casey > Fix For: 2.2-beta-3 > > Attachments: module-set-assembly-phase.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > I have the following snippet in my assembly descriptor which does not work: > --snip-- > > > my:module > > > true > > > META-INF/** > > **/.do_not_remove > > > > / > 644 > 755 > > > --snip-- > Debug output shows: > --snip-- > [DEBUG] includes: > **/* > [DEBUG] excludes: > none > --snip-- > I believe the problem is at line 271/272 of ModuleSetAssemblyPhase (in the > 2.2-beta-2 revision, anyway) -- it calls "task.setUnpack( binaries.isUnpack() > );" but does not set the unpack options (if present), hence they are ignored > :( > Patch is attached, and works just fine in my case above. -- 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-342) NPE when filtering fileSet
[
http://jira.codehaus.org/browse/MASSEMBLY-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-342:
-
Assignee: John Casey
Remaining Estimate: 0 minutes
Original Estimate: 0 minutes
> NPE when filtering fileSet
> --
>
> Key: MASSEMBLY-342
> URL: http://jira.codehaus.org/browse/MASSEMBLY-342
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Environment: Windows XP, cygwin, Java 1.5.0.9
>Reporter: Peter Verhás
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.2-beta-3
>
> Attachments: massembly-342.txt
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I get NPE when I specify filtering in an assembly descriptor. The
> {{src/assembly/bin.xml}} file (referenced by the {{pom.xml}} as an assembly
> descriptor) is the following:
> {code}
>
> bin
>
> zip
>
> false
>
>
> lib
>
>
>
>
> target
>
>
> *.jar
>
>
>
> true
>
> INSTALL*
> README*
> LICENSE*
> NOTICE*
>
>
>
>
> {code}
> This causes
> {code}
> $ mvn -e assembly:assembly
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'assembly'.
> [INFO]
>
> [INFO] Building Unnamed - verhas.com:isoapui8583:jar:1.0.0
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building Unnamed - verhas.com:isoapui8583:jar:1.0.0
> [INFO]
>
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> Downloading:
> http://repo1.maven.org/maven2/xmlbeans/xbean/2.3.0-trunk-patched/xbean-2.3.0-trunk-patched.pom
> Downloading:
> http://repo1.maven.org/maven2/groovy/groovy-all/1.5.2/groovy-all-1.5.2.pom
> Downloading:
> http://repo1.maven.org/maven2/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.pom
> Downloading:
> http://repo1.maven.org/maven2/cweb-extser/cweb-extser/0.1-b2-dev/cweb-extser-0.1-b2-dev.pom
> Downloading:
> http://repo1.maven.org/maven2/jPOS/jpos/1.6.2-r2626/jpos-1.6.2-r2626.pom
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test]
> [INFO] Surefire report directory:
> p:\projects\BASE24-soapui\BICISO-SOAPUI\target\surefire-reports
> ---
> T E S T S
> ---
> Running com.verhas.soapui.jpos.TestServer
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec
> Running com.verhas.soapui.jpos.TestClient
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec
> Running com.verhas.soapui.jpos.TestClientServer
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> Running com.verhas.soapui.jpos.TestConstants
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] [jar:jar]
> [INFO] Building jar:
> p:\projects\BASE24-soapui\BICISO-SOAPUI\target\isoapui8583-1.0.0.jar
> [INFO] [assembly:assembly]
> [INFO] Reading assembly descriptor: src/assembly/doc.xml
> [INFO] Reading assembly descriptor: src/assembly/bin.xml
> [INFO] Reading assembly descriptor: src/assembly/src.xml
> [INFO] Building zip:
> p:\projects\BASE24-soapui\BICISO-SOAPUI\target\isoapui8583-1.0.0-doc.zip
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at java.io.File.(File.java:222)
> at
> org.apache.maven.shared.model.fileset.util.FileSetManager.scan(FileSetManager.java:598)
>
[jira] Work started: (MASSEMBLY-342) NPE when filtering fileSet
[
http://jira.codehaus.org/browse/MASSEMBLY-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MASSEMBLY-342 started by John Casey.
> NPE when filtering fileSet
> --
>
> Key: MASSEMBLY-342
> URL: http://jira.codehaus.org/browse/MASSEMBLY-342
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Environment: Windows XP, cygwin, Java 1.5.0.9
>Reporter: Peter Verhás
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.2-beta-3
>
> Attachments: massembly-342.txt
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I get NPE when I specify filtering in an assembly descriptor. The
> {{src/assembly/bin.xml}} file (referenced by the {{pom.xml}} as an assembly
> descriptor) is the following:
> {code}
>
> bin
>
> zip
>
> false
>
>
> lib
>
>
>
>
> target
>
>
> *.jar
>
>
>
> true
>
> INSTALL*
> README*
> LICENSE*
> NOTICE*
>
>
>
>
> {code}
> This causes
> {code}
> $ mvn -e assembly:assembly
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'assembly'.
> [INFO]
>
> [INFO] Building Unnamed - verhas.com:isoapui8583:jar:1.0.0
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building Unnamed - verhas.com:isoapui8583:jar:1.0.0
> [INFO]
>
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> Downloading:
> http://repo1.maven.org/maven2/xmlbeans/xbean/2.3.0-trunk-patched/xbean-2.3.0-trunk-patched.pom
> Downloading:
> http://repo1.maven.org/maven2/groovy/groovy-all/1.5.2/groovy-all-1.5.2.pom
> Downloading:
> http://repo1.maven.org/maven2/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.pom
> Downloading:
> http://repo1.maven.org/maven2/cweb-extser/cweb-extser/0.1-b2-dev/cweb-extser-0.1-b2-dev.pom
> Downloading:
> http://repo1.maven.org/maven2/jPOS/jpos/1.6.2-r2626/jpos-1.6.2-r2626.pom
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test]
> [INFO] Surefire report directory:
> p:\projects\BASE24-soapui\BICISO-SOAPUI\target\surefire-reports
> ---
> T E S T S
> ---
> Running com.verhas.soapui.jpos.TestServer
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec
> Running com.verhas.soapui.jpos.TestClient
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec
> Running com.verhas.soapui.jpos.TestClientServer
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> Running com.verhas.soapui.jpos.TestConstants
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] [jar:jar]
> [INFO] Building jar:
> p:\projects\BASE24-soapui\BICISO-SOAPUI\target\isoapui8583-1.0.0.jar
> [INFO] [assembly:assembly]
> [INFO] Reading assembly descriptor: src/assembly/doc.xml
> [INFO] Reading assembly descriptor: src/assembly/bin.xml
> [INFO] Reading assembly descriptor: src/assembly/src.xml
> [INFO] Building zip:
> p:\projects\BASE24-soapui\BICISO-SOAPUI\target\isoapui8583-1.0.0-doc.zip
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at java.io.File.(File.java:222)
> at
> org.apache.maven.shared.model.fileset.util.FileSetManager.scan(FileSetManager.java:598)
> at
> org.apache.maven.shared.model.fileset.util.FileSetManager.getIncludedFiles(FileSetManager.java:186)
> at
> org.
[jira] Updated: (MASSEMBLY-314) Multiple inclusion of dependencies in binary assembly
[
http://jira.codehaus.org/browse/MASSEMBLY-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-314:
-
Fix Version/s: 2.2-beta-3
> Multiple inclusion of dependencies in binary assembly
> -
>
> Key: MASSEMBLY-314
> URL: http://jira.codehaus.org/browse/MASSEMBLY-314
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: all
>Reporter: Thorsten Möller
> Fix For: 2.2-beta-3
>
>
> Hello,
> today I tried to upgrade the Maven assembly plugin from 2.2-beta-1 to
> 2.2-beta-2. However, I noticed that for my project which consists of multiple
> modules the resulting binary assembly now contains dependency JAR files
> multiple times. The assembly descriptor contains the following excerpt (with
> changed module names):
>
>
>
> ${pom.groupId}:a
> ${pom.groupId}:b
> ${pom.groupId}:c
>
>
>
> true
> false
> /lib
>
>
>
> The projects a, b, c have several dependencies, whereby some of those
> dependencies refer to identical artifacts (derived from a parent POM), e.g.,
> commons-logging. The resulting ZIP and TAR.GZ assembly files then contain
> those dependencies multiple times (in the lib folder) with equal names! Im
> not sure if this is a bug or a feature and I might have missed something.
> I rolled back to version 2.2-beta-1 and I could reproduce the issue.
> 2.2-beta-1 works as expected, i.e., all files exist only once.
> Regards,
> Thorsten
--
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: (SCM-252) ClearCaseUpdateConsumer for I18N
[
http://jira.codehaus.org/browse/SCM-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
komusubi updated SCM-252:
-
Attachment: java.patch
I fixed this problem for japanese version, I'll give my patch.
It was good, please use it.
> ClearCaseUpdateConsumer for I18N
> -
>
> Key: SCM-252
> URL: http://jira.codehaus.org/browse/SCM-252
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.0-beta-3
> Environment: does not dependency
>Reporter: komusubi
> Fix For: future
>
> Attachments: java.patch
>
>
> It can't get updateFiles list way of indexOf("Loading") method because I
> use Japanese version.
> It might use ResourceBundle ??
> I have to need fix it because use with continuum, so I can give you a patch,
> but how should I do?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-121) System properties set on the command line get clobbered
[
http://jira.codehaus.org/browse/SUREFIRE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146121#action_146121
]
Christian Nelson commented on SUREFIRE-121:
---
Just Confirming... with maven 2.0.9 and 2.0.10-RC11, properties set on the
command line are not passed to unit tests run by surefire 2.4.3. v2.4.2 passes
the system properties.
For example:
| mvn install -Djdbc.host=192.168.2.100
With v2.4.2, System.getProperty("jdbc.host") returns 192.168.2.100. With
v.2.4.3 it returns null.
We rely on this behavior in unit tests frequently, sometime via
System.getProperty() and other times indirectly through the use of Spring's
[PropertyPlaceholderConfigurer|http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html]
in SYSTEM_PROPERTIES_MODE_OVERRIDEmode.
Is the plan to revert back to the 2.4.2 behavior?
> System properties set on the command line get clobbered
> ---
>
> Key: SUREFIRE-121
> URL: http://jira.codehaus.org/browse/SUREFIRE-121
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Linux, Maven 2.0.4, Sun JDK 1.5U5, bash 3.0
>Reporter: Brenton Leanhardt
>Priority: Critical
> Fix For: Future
>
>
> Some system properties get clobbered if you set them on the command line. For
> example,
> mvn clean test -Dtest=LoginTest -Dselenium.user=test32
> The 'test' system property will work, but the 'selenium.user' property will
> be null at runtime. I have tried:
> * hard coding the system property in the unit test, this worked fine.
> * setting the system properties in the pom file, this worked fine also.
> * tried an older version of the surefire plugin, this worked fine.
--
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: (SCM-252) ClearCaseUpdateConsumer for I18N
[
http://jira.codehaus.org/browse/SCM-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated SCM-252:
-
Fix Version/s: (was: future)
1.1.1
Patch Submitted: [Yes]
> ClearCaseUpdateConsumer for I18N
> -
>
> Key: SCM-252
> URL: http://jira.codehaus.org/browse/SCM-252
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.0-beta-3
> Environment: does not dependency
>Reporter: komusubi
> Fix For: 1.1.1
>
> Attachments: java.patch
>
>
> It can't get updateFiles list way of indexOf("Loading") method because I
> use Japanese version.
> It might use ResourceBundle ??
> I have to need fix it because use with continuum, so I can give you a patch,
> but how should I do?
--
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
