[jira] Updated: (MJAVADOC-62) javadoc:javadoc needs access to generated sources
[ http://jira.codehaus.org/browse/MJAVADOC-62?page=all ]
Brett Porter updated MJAVADOC-62:
-
Fix Version: (was: 2.0)
javadoc:javadoc needs access to generated sources
-
Key: MJAVADOC-62
URL: http://jira.codehaus.org/browse/MJAVADOC-62
Project: Maven 2.x Javadoc Plugin
Type: Bug
Versions: 2.0
Reporter: John Casey
Assignee: Brett Porter
Priority: Blocker
Attachments: MJAVADOC-62.diff, MJAVADOC-62.diff
currently, maven-model will not generate apidocs by simply calling
javadoc:javadoc. This is because maven-model's sources are generated, and the
javadoc report doesn't ensure that the 'generate-sources' phase is called.
However, when I changed the report to have:
@execute phase=generate-sources
It still doesn't work. I suspect this may be because it's forking a new
lifecycle and cloning the project to call generate-sources, which means the
report doesn't use the right project instance to create the report. However,
I've been unable to inject ${executedProject} as a parameter; it fails the
build, saying I need to supply that parameter on the command line.
I haven't committed any code changes to this report, since I don't currently
have time to debug it properly, and I obviously haven't solved the 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
[jira] Closed: (MJAVADOC-70) {inceptionYear} is not evaluated when inceptionYear is not specified in pom.
[ http://jira.codehaus.org/browse/MJAVADOC-70?page=all ]
Brett Porter closed MJAVADOC-70:
Assign To: Brett Porter
Resolution: Fixed
{inceptionYear} is not evaluated when inceptionYear is not specified in pom.
Key: MJAVADOC-70
URL: http://jira.codehaus.org/browse/MJAVADOC-70
Project: Maven 2.x Javadoc Plugin
Type: Bug
Versions: 2.0-beta-3
Reporter: Henry S. Isidro
Assignee: Brett Porter
Priority: Minor
Fix For: 2.0
Attachments: maven-javadoc-plugin.patch
The javadoc site shows {inceptionYear} if the inceptionYear parameter is not
set in pom.xml. The attached patch remedies this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-98) Assembly groupVersionAlignment excludes affects all other groupVersionAlignment
[ http://jira.codehaus.org/browse/MASSEMBLY-98?page=all ]
Edwin Punzalan updated MASSEMBLY-98:
Attachment: MASSEMBLY-98-maven-assembly-plugin.patch
Assembly groupVersionAlignment excludes affects all other
groupVersionAlignment
---
Key: MASSEMBLY-98
URL: http://jira.codehaus.org/browse/MASSEMBLY-98
Project: Maven 2.x Assembly Plugin
Type: Bug
Versions: 2.1
Reporter: Edwin Punzalan
Assignee: Edwin Punzalan
Attachments: MASSEMBLY-98-maven-assembly-plugin.patch
Setting this in your assembly xml:
{code}
repository
groupVersionAlignments
groupVersionAlignment
idgroup-a/id
version1.0/version
/groupVersionAlignment
groupVersionAlignment
idgroup-b/id
version2.0/version
excludes
excludeartifact-a/exclude
/excludes
/groupVersionAlignment
/groupVersionAlignments
/repository
{code}
what happens is that if there is an artifact with groupId=group-a and
artifactId=artifact-a, it gets excluded even though artifact-a is declared to
be excluded in group-b. What effectively happens is something like this:
{code}
repository
groupVersionAlignments
groupVersionAlignment
idgroup-a/id
version1.0/version
excludes
excludeartifact-a/exclude
/excludes
/groupVersionAlignment
groupVersionAlignment
idgroup-b/id
version2.0/version
excludes
excludeartifact-a/exclude
/excludes
/groupVersionAlignment
/groupVersionAlignments
/repository
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MSUREFIRE-106) Disabling xml report generation
[ http://jira.codehaus.org/browse/MSUREFIRE-106?page=all ] Brett Porter closed MSUREFIRE-106: -- Assign To: Brett Porter Resolution: Fixed Disabling xml report generation --- Key: MSUREFIRE-106 URL: http://jira.codehaus.org/browse/MSUREFIRE-106 Project: Maven 2.x Surefire Plugin Type: Improvement Versions: 2.1.3 Reporter: Vinod Panicker Assignee: Brett Porter Fix For: 2.2 Currently the surefire plugin generates xml reports if report generation is enabled. There is no way to turn it off completely. Since xml report generation takes a lot of time, this severely impacts total build time. It would be great to have an option to turn of xml report generation. -- 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-2237) Inherited plugin executed twice if child pom merges configuration
[ http://jira.codehaus.org/browse/MNG-2237?page=all ]
Carlos Sanchez updated MNG-2237:
Fix Version: 2.0.5
Inherited plugin executed twice if child pom merges configuration
-
Key: MNG-2237
URL: http://jira.codehaus.org/browse/MNG-2237
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.4
Reporter: Joerg Schaible
Fix For: 2.0.5
According the docs the configuration of a plugin is merged, when the plugin
is inherited. This actually hapens, but the plugin with the merged
configuration is added twice in the effective-pom and therefore executed
twice.
Setup a parent pom with a plugin configuration to attach the javadocs:
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
executions
execution
idattach-javadocs/id
goals
goaljar/goal
/goals
/execution
/executions
inheritedtrue/inherited
configuration
linksourcetrue/linksource
/configuration
/plugin
{noformat}
and a child pom that adds additional elements in the configuration:
{noformat}
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
links
linkhttp://java.sun.com/j2se/1.4.2/docs/api//link
linkhttp://jakarta.apache.org/commons/logging/commons-logging-1.0.4/docs/apidocs//link
linkhttp://jmock.codehaus.org/docs/javadoc//link
linkhttp://www.junit.org/junit/javadoc/3.8.1//link
/links
/configuration
/plugin
{noformat}
In this case the javadoc is generated twice, the goal help:effective-pom
reveals, that the plugin was merged, but added twice.
--
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: (MSUREFIRE-97) TestNG tests are not executed if invoked by */*Test.java naming pattern
[ http://jira.codehaus.org/browse/MSUREFIRE-97?page=all ] Brett Porter closed MSUREFIRE-97: - Assign To: Brett Porter Resolution: Fixed TestNG tests are not executed if invoked by */*Test.java naming pattern --- Key: MSUREFIRE-97 URL: http://jira.codehaus.org/browse/MSUREFIRE-97 Project: Maven 2.x Surefire Plugin Type: Bug Environment: Windows XP, Maven 2.0.4, Surefire from snapshot server Reporter: Andreas Guther Assignee: Brett Porter Fix For: 2.2 Attachments: my-app-2.zip I created an example project and added two testng tests, one ending with *Test.java, one with a not Test containing name. Surefire seems to be able to find the test but does not execute the tests inside the class (one should succeed, one should fail). The console output is below. I will attach my example project in zip format to the issue report. C:\workspace\my-appmvn test [INFO] Scanning for projects... [INFO] [INFO] Building Maven Quick Start Archetype [INFO]task-segment: [test] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] Compiling 2 source files to C:\workspace\my-app\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports --- T E S T S --- Running com.mycompany.app.AppTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running com.mycompany.app.TestNgJavaOneTngTest Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue May 02 07:14:11 PDT 2006 [INFO] Final Memory: 4M/508M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSUREFIRE-98) JUnit Tests are not executed if TestNG configuration file is used to invoke TestNG tests
[ http://jira.codehaus.org/browse/MSUREFIRE-98?page=all ] Brett Porter closed MSUREFIRE-98: - Assign To: Brett Porter Resolution: Won't Fix Fix Version: (was: 2.2) it's by design. The documentation for suiteXmlFiles clearly says it will stop any other tests from being run. It is assumed that if you are running a suiteXml you want to be very specific about what tests are run, so none are added automatically. JUnit Tests are not executed if TestNG configuration file is used to invoke TestNG tests Key: MSUREFIRE-98 URL: http://jira.codehaus.org/browse/MSUREFIRE-98 Project: Maven 2.x Surefire Plugin Type: Bug Environment: Windows XP, Maven 2.0.4, Java 1.4, Surefire from Snapshot server Reporter: Andreas Guther Assignee: Brett Porter Attachments: my-app.zip I have JUnit tests and TestNG unit tests in the same project. If I use a TestNG XML configurartion file only the files (TestNG) listed in the configuration file are executed. JUnit test files are ignored. TestNG allows to include JUnit tests in the configuration, but I would expect that JUnit tests should be found based on the standard naming pattern and in addition TestNG classes as listed in the TestNG XML config file are executed as well. Expected that JUnit files are executed and in addition TestNG files. It should be possible to use different test frameworks in the same project. I will attach the example project. Output: C:\workspace\my-appmvn test [INFO] Scanning for projects... [INFO] [INFO] Building Are JUnit Tests Ignored if TestNG Config XML is used? [INFO]task-segment: [test] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports --- T E S T S --- Running Test with JavaDoc Annotations under Java 1.4 com.mycompany.app.JavaOneFourTngSample: beforeClass com.mycompany.app.JavaOneFourTngSample: beforeMethod com.mycompany.app.JavaOneFourTngSample: someTestMethod com.mycompany.app.JavaOneFourTngSample: beforeMethod Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec FAILURE! Results : Tests run: 2, Failures: 1, Errors: 0, Skipped: 0 [ERROR] There are test failures. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue May 02 09:38:59 PDT 2006 [INFO] Final Memory: 4M/508M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-105) Surefire plugin fails with certain dependencies in pom
[ http://jira.codehaus.org/browse/MSUREFIRE-105?page=comments#action_65177 ] Jason Chaffee commented on MSUREFIRE-105: - I have traced this issue to the following line of code in SurefireBooter: returnCode = CommandLineUtils.executeCommandLine( cli, out, err ); For whatever reason it is failing in the CommandLineUtils and it never calls the main method of the SurfireBooter, which is the cli command. Surefire plugin fails with certain dependencies in pom -- Key: MSUREFIRE-105 URL: http://jira.codehaus.org/browse/MSUREFIRE-105 Project: Maven 2.x Surefire Plugin Type: Bug Environment: This was tested with the trunk of surefire and maven-surefire-plugin Reporter: Jason Chaffee Priority: Blocker Fix For: 2.2 I added hibernate 3.0.1 to my pom and my tests that were working begin to fail. In fact, they weren't even being run anymore. I was using testng 4.7-jdk1.5. Here is the stacktrace: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\svn-trunk\tva\packager\impl\targe t\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 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
[jira] Commented: (MSUREFIRE-105) Surefire plugin fails with certain dependencies in pom
[ http://jira.codehaus.org/browse/MSUREFIRE-105?page=comments#action_65178 ] Brett Porter commented on MSUREFIRE-105: do you have a test project? Surefire plugin fails with certain dependencies in pom -- Key: MSUREFIRE-105 URL: http://jira.codehaus.org/browse/MSUREFIRE-105 Project: Maven 2.x Surefire Plugin Type: Bug Environment: This was tested with the trunk of surefire and maven-surefire-plugin Reporter: Jason Chaffee Priority: Blocker Fix For: 2.2 I added hibernate 3.0.1 to my pom and my tests that were working begin to fail. In fact, they weren't even being run anymore. I was using testng 4.7-jdk1.5. Here is the stacktrace: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\svn-trunk\tva\packager\impl\targe t\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 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
[jira] Closed: (MSUREFIRE-100) IllegalAccessError with a dynamic proxy
[ http://jira.codehaus.org/browse/MSUREFIRE-100?page=all ] Brett Porter closed MSUREFIRE-100: -- Assign To: Brett Porter Resolution: Fixed working now IllegalAccessError with a dynamic proxy --- Key: MSUREFIRE-100 URL: http://jira.codehaus.org/browse/MSUREFIRE-100 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Reporter: Carlos Sanchez Assignee: Brett Porter Fix For: 2.2 I found this regression in the code from the book, migration chapter, when using 2.2-SNAPSHOT instead of 2.1.3 --- Test set: org.springframework.aop.support.DelegatingIntroductionInterceptorTests --- Tests run: 10, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.141 sec FAILURE! testIntroductionInterceptorWithInterfaceHierarchy(org.springframework.aop.support.DelegatingIntroductionInterceptorTests) Time elapsed: 0 sec ERROR! java.lang.IllegalAccessError: class org.springframework.aop.support.$Proxy9 cannot access its superinterface org.springframework.aop.support.DelegatingIntroductionInterceptorTests$SubTimeStamped at java.lang.reflect.Proxy.defineClass0(Native Method) at java.lang.reflect.Proxy.getProxyClass(Unknown Source) at java.lang.reflect.Proxy.newProxyInstance(Unknown Source) at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(JdkDynamicAopProxy.java:104) at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(JdkDynamicAopProxy.java:94) at org.springframework.aop.framework.ProxyFactory.getProxy(ProxyFactory.java:70) at org.springframework.aop.support.DelegatingIntroductionInterceptorTests.testIntroductionInterceptorWithInterfaceHierarchy(DelegatingIntroductionInterceptorTests.java:88) -- 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: (MSUREFIRE-105) Surefire plugin fails with certain dependencies in pom
[ http://jira.codehaus.org/browse/MSUREFIRE-105?page=all ] Brett Porter updated MSUREFIRE-105: --- Fix Version: (was: 2.2) unscheduling for later investigation, however I haven't been able to reproduce this. Surefire plugin fails with certain dependencies in pom -- Key: MSUREFIRE-105 URL: http://jira.codehaus.org/browse/MSUREFIRE-105 Project: Maven 2.x Surefire Plugin Type: Bug Environment: This was tested with the trunk of surefire and maven-surefire-plugin Reporter: Jason Chaffee Priority: Blocker I added hibernate 3.0.1 to my pom and my tests that were working begin to fail. In fact, they weren't even being run anymore. I was using testng 4.7-jdk1.5. Here is the stacktrace: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\svn-trunk\tva\packager\impl\targe t\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 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
[jira] Commented: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_65181 ]
Fredrik Vraalsen commented on MANTRUN-37:
-
I'm also seeing this problem with maven 2.0.4 and antrun 1.1 in a multiproject
build. Environment is JDK 1.5.0_06, Windows XP.
The submodule build crashes with the same type of error message as in the
original bug description. The build works however if I explicitly specify
version 1.0 of the antrun in the plugin in the pom, as Mike Pernham pointed out
in one of his comments.
I've tried disabling various subprojects and plugins, and I've finally hit a
case where I can trigger the error by enabling a single plugin: The culprit
seems to be the xdoclet plugin from mojo.codehaus.org. When this is enabled in
one of the other subprojects, the antrun 1.1 plugin fails, otherwise it runs
fine.
I've created a testcase which can be checked out using
svn co
https://svn.sourceforge.net/svnroot/coras/coras/branches/maven2-antrun-testcase/src
The module with the antrun problem is in modules/coras-help. The module using
xdoclet is in modules/asset-repository-ejb. Sorry I haven't had a chance to
create an even smaller testcase, but I figured it would be worth getting this
out there. Don't know if the problem is with the antrun or the xdoclet plugin
though.
Antrun breaks on multi-module builds
Key: MANTRUN-37
URL: http://jira.codehaus.org/browse/MANTRUN-37
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.1
Environment: Maven 2.0.1
Reporter: Mike Perham
Assignee: Carlos Sanchez
Priority: Critical
I just updated to antrun v1.1 (which needs to be marked as released in jira
BTW) and find that my multimodule build is now breaking. Running the build
in the child module itself works fine but if I build the parent, it fails
when it gets to the child with the antrun task. Here's part of the debug
output. Note it says 1.1 in the dependency tree but 1.0 further down.
{noformat}
[DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
(selected for runtime)
[DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
runtime)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
runtime)
[DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
for runtime)
[DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
[DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
[DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
at
[jira] Created: (MANTRUN-51) Can't find plugin dependency in multiproject
Can't find plugin dependency in multiproject
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because it
cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is at
the bottom.
{{plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin}}
{{[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing ant
tasks
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:77)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
... 16 more
Caused by: taskdef class com.izforge.izpack.ant.IzPackTask cannot be found
at org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:483)
at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:183)
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:71)
... 19 more
Caused by:
[jira] Created: (MSUREFIRE-107) Running tests in JAR files
Running tests in JAR files -- Key: MSUREFIRE-107 URL: http://jira.codehaus.org/browse/MSUREFIRE-107 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Hugo Palma Priority: Minor AFAIK it's not possible to run tests that are in a dependency jar and not in the tested module source files. It would be great if this was possible. -- 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: (MSUREFIRE-99) TestNG tests that cause commons-logging to load fail
[ http://jira.codehaus.org/browse/MSUREFIRE-99?page=all ] Brett Porter closed MSUREFIRE-99: - Assign To: Brett Porter Resolution: Fixed a somewhat temporary fix is made by swapping the construction of the classloaders so the test classloader is before the surefire classloader. TestNG tests that cause commons-logging to load fail Key: MSUREFIRE-99 URL: http://jira.codehaus.org/browse/MSUREFIRE-99 Project: Maven 2.x Surefire Plugin Type: Bug Environment: (Using latest from SVN as of May 1) Reporter: Patrick Lightbody Assignee: Brett Porter Fix For: 2.2 Attachments: test.zip If a TestNG test uses commons-logging (either directly or a class that is tested does), this error is returned: == [INFO] Surefire report directory: /Users/plightbo/autoriginate/hostedqa/test/target/surefire-reports --- T E S T S --- [Utils] FAILED TO CREATE CLASS class com.acme.FooTest [INFO] [ERROR] BUILD ERROR [INFO] [INFO] java.lang.reflect.InvocationTargetException; nested exception is org.testng.TestNGException: java.lang.reflect.InvocationTargetException Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. == -- 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: (MANTRUN-51) Can't find plugin dependency in multiproject
[ http://jira.codehaus.org/browse/MANTRUN-51?page=all ]
Kenney Westerhof updated MANTRUN-51:
Description:
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because it
cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is at
the bottom.
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing ant
tasks
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:77)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
... 16 more
Caused by: taskdef class com.izforge.izpack.ant.IzPackTask cannot be found
at org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:483)
at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:183)
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:71)
... 19 more
Caused by: java.lang.ClassNotFoundException: com.izforge.izpack.ant.IzPackTask
at
org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1166)
at
[jira] Commented: (MANTRUN-49) taskdef/ seems ignoring classpath
[ http://jira.codehaus.org/browse/MANTRUN-49?page=comments#action_65189 ]
Kenney Westerhof commented on MANTRUN-49:
-
First, use the xdoclet-maven-plugin. It's an extension to the antrun plugin
that contains all
the needed xdoclet dependencies.
Second, you only need to put a path reference in a property to be able to print
it; using it in a refid= / classpathref attribute in
an ant task should work just fine, which it does, since the ejbdoclet is
recognized, just not the remoteinterface tag.
I've tried to reproduce this issue, but the first failure was that
xjavadoc/xjavadoc/.. couldn't be found.
The groupId for xjavadoc is xdoclet, so i replaced xjavadoc/xjavadoc by
xdoclet/xjavadoc and it worked fine.
I get the idea that your xdoclet jars are corrupt or of the wrong version. Can
you check that
{noformat}
unzip -l
~/.m2/repository/xdoclet/xdoclet-ejb-module/1.2.3/xdoclet-ejb-module-1.2.3.jar|grep
xdoclet.modules.ejb.intf.RemoteInterfaceSubTask
{noformat}
produces output?
taskdef/ seems ignoring classpath
---
Key: MANTRUN-49
URL: http://jira.codehaus.org/browse/MANTRUN-49
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.2
Environment: Fedora
Reporter: Jacek Gerbszt
Attachments: testcase.tar.gz
I'm trying to run xdoclet in ant build file called from antrun plugin. The
build file is very simple:
{code:xml}
project name=testcase default=run
property name=maven.repository value=set repository location
here!/
property name=destdir value=target/generated-sources/
path id=xdoclet.classpath
fileset dir=${maven.repository}
include
name=commons-collections/commons-collections/3.1/commons-collections-3.1.jar/
include
name=commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar/
include
name=jboss/jboss-j2ee/4.0.2/jboss-j2ee-4.0.2.jar/
include name=xjavadoc/xjavadoc/1.1/xjavadoc-1.1.jar/
include
name=xdoclet/xdoclet/1.2.3/xdoclet-1.2.3.jar/
include
name=xdoclet/xdoclet-ejb-module/1.2.3/xdoclet-ejb-module-1.2.3.jar/
/fileset
/path
target name=run
!-- print classplath --
property refid=xdoclet.classpath name=cp/
echo message=xdoclet.classpath: ${cp}/
!-- define ejbdoclet task --
taskdef classname=xdoclet.modules.ejb.EjbDocletTask
classpathref=xdoclet.classpath name=ejbdoclet/
!-- run ejbdoclet --
ejbdoclet destdir=${destdir}
fileset includes=**/*Bean.java
dir=${basedir}/src/main/java/
remoteinterface/
/ejbdoclet
/target
/project
{code}
When executed directly from command (ant
-Dmaven.repository=/home/javor/.m2/repository) it works fine. But fails when
embedded in antrun:
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.2-SNAPSHOT/version
executions
execution
phasegenerate-sources/phase
goals
goalrun/goal
/goals
configuration
tasks
ant inheritRefs=true inheritall=true
antfile=build.xml
property name=maven.repository
value=${settings.localRepository}/
/ant
/tasks
/configuration
/execution
/executions
/plugin
{code}
Maven output:
{noformat}
...
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
run:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: The following error occurred while executing this line:
/home/javor/workspace/testcase/build.xml:26: Can't create a remoteinterface
element under ejbdoclet. Make sure the jar file containing the corresponding
subtask class is on the classpath specified in the taskdef that defined {2}.
...
{noformat}
Could you show me any workaround or put a bit of light on that 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
[jira] Commented: (MPJNLP-28) Signing jars should remove old signatures
[ http://jira.codehaus.org/browse/MPJNLP-28?page=comments#action_65192 ] Geoffrey De Smet commented on MPJNLP-28: Acegi's jar are good test cases (they are signed by Ben Alex in ibiblio). When unsigning, don't forget to remove META-INF/xxx.SF and META-INF/xxx.RSA (case insensitive) An option unsignAnyAlreadySigned would be handy, not to have to note every jar to unsign. Signing jars should remove old signatures - Key: MPJNLP-28 URL: http://jira.codehaus.org/browse/MPJNLP-28 Project: maven-jnlp-plugin Type: Bug Versions: 1.4.1 Reporter: Geoffrey De Smet Using jdk webstart 1.5: When signing a dependend jar that is already signed (for example acegic-security-0.8.2.jar), the new jar has 2 .RSA and .SF files (but each class is only signed once). But webstart can't handle this (it should but it doesn't) and it says that not all jars are signed by the same certificate. -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_65193 ] Jacob Robertson commented on MNGECLIPSE-59: --- My company is evaluating using m2eclipse. Our culture is to check out multiple projects at once while developing, but reference others from the maven repository. We also have a team that is doing PDE development. So this particular issue is basically a deal breaker for us. +1 from us... Allow artifact resolution from workspace projects - Key: MNGECLIPSE-59 URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 Project: Maven 2.x Extension for Eclipse Type: New Feature Components: Dependency Resolver Versions: 0.0.4 Reporter: Leonardo Quijano Vincenzi Assignee: Eugene Kuleshov Fix For: 1.0.0 Attachments: ArtifactResolver-try3.patch, EclipseArtifactResolver-corrected.patch, EclipseArtifactResolver.patch, maven-embedder-2.1-SNAPSHOT-dep.jar Provide artifact resolution from workspace projects, which override the same artifact from the local or remote repositories. This would allow to work with dependant Eclipse projects without specifying the Eclipse dependency manually. The workspace artifact resolution would have to be specified manually, since several Maven-Enabled projects in the same workspace could have the same artifact and version Id. Or at least automatic resolution with an optional override would be nice. More comments here: http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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-391) missing pom for xerces 2.8.0
missing pom for xerces 2.8.0 Key: MEV-391 URL: http://jira.codehaus.org/browse/MEV-391 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Olivier Lamy Add the simple xercesImpl-2.8.0.pom in http://www.ibiblio.org/maven2/xerces/xercesImpl/2.8.0/ project modelVersion4.0.0/modelVersion groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.8.0/version /project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-105) Top Matter Lost in POM
Top Matter Lost in POM -- Key: MRELEASE-105 URL: http://jira.codehaus.org/browse/MRELEASE-105 Project: Maven 2.x Release Plugin Type: Bug Versions: 2.0-beta-4 Environment: Release plugin snapshot 20060509.101136-3, Subversion Reporter: Bob Allison Fix For: 2.0 I am losing the ?xml ... ? and comment at the top of the POM. After a great deal of trial and error, I determined that the problem seems to stem from having inherited/ in one of my plugin definitions. When the POM is transformed, it becomes inherited / (notice the extra space) and that simple change causes the top matter to be retained on future releases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-106) Remember the Dry Run Status
Remember the Dry Run Status --- Key: MRELEASE-106 URL: http://jira.codehaus.org/browse/MRELEASE-106 Project: Maven 2.x Release Plugin Type: Improvement Versions: 2.0-beta-4 Environment: Release plugin snapshot 20060509.101136-3, Subversion Reporter: Bob Allison Priority: Minor Fix For: 2.0 When doing a dry run of a release, make note of that in the release.properties file so that a reasonable failure can occur if the user tries to perform the release. Also, this flag might be used to allow a non-dry-run prepare to occur without needing to do a clean in between (maybe also not need to prompt but reuse the same answers as in the dry 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] Closed: (MNG-2212) Page Not Found for http://maven.apache.org/plugins/maven-surefire-report-plugin
[ http://jira.codehaus.org/browse/MNG-2212?page=all ] Alex Mayorga Adame closed MNG-2212: --- Resolution: Fixed Link is working at the moment. (May 11, 2006). Page Not Found for http://maven.apache.org/plugins/maven-surefire-report-plugin --- Key: MNG-2212 URL: http://jira.codehaus.org/browse/MNG-2212 Project: Maven 2 Type: Bug Components: Documentation: General Versions: documentation Reporter: Ian D. Stewart Assignee: Alex Mayorga Adame Priority: Minor Time Spent: 1 minute Remaining: 0 minutes The link to the maven-surefire-report-plugin documentation page (http://mojo.codehaus.org/surefire-report-maven-plugin) at http://maven.apache.org/plugins/index.html gets redirected to http://maven.apache.org/plugins/maven-surefire-report-plugin, which returns a Page Not Found error page. -- 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-105) Top Matter Lost in POM
[ http://jira.codehaus.org/browse/MRELEASE-105?page=all ] Brett Porter updated MRELEASE-105: -- Attachment: MRELEASE-105.diff Top Matter Lost in POM -- Key: MRELEASE-105 URL: http://jira.codehaus.org/browse/MRELEASE-105 Project: Maven 2.x Release Plugin Type: Bug Versions: 2.0-beta-4 Environment: Release plugin snapshot 20060509.101136-3, Subversion Reporter: Bob Allison Fix For: 2.0 Attachments: MRELEASE-105.diff, MRELEASE-105.pom I am losing the ?xml ... ? and comment at the top of the POM. After a great deal of trial and error, I determined that the problem seems to stem from having inherited/ in one of my plugin definitions. When the POM is transformed, it becomes inherited / (notice the extra space) and that simple change causes the top matter to be retained on future releases. -- 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: (MRELEASE-105) Top Matter Lost in POM
[ http://jira.codehaus.org/browse/MRELEASE-105?page=all ] Brett Porter closed MRELEASE-105: - Assign To: Brett Porter Resolution: Fixed Fix Version: (was: 2.0) 2.0-beta-4 not yet applied to svn Top Matter Lost in POM -- Key: MRELEASE-105 URL: http://jira.codehaus.org/browse/MRELEASE-105 Project: Maven 2.x Release Plugin Type: Bug Versions: 2.0-beta-4 Environment: Release plugin snapshot 20060509.101136-3, Subversion Reporter: Bob Allison Assignee: Brett Porter Fix For: 2.0-beta-4 Attachments: MRELEASE-105.diff, MRELEASE-105.pom I am losing the ?xml ... ? and comment at the top of the POM. After a great deal of trial and error, I determined that the problem seems to stem from having inherited/ in one of my plugin definitions. When the POM is transformed, it becomes inherited / (notice the extra space) and that simple change causes the top matter to be retained on future releases. -- 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-890) Please upload jaxen-1.1-beta-9
Please upload jaxen-1.1-beta-9 -- Key: MAVENUPLOAD-890 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-890 Project: maven-upload-requests Type: Task Reporter: Lukas Theussl -- 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: (MDEP-2) Sibling Dependency Not Included in copy-dependencies output during multi-project build
[ http://jira.codehaus.org/browse/MDEP-2?page=all ] Kenney Westerhof updated MDEP-2: Fix Version: (was: 1.0) 1.1 Sibling Dependency Not Included in copy-dependencies output during multi-project build -- Key: MDEP-2 URL: http://jira.codehaus.org/browse/MDEP-2 Project: Maven 2.x Dependency Plugin Type: Bug Reporter: Stephen Duncan Jr Assignee: Kenney Westerhof Fix For: 1.1 Attachments: dependency-test.zip Using the following structure dependency-test - module1 - module2 I have the dependency-maven-plugin:copy-dependencies goal attached the package phase of the module2 module. module2 has a dependency on module1. When I run mvn package from the module2 folder, it correctly includes the module1 jar in the target/dependency folder. When I run mvn package from the dependency-test folder, the module1 jar is not included in the impl/target/dependency folder. A simple example of the problem is attached. -- 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: (MDEP-1) multi-module builds don't unpack-dependencies with dependency-maven-plugin:1.0
[ http://jira.codehaus.org/browse/MDEP-1?page=all ]
Kenney Westerhof closed MDEP-1:
---
Resolution: Fixed
Fix Version: 1.1
multi-module builds don't unpack-dependencies with dependency-maven-plugin:1.0
--
Key: MDEP-1
URL: http://jira.codehaus.org/browse/MDEP-1
Project: Maven 2.x Dependency Plugin
Type: Bug
Environment: I'm running on Windows 2003 Server, but I don't think it's
specific to that.
Reporter: Dan Fabulich
Assignee: Brian Fox
Fix For: 1.1
Attachments: unpackbug.zip
There seems to be a bug in the dependency-maven-plugin that causes
multi-module (inheritance) Maven builds to break.
In the project I'm working on, I'm using unpack-dependencies to unpack the
dependencies into ${project.build.directory}/classes. This allows me to
re-bundle my dependency jars into a single jar, for easier distribution.
I've attached a zip file with an example project. In this project, there's a
top-level project called unpackbug and three sub-level projects, one,
two and three.
one -- two -- three
one provides One.java, and has no dependencies. two depends on one,
and uses dependency-maven-plugin to unpack dependencies, in order to
re-bundle one in two.jar. Furthermore, two depends on one at the
provided scope, in order to ensure that anyone who depends on two doesn't
get an extra copy of one; they should only get the copy of one bundled
with two.
three depends on two, but does *not* depend on one.
If you run mvn install from the top-level, the build will fail, because
three can't find One.java. If you check the repository, you'll find that
two-1.0-SNAPSHOT.jar does *not* have a copy of One.java in it.
But if you go down into two and run mvn install in there, you'll find
that two-1.0-SNAPSHOT.jar *does* have a copy of One.java in it. Now our
build of three will succeed. You can now go back up to the top and run
mvn install from the top and it will work.
I've watched this happen in a debugger... The problem here is that
MavenProject.getArtifacts() (for some reason) doesn't return any artifacts
for one when running in a multi-module build, but it does return artifacts
for one when running in a single-module build of two.
I haven't attached a JUnit test case, but I have attached an example test
project, which I hope counts as testcase included. :-)
--
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: (MSUREFIRE-105) Surefire plugin fails with certain dependencies in pom
[ http://jira.codehaus.org/browse/MSUREFIRE-105?page=comments#action_65203 ] Jason Chaffee commented on MSUREFIRE-105: - I will create a test project that I can upload within a couple of days. Also, I am now having this same problem with multiple projects. I think it is has something to do with transitive dependencies because when the same projects that were using artifacts built with maven 1 would build and the tests would run. Once I converted all projects to maven 2 the main projects, that included all other artifacts would no longer run tests. In my opinion, this is a severe bug as I have at least 5 projects that have this problem and unittests cannot be run, doesn't matter if they are junit or testng. This essentially renders maven 2 useless as a build mechanism if it can't run unittests. Surefire plugin fails with certain dependencies in pom -- Key: MSUREFIRE-105 URL: http://jira.codehaus.org/browse/MSUREFIRE-105 Project: Maven 2.x Surefire Plugin Type: Bug Environment: This was tested with the trunk of surefire and maven-surefire-plugin Reporter: Jason Chaffee Priority: Blocker I added hibernate 3.0.1 to my pom and my tests that were working begin to fail. In fact, they weren't even being run anymore. I was using testng 4.7-jdk1.5. Here is the stacktrace: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\svn-trunk\tva\packager\impl\targe t\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 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
[jira] Commented: (MDEP-2) Sibling Dependency Not Included in copy-dependencies output during multi-project build
[ http://jira.codehaus.org/browse/MDEP-2?page=comments#action_65204 ] Dan Tran commented on MDEP-2: - Kenney, i think you patch it to the wrong place. the plugin has been moved to maven-dependency-plugin at Apache Sibling Dependency Not Included in copy-dependencies output during multi-project build -- Key: MDEP-2 URL: http://jira.codehaus.org/browse/MDEP-2 Project: Maven 2.x Dependency Plugin Type: Bug Reporter: Stephen Duncan Jr Assignee: Kenney Westerhof Fix For: 1.1 Attachments: dependency-test.zip Using the following structure dependency-test - module1 - module2 I have the dependency-maven-plugin:copy-dependencies goal attached the package phase of the module2 module. module2 has a dependency on module1. When I run mvn package from the module2 folder, it correctly includes the module1 jar in the target/dependency folder. When I run mvn package from the dependency-test folder, the module1 jar is not included in the impl/target/dependency folder. A simple example of the problem is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-2) Sibling Dependency Not Included in copy-dependencies output during multi-project build
[ http://jira.codehaus.org/browse/MDEP-2?page=comments#action_65207 ] Kenney Westerhof commented on MDEP-2: - Hm, indeed, the maven repo has one too. It is NOT moved, it is copied! Where's my cluebat... :) Shall we delete the dependency from the mojo project? Sibling Dependency Not Included in copy-dependencies output during multi-project build -- Key: MDEP-2 URL: http://jira.codehaus.org/browse/MDEP-2 Project: Maven 2.x Dependency Plugin Type: Bug Reporter: Stephen Duncan Jr Assignee: Kenney Westerhof Fix For: 1.1 Attachments: dependency-test.zip Using the following structure dependency-test - module1 - module2 I have the dependency-maven-plugin:copy-dependencies goal attached the package phase of the module2 module. module2 has a dependency on module1. When I run mvn package from the module2 folder, it correctly includes the module1 jar in the target/dependency folder. When I run mvn package from the dependency-test folder, the module1 jar is not included in the impl/target/dependency folder. A simple example of the problem is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-98) Assembly groupVersionAlignment excludes affects all other groupVersionAlignment
[ http://jira.codehaus.org/browse/MASSEMBLY-98?page=all ]
Brett Porter closed MASSEMBLY-98:
-
Resolution: Fixed
Assembly groupVersionAlignment excludes affects all other
groupVersionAlignment
---
Key: MASSEMBLY-98
URL: http://jira.codehaus.org/browse/MASSEMBLY-98
Project: Maven 2.x Assembly Plugin
Type: Bug
Versions: 2.1
Reporter: Edwin Punzalan
Assignee: Edwin Punzalan
Fix For: 2.1
Attachments: MASSEMBLY-98-maven-assembly-plugin.patch
Setting this in your assembly xml:
{code}
repository
groupVersionAlignments
groupVersionAlignment
idgroup-a/id
version1.0/version
/groupVersionAlignment
groupVersionAlignment
idgroup-b/id
version2.0/version
excludes
excludeartifact-a/exclude
/excludes
/groupVersionAlignment
/groupVersionAlignments
/repository
{code}
what happens is that if there is an artifact with groupId=group-a and
artifactId=artifact-a, it gets excluded even though artifact-a is declared to
be excluded in group-b. What effectively happens is something like this:
{code}
repository
groupVersionAlignments
groupVersionAlignment
idgroup-a/id
version1.0/version
excludes
excludeartifact-a/exclude
/excludes
/groupVersionAlignment
groupVersionAlignment
idgroup-b/id
version2.0/version
excludes
excludeartifact-a/exclude
/excludes
/groupVersionAlignment
/groupVersionAlignments
/repository
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=comments#action_65208 ]
Kevin Sheehan commented on MNG-624:
---
...and another two cents...
It appears (from my tests) that the parent/parent element is absolutely the
first tag accted upon when encountered in the POM. That makes sense HOWEVER...
I would like to read / load / substitute variables in that section.
i.e.
mvn -Dapp.version=1.0-SNAPSHOT compile
with POM that contains
...
parent
artifactIdartifact-id/artifactId
groupIdgroup-id/groupId
version${app.version}/version
/parent
...
should be the same as
...
parent
artifactIdartifact-id/artifactId
groupIdgroup-id/groupId
version1.0-SNAPSHOT/version
/parent
...
but is not as the version${app.version}/version is LITERALLY substituted
rather than recognizing this as an instance of variable substitution.
Allowing variable substitution in the parent/parent section should provide
enough flexibility to successfully close this.
automatic parent versioning
---
Key: MNG-624
URL: http://jira.codehaus.org/browse/MNG-624
Project: Maven 2
Type: Improvement
Components: Inheritence and Interpolation
Reporter: Brett Porter
Assignee: Brett Porter
Priority: Blocker
Fix For: 2.1
Original Estimate: 4 hours
Remaining: 4 hours
(this may be bumped to 2.1 or even made WON't FIX as it is contentious - see
MNG-521)
currently, you have to specify the parent version when extending which makes
a project stand alone very easily, but has the drawback of being a
maintainance problem when you start development on a new version. Tools can
help, but it would be nice not to have to rely on them.
One alternative is to allow the parent version to be omitted, and when it is
it is assumed you want the latest. The parent is used from the reactor or the
universal source directory. IT may also be read from a LATEST in the
repository though this is contentious - it may be better to simply fail in
that environment and require builds be in a known checkout structure for
building individual projects.
This also introduces the need for tool support to populate the version on
release and deployment for reproducibility.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-2) Sibling Dependency Not Included in copy-dependencies output during multi-project build
[ http://jira.codehaus.org/browse/MDEP-2?page=comments#action_65209 ] Brian Fox commented on MDEP-2: -- The version in maven repo represents 2.x where I started a complete refactor. I left the source here in mojo for now since it is essentially the same as 1.0 that has been released. Sibling Dependency Not Included in copy-dependencies output during multi-project build -- Key: MDEP-2 URL: http://jira.codehaus.org/browse/MDEP-2 Project: Maven 2.x Dependency Plugin Type: Bug Reporter: Stephen Duncan Jr Assignee: Kenney Westerhof Fix For: 1.1 Attachments: dependency-test.zip Using the following structure dependency-test - module1 - module2 I have the dependency-maven-plugin:copy-dependencies goal attached the package phase of the module2 module. module2 has a dependency on module1. When I run mvn package from the module2 folder, it correctly includes the module1 jar in the target/dependency folder. When I run mvn package from the dependency-test folder, the module1 jar is not included in the impl/target/dependency folder. A simple example of the problem is attached. -- 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] Lukket: (MCOMPILER-31) forking to a custom compiler does not work
[ http://jira.codehaus.org/browse/MCOMPILER-31?page=all ] David J. M. Karlsen closed MCOMPILER-31: Resolution: Duplicate Duplicates MCOMPILER-22 forking to a custom compiler does not work -- Key: MCOMPILER-31 URL: http://jira.codehaus.org/browse/MCOMPILER-31 Project: Maven 2.x Compiler Plugin Type: Bug Versions: 2.0.1 Environment: winXP / Sun JDK java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode) Reporter: David J. M. Karlsen The following configuration will fail: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration forktrue/fork compiler-version1.3/compiler-version executableC:/temp/java/bin/javac.exe/executable target1.3/target /configuration /plugin like this: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure Failure executing javac, but could not parse the error: [INFO] [DEBUG] Trace org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 5) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more [INFO] [INFO] Total time: 2 minutes 13 seconds [INFO] Finished at: Fri Apr 07 14:02:37 CEST 2006 [INFO] Final Memory: 4M/8M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-47) add zip provider (source attahced)
[ http://jira.codehaus.org/browse/WAGON-47?page=comments#action_65213 ] John Didion commented on WAGON-47: -- Oops...I always forget to change the boilerplate. Hey, is there an apache code style scheme for IntelliJ? add zip provider (source attahced) -- Key: WAGON-47 URL: http://jira.codehaus.org/browse/WAGON-47 Project: wagon Type: New Feature Components: wagon-provider-api Reporter: John Didion Attachments: wagon-provider-api.diff, wagon-provider-zip.diff As part of our build process, we generate repository snapshots contained within a jar file. We have written an installer that is able to install certain types of artifacts from any repository including a repository snapshot jar. We needed to add a zip file provider to wagon so we could use maven's repository api. It'd be nice to have that provider as part of wagon proper. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-47) add zip provider (source attahced)
[ http://jira.codehaus.org/browse/WAGON-47?page=comments#action_65216 ] John Didion commented on WAGON-47: -- Never mind, I found the code style scheme. I've attached a new diff of the zip provider with apache boilerplate and correct code style. add zip provider (source attahced) -- Key: WAGON-47 URL: http://jira.codehaus.org/browse/WAGON-47 Project: wagon Type: New Feature Components: wagon-provider-api Reporter: John Didion Attachments: wagon-provider-api.diff, wagon-provider-zip.diff, wagon-provider-zip.diff As part of our build process, we generate repository snapshots contained within a jar file. We have written an installer that is able to install certain types of artifacts from any repository including a repository snapshot jar. We needed to add a zip file provider to wagon so we could use maven's repository api. It'd be nice to have that provider as part of wagon proper. -- 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-891) json-rpc 1.0
json-rpc 1.0 Key: MAVENUPLOAD-891 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-891 Project: maven-upload-requests Type: Task Reporter: fabrizio giustina -- 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-892) sources and javadoc pack
sources and javadoc pack Key: MAVENUPLOAD-892 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-892 Project: maven-upload-requests Type: Task Reporter: fabrizio giustina the following zip contains a few source and javadoc jars for projects actually available in the maven 2 repo. Files are store with the full m2 repository structure http://magnolia.sourceforge.net/bundles/sources-m2-repo.zip -- 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: (MCOMPILER-22) Compilation fails: The command line is too long.
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_65227 ] Carlos Sanchez commented on MCOMPILER-22: - Can you provide a new MNG-MCCOMPILER-22-maven-compiler-plugin.patch without all the formatting changes? it's impossible to know what are the real changes here and what is just formatting Compilation fails: The command line is too long. -- Key: MCOMPILER-22 URL: http://jira.codehaus.org/browse/MCOMPILER-22 Project: Maven 2.x Compiler Plugin Type: Bug Reporter: Matthew Beermann Assignee: Jason van Zyl Priority: Critical Fix For: 2.0.2 Attachments: MCOMPILER-22.patch, MNG-MCCOMPILER-22-maven-compiler-plugin.patch, MNG-MCCOMPILER-22-plexus-compilers.patch For one of my project, compilation fails with the message The command line is too long. As far as I can tell, it's listing each and every source file, one at a time, in the -sourcepath attribute. (?!?) Here's the log: [DEBUG] Source roots: [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src [DEBUG] Command line options: [DEBUG] -d C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes -classpath DEPENDENCIES SNIPPED HERE -sourcepath ENORMOUSLY LONG LIST OF SOURCE FILES HERE -g -nowarn -target 1.4 -source 1.4 Compiling 167 source files to C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure Failure executing javac, but could not parse the error: The command line is too long. [INFO] [DEBUG] Trace org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) 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: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) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) ... 16 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
[jira] Created: (MIDEA-54) Fixed range versions in dependencies corrupt the module file
Fixed range versions in dependencies corrupt the module file
Key: MIDEA-54
URL: http://jira.codehaus.org/browse/MIDEA-54
Project: Maven 2.x Idea Plugin
Type: Bug
Environment: maven 2.0.4, plugin snapshot built from svn
Reporter: Andrew Perepelytsya
I have the following config snippet declared in pom.xml:
{code}
dependency
groupIdxerces/groupId
artifactIdxercesImpl/artifactId
!--
Explicitly fixing on a dependency version (those square
brackets)
does not seem to work completely as expected at the
moment.
As a workaround, dependency excludes are sprinkled
throughout the project.
Keep an eye on:
http://jira.codehaus.org/browse/MNG-1577
--
version[2.8.0]/version
/dependency
{code}
Note those *square brackets*, this works ok with Maven letting it sort of fix
the 2.8.0 version. Now it seemed to be fine when I initially generated
idea:idea project (dependency was at 2.6.2 version then). Recently it has been
upgraded, and I went back to re-generate the core module via idea:module. The
error I got:
{panel}
[WARNING] An error occurred during dependency resolution of the following
artifact:
org.codehaus.mule:mule-core2.0-SNAPSHOT
Caused by: Missing:
--
1) xerces:xercesImpl:jar:[2.8.0]
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=xerces -DartifactId=xercesImpl \
-Dversion=[2.8.0] -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.codehaus.mule:mule-core:jar:2.0-SNAPSHOT
2) xerces:xercesImpl:jar:[2.8.0]
--
1 required artifact is missing.
{panel}
The generated iml file had *all libraries removed*.
--
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: (MIDEA-54) Fixed range versions in dependencies corrupt the module file
[ http://jira.codehaus.org/browse/MIDEA-54?page=comments#action_65235 ]
Andrew Perepelytsya commented on MIDEA-54:
--
If I temporarily modify pom to reference the version without [] it is ok again,
but I can't leave it like this in the project.
Fixed range versions in dependencies corrupt the module file
Key: MIDEA-54
URL: http://jira.codehaus.org/browse/MIDEA-54
Project: Maven 2.x Idea Plugin
Type: Bug
Environment: maven 2.0.4, plugin snapshot built from svn
Reporter: Andrew Perepelytsya
I have the following config snippet declared in pom.xml:
{code}
dependency
groupIdxerces/groupId
artifactIdxercesImpl/artifactId
!--
Explicitly fixing on a dependency version (those
square brackets)
does not seem to work completely as expected at the
moment.
As a workaround, dependency excludes are sprinkled
throughout the project.
Keep an eye on:
http://jira.codehaus.org/browse/MNG-1577
--
version[2.8.0]/version
/dependency
{code}
Note those *square brackets*, this works ok with Maven letting it sort of fix
the 2.8.0 version. Now it seemed to be fine when I initially generated
idea:idea project (dependency was at 2.6.2 version then). Recently it has
been upgraded, and I went back to re-generate the core module via
idea:module. The error I got:
{panel}
[WARNING] An error occurred during dependency resolution of the following
artifact:
org.codehaus.mule:mule-core2.0-SNAPSHOT
Caused by: Missing:
--
1) xerces:xercesImpl:jar:[2.8.0]
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=xerces -DartifactId=xercesImpl \
-Dversion=[2.8.0] -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.codehaus.mule:mule-core:jar:2.0-SNAPSHOT
2) xerces:xercesImpl:jar:[2.8.0]
--
1 required artifact is missing.
{panel}
The generated iml file had *all libraries removed*.
--
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-389) org.openwfe:openwfe 1.7.0 broken pom
[ http://jira.codehaus.org/browse/MEV-389?page=all ] Carlos Sanchez closed MEV-389: -- Resolution: Fixed I see it fixed org.openwfe:openwfe 1.7.0 broken pom Key: MEV-389 URL: http://jira.codehaus.org/browse/MEV-389 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: fabrizio giustina Assignee: Carlos Sanchez Attachments: openwfe-1.7.0.pom The recently uploaded org.openwfe:openwfe 1.7.0 has a bad pom, the developer/roles element contains text instead of role elements and maven can't parse it (and so all the openwfe artifacts that depends on this one have problems. -- 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: (MPSCM-78) [SVN] scm:tag goal doesn't allow you to attach a message with a tag
[SVN] scm:tag goal doesn't allow you to attach a message with a tag --- Key: MPSCM-78 URL: http://jira.codehaus.org/browse/MPSCM-78 Project: maven-scm-plugin Type: Improvement Reporter: Sharmarke Aden I'm using SVN and it would be nice if support for adding your own custom message to a tag instead of the default hard-coded [maven-scm] copy for tag [tag name]. I'm not sure if all the other SCM allow you to attache a message with a tag (I believe CVS doesn't) but adding support for this feature will require making a change to the tag(...) method in the ScmProvider interface and trickling that change down to all the SCM providers. If that won't work, perhaps we can set a system property called scm.message and check for that property in the SvnTagCommand class. -- 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-893) Java Bean Library
Java Bean Library - Key: MAVENUPLOAD-893 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-893 Project: maven-upload-requests Type: Task Reporter: Joe D. Velopar Attachments: beanlib-3.2.0.jar, beanlib-hibernate-3.2.0.jar Java Bean Library (beanlib) is a utilities library for use with JavaBean's. Java Bean Library for Hibernate (beanlib-hibernate) is particularly handy when used with Hibernate. It allows developers to easily reuse the same pojo classes for both persistence instances and data transfer objects. -- 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: (MPSCM-79) [scm:tag] Add Ability to Append Timestamp to Tag Name
[scm:tag] Add Ability to Append Timestamp to Tag Name - Key: MPSCM-79 URL: http://jira.codehaus.org/browse/MPSCM-79 Project: maven-scm-plugin Type: New Feature Reporter: Sharmarke Aden Attachments: timestamp.patch I have created a patch that, based on configuration properties, appends today's date/time to the tag name that I would like to share and see part of scm plug-in's future releases. This enhancement adds three new configuration properties. 1) A Boolean property called addTimestamp which indicates whether the plug-in should append timestamp to the tag name. 2) A string property called timestampFormat which contains date pattern akin to java.text.SimpleDateFormat class. If timestampFormat is not set and addTimestamp property is set to true the default date pattern of MMddHHmmss will be used. 3) A string property called timestampPrefix which will be used to separate the tag name and the timestamp. The default timestampPrefix value is - Here is what the plug-in definition should look like: plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-plugin/artifactId version1.0-beta-3/version executions execution phasedeploy/phase goals goaltag/goal /goals /execution /executions configuration tagBasehttp://my/svn/project/tags/tagBase tagmy-tag-name/tag addTimestamptrue/addTimestamp timestampFormatMMddHHmmss/timestampFormat timestampPrefix-tag-/timestampPrefix /configuration /plugin ... /plugins Note that both timestampFormat and timestampPrefix have default values and therefore are optional. -- 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-391) missing pom for xerces 2.8.0
[ http://jira.codehaus.org/browse/MEV-391?page=all ] Carlos Sanchez closed MEV-391: -- Assign To: Carlos Sanchez Resolution: Won't Fix We don't put empty poms in the repo, see required info at http://maven.apache.org/guides/mini/guide-ibiblio-upload.html missing pom for xerces 2.8.0 Key: MEV-391 URL: http://jira.codehaus.org/browse/MEV-391 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Olivier Lamy Assignee: Carlos Sanchez Add the simple xercesImpl-2.8.0.pom in http://www.ibiblio.org/maven2/xerces/xercesImpl/2.8.0/ project modelVersion4.0.0/modelVersion groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.8.0/version /project -- 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-891) json-rpc 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-891?page=all ] Carlos Sanchez closed MAVENUPLOAD-891: -- Assign To: Carlos Sanchez Resolution: Fixed json-rpc 1.0 Key: MAVENUPLOAD-891 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-891 Project: maven-upload-requests Type: Task Reporter: fabrizio giustina Assignee: Carlos Sanchez -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-892) sources and javadoc pack
[ http://jira.codehaus.org/browse/MAVENUPLOAD-892?page=all ] Carlos Sanchez closed MAVENUPLOAD-892: -- Assign To: Carlos Sanchez Resolution: Fixed Thanks Next time can you please provide also checksums? This should be easy for f in `find . -type f` ; do md5sum $f $f.md5; sha1sum $f $f.sha1; done sources and javadoc pack Key: MAVENUPLOAD-892 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-892 Project: maven-upload-requests Type: Task Reporter: fabrizio giustina Assignee: Carlos Sanchez the following zip contains a few source and javadoc jars for projects actually available in the maven 2 repo. Files are store with the full m2 repository structure http://magnolia.sourceforge.net/bundles/sources-m2-repo.zip -- 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-889) http://download.berlios.de/jsontools/jsontools-core-1.1-bundle.jar
[ http://jira.codehaus.org/browse/MAVENUPLOAD-889?page=all ] Carlos Sanchez closed MAVENUPLOAD-889: -- Assign To: Carlos Sanchez Resolution: Fixed http://download.berlios.de/jsontools/jsontools-core-1.1-bundle.jar -- Key: MAVENUPLOAD-889 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-889 Project: maven-upload-requests Type: Task Reporter: Bruno Ranschaert Assignee: Carlos Sanchez JSON (JavaScript Object Notation) is a file format to represent data. It is similar to XML but has different characteristics. It is suited to represent configuration information, implement communication protocols and so on. XML is more suited to represent annotated documents. JSON parsing is very fast, the parser can be kept lean and mean. It is easy for humans to read and write. Note: Domain com.sdicons (used in Java packages and maven libs) is owned by me. -- 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-882) Please upload jgrapht version 0.6.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-882?page=all ] Carlos Sanchez closed MAVENUPLOAD-882: -- Assign To: Carlos Sanchez Resolution: Fixed Please upload jgrapht version 0.6.0 --- Key: MAVENUPLOAD-882 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-882 Project: maven-upload-requests Type: Task Reporter: jan hrabowski Assignee: Carlos Sanchez Attachments: jgrapht-0.6.0.pom I have been authorized by John V Sichi (perfecthash) to create this upload request on behalf of the jgrapht project. Since I am not part of that project, I have not created a new POM but simply copied the version 0.5.3 POM and edited the version number information. -- 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: (MSUREFIRE-105) Surefire plugin fails with certain dependencies in pom
[ http://jira.codehaus.org/browse/MSUREFIRE-105?page=comments#action_65244 ] Jason Chaffee commented on MSUREFIRE-105: - I just tested this on Linux and on Windows and it works on Linux, but not on Windows. Therefore, I am almost positive it is due to the classpath generation on windows when multiple dependencies built with maven 2 are used because the transitive dependencies are added on. Also, the paths to the dependencies in mave2 is much longer now that full namespaces are being used (i.e, org/apache/maven/). So, I believe there is a bug with the plexus-utils commandlineutils on a windows platform when there is a really huge classpath. Surefire plugin fails with certain dependencies in pom -- Key: MSUREFIRE-105 URL: http://jira.codehaus.org/browse/MSUREFIRE-105 Project: Maven 2.x Surefire Plugin Type: Bug Environment: This was tested with the trunk of surefire and maven-surefire-plugin Reporter: Jason Chaffee Priority: Blocker I added hibernate 3.0.1 to my pom and my tests that were working begin to fail. In fact, they weren't even being run anymore. I was using testng 4.7-jdk1.5. Here is the stacktrace: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\svn-trunk\tva\packager\impl\targe t\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 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
[jira] Commented: (MSUREFIRE-105) Surefire plugin fails with certain dependencies in pom
[ http://jira.codehaus.org/browse/MSUREFIRE-105?page=comments#action_65245 ] Brett Porter commented on MSUREFIRE-105: this is probably a duplicate of MSUREFIRE-104 then. There is a patch attached to it you can try while we wait for SVN access to be restored. Surefire plugin fails with certain dependencies in pom -- Key: MSUREFIRE-105 URL: http://jira.codehaus.org/browse/MSUREFIRE-105 Project: Maven 2.x Surefire Plugin Type: Bug Environment: This was tested with the trunk of surefire and maven-surefire-plugin Reporter: Jason Chaffee Priority: Blocker I added hibernate 3.0.1 to my pom and my tests that were working begin to fail. In fact, they weren't even being run anymore. I was using testng 4.7-jdk1.5. Here is the stacktrace: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\svn-trunk\tva\packager\impl\targe t\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 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
[jira] Commented: (MSUREFIRE-105) Surefire plugin fails with certain dependencies in pom
[ http://jira.codehaus.org/browse/MSUREFIRE-105?page=comments#action_65247 ] Jason Chaffee commented on MSUREFIRE-105: - The patch fixed the issue, but it exposed another issue. Now, my tests are running but they are failing due to some xml parser issues which I believe is related to forking the tests. I tried to fork pertest but that didn't seem to solve the issue. Surefire plugin fails with certain dependencies in pom -- Key: MSUREFIRE-105 URL: http://jira.codehaus.org/browse/MSUREFIRE-105 Project: Maven 2.x Surefire Plugin Type: Bug Environment: This was tested with the trunk of surefire and maven-surefire-plugin Reporter: Jason Chaffee Priority: Blocker I added hibernate 3.0.1 to my pom and my tests that were working begin to fail. In fact, they weren't even being run anymore. I was using testng 4.7-jdk1.5. Here is the stacktrace: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\svn-trunk\tva\packager\impl\targe t\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 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
[jira] Commented: (MSUREFIRE-105) Surefire plugin fails with certain dependencies in pom
[ http://jira.codehaus.org/browse/MSUREFIRE-105?page=comments#action_65251 ] Carlos Sanchez commented on MSUREFIRE-105: -- Try the childDelegation option, http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html Surefire plugin fails with certain dependencies in pom -- Key: MSUREFIRE-105 URL: http://jira.codehaus.org/browse/MSUREFIRE-105 Project: Maven 2.x Surefire Plugin Type: Bug Environment: This was tested with the trunk of surefire and maven-surefire-plugin Reporter: Jason Chaffee Priority: Blocker I added hibernate 3.0.1 to my pom and my tests that were working begin to fail. In fact, they weren't even being run anymore. I was using testng 4.7-jdk1.5. Here is the stacktrace: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\svn-trunk\tva\packager\impl\targe t\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 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
[jira] Commented: (MAVENUPLOAD-890) Please upload jaxen-1.1-beta-9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-890?page=comments#action_65253 ] Carlos Sanchez commented on MAVENUPLOAD-890: FYI there were problems with the pom, contributor inside developers Please upload jaxen-1.1-beta-9 -- Key: MAVENUPLOAD-890 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-890 Project: maven-upload-requests Type: Task Reporter: Lukas Theussl Assignee: Carlos Sanchez -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-284) missing gnujaxp/gnujaxp/1.0.0
[ http://jira.codehaus.org/browse/MEV-284?page=comments#action_65254 ] Carlos Sanchez commented on MEV-284: Done, but next time you have to reopen the issue or we won't notice the new comments missing gnujaxp/gnujaxp/1.0.0 - Key: MEV-284 URL: http://jira.codehaus.org/browse/MEV-284 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Olivier Lamy Assignee: Edwin Punzalan The pom http://www.ibiblio.org/maven2/jfree/jcommon/1.0.0-rc1/jcommon-1.0.0-rc1.pom contains a dependency to dependency groupIdgnujaxp/groupId artifactIdgnujaxp/artifactId version1.0.0/version /dependency Where is it ? Thanks, - Olivier -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-198) [scm:tag] Add Ability to Append Timestamp to Tag Name
[ http://jira.codehaus.org/browse/SCM-198?page=all ] Lukas Theussl updated SCM-198: -- Component: maven-plugin [scm:tag] Add Ability to Append Timestamp to Tag Name - Key: SCM-198 URL: http://jira.codehaus.org/browse/SCM-198 Project: Maven SCM Type: New Feature Components: maven-plugin Reporter: Sharmarke Aden Attachments: timestamp.patch I have created a patch that, based on configuration properties, appends today's date/time to the tag name that I would like to share and see part of scm plug-in's future releases. This enhancement adds three new configuration properties. 1) A Boolean property called addTimestamp which indicates whether the plug-in should append timestamp to the tag name. 2) A string property called timestampFormat which contains date pattern akin to java.text.SimpleDateFormat class. If timestampFormat is not set and addTimestamp property is set to true the default date pattern of MMddHHmmss will be used. 3) A string property called timestampPrefix which will be used to separate the tag name and the timestamp. The default timestampPrefix value is - Here is what the plug-in definition should look like: plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-plugin/artifactId version1.0-beta-3/version executions execution phasedeploy/phase goals goaltag/goal /goals /execution /executions configuration tagBasehttp://my/svn/project/tags/tagBase tagmy-tag-name/tag addTimestamptrue/addTimestamp timestampFormatMMddHHmmss/timestampFormat timestampPrefix-tag-/timestampPrefix /configuration /plugin ... /plugins Note that both timestampFormat and timestampPrefix have default values and therefore are optional. -- 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-890) Please upload jaxen-1.1-beta-9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-890?page=comments#action_65255 ] Lukas Theussl commented on MAVENUPLOAD-890: --- Oops, sorry. I submitted a patch to jaxen to fix that but I must have created the upload bundle before that.Thanks! Please upload jaxen-1.1-beta-9 -- Key: MAVENUPLOAD-890 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-890 Project: maven-upload-requests Type: Task Reporter: Lukas Theussl Assignee: Carlos Sanchez -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-105) Surefire plugin fails with certain dependencies in pom
[ http://jira.codehaus.org/browse/MSUREFIRE-105?page=comments#action_65256 ] Jason Chaffee commented on MSUREFIRE-105: - Just tried it with no luck. I should add that these tests were working before applying the patch (on linux). Therefore, while this fixes the classpath issue, it has changed something to cause another issue. Let me explain what I am doing that is failing. In one project, I am creating a custom xsd and schema validation classes. In another project, I have the first project as a dependency and I have test that uses the javax.xml.validation package to validate a xml file that is import the schema from the first project. I will try to create a couple of simple test projects that reprduce the issue. I can either attach them to this bug or create a new bug...which is probably more appropriate. Surefire plugin fails with certain dependencies in pom -- Key: MSUREFIRE-105 URL: http://jira.codehaus.org/browse/MSUREFIRE-105 Project: Maven 2.x Surefire Plugin Type: Bug Environment: This was tested with the trunk of surefire and maven-surefire-plugin Reporter: Jason Chaffee Priority: Blocker I added hibernate 3.0.1 to my pom and my tests that were working begin to fail. In fact, they weren't even being run anymore. I was using testng 4.7-jdk1.5. Here is the stacktrace: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\svn-trunk\tva\packager\impl\targe t\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 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
