[jira] Commented: (MECLIPSE-37) eclipse:eclipse should execute in a later phase than generate-sources
[ http://jira.codehaus.org/browse/MECLIPSE-37?page=comments#action_59300 ] Mark Hobson commented on MECLIPSE-37: - This change impairs the use of eclipse:eclipse somewhat for the reasons detailed by Kenney above - would it not be better for the average user to revert back to generate-resources whilst the design issues are resolved? eclipse:eclipse should execute in a later phase than generate-sources --- Key: MECLIPSE-37 URL: http://jira.codehaus.org/browse/MECLIPSE-37 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.0 Reporter: Mark Donszelmann Assignee: fabrizio giustina the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is test -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MNG-1412) .classpath should have nearest order
[ http://jira.codehaus.org/browse/MNG-1412?page=all ] Mark Hobson reopened MNG-1412: -- This is mainly required when dealing with resources within dependencies. An example would be that projects B and C both contain a log4j.properties file and you want to always pick up the nearest one. At the moment C's log4j.properties file would be used in preference to B's, which seems a bit unintuitive. Eclipse does allow you to manually reorder the classpath but this is tedious and error prone. .classpath should have nearest order Key: MNG-1412 URL: http://jira.codehaus.org/browse/MNG-1412 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Hobson Assignee: fabrizio giustina The .classpath file entries should be ordered by nearest transitiveness (if that's a word). For example, I have project A that depends on B that depends on C. The classpath for A is generated in the order C, B. Ideally the classpath should be in order of how near they are to the project, i.e. B, C. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1412) dependency sorting in classpath
[ http://jira.codehaus.org/browse/MNG-1412?page=comments#action_52237 ] Mark Hobson commented on MNG-1412: -- Yes, sorry, the ordering is the same as in maven itself - I didn't mean to imply otherwise. Moving to maven core gets my vote, thanks. dependency sorting in classpath --- Key: MNG-1412 URL: http://jira.codehaus.org/browse/MNG-1412 Project: Maven 2 Type: Bug Versions: 2.0 Reporter: Mark Hobson Assignee: fabrizio giustina The .classpath file entries should be ordered by nearest transitiveness (if that's a word). For example, I have project A that depends on B that depends on C. The classpath for A is generated in the order C, B. Ideally the classpath should be in order of how near they are to the project, i.e. B, C. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1653) Spaces in M2_HOME breaks new bootstrap
Spaces in M2_HOME breaks new bootstrap -- Key: MNG-1653 URL: http://jira.codehaus.org/browse/MNG-1653 Project: Maven 2 Type: Bug Components: bootstrap Versions: 2.0.1 Environment: Windows XP, Cygwin, Java5 Reporter: Mark Hobson Attachments: patch.txt There are various bugs that appear when M2_HOME contains spaces. The attached patch fixes a few, although the integration tests still all fail as follows: it... FAILED - Standard Out - Command: C:\Program Files\maven-2.0.1-SNAPSHOT\bin\m2 -e --no-plugin-registry --batch-mode -Dmaven.repo.local=C:\Documents and Settings\mark/.m2/repository clean:clean package - Standard Error - Exit code: 1 Error Stacktrace: org.apache.maven.it.VerificationException at org.apache.maven.it.Verifier.executeGoals(Verifier.java:676) at org.apache.maven.it.Verifier.main(Verifier.java:856) Error Stacktrace Log file contents: 'C:\Program' is not recognized as an internal or external command, operable program or batch file. 0/85 passed Failed tests: [it0085, it0084, it0083, it0082, it0081, it0080, it0079, it0078, it0077, it0076, it0075, it0074, it0073, it0072, it0071, it0070, it0069, it0068, it0067, it0066, it0065, it0064, it0063, it0062, it0061, it0060, it0059, it0058, it0057, it0056, it0055, it0054, it0053, it0052, it0051, it0050, it0049, it0048, it0047, it0046, it0045, it0044, it0043, it0042, it0041, it0040, it0039, it0038, it0037, it0036, it0035, it0034, it0033, it0032, it0031, it0030, it0029, it0028, it0027, it0026, it0025, it0024, it0023, it0022, it0021, it0020, it0019, it0018, it0017, it0016, it0014, it0013, it0012, it0011, it0010, it0009, it0008, it0007, it0006, it0005, it0004, it0003, it0002, it0001, it] -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1464) Javadoc:jar goal executes for non-Java projects
[ http://jira.codehaus.org/browse/MNG-1464?page=comments#action_51505 ] Mark Hobson commented on MNG-1464: -- Maybe worth adding affects and fixed versions to make this issue easier to find. Javadoc:jar goal executes for non-Java projects --- Key: MNG-1464 URL: http://jira.codehaus.org/browse/MNG-1464 Project: Maven 2 Type: Bug Components: maven-javadoc-plugin Reporter: David Jackman Assignee: John Casey Attachments: JavadocJar.patch When the javadoc:javadoc goal is attempted for a project that does not have Java source, it correctly displays a message to this effect and jumps out. However, the javadoc:jar goal doesn't do this (although it does display a message)--it will build a javadoc jar containing no Javadocs. I've attached a patch that fixes the issue (very simple fix). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1648) Use canonical paths in eclipse project files
Use canonical paths in eclipse project files Key: MNG-1648 URL: http://jira.codehaus.org/browse/MNG-1648 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Hobson Need to ensure all absolute file paths are moved to canonical paths as discussed on dev: http://www.nabble.com/-m2-eclipse-plugin-test-failures-t488244.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1649) Allow plugins to depend upon other plugin's goals
Allow plugins to depend upon other plugin's goals - Key: MNG-1649 URL: http://jira.codehaus.org/browse/MNG-1649 Project: Maven 2 Type: Bug Versions: 2.0 Reporter: Mark Hobson Need to resolve the use-case discussed on dev: http://www.nabble.com/Re%3A-m2-Plugins-that-depend-on-other-plugin-goals-t473646.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1617) Javadoc jar deployed for pom project releases
Javadoc jar deployed for pom project releases - Key: MNG-1617 URL: http://jira.codehaus.org/browse/MNG-1617 Project: Maven 2 Type: Bug Reporter: Mark Hobson When running mvn -DperformRelease=true deploy in a reactor build, the parent pom project had a javadoc artifact deployed. This appeared as a artifactId-version-javadoc.pom file which was actually a jar containing just the javadoc resource files. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1617) Javadoc jar deployed for pom project releases
[ http://jira.codehaus.org/browse/MNG-1617?page=comments#action_51326 ] Mark Hobson commented on MNG-1617: -- Sorry, itchy trigger finger: component maven-deploy-plugin; affects version 2.0. Javadoc jar deployed for pom project releases - Key: MNG-1617 URL: http://jira.codehaus.org/browse/MNG-1617 Project: Maven 2 Type: Bug Reporter: Mark Hobson When running mvn -DperformRelease=true deploy in a reactor build, the parent pom project had a javadoc artifact deployed. This appeared as a artifactId-version-javadoc.pom file which was actually a jar containing just the javadoc resource files. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-190) Missing dependencies for slide-webdavlib
[ http://jira.codehaus.org/browse/MEV-190?page=comments#action_51053 ] Mark Hobson commented on MEV-190: - You mean on ibiblio? It's here: http://www.ibiblio.org/maven2/slide/slide-webdavlib/2.1/ Or if you mean the project, 2.1 is here: http://jakarta.apache.org/slide/download.html Missing dependencies for slide-webdavlib Key: MEV-190 URL: http://jira.codehaus.org/browse/MEV-190 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Mark Hobson Assignee: Edwin Punzalan Unsure who's responsible for this - apache projects are meant to be synced with ibiblio and thus should be fixed at source, although the slide team have ignored requests to do so: http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev/200510.mbox/[EMAIL PROTECTED] The dependencies should be: dependencies dependency groupIdcommons-httpclient/groupId artifactIdcommons-httpclient/artifactId version2.0.2/version /dependency dependency groupIdjdom/groupId artifactIdjdom/artifactId version1.0/version /dependency dependency groupIdde.zeigermann.xml/groupId artifactIdxml-im-exporter/artifactId version1.1/version /dependency /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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-785) m2 tomcat plugin
[ http://jira.codehaus.org/browse/MNG-785?page=comments#action_50860 ]
Mark Hobson commented on MNG-785:
-
Thanks for this, I'll try to incorporate this into the next version. BTW,
probably worth raising future issues against the sandbox component in the MOJO
project.
m2 tomcat plugin
Key: MNG-785
URL: http://jira.codehaus.org/browse/MNG-785
Project: Maven 2
Type: New Feature
Components: maven-plugins
Versions: 2.0-beta-1
Reporter: Mark Hobson
Assignee: Brett Porter
Attachments: maven-tomcat-plugin.tar.gz, maven-tomcat-plugin.zip
See attached for an initial stab at a m2 Tomcat plugin. The plugin provides
the following goals:
tomcat:deploy
tomcat:undeploy
tomcat:reload
tomcat:start
tomcat:stop
It's geared towards Tomcat 5.5 in which the install/remove commands are
depreciated in preference of deploy/undeploy. It shouldn't be much work to
add these for Tomcat 5.0 users if necessary.
I tried to keep the config to a minimum since the vast number of deployment
options that Tomcat provides tends to complicate plugins. The core config
params for all tasks are:
url - the Tomcat manager URL (default = http://localhost:8080/manager;)
username - the Tomcat manager username (default = admin)
password - the Tomcat manager password (default = )
charset - the Tomcat manager request URL encoding charset (default =
ISO-8859-1)
path - the web context path (default = /${project.build.finalName})
The tomcat:deploy goal requires further parameters to customise the type of
deployment. After considering the various deployment methods supported by
manager, I decided that the project-centric ones applicable to a m2 plugin
come down to three modes of operation:
remote
- the war is deployed via a HTTP PUT to manager
- war plugin mode must be normal (i.e. not exploded)
- suitable for cross-network
local
- the war is deployed by supplying a path to the war file/dir
- the war plugin mode config param determines whether the war is deployed as
a file or as a dir
- suitable for localhost tomcat
inplace
- the war is deployed via a context.xml file that refers to the war dir
- the war plugin mode must be exploded
- suitable for dev
The other Tomcat deployment methods didn't seem too useful for
project-orientation deployment - they are summarised here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html#Deploy%20A%20New%20Application%20from%20a%20Local%20Path
So the tomcat:deploy specific config params are:
mode - remote, local or inplace (default = remote)
war - the war file path (default =
${project.build.directory}/${project.build.finalName}.war)
warDir - the war dir path (default =
${project.build.directory}/${project.build.finalName})
config - the context.xml path (default =
${project.build.directory}/${project.build.finalName}/META-INF/context.xml)
update - whether to undeploy before deploying (default = false)
When deploying inplace the context.xml Context/@docBase attribute needs to be
set to the war dir. I noticed the discussion on the m2 mailing list
regarding resource filtering, so hopefully that can perform this task pre-war.
The code is inspired by the Tomcat Ant tasks, but rewritten for m2. This is
my first m2 plugin so any constructive comments are welcome! In particular,
feedback on the following would be appreciated:
- opinions on the remote/local/inplace mode of operations
- any config options I've missed
- is the method of introspecting the war plugin config the norm, or is there
a nicer way?
You're welcome to the code I'm happy to adopt this plugin time-permitting.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-190) Missing dependencies for slide-webdavlib
Missing dependencies for slide-webdavlib Key: MEV-190 URL: http://jira.codehaus.org/browse/MEV-190 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Mark Hobson Unsure who's responsible for this - apache projects are meant to be synced with ibiblio and thus should be fixed at source, although the slide team have ignored requests to do so: http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev/200510.mbox/[EMAIL PROTECTED] The dependencies should be: dependencies dependency groupIdcommons-httpclient/groupId artifactIdcommons-httpclient/artifactId version2.0.2/version /dependency dependency groupIdjdom/groupId artifactIdjdom/artifactId version1.0/version /dependency dependency groupIdde.zeigermann.xml/groupId artifactIdxml-im-exporter/artifactId version1.1/version /dependency /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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1354) NPE when plugins throw certain exceptions
[ http://jira.codehaus.org/browse/MNG-1354?page=comments#action_50023 ] Mark Hobson commented on MNG-1354: -- Agreed, but decompiling the 2.0 distributable shows that the patch hasn't been applied. I was just unsure why there's a discrepancy between the 2.0 tag and the 2.0 distributable. NPE when plugins throw certain exceptions - Key: MNG-1354 URL: http://jira.codehaus.org/browse/MNG-1354 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: Mark Hobson Assignee: Brett Porter Regularly see this, although it's entirely obvious why looking at the source: java.lang.NullPointerException at org.apache.maven.usability.diagnostics.DiagnosisUtils.appendRootCauseIfPresentAndUnique(DiagnosisUtils.java:89) at org.apache.maven.usability.diagnostics.ErrorDiagnostics$PuntErrorDiagnoser.diagnose(ErrorDiagnostics.java:132) at org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:104) at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:693) at org.apache.maven.DefaultMaven.logFatal(DefaultMaven.java:627) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:143) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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) Can spend time creating a testcase if it's not immediately obvious. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1410) Timestamped snapshot dependencies added as file refs rather than project refs
Timestamped snapshot dependencies added as file refs rather than project refs - Key: MNG-1410 URL: http://jira.codehaus.org/browse/MNG-1410 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0.1 Environment: Windows XP, Cygwin Reporter: Mark Hobson If eclipse:eclipse is executed in a reactor build, any snapshot dependencies that have a timestamped jar (e.g. downloaded from continuum) are added to the .classpath as jar file references rather than project references. I've tracked this down to EclipseUtils.findReactorProject() where the g:a:v comparision is failing between the reactor projects' version (v-SNAPSHOT) and the artifact version (v-timestamp). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1412) .classpath should have nearest order
.classpath should have nearest order Key: MNG-1412 URL: http://jira.codehaus.org/browse/MNG-1412 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Hobson The .classpath file entries should be ordered by nearest transitiveness (if that's a word). For example, I have project A that depends on B that depends on C. The classpath for A is generated in the order C, B. Ideally the classpath should be in order of how near they are to the project, i.e. B, C. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-791) Add resource filtering to war plugin
[ http://jira.codehaus.org/browse/MNG-791?page=all ] Mark Hobson updated MNG-791: Attachment: test.zip As a workaround to this issue, you can use a project structure like the one attached. It basically splits webapp resources off into filtered and unfiltered ones - leaving the war plugin to copy the unfiltered resources, and using the resources plugin to copy the filtered resources with a cunning ../finalName path. This obviously relies on a standard maven project structure. It also works if you want to profile-off your filters for different target environments. Add resource filtering to war plugin Key: MNG-791 URL: http://jira.codehaus.org/browse/MNG-791 Project: Maven 2 Type: Improvement Components: maven-war-plugin Versions: 2.0-beta-1 Reporter: Mark Hobson Assignee: Brett Porter Fix For: 2.0.1 Attachments: test.zip Original Estimate: 15 minutes Remaining: 15 minutes I'd like to patch the war plugin to perform resource filtering as per the resources plugin. This is a trivial patch but would duplicate the following code from the resources plugin: PropertyUtils ReflectionProperties ResourcesMojo.copyFile(File, File) These look like handy util methods that could be incorporated into plexus-utils - what do the developers think? Also not sure how resource filtering will be affected by MNG-788. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1378) test-jar transitive dependencies are incorrectly calculated
test-jar transitive dependencies are incorrectly calculated --- Key: MNG-1378 URL: http://jira.codehaus.org/browse/MNG-1378 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: Mark Hobson test-jar transitive dependencies are calculated as per compile scope rather than test scope. The situation is demonstrated nicely in it0077: * module sub1 has a test-scoped dependency of commons-lang * module sub2 has a test-scoped dependency of sub1 test-jar sub2 tests should inherit the commons-lang transitive dependency. For example: Index: maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java === --- maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (revision 328307) +++ maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (working copy) @@ -1,6 +1,7 @@ package org.apache.maven.it0077; import junit.framework.TestCase; +import org.apache.commons.lang.BooleanUtils; public class PersonTwoTest extends PersonTest Results in: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31] package org.apache.commons.lang does not exist -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-155) Missing stax 1.1-dev
[ http://jira.codehaus.org/browse/MEV-155?page=comments#action_49556 ] Mark Hobson commented on MEV-155: - No probs, I'm not actually using it myself - just spotted it when noticing MEV-156. Missing stax 1.1-dev Key: MEV-155 URL: http://jira.codehaus.org/browse/MEV-155 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Mark Hobson stax:stax:1.1-dev is missing - could be similar to velocity-1.4-dev problem..? -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1354) NPE when plugins throw certain exceptions
NPE when plugins throw certain exceptions - Key: MNG-1354 URL: http://jira.codehaus.org/browse/MNG-1354 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: Mark Hobson Regularly see this, although it's entirely obvious why looking at the source: java.lang.NullPointerException at org.apache.maven.usability.diagnostics.DiagnosisUtils.appendRootCauseIfPresentAndUnique(DiagnosisUtils.java:89) at org.apache.maven.usability.diagnostics.ErrorDiagnostics$PuntErrorDiagnoser.diagnose(ErrorDiagnostics.java:132) at org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:104) at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:693) at org.apache.maven.DefaultMaven.logFatal(DefaultMaven.java:627) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:143) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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) Can spend time creating a testcase if it's not immediately obvious. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1354) NPE when plugins throw certain exceptions
[ http://jira.codehaus.org/browse/MNG-1354?page=comments#action_49486 ] Mark Hobson commented on MNG-1354: -- s/it's entirely obvious/it's not entirely obvious :) NPE when plugins throw certain exceptions - Key: MNG-1354 URL: http://jira.codehaus.org/browse/MNG-1354 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: Mark Hobson Regularly see this, although it's entirely obvious why looking at the source: java.lang.NullPointerException at org.apache.maven.usability.diagnostics.DiagnosisUtils.appendRootCauseIfPresentAndUnique(DiagnosisUtils.java:89) at org.apache.maven.usability.diagnostics.ErrorDiagnostics$PuntErrorDiagnoser.diagnose(ErrorDiagnostics.java:132) at org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:104) at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:693) at org.apache.maven.DefaultMaven.logFatal(DefaultMaven.java:627) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:143) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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) Can spend time creating a testcase if it's not immediately obvious. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-156) Wrong stax-api dependencies
Wrong stax-api dependencies --- Key: MEV-156 URL: http://jira.codehaus.org/browse/MEV-156 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Mark Hobson stax-api should have no dependencies - it currently has: dependencies dependency groupIdxmlbeans/groupId artifactIdxmlbeans-jsr173-api/artifactId version2.0-dev/version /dependency /dependencies This dependency is for stax:stax:1.1-dev, not stax:stax-api:1.0. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1341) Guide to using attached tests incorrect pom.xml
Guide to using attached tests incorrect pom.xml - Key: MNG-1341 URL: http://jira.codehaus.org/browse/MNG-1341 Project: Maven 2 Type: Bug Components: documentation Versions: 2.0.1 Reporter: Mark Hobson Attachments: patch.txt See patch. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-150) jMock 1.0.1 POM has /dependecy instead of /dependency
[ http://jira.codehaus.org/browse/MEV-150?page=comments#action_49294 ] Mark Hobson commented on MEV-150: - This is also true of jmock-cglib too. jMock 1.0.1 POM has /dependecy instead of /dependency - Key: MEV-150 URL: http://jira.codehaus.org/browse/MEV-150 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: David Jackman -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MNG-1244) bin/m2 breaks with spaces in path
[ http://jira.codehaus.org/browse/MNG-1244?page=all ] Mark Hobson reopened MNG-1244: -- You also need the inner set of quotes - I'll attach a patch to avoid ambiguity. bin/m2 breaks with spaces in path - Key: MNG-1244 URL: http://jira.codehaus.org/browse/MNG-1244 Project: Maven 2 Type: Bug Versions: 2.0 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: Brett Porter Priority: Minor Fix For: 2.0.1 The bin/m2 script breaks under cygwin if the m2 home has spaces in the path. Quick fix: 25c25 exec `dirname $0`/mvn $@ --- exec `dirname $0`/mvn $@ -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1244) bin/m2 breaks with spaces in path
[ http://jira.codehaus.org/browse/MNG-1244?page=all ] Mark Hobson updated MNG-1244: - Attachment: MNG-1244.txt bin/m2 breaks with spaces in path - Key: MNG-1244 URL: http://jira.codehaus.org/browse/MNG-1244 Project: Maven 2 Type: Bug Versions: 2.0 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: Brett Porter Priority: Minor Fix For: 2.0.1 Attachments: MNG-1244.txt The bin/m2 script breaks under cygwin if the m2 home has spaces in the path. Quick fix: 25c25 exec `dirname $0`/mvn $@ --- exec `dirname $0`/mvn $@ -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1244) bin/m2 breaks with spaces in path
bin/m2 breaks with spaces in path - Key: MNG-1244 URL: http://jira.codehaus.org/browse/MNG-1244 Project: Maven 2 Type: Bug Versions: 2.0 Environment: Windows XP, Cygwin Reporter: Mark Hobson Priority: Minor The bin/m2 script breaks under cygwin if the m2 home has spaces in the path. Quick fix: 25c25 exec `dirname $0`/mvn $@ --- exec `dirname $0`/mvn $@ -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (WAGON-23) Lightweight HTTP wagon doesn't support caching
Lightweight HTTP wagon doesn't support caching -- Key: WAGON-23 URL: http://jira.codehaus.org/browse/WAGON-23 Project: wagon Type: Bug Versions: 1.0-alpha-5 Reporter: Mark Hobson Priority: Critical LightweightHttpWagon always write a Pragma: no-cache header when requesting resources - this stops regular proxy caching from being much use.. There's a todo in the code for this, but appears to depend on wagon's being configurable - so I'm not sure if there's a issue for this to depend on. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-792) Can't ctrl-C m2 under cygwin
[ http://jira.codehaus.org/browse/MNG-792?page=comments#action_48860 ] Mark Hobson commented on MNG-792: - Woohoo, this problem appears to have vanished in 2.0 RC! I wonder what fixed it - have any relevant dependencies been upgraded? Does ctrl-C now work for everyone else? If so I guess this can be closed. Can't ctrl-C m2 under cygwin Key: MNG-792 URL: http://jira.codehaus.org/browse/MNG-792 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Under cygwin you can't ctrl-C to interrupt the process when running m2. This used to work under 2.0-alpha-3. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-955) There should be possible to use artifacts instead of project references in multi module projects
[ http://jira.codehaus.org/browse/MNG-955?page=comments#action_48733 ] Mark Hobson commented on MNG-955: - I also have doubts about eclipse project references - see my comments on MNG-827, which is a related issue. I think the point-and-click navigation advantage is a red herring, since strictly speaking this should be implemented via source artifacts. There should be possible to use artifacts instead of project references in multi module projects Key: MNG-955 URL: http://jira.codehaus.org/browse/MNG-955 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Reporter: Kaare Nilsen Assignee: Edwin Punzalan Fix For: 2.0 Attachments: MNG-955-maven-eclipse-plugin.patch One of the fine things with maven is that one can have several modules in a project. But in the eclipse plugin all dependent modules in the project is added as a project reference instead of using the delivered artifact. As a result i have to have all my modules (eclipse projects) opened just to compile in eclipse. I think this should be an option. e.g. useProjectReferencetrue/useProjectReference with this set to true as default, but when false, the classpath should use a reference to the jar in local repos as all other artifacts -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-40) URL tag invalids
[ http://jira.codehaus.org/browse/MEV-40?page=comments#action_48744 ]
Mark Hobson commented on MEV-40:
Also note that commons-codec is broken too:
http://www.ibiblio.org/maven2/commons-codec/commons-codec/1.3/commons-codec-1.3.pom:
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
packageorg.apache.commons.${pom.artifactId.substring(8)}/package
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/connection
urlhttp://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/url
URL tag invalids
Key: MEV-40
URL: http://jira.codehaus.org/browse/MEV-40
Project: Maven Evangelism
Type: Bug
Components: Invalid POM
Reporter: Vincent Siveton
Assignee: Edwin Punzalan
I noticed that the following POMs have invalid url definitions:
commons-el\commons-el\1.0\commons-el-1.0.pom :
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/connection
urlhttp://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/url
urlfile:///www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//url
urlscp://jakarta.apache.org//www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
commons-io\commons-io\1.0\commons-io-1.0.pom :
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/home/cvspublic:jakarta-commons/${pom.artifactId.substring(8)}/connection
urlhttp://cvs.apache.org/viewcvs/jakarta-commons/${pom.artifactId.substring(8)}//url
urlfile:///www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//url
urlscp://jakarta.apache.org//www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
commons-lang\commons-lang\1.0\commons-lang-1.0.pom :
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
commons-lang\commons-lang\2.1\commons-lang-2.1.pom :
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/connection
urlhttp://svn.apache.org/viewcvs/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/url
urlfile:///www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//url
urlscp://jakarta.apache.org//www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
org\codehaus\modello\modello\1.0-alpha-3\modello-1.0-alpha-3.pom :
urlhttp://cvs.modello.codehaus.org/modello/${pom.artifactId}/url
So, dependencies reports generate wrong URL.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-344) Complains about not finding m2 and then builds successfully
Complains about not finding m2 and then builds successfully --- Key: CONTINUUM-344 URL: http://jira.codehaus.org/browse/CONTINUUM-344 Project: Continuum Type: Bug Versions: 1.0-beta-1 Environment: Linux Reporter: Mark Hobson Priority: Minor Attachments: wrapper.log When adding a m2 project it complains that it can't find m2 in the attached log and then proceeds to build successfully. m2 is actually at /usr/local/m2/bin/m2 and can be run from the command line as the continuum user. -- 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-1124) guide-m1-m2 patch
guide-m1-m2 patch - Key: MNG-1124 URL: http://jira.codehaus.org/browse/MNG-1124 Project: Maven 2 Type: Improvement Components: documentation Versions: 2.0-beta-4 Reporter: Mark Hobson Priority: Minor Attachments: diff.txt Multiproject and project.properties info as per thread [m2] m1 pom conversion. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-230) attempt to reintroduce the use of a single SNAPSHOT file locally
[ http://jira.codehaus.org/browse/MNG-230?page=comments#action_48027 ] Mark Hobson commented on MNG-230: - This appears to work correctly in as far as the local repo goes, but IDE plugins such as eclipse still produce artifact paths with the timestamp suffix rather than the SNAPSHOT suffix - would this be a bug with this issue or the way that the eclipse plugin retrieves the snapshot paths? attempt to reintroduce the use of a single SNAPSHOT file locally Key: MNG-230 URL: http://jira.codehaus.org/browse/MNG-230 Project: Maven 2 Type: Improvement Components: maven-artifact Reporter: Brett Porter Assignee: Brett Porter Fix For: 2.0-beta-3 Original Estimate: 30 minutes Time Spent: 4 hours Remaining: 0 minutes we are now downloading timestamped versions and saving them under that version ID. this would be of great benefits to IDEs so that the descriptor does not need to be updated whenever a new snapshot is resolved. the reason this is not currently practical is that a POM is first resolved, and following that there is nothing to indicate that the JAR needs to be updated. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1127) IDE plugins get wrong path to snapshots
[ http://jira.codehaus.org/browse/MNG-1127?page=comments#action_48038 ] Mark Hobson commented on MNG-1127: -- I think you mean MNG-230 ;) IDE plugins get wrong path to snapshots --- Key: MNG-1127 URL: http://jira.codehaus.org/browse/MNG-1127 Project: Maven 2 Type: Bug Components: maven-artifact Reporter: Brett Porter Assignee: Brett Porter Original Estimate: 15 minutes Remaining: 15 minutes -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-3) Broken dependencies for nanocontainer
[ http://jira.codehaus.org/browse/MEV-3?page=comments#action_47843 ]
Mark Hobson commented on MEV-3:
---
What's the current situation with the nanocontainer pom? I see:
https://svn.codehaus.org/picocontainer/java/nanocontainer/tags/nanocontainer-1_0-RC-2/project.xml
is very different to:
http://www.ibiblio.org/maven2/nanocontainer/nanocontainer/1.0-RC-2/nanocontainer-1.0-RC-2.pom
How does repoclean dervive the latter pom? Is there anything that's holding up
fixing this?
Broken dependencies for nanocontainer
-
Key: MEV-3
URL: http://jira.codehaus.org/browse/MEV-3
Project: Maven Evangelism
Type: Task
Reporter: Mark Hobson
Broken dependencies for:
http://www.ibiblio.org/maven2/nanocontainer/nanocontainer/1.0-beta-4/nanocontainer-1.0-beta-4.pom
Dependencies use jelly variables ${picocontainer.version} and
${pom.currentVersion}.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-3) Broken dependencies for nanocontainer
[ http://jira.codehaus.org/browse/MEV-3?page=comments#action_47847 ]
Mark Hobson commented on MEV-3:
---
Right thanks, I'll take it to the nano list.
Broken dependencies for nanocontainer
-
Key: MEV-3
URL: http://jira.codehaus.org/browse/MEV-3
Project: Maven Evangelism
Type: Task
Reporter: Mark Hobson
Broken dependencies for:
http://www.ibiblio.org/maven2/nanocontainer/nanocontainer/1.0-beta-4/nanocontainer-1.0-beta-4.pom
Dependencies use jelly variables ${picocontainer.version} and
${pom.currentVersion}.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-3) Broken dependencies for nanocontainer
[ http://jira.codehaus.org/browse/MEV-3?page=comments#action_47849 ]
Mark Hobson commented on MEV-3:
---
I saw that this issue was depended on by another issue, but not that this issue
had any prerequisites. Is that correct?
Broken dependencies for nanocontainer
-
Key: MEV-3
URL: http://jira.codehaus.org/browse/MEV-3
Project: Maven Evangelism
Type: Task
Reporter: Mark Hobson
Broken dependencies for:
http://www.ibiblio.org/maven2/nanocontainer/nanocontainer/1.0-beta-4/nanocontainer-1.0-beta-4.pom
Dependencies use jelly variables ${picocontainer.version} and
${pom.currentVersion}.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1053) Reactor mediates projects like dependencies
[ http://jira.codehaus.org/browse/MNG-1053?page=comments#action_47768 ] Mark Hobson commented on MNG-1053: -- I think it's definitely worth moving to 2.1 and consider the impact fully then. Reactor mediates projects like dependencies --- Key: MNG-1053 URL: http://jira.codehaus.org/browse/MNG-1053 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-3 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: Brett Porter Attachments: test.zip The attached zip contains the following projects: test:a:1.0 test:a:2.0 Running m2 -r install in the project's parent directory results in only test:a:2.0 being built. It appears that m2 mediates out projects in the reactor in the same manner as 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1053) Reactor mediates projects like dependencies
[ http://jira.codehaus.org/browse/MNG-1053?page=comments#action_47666 ] Mark Hobson commented on MNG-1053: -- Should this not be pushed to 2.1 given MNG-1050? Reactor mediates projects like dependencies --- Key: MNG-1053 URL: http://jira.codehaus.org/browse/MNG-1053 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-3 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: Brett Porter Attachments: test.zip The attached zip contains the following projects: test:a:1.0 test:a:2.0 Running m2 -r install in the project's parent directory results in only test:a:2.0 being built. It appears that m2 mediates out projects in the reactor in the same manner as 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1053) Reactor mediates projects like dependencies
[ http://jira.codehaus.org/browse/MNG-1053?page=comments#action_47672 ] Mark Hobson commented on MNG-1053: -- Sorry it may have been a bit cryptic ;) I was referring to the major versions are incompatible bit, which I would have thought implied that the reactor should abide by the same rules build both 1.x and 2.x. Is there any reason why the reactor must only build one version of a project? I have a few projects where 1.x and 2.x development occurs simultaneously in the same scm with the same group artifact ids. It seems a bit daft having to add a '2' suffix to the 2.x artifact id so that the reactor picks it up - you end up artifactId2-2.0.jar :) Reactor mediates projects like dependencies --- Key: MNG-1053 URL: http://jira.codehaus.org/browse/MNG-1053 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-3 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: Brett Porter Attachments: test.zip The attached zip contains the following projects: test:a:1.0 test:a:2.0 Running m2 -r install in the project's parent directory results in only test:a:2.0 being built. It appears that m2 mediates out projects in the reactor in the same manner as 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1062) Allow custom code formatters to be written to .settings
Allow custom code formatters to be written to .settings --- Key: MNG-1062 URL: http://jira.codehaus.org/browse/MNG-1062 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0-beta-3 Reporter: Mark Hobson It'd be handy if there was a way of embedding custom code formatters to .settings. Eclipse can currently export code formatter profiles as a list of properties in an XML format, so this file could be configured against the eclipse plugin for it to generate the corresponding properties-format .settings/org.eclipse.jdt.core.prefs file. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1062) Allow custom code formatters to be written to .settings
[ http://jira.codehaus.org/browse/MNG-1062?page=comments#action_47627 ] Mark Hobson commented on MNG-1062: -- A single formatting file would be a good idea, although I'm not sure if the checkstyle config XML to eclipse settings mapping would be trivial. I couldn't see any support for code format properties in EclipseSettingsWriter. Allow custom code formatters to be written to .settings --- Key: MNG-1062 URL: http://jira.codehaus.org/browse/MNG-1062 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0-beta-3 Reporter: Mark Hobson It'd be handy if there was a way of embedding custom code formatters to .settings. Eclipse can currently export code formatter profiles as a list of properties in an XML format, so this file could be configured against the eclipse plugin for it to generate the corresponding properties-format .settings/org.eclipse.jdt.core.prefs file. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-985) plugin goals referenced in build/pluginManagment unexpectedly executed during lifecycle
[ http://jira.codehaus.org/browse/MNG-985?page=comments#action_47542 ] Mark Hobson commented on MNG-985: - I believe the fix for this has regressed using pluginManagement for plugin configuration - I can attach a test case if you reopen this issue. plugin goals referenced in build/pluginManagment unexpectedly executed during lifecycle --- Key: MNG-985 URL: http://jira.codehaus.org/browse/MNG-985 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-1 Environment: WinXP SP2, Java 1.4.2_06, Maven 2.0-beta-1 Reporter: John Fallows Assignee: John Casey Fix For: 2.0-beta-3 Attachments: pom.xml Original Estimate: 30 minutes Time Spent: 30 minutes Remaining: 0 minutes Goals referenced in buildpluginManagement plugins are executed during the lifecycle - this is unexpected. See the attached pom.xml as an example. Running m2 install on this pom causes the war plugin to execute the war goal during the packaging phase of the lifecycle. Note that the goal should not execute because it is inside the pluginManagement section. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1052) Using pluginManagement for configuration regression
Using pluginManagement for configuration regression --- Key: MNG-1052 URL: http://jira.codehaus.org/browse/MNG-1052 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-3 Reporter: Mark Hobson Attachments: test.zip I believe due to MNG-985, using pluginManagement for plugin configuration has regressed - see attached testcase. Maybe worth creating an itest for this to prevent this in future? -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-985) plugin goals referenced in build/pluginManagment unexpectedly executed during lifecycle
[ http://jira.codehaus.org/browse/MNG-985?page=comments#action_47546 ] Mark Hobson commented on MNG-985: - Opened new issue for this: MNG-1052 plugin goals referenced in build/pluginManagment unexpectedly executed during lifecycle --- Key: MNG-985 URL: http://jira.codehaus.org/browse/MNG-985 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-1 Environment: WinXP SP2, Java 1.4.2_06, Maven 2.0-beta-1 Reporter: John Fallows Assignee: John Casey Fix For: 2.0-beta-3 Attachments: pom.xml Original Estimate: 30 minutes Time Spent: 30 minutes Remaining: 0 minutes Goals referenced in buildpluginManagement plugins are executed during the lifecycle - this is unexpected. See the attached pom.xml as an example. Running m2 install on this pom causes the war plugin to execute the war goal during the packaging phase of the lifecycle. Note that the goal should not execute because it is inside the pluginManagement section. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1053) Reactor mediates projects like dependencies
Reactor mediates projects like dependencies --- Key: MNG-1053 URL: http://jira.codehaus.org/browse/MNG-1053 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-3 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: test.zip The attached zip contains the following projects: test:a:1.0 test:a:2.0 Running m2 -r install in the project's parent directory results in only test:a:2.0 being built. It appears that m2 mediates out projects in the reactor in the same manner as 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-230) attempt to reintroduce the use of a single SNAPSHOT file locally
[ http://jira.codehaus.org/browse/MNG-230?page=comments#action_47332 ] Mark Hobson commented on MNG-230: - Should this really wait until 2.1 - this appears to stop users from transparently using ci systems like continuum with snapshot repositories? attempt to reintroduce the use of a single SNAPSHOT file locally Key: MNG-230 URL: http://jira.codehaus.org/browse/MNG-230 Project: Maven 2 Type: Improvement Components: maven-artifact Reporter: Brett Porter Fix For: 2.1 we are now downloading timestamped versions and saving them under that version ID. this would be of great benefits to IDEs so that the descriptor does not need to be updated whenever a new snapshot is resolved. the reason this is not currently practical is that a POM is first resolved, and following that there is nothing to indicate that the JAR needs to be updated. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-831) Improve plugin API to ease configuration sharing between plugins
[ http://jira.codehaus.org/browse/MNG-831?page=comments#action_47334 ] Mark Hobson commented on MNG-831: - As long as the properties that a plugin sets are well documented and namespaced. My only concern is property name clashes with user pom properties - would it be safer using the plugin context from MNG-823 across multiple plugins? That way the properties are isolated from the user and only accessible by the plugin developers. Improve plugin API to ease configuration sharing between plugins Key: MNG-831 URL: http://jira.codehaus.org/browse/MNG-831 Project: Maven 2 Type: Improvement Components: maven-plugin-api Versions: 2.0-beta-1 Reporter: Mark Hobson Assignee: Brett Porter Plugins that need to introspect other plugin's configuration have to go via the Xpp3Dom configuration object. It'd be nice if this was easier for plugin authors. Some current use-cases are: * Eclipse plugin requires compiler plugin's configuration to write .settings file * Tomcat plugin requires war plugin's configuration to locate final war file and exploded state -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1037) Add war:exploded and war:inplace goals
Add war:exploded and war:inplace goals -- Key: MNG-1037 URL: http://jira.codehaus.org/browse/MNG-1037 Project: Maven 2 Type: Improvement Components: maven-war-plugin Versions: 2.0-beta-2 Reporter: Mark Hobson Need to add war:exploded and war:inplace goals to replace the depreciated war:war mode config parameter. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-230) attempt to reintroduce the use of a single SNAPSHOT file locally
[ http://jira.codehaus.org/browse/MNG-230?page=comments#action_47339 ] Mark Hobson commented on MNG-230: - Sorry, that's what I meant by transparently. I want to move to continuum produced snapshots asap, but without this IDE integration I can see no end of complaints from the dev team.. It'd be great if this can be fixed relatively easily. attempt to reintroduce the use of a single SNAPSHOT file locally Key: MNG-230 URL: http://jira.codehaus.org/browse/MNG-230 Project: Maven 2 Type: Improvement Components: maven-artifact Reporter: Brett Porter Fix For: 2.0-beta-3 Original Estimate: 30 minutes Remaining: 30 minutes we are now downloading timestamped versions and saving them under that version ID. this would be of great benefits to IDEs so that the descriptor does not need to be updated whenever a new snapshot is resolved. the reason this is not currently practical is that a POM is first resolved, and following that there is nothing to indicate that the JAR needs to be updated. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-324) State images have /continuum web context hardcoded in their URL
State images have /continuum web context hardcoded in their URL --- Key: CONTINUUM-324 URL: http://jira.codehaus.org/browse/CONTINUUM-324 Project: Continuum Type: Bug Components: continuum-web Versions: 1.0-alpha-4 Reporter: Mark Hobson Priority: Minor It appears that whereever $state.generate() is used, the resultant image src has the default web context path of '/continuum' hardcoded in. Hence status images break when continuum is installed to a different context. -- 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-1027) Deployed manifest classpaths contain SNAPSHOT filenames
Deployed manifest classpaths contain SNAPSHOT filenames --- Key: MNG-1027 URL: http://jira.codehaus.org/browse/MNG-1027 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0-beta-2 Reporter: Mark Hobson When deploying a snapshot that includes the classpath in it's manifest, the SNAPSHOT.jar filenames are written into the manifest rather than the actual deployed timestamp.jar filenames. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1017) Cannot use maven ant tasks in antrun
Cannot use maven ant tasks in antrun
Key: MNG-1017
URL: http://jira.codehaus.org/browse/MNG-1017
Project: Maven 2
Type: Bug
Components: maven-antrun-plugin
Versions: 2.0-beta-1
Environment: Windows XP, Cygwin
Reporter: Mark Hobson
Attachments: test.zip
In an attempt to subvert MNG-896 I'm using the maven ant tasks within antrun
(see attached testcase). This leads to the following error, presumably due to
the multiple plexus configuration files:
[INFO]
[INFO] Building test:test:war:1.0
[INFO]task-segment: [package]
[INFO]
[INFO] [resources:resources]
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
process-resources:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Diagnosis: Error executing ant tasks
[INFO]
[ERROR] Cause:
org.apache.maven.plugin.MojoExecutionException: Error executing ant tasks
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:62)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:63)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:357)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:452)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:438)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:131)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186)
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)
Caused by: The following error occurred while executing this line: C:\Documents
and Settings\mark\Desktop\test\build.xml:13: Unable to start embedder
at
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:539)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:384)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:56)
... 17 more
Caused by: C:\Documents and Settings\mark\Desktop\test\build.xml:13: Unable to
start embedder
at
org.apache.maven.artifact.ant.AbstractArtifactTask.getEmbedder(AbstractArtifactTask.java:323)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.lookup(AbstractArtifactTask.java:284)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRepository(AbstractArtifactTask.java:77)
at
org.apache.maven.artifact.ant.DependenciesTask.execute(DependenciesTask.java:73)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
... 21 more
Caused by: org.codehaus.plexus.PlexusContainerException: Error starting
container
at
org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:766)
at org.codehaus.plexus.embed.Embedder.start(Embedder.java:208)
at org.codehaus.plexus.embed.Embedder.start(Embedder.java:171)
[jira] Created: (MNG-1020) Improve JRE_CONTAINER classpath entry
Improve JRE_CONTAINER classpath entry - Key: MNG-1020 URL: http://jira.codehaus.org/browse/MNG-1020 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0-beta-1 Reporter: Mark Hobson Same as MPECLIPSE-104 but for m2, although this only really makes sense for dependencies in the bootclasspath as only they can override the JRE. Hence this issue depends on MNG-973. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-896) Need to declare dependencies as resources outside of WEB-INF in WARs
[ http://jira.codehaus.org/browse/MNG-896?page=comments#action_46992 ] Mark Hobson commented on MNG-896: - In most situations we'd also want to pull in all the necessary transitive dependencies. For example, an applet jar with a manifest classpath. Another use-case would be JNLP applications that are deployed via a war project. Need to declare dependencies as resources outside of WEB-INF in WARs Key: MNG-896 URL: http://jira.codehaus.org/browse/MNG-896 Project: Maven 2 Type: Improvement Components: maven-war-plugin Reporter: Mark Hobson Need to be able to declare maven dependencies as resources within WARs. Currently all dependencies are placed within WEB-INF/lib. Typical use-case is for a war project to pull in an applet from the repo to be included in the package. Would need to specify the whereabouts of the applet in the WAR. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-874) Cannot download plugin POM when auto-discovering plugins
[ http://jira.codehaus.org/browse/MNG-874?page=all ] Mark Hobson updated MNG-874: Attachment: test-plugin2.zip It doesn't seem to be even finding the POM for me? For example, see the attached test-plugin2.zip - I've added a commons-collections dependency and it's not being added to the classpath: [EMAIL PROTECTED] test-plugin]$ m2 -s settings.xml hello:hello [INFO] Searching repository for plugin with prefix: 'hello'. [INFO] hello: checking for updates from test [INFO] hello: checking for updates from central-plugins [INFO] artifact hello:hello: checking for updates from test [INFO] artifact hello:hello: checking for updates from central-plugins Downloading: http://repo1.maven.org/maven2/plugins/hello/hello/1.0/hello-1.0.pom [WARNING] * Using defaults for missing POM hello:hello:pom:1.0 * Downloading: file:target/test-repo/hello/hello/1.0/hello-1.0.jar 2K downloaded [INFO] [INFO] Building hello:hello:maven-plugin:1.0 [INFO]task-segment: [hello:hello] [INFO] [INFO] [hello:hello] --- constituent[0]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/commons-cli-1.0.jar constituent[1]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/commons-lang-1.0.jar constituent[2]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/commons-logging-1.0.jar constituent[3]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/doxia-sink-api-1.0-alpha-4.jar constituent[4]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/jline-0.9.1.jar constituent[5]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/jsch-0.1.21.jar constituent[6]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-artifact-2.0-beta-1-SNAPSHOT.jar constituent[7]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-artifact-manager-2.0-beta-1-SNAPSHOT.jar constituent[8]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-core-2.0-beta-1-SNAPSHOT.jar constituent[9]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-model-2.0-beta-1-SNAPSHOT.jar constituent[10]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-monitor-2.0-beta-1-SNAPSHOT.jar constituent[11]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-plugin-api-2.0-beta-1-SNAPSHOT.jar constituent[12]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-plugin-descriptor-2.0-beta-1-SNAPSHOT.jar constituent[13]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-plugin-registry-2.0-beta-1-SNAPSHOT.jar constituent[14]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-profile-2.0-beta-1-SNAPSHOT.jar constituent[15]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-project-2.0-beta-1-SNAPSHOT.jar constituent[16]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-reporting-api-2.0-beta-1-SNAPSHOT.jar constituent[17]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-repository-metadata-2.0-beta-1-SNAPSHOT.jar constituent[18]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/maven-settings-2.0-beta-1-SNAPSHOT.jar constituent[19]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/plexus-input-handler-1.0-alpha-2.jar constituent[20]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/wagon-file-1.0-alpha-4.jar constituent[21]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/wagon-http-lightweight-1.0-alpha-4.jar constituent[22]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/wagon-provider-api-1.0-alpha-4.jar constituent[23]: file:/c:/Progra~1/maven-2.0-SNAPSHOT/lib/wagon-ssh-1.0-alpha-4.jar --- Exception in thread main java.lang.NoClassDefFoundError: org/apache/commons/collections/FastArrayList at HelloMojo.execute(HelloMojo.java:11) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:357) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:479) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:460) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:442) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:131) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) 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
[jira] Created: (MNG-895) Profile resources not merged with main POM
Profile resources not merged with main POM -- Key: MNG-895 URL: http://jira.codehaus.org/browse/MNG-895 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Reporter: Mark Hobson Profile resources are not merged with resources specified in the main POM, e.g.: project ... build resources resourcea/resource /resources /build profiles profile ... build resources resourceb/resource /resources /build ... /profile /profiles ... /project The effective resources block should consist of both 'a' and 'b' when the profile is activated, but currently 'b' overrides 'a'. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-896) Need to declare dependencies as resources outside of WEB-INF in WARs
Need to declare dependencies as resources outside of WEB-INF in WARs Key: MNG-896 URL: http://jira.codehaus.org/browse/MNG-896 Project: Maven 2 Type: Improvement Components: maven-war-plugin Reporter: Mark Hobson Need to be able to declare maven dependencies as resources within WARs. Currently all dependencies are placed within WEB-INF/lib. Typical use-case is for a war project to pull in an applet from the repo to be included in the package. Would need to specify the whereabouts of the applet in the WAR. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-874) Cannot download plugin POM when auto-discovering plugins
Cannot download plugin POM when auto-discovering plugins Key: MNG-874 URL: http://jira.codehaus.org/browse/MNG-874 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Priority: Blocker Attachments: test-plugin.zip This issue is following the thread: [m2] using deployed plugin snapshots with new metadata See attached test-plugin project. Steps to reproduce: 1) Deploy the plugin: m2 -DupdateReleaseInfo=true clean:clean deploy [EMAIL PROTECTED] test-plugin]$ m2 -DupdateReleaseInfo=true clean:clean deploy [INFO] Searching repository for plugin with prefix: 'clean'. [INFO] [INFO] Building hello:hello:maven-plugin:1.0 [INFO]task-segment: [clean:clean, deploy] [INFO] [INFO] [clean:clean] [INFO] Deleting directory c:\Documents and Settings\mark\Desktop\test-plugin\target [INFO] [plugin:descriptor] [INFO] [resources:resources] [INFO] [compiler:compile] Compiling 1 source file to c:\Documents and Settings\mark\Desktop\test-plugin\target\classes [INFO] [resources:testResources] [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] Setting reports dir: c:\Documents and Settings\mark\Desktop\test-plugin\target/surefire-reports --- T E S T S --- There are no test to run. Results : [surefire] Tests run: 0, Failures: 0, Errors: 0 [INFO] [jar:jar] [INFO] Building jar: c:\Documents and Settings\mark\Desktop\test-plugin\target\hello-1.0.jar [INFO] [plugin:addPluginArtifactMetadata] [INFO] [install:install] [INFO] Installing c:\Documents and Settings\mark\Desktop\test-plugin\target\hello-1.0.jar to C:\Documents and Settings\m ark\.m2\repository\hello\hello\1.0\hello-1.0.jar [INFO] [deploy:deploy] Uploading: file:target/test-repo/hello/hello/1.0/hello-1.0.jar 2K uploaded [INFO] Retrieving previous metadata from test [INFO] Uploading repository metadata for: 'hello' [INFO] Retrieving previous metadata from test [INFO] Uploading project information for hello 1.0 [INFO] Retrieving previous metadata from test [INFO] Uploading repository metadata for: 'artifact hello:hello' [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 13 seconds [INFO] Finished at: Tue Sep 13 20:25:05 BST 2005 [INFO] Final Memory: 4M/12M [INFO] 2) Clean all knowledge of plugin from local-repo: rm -rf ~/.m2/repository/hello rm ~/.m2/plugin-registry.xml 3) Attempt to auto-discover plugin: m2 -s settings.xml hello:hello [EMAIL PROTECTED] test-plugin]$ m2 -s settings.xml hello:hello [INFO] Searching repository for plugin with prefix: 'hello'. [INFO] hello: checking for updates from test [INFO] hello: checking for updates from central-plugins [INFO] artifact hello:hello: checking for updates from test [INFO] artifact hello:hello: checking for updates from central-plugins Downloading: http://repo1.maven.org/maven2/plugins/hello/hello/1.0/hello-1.0.pom [WARNING] * Using defaults for missing POM hello:hello:pom:1.0 * Downloading: file:target/test-repo/hello/hello/1.0/hello-1.0.jar 2K downloaded [INFO] [INFO] Building hello:hello:maven-plugin:1.0 [INFO]task-segment: [hello:hello] [INFO] [INFO] [hello:hello] [INFO] *** Hello *** [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Sep 13 20:26:04 BST 2005 [INFO] Final Memory: 1M/3M [INFO] The plugin jar is successfully found, but not the POM..? -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-827) Allow eclipse plugin .project name to be customised
[ http://jira.codehaus.org/browse/MNG-827?page=comments#action_46217 ] Mark Hobson commented on MNG-827: - Nope this hasn't been resolved yet. I was proposing an eclipse plugin config property to customise the project name within the eclipse workspace. This is to allow different versions of the same project to co-exist in eclipse (since project names must be unique in eclipse). The problem is that a recent eclipse plugin patch dynamically links projects together within the workspace based on their dependencies and whether they also exist in the workspace. This is done by assuming that the project name is always equal to the artifactId - which would obviously break down if it were customisable as I proposed. Although handy, I'm not entirely convinced that dynamic project linking is the correct approach. Especially as it can lead to differences between eclipse maven compliation and currently does not support multiple versions of a project within the workspace (as detailed in the above comments). Has anyone got any opinions on this? Allow eclipse plugin .project name to be customised --- Key: MNG-827 URL: http://jira.codehaus.org/browse/MNG-827 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0-beta-1 Reporter: Mark Hobson Currently the EclipseWriter uses the POM artifactId as the eclipse project name in .project. This should be configurable for use-cases where different versions of the same project are used within the same eclipse workspace (since eclipse project names must be unique within workspaces). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-835) Default profile in pom.xml not activated
[ http://jira.codehaus.org/browse/MNG-835?page=comments#action_46246 ]
Mark Hobson commented on MNG-835:
-
Another use-case if it helps..
I currently require the concept of a default profile in my project to control
database configuration files. I have a default profile that pulls in a
development db config and a live profile that uses a live db config. Without
one of these specified the build will break, but obviously they're mutually
exclusive so a default profile makes sense here.
POM properties would suffice if they could be overridden at the command-line,
but I think it'd be nicer to be able to activate a non-default profile - e.g.
m2 install for default, m2 -Plive install to use the 'live' profile rather
than the default.
Default profile in pom.xml not activated
Key: MNG-835
URL: http://jira.codehaus.org/browse/MNG-835
Project: Maven 2
Type: Bug
Components: maven-core
Versions: 2.0-alpha-3
Reporter: Vincent Massol
Assignee: John Casey
Fix For: 2.0-beta-2
Original Estimate: 3 hours
Remaining: 3 hours
Pasted email from mailing list explaining the problem. I've also ran m2
projecthelp:active-profiles and it doesn't show the profile as active.
---
Hi,
I want to allow cargo build users to override a plugin property. I have seen
that using a build element is not allowed in a settings.xml file and Brett
has suggested I use a properties element instead. However I also need to
define a default value for the property that can be overridden.
Thus I have defined the following in my project's pom.xml:
[...]
build
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
systemProperties combine.children=append
property
namecargo.containers/name
value${cargo.containers}/value
/property
[...]
/systemProperties
/configuration
/plugin
/plugins
/build
profiles
profile
iddefault/id
properties
cargo.containersjetty4xEmbedded/cargo.containers
/properties
/profile
/profiles
/project
I want cargo build users to be able to create a settings.xml file with the
following for example:
settings
profiles
profile
iduser-vmassol/id
properties
cargo.containersresin3x/cargo.containers
/properties
/profile
/profiles
activeProfiles
activeProfileuser-vmassol/activeProfile
/activeProfiles
/settings
Is that the correct way to implement my use case?
So far, the issue I've had is that the default profile created in pom.xml is
not used when I issue a m2 install command. I've read on
http://docs.codehaus.org/display/MAVEN/Build+Profiles that naming a profile
default will automatically activate it. Isn't that so?
If not how can I activate a profile defined in pom.xml by default?
Thanks a lot
-Vincent
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-835) Default profile in pom.xml not activated
[ http://jira.codehaus.org/browse/MNG-835?page=comments#action_46255 ]
Mark Hobson commented on MNG-835:
-
I'm currently using profiles to augment the normal build resources and
configure plugins for deployment, for example:
project
...
profiles
profile
iddefault/id
activation
property
nameprofile/name
valuedefault/value
/property
/activation
build
resources
resource
directorysrc/profiles/default/resources/directory
/resource
/resources
plugins
...
/plugins
/build
/profile
profile
idlive/id
activation
property
nameprofile/name
valuelive/value
/property
/activation
build
finalNameROOT/finalName
resources
resource
directorysrc/profiles/live/resources/directory
/resource
/resources
plugins
...
/plugins
/build
/profile
/profiles
...
/project
Ideally I'd remove the activation block for both in preference to using the -P
switch at buildtime. Although of course one profile needs to activated, hence
the need to specify a default profile. Does this make sense or do you see a
better way of achieving this?
Default profile in pom.xml not activated
Key: MNG-835
URL: http://jira.codehaus.org/browse/MNG-835
Project: Maven 2
Type: Bug
Components: maven-core
Versions: 2.0-alpha-3
Reporter: Vincent Massol
Assignee: John Casey
Fix For: 2.0-beta-2
Original Estimate: 3 hours
Remaining: 3 hours
Pasted email from mailing list explaining the problem. I've also ran m2
projecthelp:active-profiles and it doesn't show the profile as active.
---
Hi,
I want to allow cargo build users to override a plugin property. I have seen
that using a build element is not allowed in a settings.xml file and Brett
has suggested I use a properties element instead. However I also need to
define a default value for the property that can be overridden.
Thus I have defined the following in my project's pom.xml:
[...]
build
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
systemProperties combine.children=append
property
namecargo.containers/name
value${cargo.containers}/value
/property
[...]
/systemProperties
/configuration
/plugin
/plugins
/build
profiles
profile
iddefault/id
properties
cargo.containersjetty4xEmbedded/cargo.containers
/properties
/profile
/profiles
/project
I want cargo build users to be able to create a settings.xml file with the
following for example:
settings
profiles
profile
iduser-vmassol/id
properties
cargo.containersresin3x/cargo.containers
/properties
/profile
/profiles
activeProfiles
activeProfileuser-vmassol/activeProfile
/activeProfiles
/settings
Is that the correct way to implement my use case?
So far, the issue I've had is that the default profile created in pom.xml is
not used when I issue a m2 install command. I've read on
http://docs.codehaus.org/display/MAVEN/Build+Profiles that naming a profile
default will automatically activate it. Isn't that so?
If not how can I activate a profile defined in pom.xml by default?
Thanks a lot
-Vincent
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
[jira] Commented: (MNG-835) Default profile in pom.xml not activated
[ http://jira.codehaus.org/browse/MNG-835?page=comments#action_46256 ]
Mark Hobson commented on MNG-835:
-
Oops, apologies - there *were* tabs in there!
Default profile in pom.xml not activated
Key: MNG-835
URL: http://jira.codehaus.org/browse/MNG-835
Project: Maven 2
Type: Bug
Components: maven-core
Versions: 2.0-alpha-3
Reporter: Vincent Massol
Assignee: John Casey
Fix For: 2.0-beta-2
Original Estimate: 3 hours
Remaining: 3 hours
Pasted email from mailing list explaining the problem. I've also ran m2
projecthelp:active-profiles and it doesn't show the profile as active.
---
Hi,
I want to allow cargo build users to override a plugin property. I have seen
that using a build element is not allowed in a settings.xml file and Brett
has suggested I use a properties element instead. However I also need to
define a default value for the property that can be overridden.
Thus I have defined the following in my project's pom.xml:
[...]
build
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
systemProperties combine.children=append
property
namecargo.containers/name
value${cargo.containers}/value
/property
[...]
/systemProperties
/configuration
/plugin
/plugins
/build
profiles
profile
iddefault/id
properties
cargo.containersjetty4xEmbedded/cargo.containers
/properties
/profile
/profiles
/project
I want cargo build users to be able to create a settings.xml file with the
following for example:
settings
profiles
profile
iduser-vmassol/id
properties
cargo.containersresin3x/cargo.containers
/properties
/profile
/profiles
activeProfiles
activeProfileuser-vmassol/activeProfile
/activeProfiles
/settings
Is that the correct way to implement my use case?
So far, the issue I've had is that the default profile created in pom.xml is
not used when I issue a m2 install command. I've read on
http://docs.codehaus.org/display/MAVEN/Build+Profiles that naming a profile
default will automatically activate it. Isn't that so?
If not how can I activate a profile defined in pom.xml by default?
Thanks a lot
-Vincent
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-850) Reactor should provide console feedback when scanning for projects
Reactor should provide console feedback when scanning for projects -- Key: MNG-850 URL: http://jira.codehaus.org/browse/MNG-850 Project: Maven 2 Type: Improvement Versions: 2.0-beta-1 Reporter: Mark Hobson Priority: Minor When running a reactor build in a large project hierarchy, the lack of console feedback makes it appear that m2 has hung. Need to provide feedback to the user about which poms have been discovered as and when they are found. It would also be nice to see the build order of the accumulated projects. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-831) Improve plugin API to ease configuration sharing between plugins
Improve plugin API to ease configuration sharing between plugins Key: MNG-831 URL: http://jira.codehaus.org/browse/MNG-831 Project: Maven 2 Type: Improvement Components: maven-plugin-api Versions: 2.0-beta-1 Reporter: Mark Hobson Plugins that need to introspect other plugin's configuration have to go via the Xpp3Dom configuration object. It'd be nice if this was easier for plugin authors. Some current use-cases are: * Eclipse plugin requires compiler plugin's configuration to write .settings file * Tomcat plugin requires war plugin's configuration to locate final war file and exploded state -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-827) Allow eclipse plugin .project name to be customised
Allow eclipse plugin .project name to be customised --- Key: MNG-827 URL: http://jira.codehaus.org/browse/MNG-827 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-beta-1 Reporter: Mark Hobson Currently the EclipseWriter uses the POM artifactId as the eclipse project name in .project. This should be configurable for use-cases where different versions of the same project are used within the same eclipse workspace (since eclipse project names must be unique within workspaces). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-827) Allow eclipse plugin .project name to be customised
[ http://jira.codehaus.org/browse/MNG-827?page=comments#action_45732 ] Mark Hobson commented on MNG-827: - Not too sure about that since we'd end up with rather verbose project names, e.g. myproject-1.5.3-SNAPSHOT. If any SNAPSHOT suffix was dropped then perhaps it could be managable. Linking to projects within the workspace is a nice idea, although I'm not too sure about how maven's strict dependency versioning could still be maintained. For example, if a:1.0 depended on b:1.0 and b:1.1 was in the workspace would a be linked to b? If so then eclipse could happily compile a with b:1.1 during coding, but then maven might break at buildtime since it expects b:1.0. A solution might be to use the full artifactId:version for the project name, but still things could get out of sync when SNAPSHOTs are involved - eclipse would be working with the latest source code whereas maven would be working with the last installed SNAPSHOTs. We then have the complexity of groupIds to add into the mix - how would we deal with like-named artifactIds that belong to different groupIds within the same workspace? I personally like the non-linking behaviour of .classpath files since you know for sure that eclipse and maven are seeing eye-to-eye. Allow eclipse plugin .project name to be customised --- Key: MNG-827 URL: http://jira.codehaus.org/browse/MNG-827 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-beta-1 Reporter: Mark Hobson Currently the EclipseWriter uses the POM artifactId as the eclipse project name in .project. This should be configurable for use-cases where different versions of the same project are used within the same eclipse workspace (since eclipse project names must be unique within workspaces). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-820) Over-zealous transitive dependencies during mediation
Over-zealous transitive dependencies during mediation - Key: MNG-820 URL: http://jira.codehaus.org/browse/MNG-820 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Priority: Blocker Attachments: test.zip The attached zip sets up the following project hierarchy: main.war projecta shared:1.0 librarya projectb projectc shared:2.0 libraryb From what I understand of dependency mediation shared:2.0 should be chosen in preference to shared:1.0, and hence libraryb should be included instead of librarya. Using the latest m2 the main.war WEB-INF/lib contains: projecta projectb projectc shared:2.0 librarya libraryb Thus librarya is included when it shouldn't be. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-785) m2 tomcat plugin
[ http://jira.codehaus.org/browse/MNG-785?page=comments#action_45432 ]
Mark Hobson commented on MNG-785:
-
Wahey! Thanks for that. Regarding isWarExploded(), yeah I thought that was
pretty dirty but couldn't find any other examples of plugins introspecting
other plugin's configurations. I'm happy to change it if anyone knows of a
better way.
m2 tomcat plugin
Key: MNG-785
URL: http://jira.codehaus.org/browse/MNG-785
Project: Maven 2
Type: New Feature
Components: maven-plugins
Versions: 2.0-beta-1
Reporter: Mark Hobson
Attachments: maven-tomcat-plugin.tar.gz, maven-tomcat-plugin.zip
See attached for an initial stab at a m2 Tomcat plugin. The plugin provides
the following goals:
tomcat:deploy
tomcat:undeploy
tomcat:reload
tomcat:start
tomcat:stop
It's geared towards Tomcat 5.5 in which the install/remove commands are
depreciated in preference of deploy/undeploy. It shouldn't be much work to
add these for Tomcat 5.0 users if necessary.
I tried to keep the config to a minimum since the vast number of deployment
options that Tomcat provides tends to complicate plugins. The core config
params for all tasks are:
url - the Tomcat manager URL (default = http://localhost:8080/manager;)
username - the Tomcat manager username (default = admin)
password - the Tomcat manager password (default = )
charset - the Tomcat manager request URL encoding charset (default =
ISO-8859-1)
path - the web context path (default = /${project.build.finalName})
The tomcat:deploy goal requires further parameters to customise the type of
deployment. After considering the various deployment methods supported by
manager, I decided that the project-centric ones applicable to a m2 plugin
come down to three modes of operation:
remote
- the war is deployed via a HTTP PUT to manager
- war plugin mode must be normal (i.e. not exploded)
- suitable for cross-network
local
- the war is deployed by supplying a path to the war file/dir
- the war plugin mode config param determines whether the war is deployed as
a file or as a dir
- suitable for localhost tomcat
inplace
- the war is deployed via a context.xml file that refers to the war dir
- the war plugin mode must be exploded
- suitable for dev
The other Tomcat deployment methods didn't seem too useful for
project-orientation deployment - they are summarised here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html#Deploy%20A%20New%20Application%20from%20a%20Local%20Path
So the tomcat:deploy specific config params are:
mode - remote, local or inplace (default = remote)
war - the war file path (default =
${project.build.directory}/${project.build.finalName}.war)
warDir - the war dir path (default =
${project.build.directory}/${project.build.finalName})
config - the context.xml path (default =
${project.build.directory}/${project.build.finalName}/META-INF/context.xml)
update - whether to undeploy before deploying (default = false)
When deploying inplace the context.xml Context/@docBase attribute needs to be
set to the war dir. I noticed the discussion on the m2 mailing list
regarding resource filtering, so hopefully that can perform this task pre-war.
The code is inspired by the Tomcat Ant tasks, but rewritten for m2. This is
my first m2 plugin so any constructive comments are welcome! In particular,
feedback on the following would be appreciated:
- opinions on the remote/local/inplace mode of operations
- any config options I've missed
- is the method of introspecting the war plugin config the norm, or is there
a nicer way?
You're welcome to the code I'm happy to adopt this plugin time-permitting.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-785) m2 tomcat plugin
[ http://jira.codehaus.org/browse/MNG-785?page=comments#action_45346 ]
Mark Hobson commented on MNG-785:
-
Cheers for the feedback Trygve Vincent. I've mailed the Cargo dev list to
start discussing how we could incorporate this code into a generic container
Cargo m2 plugin.
In the meantime I'm happy to move this code into mojo.codehaus.org for people
to start using immediately - my company has a strong need for the Tomcat plugin
and it makes sense to centralise it somewhere rather than keeping it in-house.
How would I proceed to submit this code?
m2 tomcat plugin
Key: MNG-785
URL: http://jira.codehaus.org/browse/MNG-785
Project: Maven 2
Type: New Feature
Components: maven-plugins
Versions: 2.0-beta-1
Reporter: Mark Hobson
Attachments: maven-tomcat-plugin.zip
See attached for an initial stab at a m2 Tomcat plugin. The plugin provides
the following goals:
tomcat:deploy
tomcat:undeploy
tomcat:reload
tomcat:start
tomcat:stop
It's geared towards Tomcat 5.5 in which the install/remove commands are
depreciated in preference of deploy/undeploy. It shouldn't be much work to
add these for Tomcat 5.0 users if necessary.
I tried to keep the config to a minimum since the vast number of deployment
options that Tomcat provides tends to complicate plugins. The core config
params for all tasks are:
url - the Tomcat manager URL (default = http://localhost:8080/manager;)
username - the Tomcat manager username (default = admin)
password - the Tomcat manager password (default = )
charset - the Tomcat manager request URL encoding charset (default =
ISO-8859-1)
path - the web context path (default = /${project.build.finalName})
The tomcat:deploy goal requires further parameters to customise the type of
deployment. After considering the various deployment methods supported by
manager, I decided that the project-centric ones applicable to a m2 plugin
come down to three modes of operation:
remote
- the war is deployed via a HTTP PUT to manager
- war plugin mode must be normal (i.e. not exploded)
- suitable for cross-network
local
- the war is deployed by supplying a path to the war file/dir
- the war plugin mode config param determines whether the war is deployed as
a file or as a dir
- suitable for localhost tomcat
inplace
- the war is deployed via a context.xml file that refers to the war dir
- the war plugin mode must be exploded
- suitable for dev
The other Tomcat deployment methods didn't seem too useful for
project-orientation deployment - they are summarised here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html#Deploy%20A%20New%20Application%20from%20a%20Local%20Path
So the tomcat:deploy specific config params are:
mode - remote, local or inplace (default = remote)
war - the war file path (default =
${project.build.directory}/${project.build.finalName}.war)
warDir - the war dir path (default =
${project.build.directory}/${project.build.finalName})
config - the context.xml path (default =
${project.build.directory}/${project.build.finalName}/META-INF/context.xml)
update - whether to undeploy before deploying (default = false)
When deploying inplace the context.xml Context/@docBase attribute needs to be
set to the war dir. I noticed the discussion on the m2 mailing list
regarding resource filtering, so hopefully that can perform this task pre-war.
The code is inspired by the Tomcat Ant tasks, but rewritten for m2. This is
my first m2 plugin so any constructive comments are welcome! In particular,
feedback on the following would be appreciated:
- opinions on the remote/local/inplace mode of operations
- any config options I've missed
- is the method of introspecting the war plugin config the norm, or is there
a nicer way?
You're welcome to the code I'm happy to adopt this plugin time-permitting.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-799) CLI equivalent of @requiresDependencyResolution
CLI equivalent of @requiresDependencyResolution --- Key: MNG-799 URL: http://jira.codehaus.org/browse/MNG-799 Project: Maven 2 Type: Improvement Components: maven-core Versions: 2.0-beta-1 Reporter: Mark Hobson Priority: Minor Add a command-line equivalent of the @requiresDependencyResolution MOJO annotation - i.e. something like m2 -d compile to resolve all compile-scoped 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-785) m2 tomcat plugin
[ http://jira.codehaus.org/browse/MNG-785?page=comments#action_45350 ]
Mark Hobson commented on MNG-785:
-
I've javadoc'd and licenced the code - see maven-tomcat-plugin.tar.gz. I
wasn't sure whether the plugin should be in the apache or codehaus package
structure (the mojo.codehaus plugins seem to be a mixture of both), so I left
it in the apache package. Let me know if I've missed anything.
m2 tomcat plugin
Key: MNG-785
URL: http://jira.codehaus.org/browse/MNG-785
Project: Maven 2
Type: New Feature
Components: maven-plugins
Versions: 2.0-beta-1
Reporter: Mark Hobson
Attachments: maven-tomcat-plugin.tar.gz, maven-tomcat-plugin.zip
See attached for an initial stab at a m2 Tomcat plugin. The plugin provides
the following goals:
tomcat:deploy
tomcat:undeploy
tomcat:reload
tomcat:start
tomcat:stop
It's geared towards Tomcat 5.5 in which the install/remove commands are
depreciated in preference of deploy/undeploy. It shouldn't be much work to
add these for Tomcat 5.0 users if necessary.
I tried to keep the config to a minimum since the vast number of deployment
options that Tomcat provides tends to complicate plugins. The core config
params for all tasks are:
url - the Tomcat manager URL (default = http://localhost:8080/manager;)
username - the Tomcat manager username (default = admin)
password - the Tomcat manager password (default = )
charset - the Tomcat manager request URL encoding charset (default =
ISO-8859-1)
path - the web context path (default = /${project.build.finalName})
The tomcat:deploy goal requires further parameters to customise the type of
deployment. After considering the various deployment methods supported by
manager, I decided that the project-centric ones applicable to a m2 plugin
come down to three modes of operation:
remote
- the war is deployed via a HTTP PUT to manager
- war plugin mode must be normal (i.e. not exploded)
- suitable for cross-network
local
- the war is deployed by supplying a path to the war file/dir
- the war plugin mode config param determines whether the war is deployed as
a file or as a dir
- suitable for localhost tomcat
inplace
- the war is deployed via a context.xml file that refers to the war dir
- the war plugin mode must be exploded
- suitable for dev
The other Tomcat deployment methods didn't seem too useful for
project-orientation deployment - they are summarised here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html#Deploy%20A%20New%20Application%20from%20a%20Local%20Path
So the tomcat:deploy specific config params are:
mode - remote, local or inplace (default = remote)
war - the war file path (default =
${project.build.directory}/${project.build.finalName}.war)
warDir - the war dir path (default =
${project.build.directory}/${project.build.finalName})
config - the context.xml path (default =
${project.build.directory}/${project.build.finalName}/META-INF/context.xml)
update - whether to undeploy before deploying (default = false)
When deploying inplace the context.xml Context/@docBase attribute needs to be
set to the war dir. I noticed the discussion on the m2 mailing list
regarding resource filtering, so hopefully that can perform this task pre-war.
The code is inspired by the Tomcat Ant tasks, but rewritten for m2. This is
my first m2 plugin so any constructive comments are welcome! In particular,
feedback on the following would be appreciated:
- opinions on the remote/local/inplace mode of operations
- any config options I've missed
- is the method of introspecting the war plugin config the norm, or is there
a nicer way?
You're welcome to the code I'm happy to adopt this plugin time-permitting.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-791) Add resource filtering to war plugin
Add resource filtering to war plugin Key: MNG-791 URL: http://jira.codehaus.org/browse/MNG-791 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-beta-1 Reporter: Mark Hobson I'd like to patch the war plugin to perform resource filtering as per the resources plugin. This is a trivial patch but would duplicate the following code from the resources plugin: PropertyUtils ReflectionProperties ResourcesMojo.copyFile(File, File) These look like handy util methods that could be incorporated into plexus-utils - what do the developers think? Also not sure how resource filtering will be affected by MNG-788. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-792) Can't ctrl-C m2 under cygwin
Can't ctrl-C m2 under cygwin Key: MNG-792 URL: http://jira.codehaus.org/browse/MNG-792 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Under cygwin you can't ctrl-C to interrupt the process when running m2. This used to work under 2.0-alpha-3. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-792) Can't ctrl-C m2 under cygwin
[ http://jira.codehaus.org/browse/MNG-792?page=comments#action_45275 ] Mark Hobson commented on MNG-792: - This happened on two different PCs when moving from alpha-3 to svn-trunk. I've just reinstalled cygwin with the latest code and the problem still occurs. If I switch my M2_HOME to alpha-3 then ctrl-C works fine - even within the same environment as when the latest m2 doesn't interrupt. I tried switching sh.exe with base.exe but in the latest cygwin distro these appear to be the same file anyways. Can't ctrl-C m2 under cygwin Key: MNG-792 URL: http://jira.codehaus.org/browse/MNG-792 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: Brett Porter Under cygwin you can't ctrl-C to interrupt the process when running m2. This used to work under 2.0-alpha-3. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-792) Can't ctrl-C m2 under cygwin
[ http://jira.codehaus.org/browse/MNG-792?page=comments#action_45279 ] Mark Hobson commented on MNG-792: - No difference ;) I've noticed that if you're quick you can ctrl-C just before m2 kicks into action, but once you start seeing output in the console it's too late. I'm not up to speed as to the m2 boot process, but could it be possible that something in one of the libraries used has changed, e.g. classworlds, etc? Can't ctrl-C m2 under cygwin Key: MNG-792 URL: http://jira.codehaus.org/browse/MNG-792 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: Brett Porter Under cygwin you can't ctrl-C to interrupt the process when running m2. This used to work under 2.0-alpha-3. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-793) eclipse:eclipse writes timestamp to .settings file
eclipse:eclipse writes timestamp to .settings file -- Key: MNG-793 URL: http://jira.codehaus.org/browse/MNG-793 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Reporter: Mark Hobson EclipseWriter uses Properties.store() to write the .settings file - this always writes the current date as a comment in the first line of the file. This is annoying since every m2 eclipse:eclipse will result in uncommitted changes, i.e. diffs like: -#Fri Aug 26 15:25:40 BST 2005 +#Fri Aug 26 15:30:17 BST 2005 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-785) m2 tomcat plugin
m2 tomcat plugin
Key: MNG-785
URL: http://jira.codehaus.org/browse/MNG-785
Project: Maven 2
Type: New Feature
Components: maven-plugins
Versions: 2.0-beta-1
Reporter: Mark Hobson
Attachments: maven-tomcat-plugin.zip
See attached for an initial stab at a m2 Tomcat plugin. The plugin provides
the following goals:
tomcat:deploy
tomcat:undeploy
tomcat:reload
tomcat:start
tomcat:stop
It's geared towards Tomcat 5.5 in which the install/remove commands are
depreciated in preference of deploy/undeploy. It shouldn't be much work to add
these for Tomcat 5.0 users if necessary.
I tried to keep the config to a minimum since the vast number of deployment
options that Tomcat provides tends to complicate plugins. The core config
params for all tasks are:
url - the Tomcat manager URL (default = http://localhost:8080/manager;)
username - the Tomcat manager username (default = admin)
password - the Tomcat manager password (default = )
charset - the Tomcat manager request URL encoding charset (default =
ISO-8859-1)
path - the web context path (default = /${project.build.finalName})
The tomcat:deploy goal requires further parameters to customise the type of
deployment. After considering the various deployment methods supported by
manager, I decided that the project-centric ones applicable to a m2 plugin come
down to three modes of operation:
remote
- the war is deployed via a HTTP PUT to manager
- war plugin mode must be normal (i.e. not exploded)
- suitable for cross-network
local
- the war is deployed by supplying a path to the war file/dir
- the war plugin mode config param determines whether the war is deployed as a
file or as a dir
- suitable for localhost tomcat
inplace
- the war is deployed via a context.xml file that refers to the war dir
- the war plugin mode must be exploded
- suitable for dev
The other Tomcat deployment methods didn't seem too useful for
project-orientation deployment - they are summarised here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html#Deploy%20A%20New%20Application%20from%20a%20Local%20Path
So the tomcat:deploy specific config params are:
mode - remote, local or inplace (default = remote)
war - the war file path (default =
${project.build.directory}/${project.build.finalName}.war)
warDir - the war dir path (default =
${project.build.directory}/${project.build.finalName})
config - the context.xml path (default =
${project.build.directory}/${project.build.finalName}/META-INF/context.xml)
update - whether to undeploy before deploying (default = false)
When deploying inplace the context.xml Context/@docBase attribute needs to be
set to the war dir. I noticed the discussion on the m2 mailing list regarding
resource filtering, so hopefully that can perform this task pre-war.
The code is inspired by the Tomcat Ant tasks, but rewritten for m2. This is my
first m2 plugin so any constructive comments are welcome! In particular,
feedback on the following would be appreciated:
- opinions on the remote/local/inplace mode of operations
- any config options I've missed
- is the method of introspecting the war plugin config the norm, or is there a
nicer way?
You're welcome to the code I'm happy to adopt this plugin time-permitting.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-783) resource/testResource dir same as source/testSource dir produces invalid .classpath
resource/testResource dir same as source/testSource dir produces invalid .classpath --- Key: MNG-783 URL: http://jira.codehaus.org/browse/MNG-783 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: setup.zip The attached project specifies a different sourceDirectory and testSourceDirectory. The same directories are also used to hold resources and so are also specified in resources and testResources. m2 eclipse:eclipse produces an invalid .classpath with duplicate entries: classpath classpathentry kind=src path=src/ classpathentry kind=src path=src/ classpathentry kind=src path=test output=target/test-classes/ classpathentry kind=src path=test output=target/test-classes/ classpathentry kind=output path=target/classes/ classpathentry kind=var rootpath=JRE_SRCROOT path=JRE_LIB sourcepath=JRE_SRC/ /classpath The plugin should check that the resource directories differ from the source directories before writing them to the classpath file. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-776) settings.xml profile activation breaks reactor
settings.xml profile activation breaks reactor -- Key: MNG-776 URL: http://jira.codehaus.org/browse/MNG-776 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Priority: Blocker Attachments: setup.zip The attached zip consists of: 1) Parent POM project A 2) Child JAR project B 3) settings.xml Running m2 in the 'a' dir: m2 -s ../settings.xml install Results in a failed build - m2 looks for B's POM at a/b/b/pom.xml rather than a/b/pom.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-780) Deploying snapshot project results in exception
Deploying snapshot project results in exception --- Key: MNG-780 URL: http://jira.codehaus.org/browse/MNG-780 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: setup.zip m2 deploy in attached project A results in: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'. [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for execution of 'deploy:deploy'. at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:437) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:131) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) 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.PluginConfigurationException: Unable to parse the created DOM for plugin configuration at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1025) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:522) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337) ... 15 more Caused by: org.codehaus.plexus.component.configurator.ComponentConfigurationException: Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be instantiated at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:120) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:83) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:118) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:55) at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1020) ... 17 more Caused by: java.lang.InstantiationException: org.apache.maven.artifact.repository.ArtifactRepository at java.lang.Class.newInstance0(Class.java:335) at java.lang.Class.newInstance(Class.java:303) at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:110) ... 21 more -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_44940 ] Mark Hobson commented on MNG-757: - Not sure if the actual use-case that led to this helps, but I had: 1) project depending on Hibernate 2) Hibernate depending on JTA 3) JTA hosted on my repo So JTA on my repo couldn't possibly be referenced by the ibiblio Hibernate POM, and so m2 needs help finding it. Either this could come from settings.xml, or maybe even a repo-hint added to the Hibernate dependency in the top-level project's POM? I haven't been keeping up-to-speed on the latest design discussions, so whatever you guys think as long as there's a way of achieving this. Transitive dependency resolution ignores custom repositories Key: MNG-757 URL: http://jira.codehaus.org/browse/MNG-757 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: John Casey Priority: Blocker Fix For: 2.0-beta-1 Attachments: projects.zip, settings.xml, test-repo.zip Original Estimate: 4 hours Remaining: 4 hours The attached files set the scene: * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo * projects.zip - expand this for the projects * settings.xml - the ~/.m2/settings.xml file The scenario is as follows: * test-repo contains a single artifact C * project B depends on C * project A depends on B defines test-repo * settings.xml also defines test-repo The build process is: * m2 install B (downloads C, installs B ok) * m2 install A (finds B and C in local repo, installs A ok) Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml. This didn't happen in 2.0-alpha-3 - is this intentional? -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_44960 ] Mark Hobson commented on MNG-757: - Sounds good to me. Would higher-level POMs have precedence over transitive dependency POMs? This would allow projects to override repositories, e.g. use an in-house repo for some dependencies rather than ibiblio (without mirroring the entirety of ibiblio). Transitive dependency resolution ignores custom repositories Key: MNG-757 URL: http://jira.codehaus.org/browse/MNG-757 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: John Casey Priority: Blocker Fix For: 2.0-beta-1 Attachments: projects.zip, settings.xml, test-repo.zip Original Estimate: 4 hours Remaining: 4 hours The attached files set the scene: * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo * projects.zip - expand this for the projects * settings.xml - the ~/.m2/settings.xml file The scenario is as follows: * test-repo contains a single artifact C * project B depends on C * project A depends on B defines test-repo * settings.xml also defines test-repo The build process is: * m2 install B (downloads C, installs B ok) * m2 install A (finds B and C in local repo, installs A ok) Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml. This didn't happen in 2.0-alpha-3 - is this intentional? -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-757) Transitive dependency resolution ignores custom repositories
Transitive dependency resolution ignores custom repositories Key: MNG-757 URL: http://jira.codehaus.org/browse/MNG-757 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: Windows XP, Cygwin Reporter: Mark Hobson Priority: Blocker Attachments: projects.zip, settings.xml, test-repo.zip The attached files set the scene: * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo * projects.zip - expand this for the projects * settings.xml - the ~/.m2/settings.xml file The scenario is as follows: * test-repo contains a single artifact C * project B depends on C * project A depends on B defines test-repo * settings.xml also defines test-repo The build process is: * m2 install B (downloads C, installs B ok) * m2 install A (finds B and C in local repo, installs A ok) Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml. This didn't happen in 2.0-alpha-3 - is this intentional? -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-1640) groupId not inherited from parent pom
groupId not inherited from parent pom - Key: MAVEN-1640 URL: http://jira.codehaus.org/browse/MAVEN-1640 Project: maven Type: Bug Versions: 1.1-beta-1 Environment: Windows XP, cygwin Reporter: Mark Hobson groupId is no longer inherited from a parent pom, but the child pom's id is used instead. This is a regression from 1.0.2. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-86) m2-bootstrap-all.bat fails if ${maven.home} contains spaces
[ http://jira.codehaus.org/browse/MNG-86?page=comments#action_40646 ]
Mark Hobson commented on MNG-86:
Sounds like a duplicate of MNG-372, which is now fixed.
m2-bootstrap-all.bat fails if ${maven.home} contains spaces
---
Key: MNG-86
URL: http://jira.codehaus.org/browse/MNG-86
Project: Maven 2
Type: Bug
Environment: Windows XP SP2, JDK 1.4.2_05
Reporter: Magne Rasmussen
Priority: Trivial
Attachments: MNG-86.patch
m2-bootstrap-all.bat (CVS rev. 1.4) fails on line 114 if
M2_HOME=%USERPROFILE%/m2 (expands to 'C:\Documents and Settings\User/m2').
This can be fixed by replacing line 104 with:
SET MAVEN_CMD_LINE_ARGS=%MAVEN_CMD_LINE_ARGS% -Dmaven.home=%M2_HOME%
The same error manifests itself in maven-core-it/maven-core-it.bat, where
line 23 can be replaced with:
%JAVA_HOME%\bin\java.exe %* -Dmaven.home=%M2_HOME% -cp
..\maven-core-it-verifier\target\maven-core-it-verifier-1.0.jar
org.apache.maven.it.Verifier
as a fix.
There will be a lot of errors if M2_HOME is set like 'SET
M2_HOME=C:\Documents and Settings\User\m2' (notice double qoutes around the
path). These qoutes should probably be stripped before trying to use M2_HOME
in any script. Or a suitable warning could be put in the docs :-)
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-18) m2 activation pom should have groupid of jaf
m2 activation pom should have groupid of jaf Key: MEV-18 URL: http://jira.codehaus.org/browse/MEV-18 Project: Maven Evangelism Type: Task Components: Invalid POM Reporter: Mark Hobson As detailed here: http://maven.apache.org/reference/standard-sun-jar-names.html Activation should have groupId 'jaf' and artifactId 'activation'. Also, although the POM is in activation/activation, it actually has groupId and artifactId of 'javamail' declared in the POM. Javamail will also need it's dependency updated accordingly. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-14) commons-loggin junit compile scope dependency
commons-loggin junit compile scope dependency - Key: MEV-14 URL: http://jira.codehaus.org/browse/MEV-14 Project: Maven Evangelism Type: Task Components: Dependencies Reporter: Mark Hobson junit is a compile scope dependency, rather than test. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-15) commons-pool junit compile scope dependency
commons-pool junit compile scope dependency --- Key: MEV-15 URL: http://jira.codehaus.org/browse/MEV-15 Project: Maven Evangelism Type: Task Components: Dependencies Reporter: Mark Hobson junit is a compile scope dependency, rather than test. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-17) nanocontainer junit compile scope dependency
nanocontainer junit compile scope dependency Key: MEV-17 URL: http://jira.codehaus.org/browse/MEV-17 Project: Maven Evangelism Type: Task Components: Dependencies Reporter: Mark Hobson junit is a compile scope dependency, rather than test. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-16) picocontainer junit compile scope dependency
picocontainer junit compile scope dependency Key: MEV-16 URL: http://jira.codehaus.org/browse/MEV-16 Project: Maven Evangelism Type: Task Components: Dependencies Reporter: Mark Hobson junit is a compile scope dependency, rather than test. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-422) Certain dependency graph causes tests to not compile
[ http://jira.codehaus.org/browse/MNG-422?page=comments#action_39619 ] Mark Hobson commented on MNG-422: - Thanks, the problem dependencies were: * commons-cli 1.0 - junit 3.7 compile * commons-logging 1.0.3-1.0.4 - junit 3.7 compile * commons-pool 1.2 - junit 3.8.1 compile * picocontainer 1.1 - junit 3.8.1 compile * nanocontainer 1.0-beta-4 - junit 3.8.1 compile I've added them to MEV. Certain dependency graph causes tests to not compile Key: MNG-422 URL: http://jira.codehaus.org/browse/MNG-422 Project: Maven 2 Type: Bug Versions: 2.0-alpha-2 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: test.zip The attached projects set up the following rough dependency hierarchy: testproject +- testdep | +- testdep2 | +- testdep3 | | +- ... | | +- testdep4 | | +- ... | +- commons-logging | +- commons-pool +- junit Not all dependencies are shown for the sake of brevity, but are obviously available in the attached poms. Now unfortuantely every dependency supplied is required to reproduce this bug - take one out and it works. What happens is as follows: * testdep4: m2 install - ok * testdep3: m2 install - ok * testdep2: m2 install - ok * testdep: m2 install - ok * testproject: m2 install - error: [INFO] [INFO] Building testgroup:testproject:jar:1.0-SNAPSHOT [INFO] [INFO] maven-jar-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-resources-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-compiler-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-surefire-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-install-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] [resources:resources] [INFO] testdep: using locally installed snapshot [INFO] testdep2: using locally installed snapshot [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] [compiler:testCompile] Compiling 1 source file to c:\Documents and Settings\mark\Desktop\testproject\target\test-classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] c:\Documents and Settings\mark\Desktop\testproject\src\test\java\Test.java:[3,-1] cannot find symbol [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Sun May 22 11:56:08 BST 2005 [INFO] Final Memory: 2M/12M [INFO] So it looks like the classpath is getting mangled somewhere since javac can't find junit. Now if Java5 is turned off in testproject, the following occurs: [INFO] [INFO] Building testgroup:testproject:jar:1.0-SNAPSHOT [INFO] [INFO] maven-jar-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-resources-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-compiler-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-surefire-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-install-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] [resources:resources] [INFO] testdep: using locally installed snapshot [INFO] testdep2: using locally installed snapshot [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] [compiler:testCompile] Compiling 1 source file to c:\Documents and Settings\mark\Desktop\testproject\target\test-classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] c:\Documents and Settings\mark\Desktop\testproject\src\test\java\Test.java:[3,7] TestCase(java.lang.String) in j unit.framework.TestCase cannot be applied to () [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Sun May 22 11:56:19
[jira] Created: (MNG-422) Certain dependency graph causes tests to not compile
Certain dependency graph causes tests to not compile Key: MNG-422 URL: http://jira.codehaus.org/browse/MNG-422 Project: Maven 2 Type: Bug Versions: 2.0-alpha-2 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: test.zip The attached projects set up the following rough dependency hierarchy: testproject +- testdep | +- testdep2 | +- testdep3 | | +- ... | | +- testdep4 | | +- ... | +- commons-logging | +- commons-pool +- junit Not all dependencies are shown for the sake of brevity, but are obviously available in the attached poms. Now unfortuantely every dependency supplied is required to reproduce this bug - take one out and it works. What happens is as follows: * testdep4: m2 install - ok * testdep3: m2 install - ok * testdep2: m2 install - ok * testdep: m2 install - ok * testproject: m2 install - error: [INFO] [INFO] Building testgroup:testproject:jar:1.0-SNAPSHOT [INFO] [INFO] maven-jar-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-resources-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-compiler-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-surefire-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-install-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] [resources:resources] [INFO] testdep: using locally installed snapshot [INFO] testdep2: using locally installed snapshot [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] [compiler:testCompile] Compiling 1 source file to c:\Documents and Settings\mark\Desktop\testproject\target\test-classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] c:\Documents and Settings\mark\Desktop\testproject\src\test\java\Test.java:[3,-1] cannot find symbol [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Sun May 22 11:56:08 BST 2005 [INFO] Final Memory: 2M/12M [INFO] So it looks like the classpath is getting mangled somewhere since javac can't find junit. Now if Java5 is turned off in testproject, the following occurs: [INFO] [INFO] Building testgroup:testproject:jar:1.0-SNAPSHOT [INFO] [INFO] maven-jar-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-resources-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-compiler-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-surefire-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] maven-install-plugin: resolved to version 2.0-alpha-2 from local repository [INFO] [resources:resources] [INFO] testdep: using locally installed snapshot [INFO] testdep2: using locally installed snapshot [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] [compiler:testCompile] Compiling 1 source file to c:\Documents and Settings\mark\Desktop\testproject\target\test-classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] c:\Documents and Settings\mark\Desktop\testproject\src\test\java\Test.java:[3,7] TestCase(java.lang.String) in j unit.framework.TestCase cannot be applied to () [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Sun May 22 11:56:19 BST 2005 [INFO] Final Memory: 2M/12M [INFO] Which could be more telling. I seem to remember a similar error in a completely different project when working with DOM Test Suites (http://www.w3.org/DOM/Test/), since their DOM test jars actually contain a modified version of junit which a different API. So I'm not sure if somewhere down the dependency graph a DOM test jar is being included which is overriding the normal junit one? A long shot, but thought worth
[jira] Commented: (MNG-375) 3-level pom plugin config inheritance causes ConcurrentModificationException
[ http://jira.codehaus.org/browse/MNG-375?page=comments#action_38821 ] Mark Hobson commented on MNG-375: - I've just: * checked out the latest code * cleaned all m2 target directories * cleaned all ~/.m2/repository/org/** * rebuilt m2 And I still get the same exception when trying a 'm2 install' on the testproject - any ideas? 3-level pom plugin config inheritance causes ConcurrentModificationException Key: MNG-375 URL: http://jira.codehaus.org/browse/MNG-375 Project: m2 Type: Bug Components: maven-core Versions: 2.0-alpha-2 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: testproject.zip The attached project structure causes the following exception: [EMAIL PROTECTED] testproject]$ m2 clean:clean --- constituent[0]: file:/c:/Program Files/maven-2.0/lib/commons-cli-1.0-beta-2.jar constituent[1]: file:/c:/Program Files/maven-2.0/lib/doxia-core-1.0-alpha-2-20050507.132213-9.jar constituent[2]: file:/c:/Program Files/maven-2.0/lib/marmalade-core-1.0-alpha-3-20050504.035023-1.jar constituent[3]: file:/c:/Program Files/maven-2.0/lib/maven-artifact-2.0-SNAPSHOT.jar constituent[4]: file:/c:/Program Files/maven-2.0/lib/maven-core-2.0-SNAPSHOT.jar constituent[5]: file:/c:/Program Files/maven-2.0/lib/maven-model-2.0-SNAPSHOT.jar constituent[6]: file:/c:/Program Files/maven-2.0/lib/maven-monitor-2.0-SNAPSHOT.jar constituent[7]: file:/c:/Program Files/maven-2.0/lib/maven-plugin-api-2.0-SNAPSHOT.jar constituent[8]: file:/c:/Program Files/maven-2.0/lib/maven-plugin-descriptor-2.0-SNAPSHOT.jar constituent[9]: file:/c:/Program Files/maven-2.0/lib/maven-project-2.0-SNAPSHOT.jar constituent[10]: file:/c:/Program Files/maven-2.0/lib/maven-reporting-api-2.0-20050507.125719-3.jar constituent[11]: file:/c:/Program Files/maven-2.0/lib/maven-script-marmalade-2.0-SNAPSHOT.jar constituent[12]: file:/c:/Program Files/maven-2.0/lib/maven-settings-2.0-SNAPSHOT.jar constituent[13]: file:/c:/Program Files/maven-2.0/lib/oro-2.0.7.jar constituent[14]: file:/c:/Program Files/maven-2.0/lib/plexus-container-artifact-1.0-alpha-3-20050422.054920-3.jar constituent[15]: file:/c:/Program Files/maven-2.0/lib/plexus-i18n-1.0-beta-3.jar constituent[16]: file:/c:/Program Files/maven-2.0/lib/plexus-marmalade-factory-1.0-alpha-3-20050504.035023-1.jar constituent[17]: file:/c:/Program Files/maven-2.0/lib/wagon-http-lightweight-1.0-alpha-3-SNAPSHOT.jar constituent[18]: file:/c:/Program Files/maven-2.0/lib/wagon-provider-api-1.0-alpha-3-SNAPSHOT.jar --- java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449) at java.util.AbstractList$Itr.next(AbstractList.java:420) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assemblePluginManagementInheritance(Def aultModelInheritanceAssembler.java:213) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelIn heritanceAssembler.java:356) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelIn heritanceAssembler.java:126) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:221) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:153) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:142) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:288) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:177) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:199) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:199) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.main(MavenCli.java:230) 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:303) at org.codehaus.classworlds.Launcher.launch(Launcher.java:243) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:416) at org.codehaus.classworlds.Launcher.main(Launcher.java:363) -- This message is automatically generated by JIRA. - If you think it was sent
[jira] Commented: (MNG-372) Cannot build m2 with spaces in M2_HOME and/or JAVA_HOME
[ http://jira.codehaus.org/browse/MNG-372?page=comments#action_38824 ]
Mark Hobson commented on MNG-372:
-
The cygpath -p switch was introduced when qualifying M2_HOME under cygwin -
this produces an invalid maven.home property when passed into MBoot, e.g.:
[EMAIL PROTECTED] components]$ echo $M2_HOME
C:\Program Files\maven-2.0
[EMAIL PROTECTED] components]$ cygpath -pw $M2_HOME
C;c:\Program Files\maven-2.0
Results in:
Exception in thread main java.io.FileNotFoundException: c:\Documents and
Settings\mark\My Documents\projects\oss\maven
\components\C;c:\Program Files\maven-2.0\bin\m2 (The filename, directory name,
or volume label syntax is incorrect)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)
at java.io.FileOutputStream.init(FileOutputStream.java:131)
at util.FileUtils.copyFile(FileUtils.java:726)
at util.FileUtils.copyFileToDirectory(FileUtils.java:686)
at util.FileUtils.copyFileToDirectory(FileUtils.java:663)
at MBoot.run(MBoot.java:382)
at MBoot.main(MBoot.java:117)
patch3.txt fixes this.
Cannot build m2 with spaces in M2_HOME and/or JAVA_HOME
---
Key: MNG-372
URL: http://jira.codehaus.org/browse/MNG-372
Project: m2
Type: Bug
Versions: 2.0-alpha-1
Environment: Windows XP, Cygwin.
Reporter: Mark Hobson
Fix For: 2.0-alpha-2
Attachments: patch, patch2.txt
There are numerous problems when trying to build m2 in Windows when JAVA_HOME
or M2_HOME contains spaces. The attached patch fixes enough of the scripts
to build m2 under cygwin, but there still exist several major flaws when
using the .bat versions.
To detail the various problems, I shall annotate the patch here:
Index: m2-bootstrap-all.sh
===
@@ -1,7 +1,7 @@
-[ -z $JAVA_HOME ] echo echo 'You must set $JAVA_HOME to use mboot!'
echo exit 1
+[ -z $JAVA_HOME ] echo echo 'You must set $JAVA_HOME to use
mboot!' echo exit 1
Quote for spaces in JAVA_HOME.
@@ -19,7 +19,11 @@
- ARGS=$ARGS -Dmaven.home=$M2_HOME
+ if [ -n $ARGS ]; then
+ARGS=$ARGS -Dmaven.home=$M2_HOME
+ else
+ARGS=-Dmaven.home=$M2_HOME
+ fi
Previously, if no ARGS are supplied then $ARGS equates to
-Dmaven.home=$M2_HOME which is not recognised by javac and a typical -D arg.
Basically ARGS cannot start or end with a space when later quoted.
@@ -39,7 +43,7 @@
- $JAVACMD $ARGS $MAVEN_OPTS -jar mboot.jar
+ $JAVACMD $ARGS $MAVEN_OPTS -jar mboot.jar
First quote for spaces in JAVA_HOME, second for spaces in M2_HOME. Not sure
if $ARGS works for multiple arguments with spaces, i.e. -Dprop1=C:/Program
Files/a -Dprop2=C:/Program Files/b. From previous experience I seem to
remember having to quote each -D seperately..
Index: maven-core/src/bin/m2.bat
===
@@ -127,7 +127,7 @@
-%MAVEN_JAVA_EXE% %MAVEN_OPTS% -classpath
%M2_HOME%\core\boot\classworlds-*.jar
-Dclassworlds.conf=%M2_HOME%\bin\m2.conf -Dmaven.home=%M2_HOME%
org.codehaus.classworlds.Launcher %MAVEN_CMD_LINE_ARGS%
+%MAVEN_JAVA_EXE% %MAVEN_OPTS% -classpath
%M2_HOME%\core\boot\classworlds-1.1-alpha-1.jar
-Dclassworlds.conf=%M2_HOME%\bin\m2.conf -Dmaven.home=%M2_HOME%
org.codehaus.classworlds.Launcher %MAVEN_CMD_LINE_ARGS%
m2.bat gets called eventually via the script even under cygwin, hence this
fix. Normal quote for M2_HOME in -classpath here, but also the
classworlds-*.jar part does not work under Windows when fully qualified.
i.e. Within M2_HOME/core/boot a javac -cp classworlds-*.jar will work, but
not once it's fully qualified as it is here. Not an ideal solution as we
have to hardcode the classworlds version.
Index: maven-core/src/bin/m2
===
@@ -126,7 +126,7 @@
-exec $JAVACMD \
+exec $JAVACMD \
Quoted for spaces in JAVA_HOME.
Index: maven-mboot2/build
===
@@ -9,8 +9,8 @@
-$JAVA_HOME/bin/javac -g -d ${classesDir} `find ${srcDir} -name '*.java'`
+$JAVA_HOME/bin/javac -g -d ${classesDir} `find ${srcDir} -name '*.java'`
Quoted for spaces in JAVA_HOME.
-( cd ${classesDir} ; $JAVA_HOME/bin/jar -cfm ../mboot.jar
../../manifest.txt * )
+( cd ${classesDir} ; $JAVA_HOME/bin/jar -cfm ../mboot.jar
../../manifest.txt * )
Quoted for spaces in JAVA_HOME.
Index: maven-core-it/maven-core-it.sh
===
@@ -25,9 +25,5 @@
-if [ ! -z $M2_HOME ]; then
- jvm_args=$jvm_args -Dmaven.home=$M2_HOME
-fi
Potentially controversial, but maven-core-it.sh receives -Dmaven.home in it's
args from the
[jira] Reopened: (MNG-372) Cannot build m2 with spaces in M2_HOME and/or JAVA_HOME
[ http://jira.codehaus.org/browse/MNG-372?page=all ]
Mark Hobson reopened MNG-372:
-
Reopened to attached patch3.txt.
Cannot build m2 with spaces in M2_HOME and/or JAVA_HOME
---
Key: MNG-372
URL: http://jira.codehaus.org/browse/MNG-372
Project: m2
Type: Bug
Versions: 2.0-alpha-1
Environment: Windows XP, Cygwin.
Reporter: Mark Hobson
Fix For: 2.0-alpha-2
Attachments: patch, patch2.txt
There are numerous problems when trying to build m2 in Windows when JAVA_HOME
or M2_HOME contains spaces. The attached patch fixes enough of the scripts
to build m2 under cygwin, but there still exist several major flaws when
using the .bat versions.
To detail the various problems, I shall annotate the patch here:
Index: m2-bootstrap-all.sh
===
@@ -1,7 +1,7 @@
-[ -z $JAVA_HOME ] echo echo 'You must set $JAVA_HOME to use mboot!'
echo exit 1
+[ -z $JAVA_HOME ] echo echo 'You must set $JAVA_HOME to use
mboot!' echo exit 1
Quote for spaces in JAVA_HOME.
@@ -19,7 +19,11 @@
- ARGS=$ARGS -Dmaven.home=$M2_HOME
+ if [ -n $ARGS ]; then
+ARGS=$ARGS -Dmaven.home=$M2_HOME
+ else
+ARGS=-Dmaven.home=$M2_HOME
+ fi
Previously, if no ARGS are supplied then $ARGS equates to
-Dmaven.home=$M2_HOME which is not recognised by javac and a typical -D arg.
Basically ARGS cannot start or end with a space when later quoted.
@@ -39,7 +43,7 @@
- $JAVACMD $ARGS $MAVEN_OPTS -jar mboot.jar
+ $JAVACMD $ARGS $MAVEN_OPTS -jar mboot.jar
First quote for spaces in JAVA_HOME, second for spaces in M2_HOME. Not sure
if $ARGS works for multiple arguments with spaces, i.e. -Dprop1=C:/Program
Files/a -Dprop2=C:/Program Files/b. From previous experience I seem to
remember having to quote each -D seperately..
Index: maven-core/src/bin/m2.bat
===
@@ -127,7 +127,7 @@
-%MAVEN_JAVA_EXE% %MAVEN_OPTS% -classpath
%M2_HOME%\core\boot\classworlds-*.jar
-Dclassworlds.conf=%M2_HOME%\bin\m2.conf -Dmaven.home=%M2_HOME%
org.codehaus.classworlds.Launcher %MAVEN_CMD_LINE_ARGS%
+%MAVEN_JAVA_EXE% %MAVEN_OPTS% -classpath
%M2_HOME%\core\boot\classworlds-1.1-alpha-1.jar
-Dclassworlds.conf=%M2_HOME%\bin\m2.conf -Dmaven.home=%M2_HOME%
org.codehaus.classworlds.Launcher %MAVEN_CMD_LINE_ARGS%
m2.bat gets called eventually via the script even under cygwin, hence this
fix. Normal quote for M2_HOME in -classpath here, but also the
classworlds-*.jar part does not work under Windows when fully qualified.
i.e. Within M2_HOME/core/boot a javac -cp classworlds-*.jar will work, but
not once it's fully qualified as it is here. Not an ideal solution as we
have to hardcode the classworlds version.
Index: maven-core/src/bin/m2
===
@@ -126,7 +126,7 @@
-exec $JAVACMD \
+exec $JAVACMD \
Quoted for spaces in JAVA_HOME.
Index: maven-mboot2/build
===
@@ -9,8 +9,8 @@
-$JAVA_HOME/bin/javac -g -d ${classesDir} `find ${srcDir} -name '*.java'`
+$JAVA_HOME/bin/javac -g -d ${classesDir} `find ${srcDir} -name '*.java'`
Quoted for spaces in JAVA_HOME.
-( cd ${classesDir} ; $JAVA_HOME/bin/jar -cfm ../mboot.jar
../../manifest.txt * )
+( cd ${classesDir} ; $JAVA_HOME/bin/jar -cfm ../mboot.jar
../../manifest.txt * )
Quoted for spaces in JAVA_HOME.
Index: maven-core-it/maven-core-it.sh
===
@@ -25,9 +25,5 @@
-if [ ! -z $M2_HOME ]; then
- jvm_args=$jvm_args -Dmaven.home=$M2_HOME
-fi
Potentially controversial, but maven-core-it.sh receives -Dmaven.home in it's
args from the parent calling script, so applying this again here causes the
following args to be used:
-Dmaven.home=C:/Program Files/maven2 -Dmaven.home=C:/Program Files/maven2
Which when quoted, results in maven.home equalling C:/Program Files/maven2
-Dmaven.home=C:/Program Files/maven2. This is a symptom of quoting multiple
args with spaces as described above.
+java $jvm_args -cp $cp $verifier
-java $jvm_args -cp $cp $verifier
Quoted for spaces in M2_HOME.
I started to look at fixing the bat files for the pure Windows build, but
came across fundamental problems in maven-mboot2/build.bat - the @argfile
form of javac only works under Windows if any paths with spaces are quoted
within it. So knowing the 'power' of DOS, this didn't seem an easy task.
All of this investigation led me to ask why you guys didn't use Ant instead
of native scripts?!
Any feedback would be welcome, cheers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
[jira] Updated: (MNG-372) Cannot build m2 with spaces in M2_HOME and/or JAVA_HOME
[ http://jira.codehaus.org/browse/MNG-372?page=all ]
Mark Hobson updated MNG-372:
Attachment: patch3.txt
patch3.txt
Cannot build m2 with spaces in M2_HOME and/or JAVA_HOME
---
Key: MNG-372
URL: http://jira.codehaus.org/browse/MNG-372
Project: m2
Type: Bug
Versions: 2.0-alpha-1
Environment: Windows XP, Cygwin.
Reporter: Mark Hobson
Fix For: 2.0-alpha-2
Attachments: patch, patch2.txt, patch3.txt
There are numerous problems when trying to build m2 in Windows when JAVA_HOME
or M2_HOME contains spaces. The attached patch fixes enough of the scripts
to build m2 under cygwin, but there still exist several major flaws when
using the .bat versions.
To detail the various problems, I shall annotate the patch here:
Index: m2-bootstrap-all.sh
===
@@ -1,7 +1,7 @@
-[ -z $JAVA_HOME ] echo echo 'You must set $JAVA_HOME to use mboot!'
echo exit 1
+[ -z $JAVA_HOME ] echo echo 'You must set $JAVA_HOME to use
mboot!' echo exit 1
Quote for spaces in JAVA_HOME.
@@ -19,7 +19,11 @@
- ARGS=$ARGS -Dmaven.home=$M2_HOME
+ if [ -n $ARGS ]; then
+ARGS=$ARGS -Dmaven.home=$M2_HOME
+ else
+ARGS=-Dmaven.home=$M2_HOME
+ fi
Previously, if no ARGS are supplied then $ARGS equates to
-Dmaven.home=$M2_HOME which is not recognised by javac and a typical -D arg.
Basically ARGS cannot start or end with a space when later quoted.
@@ -39,7 +43,7 @@
- $JAVACMD $ARGS $MAVEN_OPTS -jar mboot.jar
+ $JAVACMD $ARGS $MAVEN_OPTS -jar mboot.jar
First quote for spaces in JAVA_HOME, second for spaces in M2_HOME. Not sure
if $ARGS works for multiple arguments with spaces, i.e. -Dprop1=C:/Program
Files/a -Dprop2=C:/Program Files/b. From previous experience I seem to
remember having to quote each -D seperately..
Index: maven-core/src/bin/m2.bat
===
@@ -127,7 +127,7 @@
-%MAVEN_JAVA_EXE% %MAVEN_OPTS% -classpath
%M2_HOME%\core\boot\classworlds-*.jar
-Dclassworlds.conf=%M2_HOME%\bin\m2.conf -Dmaven.home=%M2_HOME%
org.codehaus.classworlds.Launcher %MAVEN_CMD_LINE_ARGS%
+%MAVEN_JAVA_EXE% %MAVEN_OPTS% -classpath
%M2_HOME%\core\boot\classworlds-1.1-alpha-1.jar
-Dclassworlds.conf=%M2_HOME%\bin\m2.conf -Dmaven.home=%M2_HOME%
org.codehaus.classworlds.Launcher %MAVEN_CMD_LINE_ARGS%
m2.bat gets called eventually via the script even under cygwin, hence this
fix. Normal quote for M2_HOME in -classpath here, but also the
classworlds-*.jar part does not work under Windows when fully qualified.
i.e. Within M2_HOME/core/boot a javac -cp classworlds-*.jar will work, but
not once it's fully qualified as it is here. Not an ideal solution as we
have to hardcode the classworlds version.
Index: maven-core/src/bin/m2
===
@@ -126,7 +126,7 @@
-exec $JAVACMD \
+exec $JAVACMD \
Quoted for spaces in JAVA_HOME.
Index: maven-mboot2/build
===
@@ -9,8 +9,8 @@
-$JAVA_HOME/bin/javac -g -d ${classesDir} `find ${srcDir} -name '*.java'`
+$JAVA_HOME/bin/javac -g -d ${classesDir} `find ${srcDir} -name '*.java'`
Quoted for spaces in JAVA_HOME.
-( cd ${classesDir} ; $JAVA_HOME/bin/jar -cfm ../mboot.jar
../../manifest.txt * )
+( cd ${classesDir} ; $JAVA_HOME/bin/jar -cfm ../mboot.jar
../../manifest.txt * )
Quoted for spaces in JAVA_HOME.
Index: maven-core-it/maven-core-it.sh
===
@@ -25,9 +25,5 @@
-if [ ! -z $M2_HOME ]; then
- jvm_args=$jvm_args -Dmaven.home=$M2_HOME
-fi
Potentially controversial, but maven-core-it.sh receives -Dmaven.home in it's
args from the parent calling script, so applying this again here causes the
following args to be used:
-Dmaven.home=C:/Program Files/maven2 -Dmaven.home=C:/Program Files/maven2
Which when quoted, results in maven.home equalling C:/Program Files/maven2
-Dmaven.home=C:/Program Files/maven2. This is a symptom of quoting multiple
args with spaces as described above.
+java $jvm_args -cp $cp $verifier
-java $jvm_args -cp $cp $verifier
Quoted for spaces in M2_HOME.
I started to look at fixing the bat files for the pure Windows build, but
came across fundamental problems in maven-mboot2/build.bat - the @argfile
form of javac only works under Windows if any paths with spaces are quoted
within it. So knowing the 'power' of DOS, this didn't seem an easy task.
All of this investigation led me to ask why you guys didn't use Ant instead
of native scripts?!
Any feedback would be welcome, cheers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of
[jira] Commented: (MNG-375) 3-level pom plugin config inheritance causes ConcurrentModificationException
[ http://jira.codehaus.org/browse/MNG-375?page=comments#action_38829 ] Mark Hobson commented on MNG-375: - Sure, I'm happy to if you point me in the right direction. 3-level pom plugin config inheritance causes ConcurrentModificationException Key: MNG-375 URL: http://jira.codehaus.org/browse/MNG-375 Project: m2 Type: Bug Components: maven-core Versions: 2.0-alpha-2 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: testproject.zip The attached project structure causes the following exception: [EMAIL PROTECTED] testproject]$ m2 clean:clean --- constituent[0]: file:/c:/Program Files/maven-2.0/lib/commons-cli-1.0-beta-2.jar constituent[1]: file:/c:/Program Files/maven-2.0/lib/doxia-core-1.0-alpha-2-20050507.132213-9.jar constituent[2]: file:/c:/Program Files/maven-2.0/lib/marmalade-core-1.0-alpha-3-20050504.035023-1.jar constituent[3]: file:/c:/Program Files/maven-2.0/lib/maven-artifact-2.0-SNAPSHOT.jar constituent[4]: file:/c:/Program Files/maven-2.0/lib/maven-core-2.0-SNAPSHOT.jar constituent[5]: file:/c:/Program Files/maven-2.0/lib/maven-model-2.0-SNAPSHOT.jar constituent[6]: file:/c:/Program Files/maven-2.0/lib/maven-monitor-2.0-SNAPSHOT.jar constituent[7]: file:/c:/Program Files/maven-2.0/lib/maven-plugin-api-2.0-SNAPSHOT.jar constituent[8]: file:/c:/Program Files/maven-2.0/lib/maven-plugin-descriptor-2.0-SNAPSHOT.jar constituent[9]: file:/c:/Program Files/maven-2.0/lib/maven-project-2.0-SNAPSHOT.jar constituent[10]: file:/c:/Program Files/maven-2.0/lib/maven-reporting-api-2.0-20050507.125719-3.jar constituent[11]: file:/c:/Program Files/maven-2.0/lib/maven-script-marmalade-2.0-SNAPSHOT.jar constituent[12]: file:/c:/Program Files/maven-2.0/lib/maven-settings-2.0-SNAPSHOT.jar constituent[13]: file:/c:/Program Files/maven-2.0/lib/oro-2.0.7.jar constituent[14]: file:/c:/Program Files/maven-2.0/lib/plexus-container-artifact-1.0-alpha-3-20050422.054920-3.jar constituent[15]: file:/c:/Program Files/maven-2.0/lib/plexus-i18n-1.0-beta-3.jar constituent[16]: file:/c:/Program Files/maven-2.0/lib/plexus-marmalade-factory-1.0-alpha-3-20050504.035023-1.jar constituent[17]: file:/c:/Program Files/maven-2.0/lib/wagon-http-lightweight-1.0-alpha-3-SNAPSHOT.jar constituent[18]: file:/c:/Program Files/maven-2.0/lib/wagon-provider-api-1.0-alpha-3-SNAPSHOT.jar --- java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449) at java.util.AbstractList$Itr.next(AbstractList.java:420) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assemblePluginManagementInheritance(Def aultModelInheritanceAssembler.java:213) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelIn heritanceAssembler.java:356) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelIn heritanceAssembler.java:126) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:221) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:153) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:142) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:288) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:177) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:199) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:199) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.main(MavenCli.java:230) 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:303) at org.codehaus.classworlds.Launcher.launch(Launcher.java:243) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:416) at org.codehaus.classworlds.Launcher.main(Launcher.java:363) -- 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:
[jira] Commented: (MNG-375) 3-level pom plugin config inheritance causes ConcurrentModificationException
[ http://jira.codehaus.org/browse/MNG-375?page=comments#action_38839 ] Mark Hobson commented on MNG-375: - How strange.. just svn up'ed, cleaned, rebuilt and it all works fine now! Feel free to close this one down. 3-level pom plugin config inheritance causes ConcurrentModificationException Key: MNG-375 URL: http://jira.codehaus.org/browse/MNG-375 Project: m2 Type: Bug Components: maven-core Versions: 2.0-alpha-2 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: testproject.zip The attached project structure causes the following exception: [EMAIL PROTECTED] testproject]$ m2 clean:clean --- constituent[0]: file:/c:/Program Files/maven-2.0/lib/commons-cli-1.0-beta-2.jar constituent[1]: file:/c:/Program Files/maven-2.0/lib/doxia-core-1.0-alpha-2-20050507.132213-9.jar constituent[2]: file:/c:/Program Files/maven-2.0/lib/marmalade-core-1.0-alpha-3-20050504.035023-1.jar constituent[3]: file:/c:/Program Files/maven-2.0/lib/maven-artifact-2.0-SNAPSHOT.jar constituent[4]: file:/c:/Program Files/maven-2.0/lib/maven-core-2.0-SNAPSHOT.jar constituent[5]: file:/c:/Program Files/maven-2.0/lib/maven-model-2.0-SNAPSHOT.jar constituent[6]: file:/c:/Program Files/maven-2.0/lib/maven-monitor-2.0-SNAPSHOT.jar constituent[7]: file:/c:/Program Files/maven-2.0/lib/maven-plugin-api-2.0-SNAPSHOT.jar constituent[8]: file:/c:/Program Files/maven-2.0/lib/maven-plugin-descriptor-2.0-SNAPSHOT.jar constituent[9]: file:/c:/Program Files/maven-2.0/lib/maven-project-2.0-SNAPSHOT.jar constituent[10]: file:/c:/Program Files/maven-2.0/lib/maven-reporting-api-2.0-20050507.125719-3.jar constituent[11]: file:/c:/Program Files/maven-2.0/lib/maven-script-marmalade-2.0-SNAPSHOT.jar constituent[12]: file:/c:/Program Files/maven-2.0/lib/maven-settings-2.0-SNAPSHOT.jar constituent[13]: file:/c:/Program Files/maven-2.0/lib/oro-2.0.7.jar constituent[14]: file:/c:/Program Files/maven-2.0/lib/plexus-container-artifact-1.0-alpha-3-20050422.054920-3.jar constituent[15]: file:/c:/Program Files/maven-2.0/lib/plexus-i18n-1.0-beta-3.jar constituent[16]: file:/c:/Program Files/maven-2.0/lib/plexus-marmalade-factory-1.0-alpha-3-20050504.035023-1.jar constituent[17]: file:/c:/Program Files/maven-2.0/lib/wagon-http-lightweight-1.0-alpha-3-SNAPSHOT.jar constituent[18]: file:/c:/Program Files/maven-2.0/lib/wagon-provider-api-1.0-alpha-3-SNAPSHOT.jar --- java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449) at java.util.AbstractList$Itr.next(AbstractList.java:420) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assemblePluginManagementInheritance(Def aultModelInheritanceAssembler.java:213) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelIn heritanceAssembler.java:356) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelIn heritanceAssembler.java:126) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:221) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:153) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:142) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:288) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:177) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:199) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:199) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.main(MavenCli.java:230) 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:303) at org.codehaus.classworlds.Launcher.launch(Launcher.java:243) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:416) at org.codehaus.classworlds.Launcher.main(Launcher.java:363) -- 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
[jira] Created: (MEV-9) jmock-cglib should depend on cglib
jmock-cglib should depend on cglib -- Key: MEV-9 URL: http://jira.codehaus.org/browse/MEV-9 Project: Maven Evangelism Type: Task Components: Invalid POM Reporter: Mark Hobson jmock-cglib requires cglib but doesn't state so in it's dependencies. Needs the following block: dependency groupIdcglib/groupId artifactIdcglib/artifactId version2.1/version scopetest/scope /dependency -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
