[jira] (MJAR-156) Classpath created in manifest contains timestamp instead of the suffix "-SNAPSHOT"
[
https://jira.codehaus.org/browse/MJAR-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311083#comment-311083
]
Markus KARG commented on MJAR-156:
--
A possible, acceptable workaround seems to be to explicitly specify that the
-SNAPSHOT suffix has not to be replaced:
true
false
> Classpath created in manifest contains timestamp instead of the suffix
> "-SNAPSHOT"
> ---
>
> Key: MJAR-156
> URL: https://jira.codehaus.org/browse/MJAR-156
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2, 2.4
> Environment: Win7 Pro SP1 (64 Bit), JDK 1.6.0_26 (32 Bit)
>Reporter: Markus KARG
> Attachments: Sample.zip
>
>
> Sometimes the JAR packager replaces a dependency's "-SNAPSHOT" suffix by a
> timestamp when calculating a corresponding "Class-Path:"-entry for all
> dependencies into the MANIFEST.MF file of the packaged JAR. This is
> problematic, as typically the dependency shipped together with the created
> JAR will NOT be renamed, but shipped WITH the suffix "-SNAPSHOT". The created
> JAR will at runtime not find the JAR due to the wrong suffix then
> ("ClassNotFoundException" will happen for all content in the dependency,
> obviously). Strange but true, this seem to happen only for SOME JARs and only
> in SOME particular situations, but I was not able to identify the root causes.
> Attached is a tiny MVN project containing a pom that will produce this
> behaviour.
> * How to demonstrate:
> - Unpack attached JAR
> - Manually deploy the dependency "webdav-jaxrs-1.2-SNAPSHOT.jar" found in
> subfolder "install-this-in-repo" into the local repository.
> - mvn clean package
> - "target\sample-1.0.0-SNAPSHOT.jar" contains wrong MANIFEST.MF Class-Path:
> entry now:
> Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
> (Sample output contained in ZIP\target!)
> Obviously "-SNAPSHOT" was replaced by "20120621.141509-35", what induces the
> problem that the actual dependency is not found, as its file ends still on
> "-SNAPSHOT" (by intention!). This scenario typically happens when both files
> end up in an EAR for example.
> * Expected Result:
> - Class-Path: webdav-jaxrs-1.2-SNAPSHOT.jar jsr311-api-1.1.1.jar
> * Actual Result:
> - Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
> * Workaround:
> - Provide a static MANIFEST.MF file. Drawback: Changing dependency induces
> manual corrections to the static file.
> - Fix the entry manually after each build. Drawback: Hard to automate this.
--
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] (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311085#comment-311085 ] Jorg Heymans commented on MNG-1977: --- +1 to this, though i'm not sure if maven is still being actively developed ? > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.2 > > Attachments: global_excls_it-test_v2.patch, > global_excls_it-test_v3.patch, global_excls_maven3_v2.patch, > global_excls_maven3_v3.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- 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] (MDEP-382) copy-dependencies - includeScope deos not work
Michal Kroliczek created MDEP-382: - Summary: copy-dependencies - includeScope deos not work Key: MDEP-382 URL: https://jira.codehaus.org/browse/MDEP-382 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.5.1 Environment: java 5, windows Reporter: Michal Kroliczek Hello i try to copy only dependencies with scope compile so I used compile in my plugin configuration. Unfortunately dependencies with scope provided are copied too. When i change property to: provided it works fine and provided dependencies are omitted. -- 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-81) true is ignored for maven-compiler-plugin
[ https://jira.codehaus.org/browse/MCOMPILER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311091#comment-311091 ] Anders Hammar commented on MCOMPILER-81: I confirm this (m-compiler-p v2.5.2). Comparing the result of executing javac directly with the -verbose flag and executing maven-compiler-plugin with verbose=true (and -X), the latter does not output what the compiler is doing. > true is ignored for maven-compiler-plugin > > > Key: MCOMPILER-81 > URL: https://jira.codehaus.org/browse/MCOMPILER-81 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Maven version: 2.0.7 > Java version: 1.5.0_13-rev > OS name: "sunos" version: "5.11" arch: "x86" >Reporter: Sanjeeb Sahoo > > I don't see the effect of true. When I run with -X, I do > see that verbose = true, but I don't see it being passed to javac. I tried > with fork = true and the command line that was used to invoke javac did > not have verbose option set. I am using default compiler. -- 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] (MDEP-382) copy-dependencies - includeScope deos not work
[ https://jira.codehaus.org/browse/MDEP-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Kroliczek closed MDEP-382. - Resolution: Won't Fix ok i read some other issues about how scopes are seen by maven (not like pom) and just used runtime scope - it is so confusing... > copy-dependencies - includeScope deos not work > --- > > Key: MDEP-382 > URL: https://jira.codehaus.org/browse/MDEP-382 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.5.1 > Environment: java 5, windows >Reporter: Michal Kroliczek > > Hello > i try to copy only dependencies with scope compile so I used > compile in my plugin configuration. > Unfortunately dependencies with scope provided are copied too. When i change > property to: > provided it works fine and provided > dependencies are omitted. -- 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] (MCHECKSTYLE-182) Use Maven log levels when logging to console
Andreas Sewe created MCHECKSTYLE-182:
Summary: Use Maven log levels when logging to console
Key: MCHECKSTYLE-182
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-182
Project: Maven 2.x Checkstyle Plugin
Issue Type: Improvement
Affects Versions: 2.9.1
Reporter: Andreas Sewe
Priority: Minor
Getting {{checkstyle:check}} to print out Checkstyle's findings to the console
during a build is surprisingly hard/ugly:
{code:xml}
info
false
true
{code}
While this achieves the desired effect, it produces a warning:
{code}
[WARNING] checkstyle:check violations detected but failOnViolation set to false
{code}
Moreover, all found violations, whether errors, warnings, or infos, are logged
as {{[ERROR]}}'s on Maven's console. It would be nice if the
{{maven-checkstyle-plugin}} would use the corresponding Maven log levels
instead.
--
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-81) true is ignored for maven-compiler-plugin
[ https://jira.codehaus.org/browse/MCOMPILER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311094#comment-311094 ] Anders Hammar commented on MCOMPILER-81: Checking the sources of plexus-compiler I see there is no support for handling debug messages like these, just warnings and errors! > true is ignored for maven-compiler-plugin > > > Key: MCOMPILER-81 > URL: https://jira.codehaus.org/browse/MCOMPILER-81 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Maven version: 2.0.7 > Java version: 1.5.0_13-rev > OS name: "sunos" version: "5.11" arch: "x86" >Reporter: Sanjeeb Sahoo > > I don't see the effect of true. When I run with -X, I do > see that verbose = true, but I don't see it being passed to javac. I tried > with fork = true and the command line that was used to invoke javac did > not have verbose option set. I am using default compiler. -- 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-160) javac error but build SUCCESS
[ https://jira.codehaus.org/browse/MCOMPILER-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311098#comment-311098 ] Anders Hammar commented on MCOMPILER-160: - Due to MCOMPILER-81 it's very hard to find the root cause. After creating a patched plexus-compiler-javac so that I would get all debug info, I see that the problem is that the following message from the compiler isn't catched as an error: "An exception has occurred in the compiler (1.6.0_24). Please file a bug at..." > javac error but build SUCCESS > - > > Key: MCOMPILER-160 > URL: https://jira.codehaus.org/browse/MCOMPILER-160 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.3.2 > Environment: Java 1.6.0_25 >Reporter: Jochen Stiepel >Priority: Critical > > Using javac as the (default)compiler for my source files no classes are > generated, but the Maven Build says build "SUCCESS". > Using "tycho-compiler-jdt" as the compiler, the class files are generated > correctly. > reproducible = always. > Using -X show's the javac compiler commandline, but it is to long (108376 > char's) to execute it from the cmd on windows. > Can I provide more information? -- 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-913) forkMode always - RejectedExecutionException when > 500 tests
Gary Tully created SUREFIRE-913:
---
Summary: forkMode always - RejectedExecutionException when > 500
tests
Key: SUREFIRE-913
URL: https://jira.codehaus.org/browse/SUREFIRE-913
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.12.4
Reporter: Gary Tully
executing more than 500 tests using forkMode=always gives a
RejectedExecutionException because the executor has a bounded work queue with a
hardcoded limit of 500.
>From the activemq jenkins ci build, the error is reported when 500 tests have
>run, but it occurs when they are initially scheduled by
>org.apache.maven.plugin.surefire.booterclient.ForkStarter#runSuitesForkPerTestSet
>
{code}
Waiting for Jenkins to finish collecting data
mavenExecutionResult exceptions not empty
message : Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test (default-test) on
project activemq-core: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
cause : Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test (default-test) on
project activemq-core: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
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:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at
org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
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:326)
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: org.apache.maven.plugin.PluginExecutionException: Execution
default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 27 more
Caused by: java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:168)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:121)
at
org.apache.maven.plugin.surefire.AbstractSurefi
[jira] (SUREFIRE-913) forkMode always - RejectedExecutionException when > 500 tests
[
https://jira.codehaus.org/browse/SUREFIRE-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311100#comment-311100
]
Gary Tully commented on SUREFIRE-913:
-
ps: ignore the change of 60 to 5 for the timeout in the change above. That is
unnecessary, but I can't seem to edit the description to fix that.
> forkMode always - RejectedExecutionException when > 500 tests
> -
>
> Key: SUREFIRE-913
> URL: https://jira.codehaus.org/browse/SUREFIRE-913
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12.4
>Reporter: Gary Tully
>
> executing more than 500 tests using forkMode=always gives a
> RejectedExecutionException because the executor has a bounded work queue with
> a hardcoded limit of 500.
> From the activemq jenkins ci build, the error is reported when 500 tests have
> run, but it occurs when they are initially scheduled by
> org.apache.maven.plugin.surefire.booterclient.ForkStarter#runSuitesForkPerTestSet
>
> {code}
> Waiting for Jenkins to finish collecting data
> mavenExecutionResult exceptions not empty
> message : Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test (default-test) on
> project activemq-core: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
> cause : Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test
> (default-test) on project activemq-core: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> 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:326)
> 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: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.util.concurrent.RejectedExecutionException
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExe
[jira] (SUREFIRE-913) forkMode always - RejectedExecutionException when > 500 tests
[
https://jira.codehaus.org/browse/SUREFIRE-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311102#comment-311102
]
Gary Tully commented on SUREFIRE-913:
-
issues seems to have been introduced in
http://svn.apache.org/viewvc?view=revision&revision=1222474
wile always is linear, it is also limited:
http://jira.codehaus.org/browse/SUREFIRE-799
> forkMode always - RejectedExecutionException when > 500 tests
> -
>
> Key: SUREFIRE-913
> URL: https://jira.codehaus.org/browse/SUREFIRE-913
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12.4
>Reporter: Gary Tully
>
> executing more than 500 tests using forkMode=always gives a
> RejectedExecutionException because the executor has a bounded work queue with
> a hardcoded limit of 500.
> From the activemq jenkins ci build, the error is reported when 500 tests have
> run, but it occurs when they are initially scheduled by
> org.apache.maven.plugin.surefire.booterclient.ForkStarter#runSuitesForkPerTestSet
>
> {code}
> Waiting for Jenkins to finish collecting data
> mavenExecutionResult exceptions not empty
> message : Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test (default-test) on
> project activemq-core: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
> cause : Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test
> (default-test) on project activemq-core: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> 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:326)
> 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: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.util.concurrent.RejectedExecutionException
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
> at
> java.util.concu
[jira] (MCOMPILER-160) javac error but build SUCCESS
[ https://jira.codehaus.org/browse/MCOMPILER-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311105#comment-311105 ] Anders Hammar commented on MCOMPILER-160: - Just sent a pull request on plexus-compiler (https://github.com/sonatype/plexus-compiler/pull/7) that contains a fix of the existing band-aid catching mechanism of unparseable errors. This ensure that the scenario described in this ticket shouldn't happen I believe (at least it solves the scenario I ran into). plexus-compiler-javac should handle this better (logging wise) but this will at least prevent m-compiler-p from incorrectly reporting compilation as successful. Could someone with commit rights for plexus-compiler take a look please? > javac error but build SUCCESS > - > > Key: MCOMPILER-160 > URL: https://jira.codehaus.org/browse/MCOMPILER-160 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.3.2 > Environment: Java 1.6.0_25 >Reporter: Jochen Stiepel >Priority: Critical > > Using javac as the (default)compiler for my source files no classes are > generated, but the Maven Build says build "SUCCESS". > Using "tycho-compiler-jdt" as the compiler, the class files are generated > correctly. > reproducible = always. > Using -X show's the javac compiler commandline, but it is to long (108376 > char's) to execute it from the cmd on windows. > Can I provide more information? -- 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] (MPLUGINTESTING-26) BAD URL for Cookbook
David Pilato created MPLUGINTESTING-26:
--
Summary: BAD URL for Cookbook
Key: MPLUGINTESTING-26
URL: https://jira.codehaus.org/browse/MPLUGINTESTING-26
Project: Maven 2.x Plugin Testing
Issue Type: Bug
Components: plugin-testing-harness
Affects Versions: 1.3
Reporter: David Pilato
Priority: Trivial
Hi there,
The link to the cookbook "How to use Maven Plugin Testing Harness" is incorrect.
It's:
{{#getting-startedindex.html}}
It should be:
{{getting-started/index.html}}
HTH
David.
--
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] (MPLUGINTESTING-26) BAD URL for Cookbook
[
https://jira.codehaus.org/browse/MPLUGINTESTING-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30#comment-30
]
David Pilato commented on MPLUGINTESTING-26:
Links are incorrect from home page:
http://maven.apache.org/plugin-testing/maven-plugin-testing-harness/index.html
Also for:
Testing Complex Mojo Parameters
Testing Multiproject
Testing Using Repositories
Testing Project Artifact
> BAD URL for Cookbook
>
>
> Key: MPLUGINTESTING-26
> URL: https://jira.codehaus.org/browse/MPLUGINTESTING-26
> Project: Maven 2.x Plugin Testing
> Issue Type: Bug
> Components: plugin-testing-harness
>Affects Versions: 1.3
>Reporter: David Pilato
>Priority: Trivial
>
> Hi there,
> The link to the cookbook "How to use Maven Plugin Testing Harness" is
> incorrect.
> It's:
> {{#getting-startedindex.html}}
> It should be:
> {{getting-started/index.html}}
> HTH
> David.
--
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-898) error with 2.12.1 (works with 2.12)
[
https://jira.codehaus.org/browse/SUREFIRE-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311120#comment-311120
]
Ian Springer commented on SUREFIRE-898:
---
I'm still seeing this with 2.12.4 (and not with 2.12). I'm not sure this should
have been closed as Not A Bug. The error message suggests it's trying to load a
test category as as a class ...
{code}
Caused by: java.lang.ClassNotFoundException: foonotatestsurefireissue
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
{code}
> error with 2.12.1 (works with 2.12)
> ---
>
> Key: SUREFIRE-898
> URL: https://jira.codehaus.org/browse/SUREFIRE-898
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Olivier Lamy
>Assignee: Kristian Rosenvold
> Fix For: 2.12.2
>
>
> log
> {code}
> 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:104)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category:
> foonotatestsurefireissue
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:116)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:97)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException: foonotatestsurefireissue
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:112)
> ... 12 more
> {code}
> Build archiva trunk with -Pit-js
> (http://svn.apache.org/repos/asf/archiva/trunk/)
> change surefire version in pom.
--
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] (MCHANGES-292) announcement-mail goal doesn't respect useJql parameter
Andrew Murdoch created MCHANGES-292: --- Summary: announcement-mail goal doesn't respect useJql parameter Key: MCHANGES-292 URL: https://jira.codehaus.org/browse/MCHANGES-292 Project: Maven 2.x Changes Plugin Issue Type: Bug Reporter: Andrew Murdoch When configured with the useJql parameter such that the changes plugin is able to pull a report from JIRA version 5.1 the announcement-mail goal does not appear to respect this. Executing the goal 'jira-report' generates the correct URL and produces the report successfully, however executing the goal 'announcement-mail' fails as if useJql is not specified. This may also be true for jiraUser and jiraPassword but it cant get that far due to the useJql error. Resulting error [ERROR] Error accessing http://jira.hostname.com/browse/PROJECTID java.lang.RuntimeException: The issue management URL in the POM does not include a pid, and it was not possible to extract it from the page at that URL. at org.apache.maven.plugin.jira.AbstractJiraDownloader.getParameterBasedQueryURL(AbstractJiraDownloader.java:238) at org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:147) at org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:682) at org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:454) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199) 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:319) 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) Example configuration which causes the issue true jirauserjiraUser> jirapwd true addr...@domain.com hostname 25 JIRA -- 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-898) error with 2.12.1 (works with 2.12)
[
https://jira.codehaus.org/browse/SUREFIRE-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311142#comment-311142
]
Kristian Rosenvold commented on SUREFIRE-898:
-
When running junit, categories ARE classes.
> error with 2.12.1 (works with 2.12)
> ---
>
> Key: SUREFIRE-898
> URL: https://jira.codehaus.org/browse/SUREFIRE-898
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Olivier Lamy
>Assignee: Kristian Rosenvold
> Fix For: 2.12.2
>
>
> log
> {code}
> 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:104)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category:
> foonotatestsurefireissue
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:116)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:97)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException: foonotatestsurefireissue
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:112)
> ... 12 more
> {code}
> Build archiva trunk with -Pit-js
> (http://svn.apache.org/repos/asf/archiva/trunk/)
> change surefire version in pom.
--
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-21) compiler smarts
[
https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311157#comment-311157
]
Michael Panchenko commented on MCOMPILER-21:
Why you can't use
http://maven.apache.org/ref/2.2.1/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getStartTime()
http://maven.apache.org/ref/3.0.4/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getStartTime()
to get build start time?
Instead of that you use
{code}
+protected Date getBuildStartTime()
+{
+try
+{
+Method getRequestMethod = session.getClass().getMethod(
"getRequest" );
+Object mavenExecutionRequest = getRequestMethod.invoke( session );
+Method getStartTimeMethod =
mavenExecutionRequest.getClass().getMethod( "getStartTime" );
+Date buildStartTime = (Date) getStartTimeMethod.invoke(
mavenExecutionRequest );
+return buildStartTime;
+}
+catch ( Exception e )
+{
+getLog().debug( "unable to get start time for the current build: "
+ e.getMessage() );
+}
+
+return new Date();
+}
{code}
> compiler smarts
> ---
>
> Key: MCOMPILER-21
> URL: https://jira.codehaus.org/browse/MCOMPILER-21
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Brett Porter
>Assignee: Mark Struberg
> Fix For: backlog
>
> Attachments: MCOMPILER-21.patch, MCOMPILER-21-v2.patch
>
>
> there are probably other ways we can make the compiler stale check smarter.
> List them out here if you think of them.
> 1) if a snapshot was resolved to a newer version, rebuild everything.
--
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] (MCHANGES-292) announcement-mail goal doesn't respect useJql parameter
[
https://jira.codehaus.org/browse/MCHANGES-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MCHANGES-292:
-
Description:
When configured with the useJql parameter such that the changes plugin is able
to pull a report from JIRA version 5.1 the announcement-mail goal does not
appear to respect this.
Executing the goal 'jira-report' generates the correct URL and produces the
report successfully, however executing the goal 'announcement-mail' fails as if
useJql is not specified. This may also be true for jiraUser and jiraPassword
but it cant get that far due to the useJql error.
Resulting error
{noformat}
[ERROR] Error accessing http://jira.hostname.com/browse/PROJECTID
java.lang.RuntimeException: The issue management URL in the POM does not
include a pid, and it was not possible to extract it from the page at that URL.
at
org.apache.maven.plugin.jira.AbstractJiraDownloader.getParameterBasedQueryURL(AbstractJiraDownloader.java:238)
at
org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:147)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:682)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:454)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
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:319)
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)
{noformat}
Example configuration which causes the issue
{code:xml}
true
jirauserjiraUser>
jirapwd
true
addr...@domain.com
hostname
25
JIRA
{code}
was:
When configured with the useJql parameter such that the changes plugin is able
to pull a report from JIRA version 5.1 the announcement-mail goal does not
appear to respect this.
Executing the goal 'jira-report' generates the correct URL and produces the
report successfully, however executing the goal 'announcement-mail' fails as if
useJql is not specified. This may also be true for jiraUser and jiraPassword
but it cant get that far due to the useJql error.
Resulting error
[ERROR] Error accessing http://jira.hostname.com/browse/PROJECTID
java.lang.RuntimeException: The issue management URL in the POM does not
include a pid, and it was not possible to extract it from the page at that URL.
at
org.apache.maven.plugin.jira.AbstractJiraDownloader.getParameterBasedQueryURL(AbstractJiraDownloader.java:238)
at
org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:147)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:682)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:454)
at
org.apache.maven.plugin.DefaultBuildPluginManager.execu
[jira] (MCHANGES-292) announcement-mail goal doesn't respect useJql parameter
[
https://jira.codehaus.org/browse/MCHANGES-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MCHANGES-292:
-
Issue Type: New Feature (was: Bug)
> announcement-mail goal doesn't respect useJql parameter
> ---
>
> Key: MCHANGES-292
> URL: https://jira.codehaus.org/browse/MCHANGES-292
> Project: Maven 2.x Changes Plugin
> Issue Type: New Feature
>Reporter: Andrew Murdoch
>
> When configured with the useJql parameter such that the changes plugin is
> able to pull a report from JIRA version 5.1 the announcement-mail goal does
> not appear to respect this.
> Executing the goal 'jira-report' generates the correct URL and produces the
> report successfully, however executing the goal 'announcement-mail' fails as
> if useJql is not specified. This may also be true for jiraUser and
> jiraPassword but it cant get that far due to the useJql error.
> Resulting error
> {noformat}
> [ERROR] Error accessing http://jira.hostname.com/browse/PROJECTID
> java.lang.RuntimeException: The issue management URL in the POM does not
> include a pid, and it was not possible to extract it from the page at that
> URL.
> at
> org.apache.maven.plugin.jira.AbstractJiraDownloader.getParameterBasedQueryURL(AbstractJiraDownloader.java:238)
> at
> org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:147)
> at
> org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:682)
> at
> org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:454)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
> 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:319)
> 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)
> {noformat}
> Example configuration which causes the issue
> {code:xml}
> true
> jirauserjiraUser>
> jirapwd
> true
>
>addr...@domain.com
>
> hostname
> 25
>
>JIRA
>
> {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] (MCHANGES-292) announcement-mail goal doesn't respect useJql parameter
[
https://jira.codehaus.org/browse/MCHANGES-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311158#comment-311158
]
Dennis Lundberg commented on MCHANGES-292:
--
Hi
I think that you mean the {{changes:announcement-generate}} goal. All the
{{changes:announcement-mail}} goal does is send an email based on a previously
generated template.
The {{changes:announcement-generate}} goal does not yet support the {{useJql
parameter}}, as can be seen in the plugin documentation:
http://maven.apache.org/plugins/maven-changes-plugin/announcement-generate-mojo.html
> announcement-mail goal doesn't respect useJql parameter
> ---
>
> Key: MCHANGES-292
> URL: https://jira.codehaus.org/browse/MCHANGES-292
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
>Reporter: Andrew Murdoch
>
> When configured with the useJql parameter such that the changes plugin is
> able to pull a report from JIRA version 5.1 the announcement-mail goal does
> not appear to respect this.
> Executing the goal 'jira-report' generates the correct URL and produces the
> report successfully, however executing the goal 'announcement-mail' fails as
> if useJql is not specified. This may also be true for jiraUser and
> jiraPassword but it cant get that far due to the useJql error.
> Resulting error
> {noformat}
> [ERROR] Error accessing http://jira.hostname.com/browse/PROJECTID
> java.lang.RuntimeException: The issue management URL in the POM does not
> include a pid, and it was not possible to extract it from the page at that
> URL.
> at
> org.apache.maven.plugin.jira.AbstractJiraDownloader.getParameterBasedQueryURL(AbstractJiraDownloader.java:238)
> at
> org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:147)
> at
> org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:682)
> at
> org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:454)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
> 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:319)
> 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)
> {noformat}
> Example configuration which causes the issue
> {code:xml}
> true
> jirauserjiraUser>
> jirapwd
> true
>
>addr...@domain.com
>
> hostname
> 25
>
>JIRA
>
> {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] (MSCMPUB-2) publish-scm can fail with many files
Mark Hobson created MSCMPUB-2: - Summary: publish-scm can fail with many files Key: MSCMPUB-2 URL: https://jira.codehaus.org/browse/MSCMPUB-2 Project: maven-scm-publish-plugin Issue Type: Bug Environment: Cygwin, Windows Reporter: Mark Hobson Running publish-scm with a large site can cause the command process to fail due to the command line being too long. For example: [INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X --- ... [INFO] Executing: cmd.exe /X /C "git add -- " Results in: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) on project X: Failed to add new files to SCM: Exception while executing SCM command. Error while executing command. Error while executing process. Cannot run program "cmd.exe" (in directory X): CreateProcess error=206, The filename or extension is too long -> [Help 1] -- 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] (MSCMPUB-2) publish-scm can fail with many files
[
https://jira.codehaus.org/browse/MSCMPUB-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hobson updated MSCMPUB-2:
--
Description:
Running publish-scm with a large site can cause the command process to fail due
to the command line being too long. For example:
{noformat}
[INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X ---
...
[INFO] Executing: cmd.exe /X /C "git add -- "
{noformat}
Results in:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(scm-publish) on project X: Failed to add new files to SCM: Exception while
executing SCM command. Error while executing command. Error while executing
process. Cannot run program "cmd.exe" (in directory X): CreateProcess
error=206, The filename or extension is too long -> [Help 1]
{noformat}
was:
Running publish-scm with a large site can cause the command process to fail due
to the command line being too long. For example:
{noformat}
[INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X ---
...
[INFO] Executing: cmd.exe /X /C "git add -- "
{noformat}
Results in:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(scm-publish) on project X: Failed to add
new files to SCM: Exception while executing SCM command. Error while executing
command. Error while executing process. Cannot run program "cmd.exe" (in
directory X): CreateProcess error=206, The filename or extension is too long ->
[Help 1]
{noformat}
> publish-scm can fail with many files
>
>
> Key: MSCMPUB-2
> URL: https://jira.codehaus.org/browse/MSCMPUB-2
> Project: maven-scm-publish-plugin
> Issue Type: Bug
> Environment: Cygwin, Windows
>Reporter: Mark Hobson
>
> Running publish-scm with a large site can cause the command process to fail
> due to the command line being too long. For example:
> {noformat}
> [INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X
> ---
> ...
> [INFO] Executing: cmd.exe /X /C "git add -- "
> {noformat}
> Results in:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
> (scm-publish) on project X: Failed to add new files to SCM: Exception while
> executing SCM command. Error while executing command. Error while executing
> process. Cannot run program "cmd.exe" (in directory X): CreateProcess
> error=206, The filename or extension is too long -> [Help 1]
> {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] (MSCMPUB-2) publish-scm can fail with many files
[
https://jira.codehaus.org/browse/MSCMPUB-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hobson updated MSCMPUB-2:
--
Description:
Running publish-scm with a large site can cause the command process to fail due
to the command line being too long. For example:
{noformat}
[INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X ---
...
[INFO] Executing: cmd.exe /X /C "git add -- "
{noformat}
Results in:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(scm-publish) on project X: Failed to add
new files to SCM: Exception while executing SCM command. Error while executing
command. Error while executing process. Cannot run program "cmd.exe" (in
directory X): CreateProcess error=206, The filename or extension is too long ->
[Help 1]
{noformat}
was:
Running publish-scm with a large site can cause the command process to fail due
to the command line being too long. For example:
[INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X ---
...
[INFO] Executing: cmd.exe /X /C "git add -- "
Results in:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(scm-publish) on project X: Failed to add
new files to SCM: Exception while executing SCM command. Error while executing
command. Error while executing process. Cannot run program "cmd.exe" (in
directory X): CreateProcess error=206, The filename or extension is too long ->
[Help 1]
> publish-scm can fail with many files
>
>
> Key: MSCMPUB-2
> URL: https://jira.codehaus.org/browse/MSCMPUB-2
> Project: maven-scm-publish-plugin
> Issue Type: Bug
> Environment: Cygwin, Windows
>Reporter: Mark Hobson
>
> Running publish-scm with a large site can cause the command process to fail
> due to the command line being too long. For example:
> {noformat}
> [INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X
> ---
> ...
> [INFO] Executing: cmd.exe /X /C "git add -- "
> {noformat}
> Results in:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
> (scm-publish) on project X: Failed to add
> new files to SCM: Exception while executing SCM command. Error while
> executing command. Error while executing process. Cannot run program
> "cmd.exe" (in directory X): CreateProcess error=206, The filename or
> extension is too long -> [Help 1]
> {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] (MCHANGES-291) Cannot authenticate to Jira OnDemand
[
https://jira.codehaus.org/browse/MCHANGES-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311164#comment-311164
]
Jamie Duncombe commented on MCHANGES-291:
-
Hi,
I am also seeing this problem on a Jira OnDemand instance. It started
occurring around Mid-September which is also when Atlassian updated the
authentication mechanisms for OnDemand instances.
I'm guessing it's related to the authentication no longer working as if I copy
the URL generated by the plugin and pasting it into a browser window which
already has a valid session on the Jira Instance the Url itself works fine.
Out of interest is there a particular reason you haven't switched to using the
REST api for jira? Is this just because it isn't turned on by default in all
Jira instances?
I also have a support request open with Atlassian on the issue, so if they are
able to provide me with any advice or information for fixing the issue I'll
provide it here.
Jamie
> Cannot authenticate to Jira OnDemand
>
>
> Key: MCHANGES-291
> URL: https://jira.codehaus.org/browse/MCHANGES-291
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira
>Affects Versions: 2.8
>Reporter: Gary Clayburg
>
> This plugin recently stopped working for our project that uses Atlassian Jira
> OnDemand.
> It now appears to fail with this 400 error. I'm thinking this is due to
> recent changes in the way that Jira OnDemand is doing authentication. I get a
> similar error in a browser if the session is not authenticated. Does anyone
> else use Jira OnDemand with this plugin?
> {code}
> $ mvn -f pom_changestest.xml changes:jira-report
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building changes-tests 1.22
> [INFO]
>
> [INFO]
> [INFO] --- maven-changes-plugin:2.8:jira-report (default-cli) @ changes-tests
> ---
> [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink
> instance and no SinkFactory available. Please update this plugin.
> [INFO] Downloading from JIRA at:
> https://urlremoved.jira.com/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?tempMax=100&reset=true&jqlQuery=project+%3D+OIAM+AND+fixVersion+in+%28%221.0.5%22%29+AND+status+in+%28Closed%29+AND+resolution+in+%28Fixed%29+ORDER+BY+priority+DESC%2C+created+DESC
> [WARNING] Downloading from JIRA failed. Received: [400]
> [WARNING] JIRA file C:\QA\integration-tests\target\jira-results.xml doesn't
> exist.
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 3.340s
> [INFO] Finished at: Fri Oct 05 09:32:48 MDT 2012
> [INFO] Final Memory: 18M/152M
> [INFO]
>
> {code}
> The pom.xml file is this:
> {code}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.urlremoved
> changes-tests
> jar
> changes-tests
> 1.22
>
> JIRA
> https://urlremoved.jira.com/browse/OIAM
>
>
> changes-tests
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.8
>
> true
> 1.0.5
> justsomed...@somewhere.com
> EnterRealPasswordHere
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I also notice that even this test is executed in debug mode, it indicates
> that login to Jira succeeded even when an invalid password is supplied:
> {code}
> [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink
> instance and no SinkFactory available. Please update this plugin.
> [DEBUG] Encoding JQL query project = OIAM AND fixVersion in ("1.0.5") AND
> status in (Closed) AND resolution in (Fixed) ORDER BY priority DESC, created
> DESC
> [DEBUG] Encoded JQL query
> project+%3D+OIAM+AND+fixVersion+in+%28%221.0.5%22%29+AND+status+in+%28Closed%29+AND+resolution+in+%28Fixed%29+ORDER+BY+priority+DESC%2C+created+DESC
> [DEBUG] JIRA lives at: https://urlremoved.jira.com
> [DEBUG] Login URL:
> https://urlremoved.jira.com/login.jsp?os_destination=/secure/&os_username=justsomedude%40somewhere.com&os_password=*
> [DEBUG] Successfully logged in into JIRA.
> [DEBUG] download jira issues from url
> http
[jira] (MCOMPILER-141) do not create generated-sources folder when proc = none
[
https://jira.codehaus.org/browse/MCOMPILER-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311166#comment-311166
]
Jesse Glick commented on MCOMPILER-141:
---
Even more common is that is that {{none}} has not been specified
but no sources were generated. I think a better fix would be to just delete
these directories after compilation if they remain empty.
> do not create generated-sources folder when proc = none
> ---
>
> Key: MCOMPILER-141
> URL: https://jira.codehaus.org/browse/MCOMPILER-141
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Minas Manthos
>
> Currently generated-source folder
> (generatedSourcesDirectory/generatedTestSourcesDirectory) is always created,
> even if none is set.
> if proc is none, then folders should not be generated and also not added to
> javac command line...
> We have a lot of modules in our projects and only a few have
> annotationsProcesses. Our IDE adds all generated-source folder to Project but
> mostly of them are empty and overview suffers.
--
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-356) aggegating javadoc-resources of depending projects does not work
Gert Vanderseypen created MJAVADOC-356: -- Summary: aggegating javadoc-resources of depending projects does not work Key: MJAVADOC-356 URL: https://jira.codehaus.org/browse/MJAVADOC-356 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.9 Reporter: Gert Vanderseypen Attachments: workspace-javadoc-test.rar The maven-javadoc-plugin documentation describes how to include javadoc-resources of dependent projects. http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate-dependency-sources.html Preliminary step: make the "dependent project" generate (install) javadoc.jar + javadoc-resources.jar Afterwards it's said that maven should automatically take the dependent javadoc-resources during the aggragation process, just like for the javadoc itself. This is exactly what we need. It seems to work fine for the javadoc itself, but not for the resources. My test project can be found in attachment. I use maven 2.2.1 (I tried it also with maven 3.0.4) first I install my project dep1: mvn clean install site >>> i look in the maven repo, and it seems my dep1 javadoc-resources.jar are >>> installed, but it contains nothing, because i have no resources in this >>> project of course. thereafter I install my project dep2: mvn clean install site >>> (i look in the maven repo, and it seems my dep2 javadoc-resources.jar are >>> installed, and its content contains the right resource image thereafter I install my project Service, which is configured to only contain the javadoc (and thus also the resources?) from dep2: mvn clean install site however, it seems when I open the site/javadoc folder, it contains the javadoc from dep2, but it does NOT contain the resources! I suppose this is not normal? -- 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
