[jira] Reopened: (MNG-3014) java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter getting this error while running APPC
[ http://jira.codehaus.org/browse/MNG-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Debabrat reopened MNG-3014: --- hi Brett Porter I posted this issue because i am getting error while running weblogic:appc using weblogic-maven-plugin. How can you say this is not regarding maven. While running weblogic:appc using maven i am getting the error the weblogic:appc working fine with ANT Deb java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter getting this error while running APPC --- Key: MNG-3014 URL: http://jira.codehaus.org/browse/MNG-3014 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.4 Environment: window xp,maven 2.0.4 Reporter: Debabrat Hello -- I'm building my application using weblogic9.2 and am up to the part where weblogic.appc ant task kicks in. I get the following error message: [May 29, 2007 7:29:29 AM CDT Info HTTP BEA-101047 [ComplianceChecker] Check ing servlet-mapping for servlet name : ImageViewer. [jspc] -webapp specified, searching . for JSPs java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter at weblogic.servlet.jsp.jspc20.runBodyInternal(jspc20.java:420) at weblogic.servlet.jsp.jspc20.runJspc(jspc20.java:195) at weblogic.servlet.jsp.JspcInvoker.compile(JspcInvoker.java:239) at weblogic.application.compiler.AppcUtils.compileWAR(AppcUtils.java:353) at weblogic.application.compiler.WARCompiler.compile(WARCompiler.java:78) at weblogic.application.compiler.flow.AppCompilerFlow.compileInput(AppCompi lerFlow.java:118) at weblogic.application.compiler.flow.AppCompilerFlow.compile(AppCompilerFl ow.java:43) at weblogic.application.compiler.FlowDriver$FlowStateChange.next(FlowDriver .java:69) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:26) at weblogic.application.compiler.FlowDriver.nextState(FlowDriver.java:36) at weblogic.application.compiler.FlowDriver.run(FlowDriver.java:26) at weblogic.application.compiler.Appc.runBody(Appc.java:163) at weblogic.utils.compiler.Tool.run(Tool.java:158) at weblogic.utils.compiler.Tool.run(Tool.java:115) at weblogic.application.compiler.Appc.main(Appc.java:174) at weblogic.appc.main(appc.java:14) at org.codehaus.mojo.weblogic.AppcMojo.execute(AppcMojo.java:129) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.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) [ERROR] Exception encountered during APPC processing java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter at weblogic.servlet.jsp.jspc20.runBodyInternal(jspc20.java:420) at weblogic.servlet.jsp.jspc20.runJspc(jspc20.java:195) at weblogic.servlet.jsp.JspcInvoker.compile(JspcInvoker.java:239) at weblogic.application.compiler.AppcUtils.compileWAR(AppcUtils.java:353) at weblogic.application.compiler.WARCompiler.compile(WARCompiler.java:78) at weblogic.application.compiler.flow.AppCompilerFlow.compileInput(AppCompi lerFlow.java:118) at
[jira] Closed: (MNG-3014) java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter getting this error while running APPC
[ http://jira.codehaus.org/browse/MNG-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3014. - Resolution: Incomplete because the weblogic plugin is not a part of the maven project. I'd suggest looking at the weblogic plugin itself for help, or asking your question on [EMAIL PROTECTED] Issues here are for identified, reproducible problems found with Maven's core distribution. java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter getting this error while running APPC --- Key: MNG-3014 URL: http://jira.codehaus.org/browse/MNG-3014 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.4 Environment: window xp,maven 2.0.4 Reporter: Debabrat Hello -- I'm building my application using weblogic9.2 and am up to the part where weblogic.appc ant task kicks in. I get the following error message: [May 29, 2007 7:29:29 AM CDT Info HTTP BEA-101047 [ComplianceChecker] Check ing servlet-mapping for servlet name : ImageViewer. [jspc] -webapp specified, searching . for JSPs java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter at weblogic.servlet.jsp.jspc20.runBodyInternal(jspc20.java:420) at weblogic.servlet.jsp.jspc20.runJspc(jspc20.java:195) at weblogic.servlet.jsp.JspcInvoker.compile(JspcInvoker.java:239) at weblogic.application.compiler.AppcUtils.compileWAR(AppcUtils.java:353) at weblogic.application.compiler.WARCompiler.compile(WARCompiler.java:78) at weblogic.application.compiler.flow.AppCompilerFlow.compileInput(AppCompi lerFlow.java:118) at weblogic.application.compiler.flow.AppCompilerFlow.compile(AppCompilerFl ow.java:43) at weblogic.application.compiler.FlowDriver$FlowStateChange.next(FlowDriver .java:69) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:26) at weblogic.application.compiler.FlowDriver.nextState(FlowDriver.java:36) at weblogic.application.compiler.FlowDriver.run(FlowDriver.java:26) at weblogic.application.compiler.Appc.runBody(Appc.java:163) at weblogic.utils.compiler.Tool.run(Tool.java:158) at weblogic.utils.compiler.Tool.run(Tool.java:115) at weblogic.application.compiler.Appc.main(Appc.java:174) at weblogic.appc.main(appc.java:14) at org.codehaus.mojo.weblogic.AppcMojo.execute(AppcMojo.java:129) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.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) [ERROR] Exception encountered during APPC processing java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter at weblogic.servlet.jsp.jspc20.runBodyInternal(jspc20.java:420) at weblogic.servlet.jsp.jspc20.runJspc(jspc20.java:195) at weblogic.servlet.jsp.JspcInvoker.compile(JspcInvoker.java:239) at weblogic.application.compiler.AppcUtils.compileWAR(AppcUtils.java:353) at weblogic.application.compiler.WARCompiler.compile(WARCompiler.java:78) at weblogic.application.compiler.flow.AppCompilerFlow.compileInput(AppCompi lerFlow.java:118) at
[jira] Created: (MNG-3073) Memory Leak in maven2 for multiproject
Memory Leak in maven2 for multiproject -- Key: MNG-3073 URL: http://jira.codehaus.org/browse/MNG-3073 Project: Maven 2 Issue Type: Bug Components: General, Performance Affects Versions: 2.0.7 Reporter: Nicolas Cazottes We use Maven2 for a massive multiproject composed of 433 jars projects in 3 levels of hierarchy and lots of inter-dependencies. Our project contains 3577 classes at this time but it is constantly growing. As it grows, the number of projects increases and the number of versions of each project increases as well. What we are faced to is that we constantly need to increase the memory size allowed to Maven. With 433 projects and 3577 classes, we need the following memory parameters : -Xmx900m -Xms128m for our compilation with the following command line : mvn install -Dmaven.test.skip=true. I think there are memory leak in Maven that explains this behaviour. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3073) Memory Leak in maven2 for multiproject
[ http://jira.codehaus.org/browse/MNG-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100667 ] Debabrat commented on MNG-3073: --- set your memery size inside mvn.bat file like this set ANT_OPTS= -Xmx1024m for your reference @REM Reaching here means variables are defined and arguments have been captured :endInit SET MAVEN_JAVA_EXE=%JAVA_HOME%\bin\java.exe set ANT_OPTS= -Xmx1024m Memory Leak in maven2 for multiproject -- Key: MNG-3073 URL: http://jira.codehaus.org/browse/MNG-3073 Project: Maven 2 Issue Type: Bug Components: General, Performance Affects Versions: 2.0.7 Reporter: Nicolas Cazottes We use Maven2 for a massive multiproject composed of 433 jars projects in 3 levels of hierarchy and lots of inter-dependencies. Our project contains 3577 classes at this time but it is constantly growing. As it grows, the number of projects increases and the number of versions of each project increases as well. What we are faced to is that we constantly need to increase the memory size allowed to Maven. With 433 projects and 3577 classes, we need the following memory parameters : -Xmx900m -Xms128m for our compilation with the following command line : mvn install -Dmaven.test.skip=true. I think there are memory leak in Maven that explains this behaviour. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-83) Wrong username during release:prepare tagging
[ http://jira.codehaus.org/browse/MRELEASE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100668 ] Jaran Nilsen commented on MRELEASE-83: -- Having the same issue with 2.0-beta-6. The first checkout the plugin performs works fine, but when the modified POM is to be checked in, the plugin uses the username of the logged on user on the computer, instead of what's specified in the scm.connection/developerConnection in the POM. The -Dusername= parameter, or the workaround proposed by Niclas is not working in 2.0-beta-6 as far as I can see. Wrong username during release:prepare tagging - Key: MRELEASE-83 URL: http://jira.codehaus.org/browse/MRELEASE-83 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Reporter: Niclas Hedhman If I my Svn repository requires a different username than the login name, and I issue mvn [EMAIL PROTECTED] release:prepare The first phase (checking in modified POMs) will succeed with that username. Then somewhere between that point and writing out the release.properties file, the user name falls back to the login name (in my case niclas), which is written into the release.properties file, and used during the tagging of the repository. Now, looking at the source, I think that is unwise to keep a username both in the ReleaseProgressTracker as well as in the ScmHelper, and I suspect that there is some type of sequencing problem in there. WORKAROUND; Before starting the release:prepare, create a release.properties file manually which contains [EMAIL PROTECTED] and everything will work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3073) Memory Leak in maven2 for multiproject
[ http://jira.codehaus.org/browse/MNG-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100667 ] Debabrat edited comment on MNG-3073 at 6/27/07 3:01 AM: Set the memory size inside Maven2.0.4/bin/mvn.bat file like this set ANT_OPTS= -Xmx1024m for your reference where to set ANT_OPTS @REM Reaching here means variables are defined and arguments have been captured :endInit SET MAVEN_JAVA_EXE=%JAVA_HOME%\bin\java.exe set ANT_OPTS= -Xmx1024m was: set your memery size inside mvn.bat file like this set ANT_OPTS= -Xmx1024m for your reference @REM Reaching here means variables are defined and arguments have been captured :endInit SET MAVEN_JAVA_EXE=%JAVA_HOME%\bin\java.exe set ANT_OPTS= -Xmx1024m Memory Leak in maven2 for multiproject -- Key: MNG-3073 URL: http://jira.codehaus.org/browse/MNG-3073 Project: Maven 2 Issue Type: Bug Components: General, Performance Affects Versions: 2.0.7 Reporter: Nicolas Cazottes We use Maven2 for a massive multiproject composed of 433 jars projects in 3 levels of hierarchy and lots of inter-dependencies. Our project contains 3577 classes at this time but it is constantly growing. As it grows, the number of projects increases and the number of versions of each project increases as well. What we are faced to is that we constantly need to increase the memory size allowed to Maven. With 433 projects and 3577 classes, we need the following memory parameters : -Xmx900m -Xms128m for our compilation with the following command line : mvn install -Dmaven.test.skip=true. I think there are memory leak in Maven that explains this behaviour. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3073) Memory Leak in maven2 for multiproject
[ http://jira.codehaus.org/browse/MNG-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100669 ] Milos Kleint commented on MNG-3073: --- forking the compiler could have influence on memory usage as well. Haven't measured rigorously though. Memory Leak in maven2 for multiproject -- Key: MNG-3073 URL: http://jira.codehaus.org/browse/MNG-3073 Project: Maven 2 Issue Type: Bug Components: General, Performance Affects Versions: 2.0.7 Reporter: Nicolas Cazottes We use Maven2 for a massive multiproject composed of 433 jars projects in 3 levels of hierarchy and lots of inter-dependencies. Our project contains 3577 classes at this time but it is constantly growing. As it grows, the number of projects increases and the number of versions of each project increases as well. What we are faced to is that we constantly need to increase the memory size allowed to Maven. With 433 projects and 3577 classes, we need the following memory parameters : -Xmx900m -Xms128m for our compilation with the following command line : mvn install -Dmaven.test.skip=true. I think there are memory leak in Maven that explains this behaviour. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-83) Wrong username during release:prepare tagging
[ http://jira.codehaus.org/browse/MRELEASE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated MRELEASE-83: - Fix Version/s: 2.0-beta-7 Wrong username during release:prepare tagging - Key: MRELEASE-83 URL: http://jira.codehaus.org/browse/MRELEASE-83 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Reporter: Niclas Hedhman Fix For: 2.0-beta-7 If I my Svn repository requires a different username than the login name, and I issue mvn [EMAIL PROTECTED] release:prepare The first phase (checking in modified POMs) will succeed with that username. Then somewhere between that point and writing out the release.properties file, the user name falls back to the login name (in my case niclas), which is written into the release.properties file, and used during the tagging of the repository. Now, looking at the source, I think that is unwise to keep a username both in the ReleaseProgressTracker as well as in the ScmHelper, and I suspect that there is some type of sequencing problem in there. WORKAROUND; Before starting the release:prepare, create a release.properties file manually which contains [EMAIL PROTECTED] and everything will work. -- 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: (MIDEA-98) Module filepath is generated incorrectly
Module filepath is generated incorrectly
Key: MIDEA-98
URL: http://jira.codehaus.org/browse/MIDEA-98
Project: Maven 2.x IDEA Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: $ mvn -v
Maven version: 2.0.7
Java version: 1.5.0_11
OS name: windows xp version: 5.1 arch: x86
Reporter: Ben Hood
I have a multi-module mvn project.
When I do an mvn idea:clean idea:idea, the following ProjectModuleManager
snippet in the top level .ipr is generated:
component name=ProjectModuleManager
modules
!-- module filepath=$$PROJECT_DIR$$/${pom.artifactId}.iml/ --
module filepath=$PROJECT_DIR$/gateway.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml/
/modules
/component
The $PROJECT_DIR in this case is C:/dev/voca/gateway/.
But this path is being appended in a hard-coded fashion after the $PROJECT_DIR
entry.
The symptom in Intellij is the following error message:
Cannot load module: File
C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not exist
Would you like to remove the module from the project?
The workaround is to delete the extra appended file path from each module entry
in the above mentioned snippet.
--
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: (MRESOURCES-43) resources:resources overwrites destination files when filtering is on, not when filtering is off
resources:resources overwrites destination files when filtering is on, not when filtering is off Key: MRESOURCES-43 URL: http://jira.codehaus.org/browse/MRESOURCES-43 Project: Maven 2.x Resources Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Linux Reporter: Roar Lauritzsen It is not possible to specify that resources:resources should overwrite destination files or not if they already exist. However, the behavior should at the very least be predictable so that one can achieve the desired result through phase ordering or ant scripts. As it is today, when filtering is turned on, destination files are overwritten. When filtering is off, destination files are not overwritten. If not selectable, the most practical solution would be to always overwrite (I believe). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-224) Support Signing assembled jars
Support Signing assembled jars -- Key: MASSEMBLY-224 URL: http://jira.codehaus.org/browse/MASSEMBLY-224 Project: Maven 2.x Assembly Plugin Issue Type: Wish Affects Versions: 2.2-beta-1 Reporter: Florian Domino Priority: Minor The Configuration Tag does not include the signing parts of the jar plugin you can set alias and storepassword but it is ignored/never called Fix: delegate the signing configuration tags to the jar plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3073) Memory Leak in maven2 for multiproject
[ http://jira.codehaus.org/browse/MNG-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100688 ] Nicolas Cazottes commented on MNG-3073: --- I actually set the memory configuration I mentionned through the environment variable MAVEN_OPTS. My point is that the solution to increase the memory endless is not a good one because I may be at some time faced to a limit of my computer memory size if my number of projects increases to 1000. Forking the compiler should be an option but I think it will increase the compilation time which is currently 12min average. I will try it to see. Memory Leak in maven2 for multiproject -- Key: MNG-3073 URL: http://jira.codehaus.org/browse/MNG-3073 Project: Maven 2 Issue Type: Bug Components: General, Performance Affects Versions: 2.0.7 Reporter: Nicolas Cazottes We use Maven2 for a massive multiproject composed of 433 jars projects in 3 levels of hierarchy and lots of inter-dependencies. Our project contains 3577 classes at this time but it is constantly growing. As it grows, the number of projects increases and the number of versions of each project increases as well. What we are faced to is that we constantly need to increase the memory size allowed to Maven. With 433 projects and 3577 classes, we need the following memory parameters : -Xmx900m -Xms128m for our compilation with the following command line : mvn install -Dmaven.test.skip=true. I think there are memory leak in Maven that explains this behaviour. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-529) Please fix aspectj mavane-metadata.xml
[ http://jira.codehaus.org/browse/MEV-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100696 ] Richard A. Gill commented on MEV-529: - Thank you! Please fix aspectj mavane-metadata.xml -- Key: MEV-529 URL: http://jira.codehaus.org/browse/MEV-529 Project: Maven Evangelism Issue Type: Task Components: Invalid Metadata Reporter: Richard A. Gill Assignee: Carlos Sanchez Please update the metadata to reflect the latest (newer) version 1.5.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
[jira] Created: (MEV-534) Dependencies of commons-logging should be optional
Dependencies of commons-logging should be optional -- Key: MEV-534 URL: http://jira.codehaus.org/browse/MEV-534 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: J-C Walmetz Dependencies in pom should be dependencies dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version optionaltrueoptional /dependency instead of dependencies #8722; dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency /dependencies /dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-534) Dependencies of commons-logging should be optional
[ http://jira.codehaus.org/browse/MEV-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100700 ] J-C Walmetz commented on MEV-534: - Just a mistake in previous post dependencies dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version optionaltrueoptional /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version optionaltrueoptional /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version optionaltrueoptional /dependency dependencies instead of dependencies dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency /dependencies Dependencies of commons-logging should be optional -- Key: MEV-534 URL: http://jira.codehaus.org/browse/MEV-534 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: J-C Walmetz Dependencies in pom should be dependencies dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version optionaltrueoptional /dependency instead of dependencies #8722; dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency /dependencies /dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-534) Dependencies of commons-logging should be optional
[ http://jira.codehaus.org/browse/MEV-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100701 ] Arik Kfir commented on MEV-534: --- Shouldn't log4j be optional too? Dependencies of commons-logging should be optional -- Key: MEV-534 URL: http://jira.codehaus.org/browse/MEV-534 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: J-C Walmetz Dependencies in pom should be dependencies dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version optionaltrueoptional /dependency instead of dependencies #8722; dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency /dependencies /dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1614) Request to upload new project - Simple XML
Request to upload new project - Simple XML -- Key: MAVENUPLOAD-1614 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1614 Project: maven-upload-requests Issue Type: Bug Reporter: Niall Gallagher Attachments: simple-xml-1.4-bundle.jar, simple-xml-1.4-javadoc.jar http://simple.sourceforge.net/simple-xml-1.4-bundle.jar Project: http://simple.sourceforge.net Proof of Ownership: http://simple.sourceforge.net/download/stream/doc/javadoc/simple/xml/Serializer.html Proof of URL Ownership: http://www.whois.net/whois_new.cgi?d=simpleframeworktld=org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-534) Dependencies of commons-logging should be optional
[ http://jira.codehaus.org/browse/MEV-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100705 ] J-C Walmetz commented on MEV-534: - Yes that's a mistake, log4j should be optional too. That's purpose of common-loggings to be able to switch from log4j to JDK logger. It should be : dependencies dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version optionaltrueoptional /dependency dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version optionaltrueoptional /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version optionaltrueoptional /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version optionaltrueoptional /dependency dependencies Dependencies of commons-logging should be optional -- Key: MEV-534 URL: http://jira.codehaus.org/browse/MEV-534 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: J-C Walmetz Dependencies in pom should be dependencies dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version optionaltrueoptional /dependency instead of dependencies #8722; dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency /dependencies /dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-534) Dependencies of commons-logging should be optional
[ http://jira.codehaus.org/browse/MEV-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-534. -- Assignee: Carlos Sanchez Resolution: Duplicate Dependencies of commons-logging should be optional -- Key: MEV-534 URL: http://jira.codehaus.org/browse/MEV-534 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: J-C Walmetz Assignee: Carlos Sanchez Dependencies in pom should be dependencies dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version optionaltrueoptional /dependency instead of dependencies #8722; dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency #8722; dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency #8722; dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency #8722; dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency #8722; dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency /dependencies /dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2771) Provide a means of loading custom substitute components instead of default Maven components
[ http://jira.codehaus.org/browse/MNG-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100709 ] Mark Hobson commented on MNG-2771: -- Added it0124 to reproduce the above problem. Provide a means of loading custom substitute components instead of default Maven components --- Key: MNG-2771 URL: http://jira.codehaus.org/browse/MNG-2771 Project: Maven 2 Issue Type: New Feature Components: General Affects Versions: 2.0.4 Reporter: John Casey Assignee: Kenney Westerhof Fix For: 2.1-alpha-1 At times, it is necessary to use different mechanisms for resolving artifacts, building projects, etc. Since Maven is built on component-oriented technology, it should be possible to substitute the component implementation used for these tasks. Yet this is currently impossible. We need a mechanism for specifying, resolving, loading, and using custom components during the build process. -- 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-3074) Anchor links in several documentations do not work
Anchor links in several documentations do not work -- Key: MNG-3074 URL: http://jira.codehaus.org/browse/MNG-3074 Project: Maven 2 Issue Type: Bug Components: Documentation: General Reporter: Rick Janda Priority: Minor In the online documentation User Centre, the anchor links from the table of contents at the beginning of the Settings Reference and the POM Reference do not work at all. Also the anchor links to the different sections at the beginning of the Getting Started Guide do not work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1614) Request to upload new project - Simple XML
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100713 ] Niall Gallagher commented on MAVENUPLOAD-1614: -- Mistake on the proof of ownership link, the following will work instead. http://simple.sourceforge.net/download/stream/doc/javadoc/org/simpleframework/xml/Serializer.html Request to upload new project - Simple XML -- Key: MAVENUPLOAD-1614 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1614 Project: maven-upload-requests Issue Type: Bug Reporter: Niall Gallagher Attachments: simple-xml-1.4-bundle.jar, simple-xml-1.4-javadoc.jar http://simple.sourceforge.net/simple-xml-1.4-bundle.jar Project: http://simple.sourceforge.net Proof of Ownership: http://simple.sourceforge.net/download/stream/doc/javadoc/simple/xml/Serializer.html Proof of URL Ownership: http://www.whois.net/whois_new.cgi?d=simpleframeworktld=org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2900) Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail.
[ http://jira.codehaus.org/browse/MNG-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100720 ] Calin Medianu commented on MNG-2900: Hi, In 2.0.7 the error has changed, but it it still not possible to do a DAV upload from the command line. in 2.0.6 I was getting the StringUtils stacktrace. $ ./mvn.bat deploy:deploy-file -DgroupId=test.case -DartifactId=GWT-Stuff -Dversion=20070309 -DgeneratePom=true -Dpackaging=jar -DrepositoryId=server -Durl=dav:http://server:/maven2/sandbox -Dfile=GWT-Stuff.jar [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] --- - [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] --- - [INFO] [deploy:deploy-file] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find wagon wh ich supports the requested protocol: dav Component descriptor cannot be found in the component repository: org.apache.maven .wagon.Wagondav. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Jun 27 12:40:22 PDT 2007 [INFO] Final Memory: 2M/5M [INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protoc ol: dav at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defaul tLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGo al(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Default LifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandl eFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLife cycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja va:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying artifac t: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested pro tocol: dav at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.ja va:243) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginM anager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defaul tLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error d eploying artifact: Unsupported Protocol: 'dav': Cannot find wagon which supports t he requested protocol: dav at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Defau ltArtifactDeployer.java:94) at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.ja va:239) ... 18 more Caused by: org.apache.maven.wagon.TransferFailedException: Unsupported Protocol: ' dav': Cannot find wagon which supports the requested protocol: dav at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(Def aultWagonManager.java:184) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(Defau ltWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Defau ltArtifactDeployer.java:80) ... 19 more Caused by:
[jira] Commented: (MNG-2900) Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail.
[ http://jira.codehaus.org/browse/MNG-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100721 ] Jason van Zyl commented on MNG-2900: We need your POM as you must have something different. I upload via WebDAV all day with 2.0.7 as I did with 2.0.6. I need to see the project. Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail. - Key: MNG-2900 URL: http://jira.codehaus.org/browse/MNG-2900 Project: Maven 2 Issue Type: Bug Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 2.0.6 This is happening with the WebDAV Wagon: java.lang.NoClassDefFoundError: org/codehaus/plexus/util/StringUtils at org.apache.maven.wagon.providers.webdav.WebDavWagon.put(WebDavWagon.java:192) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:237) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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) -- 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-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.
Project properties, project.artifactId and project.version, are incorrectly
translated when use defined in a parent POM.
Key: MNG-3075
URL: http://jira.codehaus.org/browse/MNG-3075
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.7, 2.0.6
Reporter: Paul Spencer
I have defined the scm and distributionManagement tags in a parent POM.
The definitions in the parent POM use ${project.artifactId} and
${project.version}. The problem is the resulting POM has incorrect tags.
As an example: When the master POM contains the following configuration, the
distribution site url for the bad-effective-pom project is
scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
distributionManagement
site
idfoo-project-site/id
nameProject Site/name
urlscp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}/url
/site
/distributionManagement
As the level of POM inheritance increases, so do the problem.
A test case will be attached to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.
[
http://jira.codehaus.org/browse/MNG-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Spencer updated MNG-3075:
--
Attachment: pom.xml
This pom inherits the SCM and Distribution Management configuration from the
parent POM.
Project properties, project.artifactId and project.version, are incorrectly
translated when use defined in a parent POM.
Key: MNG-3075
URL: http://jira.codehaus.org/browse/MNG-3075
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.6, 2.0.7
Reporter: Paul Spencer
Attachments: pom.xml, pom.xml, pom.xml
I have defined the scm and distributionManagement tags in a parent POM.
The definitions in the parent POM use ${project.artifactId} and
${project.version}. The problem is the resulting POM has incorrect tags.
As an example: When the master POM contains the following configuration, the
distribution site url for the bad-effective-pom project is
scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
distributionManagement
site
idfoo-project-site/id
nameProject Site/name
urlscp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}/url
/site
/distributionManagement
As the level of POM inheritance increases, so do the problem.
A test case will be attached to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.
[
http://jira.codehaus.org/browse/MNG-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Spencer updated MNG-3075:
--
Attachment: pom.xml
Parent POM
Project properties, project.artifactId and project.version, are incorrectly
translated when use defined in a parent POM.
Key: MNG-3075
URL: http://jira.codehaus.org/browse/MNG-3075
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.6, 2.0.7
Reporter: Paul Spencer
Attachments: pom.xml, pom.xml, pom.xml
I have defined the scm and distributionManagement tags in a parent POM.
The definitions in the parent POM use ${project.artifactId} and
${project.version}. The problem is the resulting POM has incorrect tags.
As an example: When the master POM contains the following configuration, the
distribution site url for the bad-effective-pom project is
scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
distributionManagement
site
idfoo-project-site/id
nameProject Site/name
urlscp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}/url
/site
/distributionManagement
As the level of POM inheritance increases, so do the problem.
A test case will be attached to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.
[
http://jira.codehaus.org/browse/MNG-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100729
]
Paul Spencer commented on MNG-3075:
---
I should have mentioned, the expected distribution site url in the example is
scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT
Project properties, project.artifactId and project.version, are incorrectly
translated when use defined in a parent POM.
Key: MNG-3075
URL: http://jira.codehaus.org/browse/MNG-3075
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.6, 2.0.7
Reporter: Paul Spencer
Attachments: pom.xml, pom.xml, pom.xml
I have defined the scm and distributionManagement tags in a parent POM.
The definitions in the parent POM use ${project.artifactId} and
${project.version}. The problem is the resulting POM has incorrect tags.
As an example: When the master POM contains the following configuration, the
distribution site url for the bad-effective-pom project is
scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
distributionManagement
site
idfoo-project-site/id
nameProject Site/name
urlscp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}/url
/site
/distributionManagement
As the level of POM inheritance increases, so do the problem.
A test case will be attached to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.
[
http://jira.codehaus.org/browse/MNG-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100730
]
Paul Spencer commented on MNG-3075:
---
The projecturl tag also has the problem.
project
...
url
http://developer.foo.com/projects/${project.artifactId}/${project.version}
/url
...
/project
Project properties, project.artifactId and project.version, are incorrectly
translated when use defined in a parent POM.
Key: MNG-3075
URL: http://jira.codehaus.org/browse/MNG-3075
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.6, 2.0.7
Reporter: Paul Spencer
Attachments: pom.xml, pom.xml, pom.xml
I have defined the scm and distributionManagement tags in a parent POM.
The definitions in the parent POM use ${project.artifactId} and
${project.version}. The problem is the resulting POM has incorrect tags.
As an example: When the master POM contains the following configuration, the
distribution site url for the bad-effective-pom project is
scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
distributionManagement
site
idfoo-project-site/id
nameProject Site/name
urlscp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}/url
/site
/distributionManagement
As the level of POM inheritance increases, so do the problem.
A test case will be attached to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2900) Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail.
[ http://jira.codehaus.org/browse/MNG-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100731 ] Calin Medianu commented on MNG-2900: Thank you for your reply. There is no POM or project. With this command line I am trying to upload (deploy:deploy-file) a pomless jar into the repository. The command line is: ./mvn.bat deploy:deploy-file -DgroupId=test.case -DartifactId=GWT-Stuff -Dversion=20070309 -DgeneratePom=true -Dpackaging=jar -DrepositoryId=server -Durl=dav:http://server:/maven2/sandbox -Dfile=GWT-Stuff.jar I expect it to generate the pom and the checksums. I got this working in 2.0.4 by adding a bunch of dav related files to maven-2.0.4\lib Thanks, Calin Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail. - Key: MNG-2900 URL: http://jira.codehaus.org/browse/MNG-2900 Project: Maven 2 Issue Type: Bug Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 2.0.6 This is happening with the WebDAV Wagon: java.lang.NoClassDefFoundError: org/codehaus/plexus/util/StringUtils at org.apache.maven.wagon.providers.webdav.WebDavWagon.put(WebDavWagon.java:192) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:237) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2900) Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail.
[ http://jira.codehaus.org/browse/MNG-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100732 ] Jason van Zyl commented on MNG-2900: Right ... this is a known problem and you must load webdav as an extension or you must have had the dav libraries in your classpath, or Maven home for this to work. We are aware of this problem. When webdav is listed as an extension, which is the only way it works, then you can deploy fine. So this problem is actually fixed, and in the future it might be a little more kind to a project like Maven not to post your issues to site like TSS telling the world the issue hasn't been fixed when, in fact, is was. You have a different problem. We will make the deployment plugin smarter in that it should parse user supplied URLs for Wagon extensions and load them. But this is not a an issue with plexus-utils not being present. I deploy everyday using WebDAV but it doesn have to be configured in the POM to load the extension into the right classloader. Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail. - Key: MNG-2900 URL: http://jira.codehaus.org/browse/MNG-2900 Project: Maven 2 Issue Type: Bug Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 2.0.6 This is happening with the WebDAV Wagon: java.lang.NoClassDefFoundError: org/codehaus/plexus/util/StringUtils at org.apache.maven.wagon.providers.webdav.WebDavWagon.put(WebDavWagon.java:192) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:237) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1615) repo1.maven.org not updated from shell.sf.net
repo1.maven.org not updated from shell.sf.net - Key: MAVENUPLOAD-1615 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1615 Project: maven-upload-requests Issue Type: Bug Reporter: Misha Gridnev repo1.maven.org does not reflect the contents of [EMAIL PROTECTED]:/home/groups/j/jf/jframework/repository/org/jframework/. I verified that: 1. org.jframework.sh was added to the update scripts (See issue MAVENUPLOAD-1611). The script defines [EMAIL PROTECTED]:/home/groups/j/jf/jframework/repository and GROUP_DIR=org/jframework/ 2. [EMAIL PROTECTED] already has a proper public key 3. jframework and jframework-core artifacts are available in shell.sf.net:/home/groups/j/jf/jframework/repository/org/jframework/ directory Yet there's no jframework showing under http://repo1.maven.org/maven2/org/ Obvioulsy, I am doing something wrong. How often does the central repo update script run? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2900) Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail.
[ http://jira.codehaus.org/browse/MNG-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100735 ] Calin Medianu commented on MNG-2900: Hi, Thanks again for looking into it. Indeed, in 2.0.7 this issue is fixed and another issue has surfaced. In 2.0.6 is is NOT fixed. I said on TSS that this bug was not fixed in 2.0.6, which is true. My comment on TSS was unkind and I'm sorry for that. The reason was to draw attention to the comment from Brill Pappin - [07/May/07 12:04 PM ] which was ignored for 2 months as well as the frustration from having to support a co-worker that decided to upgrade from 2.0.4 to 2.0.6 and DAV stopped working for her. in 2.0.4 dav is working from the command line with the extra jars in maven/lib, in 2.0.6 it cannot find the org/codehaus/plexus/util/StringUtils I am actually a promoter of maven2 in my organization... Thanks, Calin Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail. - Key: MNG-2900 URL: http://jira.codehaus.org/browse/MNG-2900 Project: Maven 2 Issue Type: Bug Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 2.0.6 This is happening with the WebDAV Wagon: java.lang.NoClassDefFoundError: org/codehaus/plexus/util/StringUtils at org.apache.maven.wagon.providers.webdav.WebDavWagon.put(WebDavWagon.java:192) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:237) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1616) Upload Simple-JNDI 0.11.2
Upload Simple-JNDI 0.11.2 - Key: MAVENUPLOAD-1616 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1616 Project: maven-upload-requests Issue Type: Task Reporter: Henri Yandell Assignee: Henri Yandell -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1614) Request to upload new project - Simple XML
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MAVENUPLOAD-1614. -- Assignee: Henri Yandell Resolution: Fixed Done. Request to upload new project - Simple XML -- Key: MAVENUPLOAD-1614 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1614 Project: maven-upload-requests Issue Type: Bug Reporter: Niall Gallagher Assignee: Henri Yandell Attachments: simple-xml-1.4-bundle.jar, simple-xml-1.4-javadoc.jar http://simple.sourceforge.net/simple-xml-1.4-bundle.jar Project: http://simple.sourceforge.net Proof of Ownership: http://simple.sourceforge.net/download/stream/doc/javadoc/simple/xml/Serializer.html Proof of URL Ownership: http://www.whois.net/whois_new.cgi?d=simpleframeworktld=org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1616) Upload Simple-JNDI 0.11.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MAVENUPLOAD-1616. -- Resolution: Fixed Donedone! Upload Simple-JNDI 0.11.2 - Key: MAVENUPLOAD-1616 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1616 Project: maven-upload-requests Issue Type: Task Reporter: Henri Yandell Assignee: Henri Yandell -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1552) Upload mysql:mysql-connector-java:jar:5.0.6 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100747 ] Henri Yandell commented on MAVENUPLOAD-1552: Did they get it done Mark? ie) can I mark this WONTFIX? Upload mysql:mysql-connector-java:jar:5.0.6 to ibiblio -- Key: MAVENUPLOAD-1552 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1552 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/mysql-connector-java-5.0.6-bundle.jar http://dev.mysql.com/downloads/connector/j/5.0.html MySQL Connector/J is the official JDBC driver for MySQL. -- 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: (MRM-427) Bug in meeper maven-upload-bundle handling
Bug in meeper maven-upload-bundle handling -- Key: MRM-427 URL: http://jira.codehaus.org/browse/MRM-427 Project: Archiva Issue Type: Bug Reporter: Henri Yandell (Putting in MRM for want of anywhere else to record this). When handling Maven bundles, the maven metadata xml's are not generated nor 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
