[jira] (MWAR-110) Dependencies with scope "provided" are incorrectly added to the WEB-INF/lib directory
[ https://jira.codehaus.org/browse/MWAR-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308502#comment-308502 ] Alex T commented on MWAR-110: - We're seeing this as well. Will try to reproduce. > Dependencies with scope "provided" are incorrectly added to the WEB-INF/lib > directory > - > > Key: MWAR-110 > URL: https://jira.codehaus.org/browse/MWAR-110 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.0.2 >Reporter: Manuel Santillán >Assignee: Stéphane Nicoll > > buildWebapp method in class AbstractWarMojo does the following: > ... > ScopeArtifactFilter filter = new ScopeArtifactFilter( Artifact.SCOPE_RUNTIME > ); > if ( !artifact.isOptional() && filter.include( artifact ) ) > ... > while it should do something like > ScopeArtifactFilter filter = new ScopeArtifactFilter( Artifact.SCOPE_PROVIDED > ); > if ( !artifact.isOptional() && filter.include( artifact ) ) > in order to be in-sync with the documentation. Probably both runtime and > provided dependencies should be excluded from the lib directory, so something > like > ScopeArtifactFilter runtimeFilter = new ScopeArtifactFilter( > Artifact.SCOPE_RUNTIME ); > ScopeArtifactFilter providedFilter = new ScopeArtifactFilter( > Artifact.SCOPE_PROVIDED ); > if ( !artifact.isOptional() && runtimeFilter.include( artifact ) > &&providedFilter.include(artifact) ) > would be more appropriate. > Sorry for not attaching a proper patch to the issue, but I'm afraid I don't > have svn access through my corporate firewall. However, it should be quite a > straightforward fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-133) Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
[ https://jira.codehaus.org/browse/MCOMPILER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308503#comment-308503 ] Mark Struberg commented on MCOMPILER-133: - agree, setting to wont-fix > Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed > after JavacCompiler is done with compilation. > --- > > Key: MCOMPILER-133 > URL: https://jira.codehaus.org/browse/MCOMPILER-133 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Windows 2003 Server >Reporter: kaniska >Priority: Blocker > Attachments: IsolatedClassLoader_Issue.docx > > > In Eclipse environment for a maven-based project, Auto-build fires > Maven-build which in turn executes CompilerMojo, finally creating an > IsolatedClassloader for each compile call ! > IsolatedClassLoader.addURL(URL) line: 42... > JavacCompiler.compile(CompilerConfiguration) line: 141 > CompilerMojo(AbstractCompilerMojo).execute() line: 493... > DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: > 105... > MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ... > MavenBuilder.build(int, Map, IProgressMonitor) line: 153 > AutoBuildJob.run(IProgressMonitor) line: 238 > So every single change in maven-v4 project creates a new IsolatedClassloader > which is fine. > But the problem is JavacCompiler is not closing the loader which holds huge > number of jars (url points to maven-repo) in its url classpath. > It should use ClassLoaderutil.releaseLoader(..) to unload the jars. > GC does not reclaim the isolatedclassloader instances (not sure why). > As a result, IsolatedClassloader instances consume retains the heap. > Eventually maven-application goes OutOfMemory ! > Attached is the heapdump analysis of isolatedclassloader that holds the > memory. > This is kind of blocking us from building largescale maven app which requires > good number of jars in development time for compiling the app source at > development time. > Please note that we face this issue at development time whenever developer > making changes in source code as explained in the code-flow above. > Please let us know if more information is required. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-133) Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
[ https://jira.codehaus.org/browse/MCOMPILER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MCOMPILER-133. --- Resolution: Won't Fix > Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed > after JavacCompiler is done with compilation. > --- > > Key: MCOMPILER-133 > URL: https://jira.codehaus.org/browse/MCOMPILER-133 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Windows 2003 Server >Reporter: kaniska >Priority: Blocker > Attachments: IsolatedClassLoader_Issue.docx > > > In Eclipse environment for a maven-based project, Auto-build fires > Maven-build which in turn executes CompilerMojo, finally creating an > IsolatedClassloader for each compile call ! > IsolatedClassLoader.addURL(URL) line: 42... > JavacCompiler.compile(CompilerConfiguration) line: 141 > CompilerMojo(AbstractCompilerMojo).execute() line: 493... > DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: > 105... > MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ... > MavenBuilder.build(int, Map, IProgressMonitor) line: 153 > AutoBuildJob.run(IProgressMonitor) line: 238 > So every single change in maven-v4 project creates a new IsolatedClassloader > which is fine. > But the problem is JavacCompiler is not closing the loader which holds huge > number of jars (url points to maven-repo) in its url classpath. > It should use ClassLoaderutil.releaseLoader(..) to unload the jars. > GC does not reclaim the isolatedclassloader instances (not sure why). > As a result, IsolatedClassloader instances consume retains the heap. > Eventually maven-application goes OutOfMemory ! > Attached is the heapdump analysis of isolatedclassloader that holds the > memory. > This is kind of blocking us from building largescale maven app which requires > good number of jars in development time for compiling the app source at > development time. > Please note that we face this issue at development time whenever developer > making changes in source code as explained in the code-flow above. > Please let us know if more information is required. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-834) Groups are ignored if test are executed in parallel mode
[
https://jira.codehaus.org/browse/SUREFIRE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Krautz updated SUREFIRE-834:
--
Attachment: surefire834_integrationtest.patch
integration test to verify wrong behaviour
> Groups are ignored if test are executed in parallel mode
>
>
> Key: SUREFIRE-834
> URL: https://jira.codehaus.org/browse/SUREFIRE-834
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.12
> Environment: Linux 3.0.0-15-generic #26-Ubuntu SMP x86_64 x86_64
> x86_64 GNU/Linux
> Junit 4.10
>Reporter: Mario Krautz
> Attachments: bugexample.zip, surefire834_integrationtest.patch,
> test-playground.tar.gz, test-playground.tar.gz
>
>
> Hi!
> We have a maven-project containing multiple modules. Our junit tests are
> annotated with categories (@Category annotation). If we start the test with:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> everything works as expected (only MyCategory-annotated tests are executed).
> But in parallel mode *all* tests are executed!
> I have attached an example project to demonstrate the bug.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> two test are executed.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory -Pparallel{code}
> four tests are executed.
> The parallel profile looks like this:
> {code}
>
> parallel
>
>
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 2.12
>
> methods
> 2
> false
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-243) add a way to calculate diffs of a directory at 2 different times
Mark Struberg created MSHARED-243: - Summary: add a way to calculate diffs of a directory at 2 different times Key: MSHARED-243 URL: https://jira.codehaus.org/browse/MSHARED-243 Project: Maven Shared Components Issue Type: New Feature Components: maven-shared-utils Reporter: Mark Struberg For implementing the incremental build it should be possible to detect which files got created by a certain mojo execution. An example would be the maven-compiler-plugin which currently doesn't remove class files for Java sources which got deleted. The idea is to introduce a helper which can capture a snapshot of a certain directory (e.g. target/classes), then you do the mojo work (javac invocation with all source files) and take a capture of that very directory again. The tool will allow you to take a 'diff' and store the names of all the added files to a file in target/... The next time you invoke a build you can delete all those created classes by this very mojo-execution and so you do not have any left-overs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-834) Groups are ignored if test are executed in parallel mode
[
https://jira.codehaus.org/browse/SUREFIRE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308508#comment-308508
]
Mario Krautz commented on SUREFIRE-834:
---
I've seen, that the bug is fixed within failsafe-2.13-SNAPSHOT - it can be
verified by the integration test I've added as patch.
> Groups are ignored if test are executed in parallel mode
>
>
> Key: SUREFIRE-834
> URL: https://jira.codehaus.org/browse/SUREFIRE-834
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.12
> Environment: Linux 3.0.0-15-generic #26-Ubuntu SMP x86_64 x86_64
> x86_64 GNU/Linux
> Junit 4.10
>Reporter: Mario Krautz
> Attachments: bugexample.zip, surefire834_integrationtest.patch,
> test-playground.tar.gz, test-playground.tar.gz
>
>
> Hi!
> We have a maven-project containing multiple modules. Our junit tests are
> annotated with categories (@Category annotation). If we start the test with:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> everything works as expected (only MyCategory-annotated tests are executed).
> But in parallel mode *all* tests are executed!
> I have attached an example project to demonstrate the bug.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> two test are executed.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory -Pparallel{code}
> four tests are executed.
> The parallel profile looks like this:
> {code}
>
> parallel
>
>
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 2.12
>
> methods
> 2
> false
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-834) Groups are ignored if test are executed in parallel mode
[
https://jira.codehaus.org/browse/SUREFIRE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Krautz closed SUREFIRE-834.
-
Resolution: Fixed
> Groups are ignored if test are executed in parallel mode
>
>
> Key: SUREFIRE-834
> URL: https://jira.codehaus.org/browse/SUREFIRE-834
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.12
> Environment: Linux 3.0.0-15-generic #26-Ubuntu SMP x86_64 x86_64
> x86_64 GNU/Linux
> Junit 4.10
>Reporter: Mario Krautz
> Attachments: bugexample.zip, surefire834_integrationtest.patch,
> test-playground.tar.gz, test-playground.tar.gz
>
>
> Hi!
> We have a maven-project containing multiple modules. Our junit tests are
> annotated with categories (@Category annotation). If we start the test with:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> everything works as expected (only MyCategory-annotated tests are executed).
> But in parallel mode *all* tests are executed!
> I have attached an example project to demonstrate the bug.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> two test are executed.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory -Pparallel{code}
> four tests are executed.
> The parallel profile looks like this:
> {code}
>
> parallel
>
>
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 2.12
>
> methods
> 2
> false
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-834) Groups are ignored if test are executed in parallel mode
[
https://jira.codehaus.org/browse/SUREFIRE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308520#comment-308520
]
Mario Krautz commented on SUREFIRE-834:
---
After retest I can announce, that it was already fixed with 2.12.1
> Groups are ignored if test are executed in parallel mode
>
>
> Key: SUREFIRE-834
> URL: https://jira.codehaus.org/browse/SUREFIRE-834
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.12
> Environment: Linux 3.0.0-15-generic #26-Ubuntu SMP x86_64 x86_64
> x86_64 GNU/Linux
> Junit 4.10
>Reporter: Mario Krautz
> Attachments: bugexample.zip, surefire834_integrationtest.patch,
> test-playground.tar.gz, test-playground.tar.gz
>
>
> Hi!
> We have a maven-project containing multiple modules. Our junit tests are
> annotated with categories (@Category annotation). If we start the test with:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> everything works as expected (only MyCategory-annotated tests are executed).
> But in parallel mode *all* tests are executed!
> I have attached an example project to demonstrate the bug.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> two test are executed.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory -Pparallel{code}
> four tests are executed.
> The parallel profile looks like this:
> {code}
>
> parallel
>
>
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 2.12
>
> methods
> 2
> false
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-149) skinnyWars and SNAPSHOT unique dependencies
[ https://jira.codehaus.org/browse/MEAR-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308524#comment-308524 ] Geert Schuring commented on MEAR-149: - I'm running into this problem, and I must say that I'm quite stunned that this kind of bug is still present in the 2.8 version of the maven ear plugin, especially when there's a path available that solves it. Could you (any committer) release 2.8.1 that includes this patch? > skinnyWars and SNAPSHOT unique dependencies > --- > > Key: MEAR-149 > URL: https://jira.codehaus.org/browse/MEAR-149 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.7 > Environment: All >Reporter: Seth Rife >Priority: Minor > Fix For: 2.8.1 > > Attachments: ear-snapshot-dependencies.txt > > > When trying to create skinnyWars, any SNAPSHOTS dependencies are not > extracted out of WARs that have SNAPSHOT dependencies with unique timestamps. > The AbstractFileNameMapping class uses the baseVersion to generate the > filename which doesn't take into account timestamp dependencies, therefore > the plugin is unable to delete any dependency in the libDir folder. Using the > Artifact.version property will produce the correct filename for deletion. > The really only affects DEV-produced artifacts where EARs are built for > deployment and testing. Additionally, bloated EARs can affect repository > managers where excessive disk space may not be available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-149) skinnyWars and SNAPSHOT unique dependencies
[ https://jira.codehaus.org/browse/MEAR-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308524#comment-308524 ] Geert Schuring edited comment on MEAR-149 at 9/14/12 8:53 AM: -- I'm running into this problem, and I must say that I'm quite stunned that this kind of bug is still present in the 2.8 version of the maven ear plugin, especially when there's a patch available that solves it. Could you (any committer) release 2.8.1 that includes this patch? was (Author: cathodion): I'm running into this problem, and I must say that I'm quite stunned that this kind of bug is still present in the 2.8 version of the maven ear plugin, especially when there's a path available that solves it. Could you (any committer) release 2.8.1 that includes this patch? > skinnyWars and SNAPSHOT unique dependencies > --- > > Key: MEAR-149 > URL: https://jira.codehaus.org/browse/MEAR-149 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.7 > Environment: All >Reporter: Seth Rife >Priority: Minor > Fix For: 2.8.1 > > Attachments: ear-snapshot-dependencies.txt > > > When trying to create skinnyWars, any SNAPSHOTS dependencies are not > extracted out of WARs that have SNAPSHOT dependencies with unique timestamps. > The AbstractFileNameMapping class uses the baseVersion to generate the > filename which doesn't take into account timestamp dependencies, therefore > the plugin is unable to delete any dependency in the libDir folder. Using the > Artifact.version property will produce the correct filename for deletion. > The really only affects DEV-produced artifacts where EARs are built for > deployment and testing. Additionally, bloated EARs can affect repository > managers where excessive disk space may not be available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-149) skinnyWars and SNAPSHOT unique dependencies
[ https://jira.codehaus.org/browse/MEAR-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308524#comment-308524 ] Geert Schuring edited comment on MEAR-149 at 9/14/12 9:15 AM: -- I'm running into this problem, and I must say that I'm quite stunned that this kind of bug is still present in the 2.8 version of the maven ear plugin, especially when there's a patch available that solves it. Could you (any committer) release 2.8.1 that includes this patch? Some detail about our situation: Because some jar is present twice in the ear file (once in ear file, and once in embedded war file), Weld throws an exception because it finds 2 candidates for 1 injection point and our ears cannot be deployed on our application server (Glassfish 3). was (Author: cathodion): I'm running into this problem, and I must say that I'm quite stunned that this kind of bug is still present in the 2.8 version of the maven ear plugin, especially when there's a patch available that solves it. Could you (any committer) release 2.8.1 that includes this patch? > skinnyWars and SNAPSHOT unique dependencies > --- > > Key: MEAR-149 > URL: https://jira.codehaus.org/browse/MEAR-149 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.7 > Environment: All >Reporter: Seth Rife >Priority: Minor > Fix For: 2.8.1 > > Attachments: ear-snapshot-dependencies.txt > > > When trying to create skinnyWars, any SNAPSHOTS dependencies are not > extracted out of WARs that have SNAPSHOT dependencies with unique timestamps. > The AbstractFileNameMapping class uses the baseVersion to generate the > filename which doesn't take into account timestamp dependencies, therefore > the plugin is unable to delete any dependency in the libDir folder. Using the > Artifact.version property will produce the correct filename for deletion. > The really only affects DEV-produced artifacts where EARs are built for > deployment and testing. Additionally, bloated EARs can affect repository > managers where excessive disk space may not be available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-181) NullPointerException on MacOS computer
Clebert Suconic created MCOMPILER-181: - Summary: NullPointerException on MacOS computer Key: MCOMPILER-181 URL: https://jira.codehaus.org/browse/MCOMPILER-181 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.5.1, 2.5 Environment: MacOS 10.8.1 and 10.7.x Macintosh-3:~ clebertsuconic$ mvn -version Apache Maven 3.0.4 (r1232337; 2012-01-17 02:44:56-0600) Maven home: /work/maven/apache-maven-3.0.4 Java version: 1.6.0_35, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x", version: "10.8.1", arch: "x86_64", family: "mac" Reporter: Clebert Suconic I'm facing a NullPointerException on my project (HornetQ/master) when we update the maven-compiler to 2.5.1 or 2.5. It all works fine with 2.3.2 and as soon as we update it we start having these NPEs. It's funny that's only happening on MacOS for us while all our Linux Envs are working fine. I'm not sure the root cause but it may be something that would eventually happen in other environments as well. Steps to reproduce it: I don't have an isolated issue, but you can reproduce on my project: On a MacOS: git clone git://github.com/hornetq/hornetq.git edit the maven-compiler version to 2.5.1 on the main pom and use mvn package [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.592s [INFO] Finished at: Fri Sep 14 09:22:23 CDT 2012 [INFO] Final Memory: 9M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project hornetq-commons: Compilation failure [ERROR] error: java.lang.NullPointerException [ERROR] -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project hornetq-commons: Compilation failure error: java.lang.NullPointerException at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure error: java.lang.NullPointerException at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:729) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more [ERROR] [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-834) Groups are ignored if test are executed in parallel mode
[
https://jira.codehaus.org/browse/SUREFIRE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-834:
Fix Version/s: 2.12.1
> Groups are ignored if test are executed in parallel mode
>
>
> Key: SUREFIRE-834
> URL: https://jira.codehaus.org/browse/SUREFIRE-834
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.12
> Environment: Linux 3.0.0-15-generic #26-Ubuntu SMP x86_64 x86_64
> x86_64 GNU/Linux
> Junit 4.10
>Reporter: Mario Krautz
> Fix For: 2.12.1
>
> Attachments: bugexample.zip, surefire834_integrationtest.patch,
> test-playground.tar.gz, test-playground.tar.gz
>
>
> Hi!
> We have a maven-project containing multiple modules. Our junit tests are
> annotated with categories (@Category annotation). If we start the test with:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> everything works as expected (only MyCategory-annotated tests are executed).
> But in parallel mode *all* tests are executed!
> I have attached an example project to demonstrate the bug.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> two test are executed.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory -Pparallel{code}
> four tests are executed.
> The parallel profile looks like this:
> {code}
>
> parallel
>
>
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 2.12
>
> methods
> 2
> false
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-908) Surefire fails with StackOverflowError when toolchains are present
[
https://jira.codehaus.org/browse/SUREFIRE-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-908:
Fix Version/s: 2.13
> Surefire fails with StackOverflowError when toolchains are present
> --
>
> Key: SUREFIRE-908
> URL: https://jira.codehaus.org/browse/SUREFIRE-908
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12.3
>Reporter: Sergei Ivanov
>Priority: Blocker
> Fix For: 2.13
>
>
> All our builds failed after an upgrade from 2.12.2 to 2.12.3 with the
> following stack trace. Looking at the trunk version of
> {{AbstractSurefireMojo.java}}, there's indeed an infinite recursion between
> the two methods. The recursion only happens when a toolchain is defined in
> the project.
> {noformat}
> [INFO] --- maven-surefire-plugin:2.12.3:test (default-test) @ config-server
> ---
> [INFO] Toolchain in surefire-plugin:
> JDK[/opt/app//tools/jdk/64/jdk1.6.0_15]
> java.lang.reflect.InvocationTargetException
> 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:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:287)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.StackOverflowError
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveForkMode(AbstractSurefireMojo.java:890)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.isForkModeNever(AbstractSurefireMojo.java:880)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveForkMode(AbstractSurefireMojo.java:892)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.isForkModeNever(AbstractSurefireMojo.java:880)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveForkMode(AbstractSurefireMojo.java:892)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.isForkModeNever(AbstractSurefireMojo.java:880)
> ...
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-911) Regression: Since Surefire version 2.12.x, hyphens are not allowed in Group Names.
[ https://jira.codehaus.org/browse/SUREFIRE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-911: Fix Version/s: 2.13 > Regression: Since Surefire version 2.12.x, hyphens are not allowed in Group > Names. > -- > > Key: SUREFIRE-911 > URL: https://jira.codehaus.org/browse/SUREFIRE-911 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12.2 > Environment: Windows. >Reporter: Dameon Hunt > Fix For: 2.13 > > > We use TestNG groups for our tests and our group names for various classes > have a hyphen in them (e.g. "TEST-FRONTEND"). When we tried to move from > surefire version 2.11 to 2.12, it fails with the below error: > To reproduce, just execute a test case assigned to a testng group with a > hyphen in it. > ### > [INFO] --- maven-surefire-plugin:2.12.3:test (default-test) @ RRTests --- > [INFO] Surefire report directory: > C:\dev\eclipse\workspace\CyberSource_RR_Current_Lane-Hotness\ > AV2\RRTests\target\surefire-reports > --- > T E S T S > --- > Running TestSuite > org.apache.maven.surefire.util.SurefireReflectionException: > java.lang.reflect.InvocationTargetE > xception; nested exception is java.lang.reflect.InvocationTargetException: > null > java.lang.reflect.InvocationTargetException > 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:597) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils > .java:189) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactor > y.java:165) > at > org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java > :85) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:1 > 15) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) > Caused by: org.apache.maven.surefire.testset.TestSetFailedException: null; > nested exception is > java.lang.reflect.InvocationTargetException: null > at > org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.ja > va:165) > at > org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:66) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirecto > ryTestSuite.java:159) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTes > tSuite.java:99) > at > org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106) > ... 9 more > Caused by: java.lang.reflect.InvocationTargetException > 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:597) > at > org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.ja > va:141) > ... 13 more > Caused by: org.apache.maven.surefire.group.parse.TokenMgrError: Lexical error > at line 1, column > 3. Encountered: "-" (45), after : "" > at > org.apache.maven.surefire.group.parse.GroupMatcherParserTokenManager.getNextToken(Gr > oupMatcherParserTokenManager.java:468) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_scan_token(GroupMatcherP > arser.java:527) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_7(GroupMatcherParser.j > ava:274) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_3(GroupMatcherParser. > java:287) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_3(GroupMatcherParser.j > ava:279) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_1(GroupMatcherParser. > java:320) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_1(GroupMatcherParser.j > ava:335) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_2_1(GroupMatcherParser.j > ava:179) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.expr(GroupMatcherParser.jav > a:63) > at > org.a
[jira] (SUREFIRE-909) Wrong elapsed time calculation
[ https://jira.codehaus.org/browse/SUREFIRE-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-909: Fix Version/s: 2.13 > Wrong elapsed time calculation > --- > > Key: SUREFIRE-909 > URL: https://jira.codehaus.org/browse/SUREFIRE-909 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.3 > Environment: linux, likely others >Reporter: nkeywal > Fix For: 2.13 > > > It's a regression in 2.12.3 vs. the previous versions. > See "Time elapsed: 251992 sec" > 2.12.3 > Running my.Test > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 252.358 sec > <<< FAILURE! > test(my.Test) Time elapsed: 251992 sec <<< FAILURE! > java.lang.AssertionError: expected array was null > 2.10 or 2.11 or 2.12.1 or 2.12.2 > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 252.444 sec > <<< FAILURE! > test(my.Test) Time elapsed: 252.194 sec <<< FAILURE! > java.lang.AssertionError: expected array was null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-910) Surefire 2.12.1 fails with "The forked VM terminated without saying properly goodbye"
[
https://jira.codehaus.org/browse/SUREFIRE-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308530#comment-308530
]
Kristian Rosenvold commented on SUREFIRE-910:
-
Can you see anything in the logs/console logs ?
> Surefire 2.12.1 fails with "The forked VM terminated without saying properly
> goodbye"
> -
>
> Key: SUREFIRE-910
> URL: https://jira.codehaus.org/browse/SUREFIRE-910
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: Ilya Katsov
>
> Build fails with "The forked VM terminated without saying properly goodbye"
> message with no information about the source of the problem:
> {code}
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.125 sec
> Running org.apache.hadoop.fs.viewfs.TestViewFsHdfs
> Tests run: 42, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 14.149 sec
> Running org.apache.hadoop.fs.TestFcHdfsSymlink
> Tests run: 67, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 20.792 sec
> Results :
> Tests run: 1033, Failures: 0, Errors: 0, Skipped: 1
> [INFO]
>
> [INFO]
>
> [INFO] Skipping Apache Hadoop HDFS Project
> [INFO] This project has been banned from the build due to previous failures.
> [INFO]
>
> [INFO]
>
> [INFO]
>
> [INFO] Skipping Apache Hadoop HDFS
> [INFO] This project has been banned from the build due to previous failures.
> [INFO]
>
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Hadoop HDFS FAILURE
> [1:06:10.415s]
> [INFO] Apache Hadoop HttpFS .. SKIPPED
> [INFO] Apache Hadoop HDFS Project SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1:06:11.188s
> [INFO] Finished at: Wed Sep 05 12:01:46 MSK 2012
> [INFO] Final Memory: 24M/394M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.1:test (default-test) on
> project hadoop-hdfs: ExecutionException; nested exception is
> java.util.concurrent.ExecutionException: java.lang.RuntimeException: The
> forked VM terminated without saying properly goodbye. VM crash or System.exit
> called ? -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.12.1:test
> (default-test) on project hadoop-hdfs: ExecutionException; nested exception
> is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The
> forked VM terminated without saying properly goodbye. VM crash or System.exit
> called ?
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 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:597)
> at
> org.codehaus.plexus.classworl
[jira] (SUREFIRE-863) NPE in ConcurrentReporterManager
[ https://jira.codehaus.org/browse/SUREFIRE-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-863: Fix Version/s: 2.13 > NPE in ConcurrentReporterManager > > > Key: SUREFIRE-863 > URL: https://jira.codehaus.org/browse/SUREFIRE-863 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12 >Reporter: Mark Struberg > Fix For: 2.13 > > Attachments: SUREFIRE-863.patch > > > I have a wird NPE in surefire with one of my projects: > Caused by: java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getTestSet(ConcurrentReporterManager.java:157) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getOrCreateTestMethod(ConcurrentReporterManager.java:127) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.testError(ConcurrentReporterManager.java:83) > at > org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:110) > at > org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-911) Regression: Since Surefire version 2.12.x, hyphens are not allowed in Group Names.
[ https://jira.codehaus.org/browse/SUREFIRE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-911. --- Resolution: Duplicate Duplicates SUREFIRE-831 > Regression: Since Surefire version 2.12.x, hyphens are not allowed in Group > Names. > -- > > Key: SUREFIRE-911 > URL: https://jira.codehaus.org/browse/SUREFIRE-911 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12.2 > Environment: Windows. >Reporter: Dameon Hunt > Fix For: 2.13 > > > We use TestNG groups for our tests and our group names for various classes > have a hyphen in them (e.g. "TEST-FRONTEND"). When we tried to move from > surefire version 2.11 to 2.12, it fails with the below error: > To reproduce, just execute a test case assigned to a testng group with a > hyphen in it. > ### > [INFO] --- maven-surefire-plugin:2.12.3:test (default-test) @ RRTests --- > [INFO] Surefire report directory: > C:\dev\eclipse\workspace\CyberSource_RR_Current_Lane-Hotness\ > AV2\RRTests\target\surefire-reports > --- > T E S T S > --- > Running TestSuite > org.apache.maven.surefire.util.SurefireReflectionException: > java.lang.reflect.InvocationTargetE > xception; nested exception is java.lang.reflect.InvocationTargetException: > null > java.lang.reflect.InvocationTargetException > 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:597) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils > .java:189) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactor > y.java:165) > at > org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java > :85) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:1 > 15) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) > Caused by: org.apache.maven.surefire.testset.TestSetFailedException: null; > nested exception is > java.lang.reflect.InvocationTargetException: null > at > org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.ja > va:165) > at > org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:66) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirecto > ryTestSuite.java:159) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTes > tSuite.java:99) > at > org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106) > ... 9 more > Caused by: java.lang.reflect.InvocationTargetException > 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:597) > at > org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.ja > va:141) > ... 13 more > Caused by: org.apache.maven.surefire.group.parse.TokenMgrError: Lexical error > at line 1, column > 3. Encountered: "-" (45), after : "" > at > org.apache.maven.surefire.group.parse.GroupMatcherParserTokenManager.getNextToken(Gr > oupMatcherParserTokenManager.java:468) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_scan_token(GroupMatcherP > arser.java:527) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_7(GroupMatcherParser.j > ava:274) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_3(GroupMatcherParser. > java:287) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_3(GroupMatcherParser.j > ava:279) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_1(GroupMatcherParser. > java:320) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_1(GroupMatcherParser.j > ava:335) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_2_1(GroupMatcherParser.j > ava:179) > at > org.apache.maven.surefire.group.parse.GroupMatcherParser.expr(GroupMatcherPar
[jira] (SUREFIRE-831) Lexical error in surefire-plugin (TestNGExecutor.applyGroupMatching()) if the groupName of an excludedGroup contains a '-' sign
[
https://jira.codehaus.org/browse/SUREFIRE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-831:
Fix Version/s: 2.13
> Lexical error in surefire-plugin (TestNGExecutor.applyGroupMatching()) if the
> groupName of an excludedGroup contains a '-' sign
> ---
>
> Key: SUREFIRE-831
> URL: https://jira.codehaus.org/browse/SUREFIRE-831
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.11, 2.12
> Environment: Tested with maven-surefire-plugin-2.13-20120207.212404-8
>Reporter: Andreas Kuhtz
> Fix For: 2.13
>
>
> This occurs even with the current SNAPSHOT release. The issue might be
> related to SUREFIRE-828.
> {code:title=pom.xml}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> ui-test
>
>
> {code}
> {code}
> Running TestSuite
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exceptio
> n is java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> 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:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: org.apache.maven.surefire.testset.TestSetFailedException: null;
> nested exception is java.lang.reflect.Invocat
> ionTargetException: null
> at
> org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:164)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:65)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:161)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:101)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:115)
> ... 9 more
> Caused by: java.lang.reflect.InvocationTargetException
> 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:597)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:140)
> ... 13 more
> Caused by: org.apache.maven.surefire.group.parse.TokenMgrError: Lexical error
> at line 1, column 3. Encountered: "-" (45
> ), after : ""
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParserTokenManager.getNextToken(GroupMatcherParserTokenMana
> ger.java:468)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_scan_token(GroupMatcherParser.java:527)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_7(GroupMatcherParser.java:274)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_3(GroupMatcherParser.java:287)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_3(GroupMatcherParser.java:279)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_1(GroupMatcherParser.java:320)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_1(GroupMatcherParser.java:335)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_2_1(GroupMatcherParser.java:179)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.expr(GroupMatcherParser.java:63)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.parse(GroupMatcherParser.java:56)
> at
> org.apache.maven.surefire.testng.utils.GroupMatcherMethodSelector.setGroups(GroupMatcherMethodSelector.java:7
> 6)
> ... 18 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIR
[jira] (SUREFIRE-841) Incorrect Test Run Count
[ https://jira.codehaus.org/browse/SUREFIRE-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-841: Fix Version/s: 2.13 > Incorrect Test Run Count > > > Key: SUREFIRE-841 > URL: https://jira.codehaus.org/browse/SUREFIRE-841 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Reporter: karthik kandasamy > Fix For: 2.13 > > > When a simple Junit test with errors in the @Before() and @After() method are > run directly with java or ant's junit task, it reports correctly that the > Tests Run = 1 and Errors = 2. > But when the same is run through maven surefire plugin, it reports it as > Tests Run = 2 and Errors = 2. > Its the same test in which 2 errors are encountered, so the Tests Run should > be 1. > I traced the issue to the org.apache.maven.surefire.report.TestSetRunListener > Class - testError() method, where the completed count is also incremented > along with the error count irrespective of whether its in the same test the > error is encountered. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-343) add symbolic links managment
[ https://jira.codehaus.org/browse/MASSEMBLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308537#comment-308537 ] Ahmed El-Madhoun commented on MASSEMBLY-343: Hi Zuhayr, Thanks for the response. I am trying out this patch and I am just having little trouble applying the patches. From what you have told me, I am using the following maven plugin and plexus components: maven-assembly-plugin 2.2.1 plexus-archiver 1.1 plexus-io 1.0.1 I do get some failures applying the patch, I did not look further into it, but I will later tonight. I just want to check that I am using the right versions. Thanks again and great work so far, any reason why this is not yet officially incorporated? > add symbolic links managment > > > Key: MASSEMBLY-343 > URL: https://jira.codehaus.org/browse/MASSEMBLY-343 > Project: Maven 2.x Assembly Plugin > Issue Type: Wish >Affects Versions: 2.2-beta-2 > Environment: linux, ubuntu >Reporter: Godet Gilles > Attachments: MASSEMBLY-343_maven-assembly-plugin.patch > > > i need to buid archives ( tar for example ) with symbolic links > the plugin build an archive with a file containing the destination of the > link, not the link itself > => the plugin need an option to know if deferencement of links is needed > this is just like -h option of tar > -h, --dereference > don't dump symlinks; dump the files they point to > actually, if you do an archive of /lib, for example, many file will be in > double with différent names. extract of archive will not be the exactly the > same as the source of the archive. => this is a test ! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-351) Javadoc:fix fixTags parameter doesn't support 'return' value
Lars van der Vliet created MJAVADOC-351:
---
Summary: Javadoc:fix fixTags parameter doesn't support 'return'
value
Key: MJAVADOC-351
URL: https://jira.codehaus.org/browse/MJAVADOC-351
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.8.1, 2.8, 2.7
Reporter: Lars van der Vliet
Attachments: fixTags.patch
Javadoc:fix fixTags parameter doesn't support 'return' value
According to the docs
(http://maven.apache.org/plugins/maven-javadoc-plugin/fix-mojo.html#fixTags)
the fixTags parameter should be able to handle the following values:
# all (fix all Javadoc tags)
# author (fix only @author tag)
# version (fix only @version tag)
# since (fix only @since tag)
# param (fix only @param tag)
# return (fix only @return tag)
# throws (fix only @throws tag)
# link (fix only @link tag)
When Calling javadoc:fix version 2.8 or 2.7 with -DfixTags=return gives the
following error:
{code}
Unrecognized 'return' for fixTags parameter. Ignored it!
{code}
Using 2.6 this works just fine. When looking at the following diff:
{code}
---
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
2011/04/25 13:38:09 1096478
+++
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
2011/04/30 18:59:02 1098139
@@ -491,10 +491,8 @@
for ( int j = 0; j < split.length; j++ )
{
String s = split[j].trim();
-if ( FIX_TAGS_ALL.equalsIgnoreCase( s.trim() ) ||
AUTHOR_TAG.equalsIgnoreCase( s.trim() )
-|| VERSION_TAG.equalsIgnoreCase( s.trim() ) ||
SINCE_TAG.equalsIgnoreCase( s.trim() )
-|| PARAM_TAG.equalsIgnoreCase( s.trim() ) ||
RETURN_TAG.equalsIgnoreCase( s.trim() )
-|| THROWS_TAG.equalsIgnoreCase( s.trim() ) )
+if ( JavadocUtil.equalsIgnoreCase( s, FIX_TAGS_ALL,
AUTHOR_TAG, VERSION_TAG, SINCE_TAG, PARAM_TAG,
+ THROWS_TAG ) )
{
filtered.add( s );
}
{code}
the functionality seems to be broken since revision 1098139. I added a patch
which restores the functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-32) Add javadoc links to dependencies in project.xml
[
https://jira.codehaus.org/browse/MJAVADOC-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MJAVADOC-32.
Resolution: Won't Fix
Assignee: Benson Margulies
Since Maven no longer even has project.xml, I don't think we need this JIRA.
> Add javadoc links to dependencies in project.xml
>
>
> Key: MJAVADOC-32
> URL: https://jira.codehaus.org/browse/MJAVADOC-32
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
>Reporter: Brett Porter
>Assignee: Benson Margulies
>
> (originally filed by Tim McCune)
> It would be nice to be able to specify the URLs that are currently in
> maven.javadoc.links in project.properties in my project.xml. For example:
> {code:xml}
> junit
> junit
> 3.8
> http://junit.sourceforge.net/javadoc
> {code}
> It would also be nice to be able to specify a JDK version in project.xml and
> have Maven automatically link in the javadoc API for that version of the JDK.
> Specifying the JDK version in project.xml would also allow Maven to make
> intelligent assumptions about stuff like maven.compile.source,
> maven.compile.target, maven.javadoc.source, maven.test.source, etc. It's
> really annoying to have to specify at least 4 separate properties in
> project.properties for every project just because I'm using JDK 1.5.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-249) javadoc:fix should wrap existing comments in
[
https://jira.codehaus.org/browse/MJAVADOC-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MJAVADOC-249.
-
Resolution: Fixed
> javadoc:fix should wrap existing comments in
>
>
> Key: MJAVADOC-249
> URL: https://jira.codehaus.org/browse/MJAVADOC-249
> Project: Maven 2.x Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.6
>Reporter: jieryn
>Priority: Minor
>
> When I run the javadoc:fix mojo, freshly generated comments are wrapped
> inside tags. However, comments which existed prior to the run are
> not wrapped in such tags, even when they do not exist. This mojo does more
> than just add missing javadoc comments, but also tries to fix them up (for
> example, /**\n* {@inheritDoc}\n*/ gets transformed to /** {@inheritDoc} */
> ... which sets the precedent that the mojo is at least open to the idea of
> fixing existing comments.
> Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-205) Review output directory for Javadoc reports (main and test) and jar (main and test)
[ https://jira.codehaus.org/browse/MJAVADOC-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308546#comment-308546 ] Benson Margulies commented on MJAVADOC-205: --- VIncent, is there work to do here? > Review output directory for Javadoc reports (main and test) and jar (main and > test) > --- > > Key: MJAVADOC-205 > URL: https://jira.codehaus.org/browse/MJAVADOC-205 > Project: Maven 2.x Javadoc Plugin > Issue Type: Task >Affects Versions: 2.4 >Reporter: Vincent Siveton > > Actually, plugin report used: > * ouputDirectory > * reportOutputDirectory > * destDir in JavadocReport and TestJavadocReport > The configuration is not easy to change ouput directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-263) No respect for JAVA_HOME or PATH in locating javadoc executable
[ https://jira.codehaus.org/browse/MJAVADOC-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MJAVADOC-263. - Resolution: Incomplete Assignee: Benson Margulies The workaround is sufficient. > No respect for JAVA_HOME or PATH in locating javadoc executable > --- > > Key: MJAVADOC-263 > URL: https://jira.codehaus.org/browse/MJAVADOC-263 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Benson Margulies >Assignee: Benson Margulies > > I have code that runs into a java 1.6 bug in javadoc, so I'm trying to be > sure to use the 1.5 version of javadoc. > In my .mavenrc, I set JAVA_HOME to point to 1.5. I set PATH to find a 1.5 > version of javadoc. I set my PATH in my shell to find the 1.5 version of > Javadoc. Still, somehow, the maven-javadoc-plugin finds and runs the 1.6.0 > version. > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/javadoc > @options @packages > I cannot embed a shared pathname in the POM which won't work on other > people's machines. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-274) Regression in 2.6.1 - modules with no sources cause an error
[ https://jira.codehaus.org/browse/MJAVADOC-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308548#comment-308548 ] Benson Margulies commented on MJAVADOC-274: --- Since the javadoc tool itself does not like this situation, why is it up to us to work around? I propose to close this based on Hervé's observation. > Regression in 2.6.1 - modules with no sources cause an error > > > Key: MJAVADOC-274 > URL: https://jira.codehaus.org/browse/MJAVADOC-274 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6.1 >Reporter: Andrey Razumovsky >Assignee: John Casey > Attachments: MJAVADOC-274.zip > > > After upgrading from 2.6 to 2.6.1 our Apache Cayenne builds got broken. The > problem is in module with no public or protected sources (there's only a > package-private class). Now, after infamous message > "'org.apache.maven.plugins:maven-javadoc-plugin:2.6:javadoc' has not be > previously called for the project ..." build fails and creates an error > report. In the report: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation: > Exit code: 1 - javadoc: error - No public or protected classes found to > document. > Command line was: C:\Progra~1\Java\jdk1.6.0_13\jre\..\bin\javadoc.exe > @options @packages > Refer to the generated Javadoc files in > 'C:\Project\cayenne-parent\framework\cayenne-jdk1.6-unpublished\target\site\apidocs' > dir. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-278) Plugin does not include javadocDirectory correctly
[
https://jira.codehaus.org/browse/MJAVADOC-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MJAVADOC-278.
-
Resolution: Cannot Reproduce
Fix Version/s: 2.9
Assignee: Benson Margulies
The IT added here demonstrates that there is no bug here.
r1384979 | bimargulies | 2012-09-14 20:14:08 -0400 (Fri, 14 Sep 2012) | 3 lines
MJAVADOC-278: Plugin does not include javadocDirectory correctly
o add a test that proves that there's no problem here.
> Plugin does not include javadocDirectory correctly
> --
>
> Key: MJAVADOC-278
> URL: https://jira.codehaus.org/browse/MJAVADOC-278
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Windows XP, RHEL 5.3, maven 2.0.9
>Reporter: Thomas Reitz
>Assignee: Benson Margulies
> Fix For: 2.9
>
>
> The maven-javadoc-plugin seem not to include the javadoc resources correctly.
> The files placed in the according folders are not copied to the generated
> target reports.
> Project structure:
> {noformat}d:\test
> +---core
> +---src
> +---main
> ¦ +---java
> ¦ ¦ +---com
> ¦ ¦ +---test
> ¦ ¦ +---api
> ¦ ¦ +---spi
> ¦ +---javadoc <-- contains files to be included
> ¦ ¦ +---doc-files
> ¦ +---resources
> +---test{noformat}
>
> Master POM file is int the d:\test directory. The module POM file under
> d:\test\core. The parent pom file contains the following configuration for
> the reporting section:
> {code:xml}
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.6.1
> true
>
> 1.6
> true
> 128m
> 1g
> private
> true
> false
>
>
> BE-Core Packages
> com.test.*
>
>
>
> true
> true
>
>
>
> ${basedir}/src/main/javadoc
>
>
> http://build.cm.trovicor.com/javase/6/docs/api
>
>
> My
v${project.version}
> API-Documentation
>
>
> My
v${project.version}
> API-Documentation
>
>
>
>
>
>
> date
> t
> Creation Date:
>
>
>
> {code}
>
> When executing the report generation, the following output is generated:
> {noformat}D:\test>mvn javadoc:javadoc -X
> D:\test>set MAVEN_OPTS=-XX:MaxPermSize=298m -XX:+CMSClassUnloadingEnabled
> + Error stacktraces are turned on.
> Maven version: 2.0.9
> Java version: 1.6.0_18
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] test
> [INFO] core
> [INFO] Searching repository for plugin with prefix: 'javadoc'.
> [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins
> [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo
> [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::10 for
> project: null:maven-javadoc-plugin:maven-plugin:2.4 from
> the repository.
> [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project:
> org.apache.maven.plugins:maven-plugins:pom:10 from the rep
> ository.
> [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project:
> org.apache.maven:maven-parent:pom:7 from the repository.
> [INFO]
>
> [INFO] Building test
> [INFO]task-segment: [javadoc:javadoc]
> [INFO]
>
> [DEBUG] com:test:pom:1.0-SNAPSHOT (selected for null)
> [DEBUG] junit:junit:jar:4.4:test (selected for test)
> [DEBUG] Plugin dependencies for:
> org.apache.maven.plugins:maven-javadoc-plugin:2.4
> are:
>...
> These will use the artifact files already in the core ClassRealm instead, to
> allow them to be included in PluginDescriptor.getArtifacts
> ().
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] *
[jira] (MJAVADOC-278) Plugin does not include javadocDirectory correctly
[
https://jira.codehaus.org/browse/MJAVADOC-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308551#comment-308551
]
Benson Margulies commented on MJAVADOC-278:
---
Note that resources are not copied unless you have docfilessubdir in the
configuration.
> Plugin does not include javadocDirectory correctly
> --
>
> Key: MJAVADOC-278
> URL: https://jira.codehaus.org/browse/MJAVADOC-278
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Windows XP, RHEL 5.3, maven 2.0.9
>Reporter: Thomas Reitz
>Assignee: Benson Margulies
> Fix For: 2.9
>
>
> The maven-javadoc-plugin seem not to include the javadoc resources correctly.
> The files placed in the according folders are not copied to the generated
> target reports.
> Project structure:
> {noformat}d:\test
> +---core
> +---src
> +---main
> ¦ +---java
> ¦ ¦ +---com
> ¦ ¦ +---test
> ¦ ¦ +---api
> ¦ ¦ +---spi
> ¦ +---javadoc <-- contains files to be included
> ¦ ¦ +---doc-files
> ¦ +---resources
> +---test{noformat}
>
> Master POM file is int the d:\test directory. The module POM file under
> d:\test\core. The parent pom file contains the following configuration for
> the reporting section:
> {code:xml}
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.6.1
> true
>
> 1.6
> true
> 128m
> 1g
> private
> true
> false
>
>
> BE-Core Packages
> com.test.*
>
>
>
> true
> true
>
>
>
> ${basedir}/src/main/javadoc
>
>
> http://build.cm.trovicor.com/javase/6/docs/api
>
>
> My
v${project.version}
> API-Documentation
>
>
> My
v${project.version}
> API-Documentation
>
>
>
>
>
>
> date
> t
> Creation Date:
>
>
>
> {code}
>
> When executing the report generation, the following output is generated:
> {noformat}D:\test>mvn javadoc:javadoc -X
> D:\test>set MAVEN_OPTS=-XX:MaxPermSize=298m -XX:+CMSClassUnloadingEnabled
> + Error stacktraces are turned on.
> Maven version: 2.0.9
> Java version: 1.6.0_18
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] test
> [INFO] core
> [INFO] Searching repository for plugin with prefix: 'javadoc'.
> [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins
> [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo
> [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::10 for
> project: null:maven-javadoc-plugin:maven-plugin:2.4 from
> the repository.
> [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project:
> org.apache.maven.plugins:maven-plugins:pom:10 from the rep
> ository.
> [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project:
> org.apache.maven:maven-parent:pom:7 from the repository.
> [INFO]
>
> [INFO] Building test
> [INFO]task-segment: [javadoc:javadoc]
> [INFO]
>
> [DEBUG] com:test:pom:1.0-SNAPSHOT (selected for null)
> [DEBUG] junit:junit:jar:4.4:test (selected for test)
> [DEBUG] Plugin dependencies for:
> org.apache.maven.plugins:maven-javadoc-plugin:2.4
> are:
>...
> These will use the artifact files already in the core ClassRealm instead, to
> allow them to be included in PluginDescriptor.getArtifacts
> ().
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Inst
[jira] (MJAVADOC-281) Javadoc plugin in reporting section triggers compile phase
[ https://jira.codehaus.org/browse/MJAVADOC-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MJAVADOC-281. - Resolution: Won't Fix Assignee: Benson Margulies I don't care any more and no one else does. > Javadoc plugin in reporting section triggers compile phase > -- > > Key: MJAVADOC-281 > URL: https://jira.codehaus.org/browse/MJAVADOC-281 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6.1 >Reporter: Benson Margulies >Assignee: Benson Margulies > > Please see MSITE-475. > Using the test case project attached there, you will observe that including > the javadoc plugin in the reporting section has the result of triggering the > compile phase when running mvn site:site. This is inconvenient and I think > arguably wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-296) explain resources directory
[ https://jira.codehaus.org/browse/MJAVADOC-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MJAVADOC-296. - Resolution: Fixed Fix Version/s: 2.9 Assignee: Benson Margulies r1384980 | bimargulies | 2012-09-14 20:19:20 -0400 (Fri, 14 Sep 2012) | 3 lines MJAVADOC-296: explain resources directory o added some more explanation. > explain resources directory > --- > > Key: MJAVADOC-296 > URL: https://jira.codehaus.org/browse/MJAVADOC-296 > Project: Maven 2.x Javadoc Plugin > Issue Type: Wish >Affects Versions: 2.7 > Environment: documentation >Reporter: Gerard Weatherby >Assignee: Benson Margulies >Priority: Minor > Fix For: 2.9 > > > On > http://maven.apache.org/plugins/maven-javadoc-plugin/examples/javadoc-resources.html > it's unclear to me what the "resources" directory shown is used for. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-298) java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be cast to com.sun.javadoc.AnnotationTypeDoc when building a javadoc-jar
[
https://jira.codehaus.org/browse/MJAVADOC-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MJAVADOC-298.
-
Resolution: Cannot Reproduce
Assignee: Benson Margulies
> java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be
> cast to com.sun.javadoc.AnnotationTypeDoc when building a javadoc-jar
>
>
> Key: MJAVADOC-298
> URL: https://jira.codehaus.org/browse/MJAVADOC-298
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Marius Kruger
>Assignee: Benson Margulies
> Attachments: test-javadoc.zip
>
>
> I'm trying to build java-doc jar, but I get the stack trace below if I run
> `mvn install` in the attached maven project.
> I tried the workarounds in the following, but could not get them to work for
> building a javadoc-jar:
> MJAVADOC-214
> http://maven.40175.n5.nabble.com/JavaDoc-Report-crashes-with-TestNG-td106262.html
> {noformat}[ERROR] MavenReportException: Error while creating archive: Exit
> code: 1 -
> /stf/prj/arch_prototypes/maven/test-javadoc/src/main/java/com/google/common/collect/UnFinalHashMultimap.java:49:
> warning - Tag @link: reference not found:
> com.google.common.collect.HashMultimaps
> /stf/prj/arch_prototypes/maven/test-javadoc/src/main/java/com/google/common/collect/UnFinalHashMultimap.java:49:
> warning - Tag @link: reference not found:
> http://code.google.com/p/guava-libraries/issues/detail?id=338
>
>
> java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be
> cast to com.sun.javadoc.AnnotationTypeDoc
> at
> com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46)
> at
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.getAnnotations(HtmlDocletWriter.java:1739)
> at
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.writeAnnotationInfo(HtmlDocletWriter.java:1713)
> at
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.writeAnnotationInfo(HtmlDocletWriter.java:1692)
> at
> com.sun.tools.doclets.formats.html.AbstractExecutableMemberWriter.writeParameters(AbstractExecutableMemberWriter.java:117)
> at
> com.sun.tools.doclets.formats.html.AbstractExecutableMemberWriter.writeParameters(AbstractExecutableMemberWriter.java:100)
> at
> com.sun.tools.doclets.formats.html.MethodWriterImpl.writeSignature(MethodWriterImpl.java:154)
> at
> com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildSignature(MethodBuilder.java:176)
> 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:597)
> at
> com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109)
> at
> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90)
> at
> com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56)
> at
> com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildMethodDoc(MethodBuilder.java:150)
> 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:597)
> at
> com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109)
> at
> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90)
> at
> com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56)
> at
> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildMethodDetails(ClassBuilder.java:322)
> 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:597)
> at
> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(Cla
[jira] (MJAVADOC-298) java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be cast to com.sun.javadoc.AnnotationTypeDoc when building a javadoc-jar
[
https://jira.codehaus.org/browse/MJAVADOC-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308554#comment-308554
]
Benson Margulies commented on MJAVADOC-298:
---
There is nothing Maven can do to produce this problem, which is entirely
internal to javadoc.
> java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be
> cast to com.sun.javadoc.AnnotationTypeDoc when building a javadoc-jar
>
>
> Key: MJAVADOC-298
> URL: https://jira.codehaus.org/browse/MJAVADOC-298
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Marius Kruger
> Attachments: test-javadoc.zip
>
>
> I'm trying to build java-doc jar, but I get the stack trace below if I run
> `mvn install` in the attached maven project.
> I tried the workarounds in the following, but could not get them to work for
> building a javadoc-jar:
> MJAVADOC-214
> http://maven.40175.n5.nabble.com/JavaDoc-Report-crashes-with-TestNG-td106262.html
> {noformat}[ERROR] MavenReportException: Error while creating archive: Exit
> code: 1 -
> /stf/prj/arch_prototypes/maven/test-javadoc/src/main/java/com/google/common/collect/UnFinalHashMultimap.java:49:
> warning - Tag @link: reference not found:
> com.google.common.collect.HashMultimaps
> /stf/prj/arch_prototypes/maven/test-javadoc/src/main/java/com/google/common/collect/UnFinalHashMultimap.java:49:
> warning - Tag @link: reference not found:
> http://code.google.com/p/guava-libraries/issues/detail?id=338
>
>
> java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be
> cast to com.sun.javadoc.AnnotationTypeDoc
> at
> com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46)
> at
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.getAnnotations(HtmlDocletWriter.java:1739)
> at
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.writeAnnotationInfo(HtmlDocletWriter.java:1713)
> at
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.writeAnnotationInfo(HtmlDocletWriter.java:1692)
> at
> com.sun.tools.doclets.formats.html.AbstractExecutableMemberWriter.writeParameters(AbstractExecutableMemberWriter.java:117)
> at
> com.sun.tools.doclets.formats.html.AbstractExecutableMemberWriter.writeParameters(AbstractExecutableMemberWriter.java:100)
> at
> com.sun.tools.doclets.formats.html.MethodWriterImpl.writeSignature(MethodWriterImpl.java:154)
> at
> com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildSignature(MethodBuilder.java:176)
> 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:597)
> at
> com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109)
> at
> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90)
> at
> com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56)
> at
> com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildMethodDoc(MethodBuilder.java:150)
> 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:597)
> at
> com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109)
> at
> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90)
> at
> com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56)
> at
> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildMethodDetails(ClassBuilder.java:322)
> 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:597)
> at
> com.sun.tools.doclet
[jira] (MJAVADOC-312) having parenthesis as part of a path causes ArrayIndexOutOfBounds exception
[ https://jira.codehaus.org/browse/MJAVADOC-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MJAVADOC-312. - Resolution: Fixed Fix Version/s: 2.9 Assignee: Benson Margulies r1384982 | bimargulies | 2012-09-14 20:26:16 -0400 (Fri, 14 Sep 2012) | 3 lines MJAVADOC-312: having parenthesis as part of a path causes ArrayIndexOutOfBounds exception o added call to Pattern.quote to protect from problem. > having parenthesis as part of a path causes ArrayIndexOutOfBounds exception > --- > > Key: MJAVADOC-312 > URL: https://jira.codehaus.org/browse/MJAVADOC-312 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Marshall Schor >Assignee: Benson Margulies >Priority: Minor > Fix For: 2.9 > > > If you are running this plugin, for a project in a directory, where the > directory name contains a parenthesized part, e.g., "(2)", the method > getExcludedPackages in class JavadocUtil fails on line 508 saying > ArrayIndexOutOfBoundsException - with the array index being "1". > This is due to incorrect assmptions being made about characters in file > paths, in particular, the code on line 507 is using a file path as a regular > expression - to chop off the part in front that matches. This only works, if > no characters in the file path string are "special meaning" characters for > regular expressions, and parenthesis are, of course. > The way parenthesis got into the path name was: > 1) I downloaded from the web a source release zip file. > 2) later I downloaded an updated version of this same file. My browser, > seeing I already had a file by that name in my "Downloads" area, named this > 2nd download as (2).zip - adding the "(2)" to the name of the download. > 3) My "unzipper" creates a directory with the same name as the zip file by > convention, so the directory was named ... / (2)/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-323) Jersey generate-wadl sample fails with Javadoc >2.4
[
https://jira.codehaus.org/browse/MJAVADOC-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MJAVADOC-323.
-
Resolution: Not A Bug
Assignee: Benson Margulies
This is not a problem with the maven-javadoc-plugin.
> Jersey generate-wadl sample fails with Javadoc >2.4
> ---
>
> Key: MJAVADOC-323
> URL: https://jira.codehaus.org/browse/MJAVADOC-323
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5, 2.6, 2.6.1, 2.7, 2.8
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Java version: 1.6.0_26, vendor: Apple Inc.
>Reporter: Roland Müller
>Assignee: Benson Margulies
>
> If I want to compile generate-wadl sample of Jersey 1.8 in its standard
> configuration with maven-javadoc-plugin version 2.4, everything works well.
> If I change to a higher javadoc version, the build fails:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc (default) on
> project generate-wadl: An error has occurred in JavaDocs report generation:
> Unable to find artifact:groupId = 'com.sun.jersey'
> [ERROR] artifactId = 'jersey-server'
> [ERROR] version = '1.8': Failure to find
> com.sun.jersey:jersey-server:bundle:1.8 in
> http://nexus.xxx/nexus/content/groups/public was cached in the local
> repository, resolution will not be reattempted until the update interval of
> nexus has elapsed or updates are forced
> [ERROR]
> [ERROR] Try downloading the file manually from the project website.
> [ERROR]
> [ERROR] Then, install it using the command:
> [ERROR] mvn install:install-file -DgroupId=com.sun.jersey
> -DartifactId=jersey-server -Dversion=1.8 -Dpackaging=bundle
> -Dfile=/path/to/file
> [ERROR]
> [ERROR] Alternatively, if you host your own repository you can deploy the
> file there:
> [ERROR] mvn deploy:deploy-file -DgroupId=com.sun.jersey
> -DartifactId=jersey-server -Dversion=1.8 -Dpackaging=bundle
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> {noformat}
> What confuses me is the {com.sun.jersey:jersey-server:bundle:1.8}. Shouldn't
> it be {com.sun.jersey:jersey-server:1.8} or {com.sun.jersey:bundle:1.8}?
> The generate-wadl sample is available here:
> http://java.net/projects/jersey/sources/svn/show/tags/jersey-1.8/jersey/samples/generate-wadl
> To reproduce the build failure, edit pom.xml and change maven-javadoc-plugin
> version from 2.4 to 2.8.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-343) maven-javadoc-plugin is not marked as @threadsafe, which leads to a warning shown during parallel builds
[ https://jira.codehaus.org/browse/MJAVADOC-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MJAVADOC-343. - Resolution: Fixed Fix Version/s: 2.9 Assignee: Benson Margulies r1384986 | bimargulies | 2012-09-14 20:30:29 -0400 (Fri, 14 Sep 2012) | 3 lines MJAVADOC-343: maven-javadoc-plugin is not marked as @threadsafe, which leads to a warning shown during parallel builds o added threadSafe. I can't see any reason for it to be unsafe. > maven-javadoc-plugin is not marked as @threadsafe, which leads to a warning > shown during parallel builds > > > Key: MJAVADOC-343 > URL: https://jira.codehaus.org/browse/MJAVADOC-343 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.8.1 >Reporter: ask >Assignee: Benson Margulies > Fix For: 2.9 > > > [java] [WARNING] > * > [java] [WARNING] * Your build is requesting parallel execution, but > project * > [java] [WARNING] * contains the following plugin(s) that are not marked > as * > [java] [WARNING] * @threadSafe to support parallel building. > * > [java] [WARNING] * While this /may/ work fine, please look for plugin > updates* > [java] [WARNING] * and/or request plugins be made thread-safe. > * > [java] [WARNING] * If reporting an issue, report it against the plugin > in* > [java] [WARNING] * question, not against maven-core > * > [java] [WARNING] > * > [java] [WARNING] The following plugins are not marked @threadSafe in > ab-plugin: > [java] [WARNING] org.apache.maven.plugins:maven-javadoc-plugin:2.8.1 > [java] [WARNING] > * -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-349) additionalJOption only supports one additional option
[ https://jira.codehaus.org/browse/MJAVADOC-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned MJAVADOC-349: - Assignee: Benson Margulies > additionalJOption only supports one additional option > - > > Key: MJAVADOC-349 > URL: https://jira.codehaus.org/browse/MJAVADOC-349 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.8.1 >Reporter: Michael Ekstrand >Assignee: Benson Margulies > > The additionalJOption option only seems to support a single -J option. I need > to be able to pass multiple -J options to JavaDoc. > The specific use case is defining properties that are picked up by my custom > taglets; alternatively, an option to define properties that get passed to > JavaDoc would also be a welcome solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-349) additionalJOption only supports one additional option
[ https://jira.codehaus.org/browse/MJAVADOC-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MJAVADOC-349. - Resolution: Fixed Fix Version/s: 2.9 Please test a snapshot, as I couldn't think of a good way to make an automated test for this. > additionalJOption only supports one additional option > - > > Key: MJAVADOC-349 > URL: https://jira.codehaus.org/browse/MJAVADOC-349 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.8.1 >Reporter: Michael Ekstrand >Assignee: Benson Margulies > Fix For: 2.9 > > > The additionalJOption option only seems to support a single -J option. I need > to be able to pass multiple -J options to JavaDoc. > The specific use case is defining properties that are picked up by my custom > taglets; alternatively, an option to define properties that get passed to > JavaDoc would also be a welcome solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-349) additionalJOption only supports one additional option
[ https://jira.codehaus.org/browse/MJAVADOC-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308558#comment-308558 ] Benson Margulies commented on MJAVADOC-349: --- r1384988 | bimargulies | 2012-09-14 20:40:09 -0400 (Fri, 14 Sep 2012) | 3 lines MJAVADOC-349: additionalJOption only supports one additional option > additionalJOption only supports one additional option > - > > Key: MJAVADOC-349 > URL: https://jira.codehaus.org/browse/MJAVADOC-349 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.8.1 >Reporter: Michael Ekstrand >Assignee: Benson Margulies > Fix For: 2.9 > > > The additionalJOption option only seems to support a single -J option. I need > to be able to pass multiple -J options to JavaDoc. > The specific use case is defining properties that are picked up by my custom > taglets; alternatively, an option to define properties that get passed to > JavaDoc would also be a welcome solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-348) Update "javaApiLinks" links
[ https://jira.codehaus.org/browse/MJAVADOC-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MJAVADOC-348. - Resolution: Fixed Fix Version/s: 2.9 Assignee: Benson Margulies r1384990 | bimargulies | 2012-09-14 20:44:33 -0400 (Fri, 14 Sep 2012) | 2 lines MJAVADOC-348: Update "javaApiLinks" links > Update "javaApiLinks" links > --- > > Key: MJAVADOC-348 > URL: https://jira.codehaus.org/browse/MJAVADOC-348 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: Paul Benedict >Assignee: Benson Margulies >Priority: Minor > Fix For: 2.9 > > > Oracle has moved their API documentation from download.oracle.com to > docs.oracle.com -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-342) An incomplete fix for the NPE bugs in AbstractJavadocMojo.java
[ https://jira.codehaus.org/browse/MJAVADOC-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308561#comment-308561 ] Benson Margulies commented on MJAVADOC-342: --- THis is more likely to get fixed with test case(s) attached. > An incomplete fix for the NPE bugs in AbstractJavadocMojo.java > -- > > Key: MJAVADOC-342 > URL: https://jira.codehaus.org/browse/MJAVADOC-342 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Reporter: Guangtai Liang >Priority: Critical > > The fix revision 554202 was aimed to remove an NPE bug on the returned value > of "getJavadocDirectory()" in the method "getSourcePaths " of the file > "/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java" > , but it is incomplete. > Since the returned value "getJavadocDirectory()" could be null during the > runtime execution, its value should also be null-checked before being > dereferenced in other methods. > The buggy code locations the same fix needs to be applied at are as bellows: > Line 2401 of the method "copyJavadocResources"; > Line 1505 of the method "getSourcePaths". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-205) Review output directory for Javadoc reports (main and test) and jar (main and test)
[ https://jira.codehaus.org/browse/MJAVADOC-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308562#comment-308562 ] Vincent Siveton commented on MJAVADOC-205: -- Nothing right now. > Review output directory for Javadoc reports (main and test) and jar (main and > test) > --- > > Key: MJAVADOC-205 > URL: https://jira.codehaus.org/browse/MJAVADOC-205 > Project: Maven 2.x Javadoc Plugin > Issue Type: Task >Affects Versions: 2.4 >Reporter: Vincent Siveton > > Actually, plugin report used: > * ouputDirectory > * reportOutputDirectory > * destDir in JavadocReport and TestJavadocReport > The configuration is not easy to change ouput directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
