[jira] Closed: (MCHECKSTYLE-158) Embedded error: Unable to copy static resources
[
https://jira.codehaus.org/browse/MCHECKSTYLE-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashok Manji closed MCHECKSTYLE-158.
---
Resolution: Not A Bug
For your information, this issue was resolved by simply adding the
outputDirectory parameter to the maven-checkstyle-plugin configuration in the
pom file. i.e.
outputDirectory${project.build.directory}/checkstyle/outputDirectory
When this was not defined, the reports etc were being written to /target (the
ROOT directory on the filesystem) and not the project's build directory /target
directory.
Embedded error: Unable to copy static resources
---
Key: MCHECKSTYLE-158
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-158
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.6
Environment: Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_22
Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 2.6.32-28-server arch: amd64 Family: unix
Reporter: Ashok Manji
Attachments: rss.png_checkstyle_error.rtf
On a local developer machine, running checkstyle completes successfully,
however, when running checkstyle on a server (Environment details above), the
following build error occurs relating to rss.png. I cannot seem to figure
this out. Cleaning out the maven repository, re-downloading, going back to
version 2.5 makes no difference. Works locally, but not on a server.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An error has occurred in Checkstyle report generation.
Embedded error: Unable to copy static resources.
/target/images/rss.png (No such file or directory)
[INFO]
Attached full stacktrace to this ticket.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5145) Optional compile dependencies being resolved by test dependencies
[
https://jira.codehaus.org/browse/MNG-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274733#comment-274733
]
Benjamin Bentmann commented on MNG-5145:
Part of the issue is {{commons-logging:1.1}}, declaring
{{commons-logging:1.1.1}} in {{dependencyManagement}} can be used to
workaround the bug.
Optional compile dependencies being resolved by test dependencies
-
Key: MNG-5145
URL: https://jira.codehaus.org/browse/MNG-5145
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0.3
Reporter: Robert Watkins
Priority: Critical
Attachments: pom.xml
Optional compile-time dependencies are being resolved (in WAR projects, at
least) into the packaged artifact.
There has been a regression since Maven 2.2.1 in regards to resolving
optional dependencies.
In the attached pom (which builds a WAR), there are two dependencies:
* org.springframework:spring-core:2.5.6 - at compile scope
* org.dbunit:dbunit:2.3.0 - at test scope.
The dependency tree looks like this:
net.twasink:webapp:war:1.0
+- org.springframework:spring-core:jar:2.5.6:compile
| \- commons-logging:commons-logging:jar:1.1.1:compile
\- org.dbunit:dbunit:jar:2.3.0:test
+- junit:junit:jar:3.8.2:test
+- junit-addons:junit-addons:jar:1.4:test
| +- xerces:xercesImpl:jar:2.6.2:test
| \- xerces:xmlParserAPIs:jar:2.6.2:test
+- org.apache.poi:poi:jar:3.1-FINAL:test
| \- log4j:log4j:jar:1.2.13:test
+- commons-collections:commons-collections:jar:3.1:test
+- commons-lang:commons-lang:jar:2.1:test
+- org.slf4j:slf4j-api:jar:1.4.3:test
\- org.slf4j:slf4j-nop:jar:1.4.3:test
Note that log4j:log4j:1.2.13 is a test dependency. However, when you do 'mvn
package', and inspect the resulting WAR file, it includes log4j!
The problem appears to be that commons-logging (a compile dependency brought
in by spring-core) declares log4j as an _optional_ compile dependency. This
is clashing with the test dependency brought in transitively by dbunit.
To make it worse, this is still brought in if you add an explicit exclusion
of log4j to spring-core.
Maven 2.2.1 did not bring in the log4j JAR - this is a regression under Maven
3.0.3
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MVERIFIER-10) Print the absolute path to the input file when verification fails
[
https://jira.codehaus.org/browse/MVERIFIER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MVERIFIER-10.
-
Resolution: Fixed
Assignee: Olivier Lamy
fixed r1152710
Print the absolute path to the input file when verification fails
-
Key: MVERIFIER-10
URL: https://jira.codehaus.org/browse/MVERIFIER-10
Project: Maven 2.x Verifier Plugin
Issue Type: New Feature
Reporter: Aaron Digulla
Assignee: Olivier Lamy
While building Tycho, I had this exception:
{{org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
mavenProfile entry. Missing one or more fields: {localRepository}.}}
The error message was useless for me because I have no idea which file caused
the error.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-162) Upgrade to checkstyle 5.4
[ https://jira.codehaus.org/browse/MCHECKSTYLE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCHECKSTYLE-162. Resolution: Fixed Assignee: Olivier Lamy fixed [rev 1152718|http://svn.apache.org/viewvc?rev=1152718view=rev] Upgrade to checkstyle 5.4 - Key: MCHECKSTYLE-162 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-162 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.7 Reporter: HuiSheng Xu Assignee: Olivier Lamy Since checkstyle 5.4 has bean released, and current version of maven-checkstyle-plugin has supported checktyle 5.3. I think it is a good idea to upgrade checkstyle to 5.4. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHECKSTYLE-162) Upgrade to checkstyle 5.4
[ https://jira.codehaus.org/browse/MCHECKSTYLE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCHECKSTYLE-162: - Affects Version/s: (was: 2.7) 2.6 Fix Version/s: 2.7 Upgrade to checkstyle 5.4 - Key: MCHECKSTYLE-162 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-162 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.6 Reporter: HuiSheng Xu Assignee: Olivier Lamy Fix For: 2.7 Since checkstyle 5.4 has bean released, and current version of maven-checkstyle-plugin has supported checktyle 5.3. I think it is a good idea to upgrade checkstyle to 5.4. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MCHECKSTYLE-162) Upgrade to checkstyle 5.4
[ https://jira.codehaus.org/browse/MCHECKSTYLE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reopened MCHECKSTYLE-162: -- Upgrade to checkstyle 5.4 - Key: MCHECKSTYLE-162 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-162 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.6 Reporter: HuiSheng Xu Assignee: Olivier Lamy Fix For: 2.7 Since checkstyle 5.4 has bean released, and current version of maven-checkstyle-plugin has supported checktyle 5.3. I think it is a good idea to upgrade checkstyle to 5.4. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-162) Upgrade to checkstyle 5.4
[ https://jira.codehaus.org/browse/MCHECKSTYLE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCHECKSTYLE-162. Resolution: Fixed update fix version Upgrade to checkstyle 5.4 - Key: MCHECKSTYLE-162 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-162 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.6 Reporter: HuiSheng Xu Assignee: Olivier Lamy Fix For: 2.7 Since checkstyle 5.4 has bean released, and current version of maven-checkstyle-plugin has supported checktyle 5.3. I think it is a good idea to upgrade checkstyle to 5.4. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5145) Optional compile dependencies being resolved by test dependencies
[ https://jira.codehaus.org/browse/MNG-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274738#comment-274738 ] Robert Watkins commented on MNG-5145: - As shown in the dependency tree, this is already using commongs-logging:1.1.1 AFAIK, commons-logging:1.1.1 is doing the right thing by declaring the dependency on log4j optional. Certainly the attached pom worked correctly under Maven 2.2. Optional compile dependencies being resolved by test dependencies - Key: MNG-5145 URL: https://jira.codehaus.org/browse/MNG-5145 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.3 Reporter: Robert Watkins Priority: Critical Attachments: pom.xml Optional compile-time dependencies are being resolved (in WAR projects, at least) into the packaged artifact. There has been a regression since Maven 2.2.1 in regards to resolving optional dependencies. In the attached pom (which builds a WAR), there are two dependencies: * org.springframework:spring-core:2.5.6 - at compile scope * org.dbunit:dbunit:2.3.0 - at test scope. The dependency tree looks like this: net.twasink:webapp:war:1.0 +- org.springframework:spring-core:jar:2.5.6:compile | \- commons-logging:commons-logging:jar:1.1.1:compile \- org.dbunit:dbunit:jar:2.3.0:test +- junit:junit:jar:3.8.2:test +- junit-addons:junit-addons:jar:1.4:test | +- xerces:xercesImpl:jar:2.6.2:test | \- xerces:xmlParserAPIs:jar:2.6.2:test +- org.apache.poi:poi:jar:3.1-FINAL:test | \- log4j:log4j:jar:1.2.13:test +- commons-collections:commons-collections:jar:3.1:test +- commons-lang:commons-lang:jar:2.1:test +- org.slf4j:slf4j-api:jar:1.4.3:test \- org.slf4j:slf4j-nop:jar:1.4.3:test Note that log4j:log4j:1.2.13 is a test dependency. However, when you do 'mvn package', and inspect the resulting WAR file, it includes log4j! The problem appears to be that commons-logging (a compile dependency brought in by spring-core) declares log4j as an _optional_ compile dependency. This is clashing with the test dependency brought in transitively by dbunit. To make it worse, this is still brought in if you add an explicit exclusion of log4j to spring-core. Maven 2.2.1 did not bring in the log4j JAR - this is a regression under Maven 3.0.3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-160) Checkstyle does not take into account proxy settings from settings.xml
[ https://jira.codehaus.org/browse/MCHECKSTYLE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCHECKSTYLE-160. Resolution: Duplicate Assignee: Olivier Lamy Checkstyle does not take into account proxy settings from settings.xml -- Key: MCHECKSTYLE-160 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-160 Project: Maven 2.x Checkstyle Plugin Issue Type: Sub-task Affects Versions: 2.6 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: C:\PROGRA~1\APACHE~1\APACHE~1.3 Java version: 1.6.0_23, vendor: Sun Microsystems Inc. Java home: c:\Program Files\Java\jdk1.6.0_23\jre Default locale: de_DE, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows Reporter: Heinrich Schuchardt Assignee: Olivier Lamy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5145) Optional compile dependencies being resolved by test dependencies
[ https://jira.codehaus.org/browse/MNG-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274743#comment-274743 ] Robert Watkins commented on MNG-5145: - Ah - this appears to be related to http://jira.codehaus.org/browse/MNG-5056. Similar behaviour, anyway. Optional compile dependencies being resolved by test dependencies - Key: MNG-5145 URL: https://jira.codehaus.org/browse/MNG-5145 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.3 Reporter: Robert Watkins Priority: Critical Attachments: pom.xml Optional compile-time dependencies are being resolved (in WAR projects, at least) into the packaged artifact. There has been a regression since Maven 2.2.1 in regards to resolving optional dependencies. In the attached pom (which builds a WAR), there are two dependencies: * org.springframework:spring-core:2.5.6 - at compile scope * org.dbunit:dbunit:2.3.0 - at test scope. The dependency tree looks like this: net.twasink:webapp:war:1.0 +- org.springframework:spring-core:jar:2.5.6:compile | \- commons-logging:commons-logging:jar:1.1.1:compile \- org.dbunit:dbunit:jar:2.3.0:test +- junit:junit:jar:3.8.2:test +- junit-addons:junit-addons:jar:1.4:test | +- xerces:xercesImpl:jar:2.6.2:test | \- xerces:xmlParserAPIs:jar:2.6.2:test +- org.apache.poi:poi:jar:3.1-FINAL:test | \- log4j:log4j:jar:1.2.13:test +- commons-collections:commons-collections:jar:3.1:test +- commons-lang:commons-lang:jar:2.1:test +- org.slf4j:slf4j-api:jar:1.4.3:test \- org.slf4j:slf4j-nop:jar:1.4.3:test Note that log4j:log4j:1.2.13 is a test dependency. However, when you do 'mvn package', and inspect the resulting WAR file, it includes log4j! The problem appears to be that commons-logging (a compile dependency brought in by spring-core) declares log4j as an _optional_ compile dependency. This is clashing with the test dependency brought in transitively by dbunit. To make it worse, this is still brought in if you add an explicit exclusion of log4j to spring-core. Maven 2.2.1 did not bring in the log4j JAR - this is a regression under Maven 3.0.3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5056) Test dependencies get packaged into WAR file.
[ https://jira.codehaus.org/browse/MNG-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274744#comment-274744 ] Robert Watkins commented on MNG-5056: - See http://jira.codehaus.org/browse/MNG-5145 for a probably related bug. Test dependencies get packaged into WAR file. - Key: MNG-5056 URL: https://jira.codehaus.org/browse/MNG-5056 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.3 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /usr/share/maven Java version: 1.6.0_24, 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.6.6, arch: x86_64, family: mac Reporter: Lars Vonk Priority: Critical Attachments: debug.out, web.zip When I add the following dependency as scope test in my pom.xml some of its transitive dependencies (I guess) still get packaged into the WAR file. dependency groupIdcom.atomikos/groupId artifactIdtransactions-jta/artifactId version3.6.4/version scopetest/scope /dependency -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-349) Property not available in config when defaultValue in descriptor contains token
[
https://jira.codehaus.org/browse/ARCHETYPE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse McConnell updated ARCHETYPE-349:
--
Attachment: archetype-349.patch
reformatted patch, applies from the top of the archetype project
Property not available in config when defaultValue in descriptor contains
token
---
Key: ARCHETYPE-349
URL: https://jira.codehaus.org/browse/ARCHETYPE-349
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0
Environment: any
Reporter: Petr Janata
Attachments: archetype-349.patch, test_and_patch.tgz
There is a bug with property resolving when calling archetype:generate mojo.
Default property value provided in archetype descriptor hides the value
passed as parameter to mojo.
archetype-metadata.xml:
{code:xml}requiredProperty key=foo
defaultValue${some.name}/defaultValue
/requiredProperty{code}
running:
{noformat}mvn archetype:generate ... -Dfoo=bar
...
Define value for property 'foo': ${some.name}: :{noformat}
Generation stops and asks for value of property foo although it was passed as
parameter.
I have attached example archetype and patch that solves this issue.
Please review and focus on suspicious line (112 before patching, 116 after
patching).
Basically the default value from metadata should be ignored, when value is
explicitly set.
Handling nested tokens is a different story...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-349) Property not available in config when defaultValue in descriptor contains token
[
https://jira.codehaus.org/browse/ARCHETYPE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed ARCHETYPE-349.
--
Resolution: Fixed
Fix Version/s: 2.1
Assignee: Brett Porter
Patch applied, thanks both!
Property not available in config when defaultValue in descriptor contains
token
---
Key: ARCHETYPE-349
URL: https://jira.codehaus.org/browse/ARCHETYPE-349
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0
Environment: any
Reporter: Petr Janata
Assignee: Brett Porter
Fix For: 2.1
Attachments: archetype-349.patch, test_and_patch.tgz
There is a bug with property resolving when calling archetype:generate mojo.
Default property value provided in archetype descriptor hides the value
passed as parameter to mojo.
archetype-metadata.xml:
{code:xml}requiredProperty key=foo
defaultValue${some.name}/defaultValue
/requiredProperty{code}
running:
{noformat}mvn archetype:generate ... -Dfoo=bar
...
Define value for property 'foo': ${some.name}: :{noformat}
Generation stops and asks for value of property foo although it was passed as
parameter.
I have attached example archetype and patch that solves this issue.
Please review and focus on suspicious line (112 before patching, 116 after
patching).
Basically the default value from metadata should be ignored, when value is
explicitly set.
Handling nested tokens is a different story...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-446) Surefire fails to capture TestNG results when forkMode=always
[
https://jira.codehaus.org/browse/SUREFIRE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lynch updated SUREFIRE-446:
-
Fix Version/s: (was: Backlog)
2.9
Surefire fails to capture TestNG results when forkMode=always
-
Key: SUREFIRE-446
URL: https://jira.codehaus.org/browse/SUREFIRE-446
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.4
Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
Reporter: Benjamin Bentmann
Fix For: 2.9
Attachments: testng-fork-mode-it.patch
The interplay between {{surefire.Surefire}} and
{{testng.TestNGDirectoryTestSuite}} does not properly notify the
ReportManager such that it reports 0 executed tests after the end of the day.
IT to reproduce attached.
Also confirmed against 2.5-SNAPSHOT.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-446) Surefire fails to capture TestNG results when forkMode=always
[
https://jira.codehaus.org/browse/SUREFIRE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274765#comment-274765
]
Peter Lynch edited comment on SUREFIRE-446 at 8/1/11 10:42 AM:
---
velo's patch was applied and included in the 2.9 release.
http://svn.apache.org/viewvc?view=revisionrevision=1133426
Didn't see another reason to keep this issue open - if there is, feel free to
reopen it.
was (Author: plynch):
velo's patch was applied and included in the 2.9 release.
http://svn.apache.org/viewvc?view=revisionrevision=1133426
Surefire fails to capture TestNG results when forkMode=always
-
Key: SUREFIRE-446
URL: https://jira.codehaus.org/browse/SUREFIRE-446
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.4
Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
Reporter: Benjamin Bentmann
Fix For: 2.9
Attachments: testng-fork-mode-it.patch
The interplay between {{surefire.Surefire}} and
{{testng.TestNGDirectoryTestSuite}} does not properly notify the
ReportManager such that it reports 0 executed tests after the end of the day.
IT to reproduce attached.
Also confirmed against 2.5-SNAPSHOT.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-22) Compilation fails: The command line is too long.
[ https://jira.codehaus.org/browse/MCOMPILER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274776#comment-274776 ] David Biesack commented on MCOMPILER-22: On a slightly related note, our javac builds in Maven (using v 2.3.2 of the compiler plugin) was failing with a similar error [INFO] Compilation failure error: error reading /u/sasdjb/.m2/repository/com/sas/commons/lang/sas.commons.lang/1.1-SNAPSHOT/sas.commons.lang-1.1-SNAPSHOT.jar; line too long It was unrelated to this old and fixed problem, but I want to add a note here since a web search for my problem lead me here, and there were no other hints. So this may help others who search for compilation failure and error reading and line too long My problem turned out to be due to a bad (manual) MANIFEST.MF created in a dependent jar's maven build. (we require specific manifest entries not created by default) I fixed the MANIFEST.MF generation and rebuilt it, and this solved the javac error. javac was not complaining about the command line being too long, but about a line in the MANIFEST.MF file in the jar being too long -- although it does not say that. Compilation fails: The command line is too long. -- Key: MCOMPILER-22 URL: https://jira.codehaus.org/browse/MCOMPILER-22 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0, 2.0.1 Reporter: Matthew Beermann Assignee: Carlos Sanchez Priority: Critical Fix For: 2.0.2 Attachments: maven-compiler-plugin.patch, maven-compiler-plugin-space-fix.patch, MCOMPILER-22.patch, MNG-MCCOMPILER-22-maven-compiler-plugin.patch, MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, plexus-compiler-javac.patch For one of my project, compilation fails with the message The command line is too long. As far as I can tell, it's listing each and every source file, one at a time, in the -sourcepath attribute. (?!?) Here's the log: [DEBUG] Source roots: [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src [DEBUG] Command line options: [DEBUG] -d C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes -classpath DEPENDENCIES SNIPPED HERE -sourcepath ENORMOUSLY LONG LIST OF SOURCE FILES HERE -g -nowarn -target 1.4 -source 1.4 Compiling 167 source files to C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure Failure executing javac, but could not parse the error: The command line is too long. [INFO] [DEBUG] Trace org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) at
[jira] Updated: (MNG-3811) Report plugins don't inherit configuration
[
https://jira.codehaus.org/browse/MNG-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-3811:
---
Description:
'm trying to set up reporting plugin inheritance and not having any luck. I'm
using Maven 2.0.9 on Java 1.6.0_07. Here is my problem:
parent/pom.xml has
{code:xml}
reporting
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
silenttrue/silent
links
linkparentLink/link
/links
/configuration
/plugin
/plugins
/reporting{code}
child/pom.xml has
{code:xml} reporting
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
links combine.children=append
linkchildLink/link
/links
/configuration
/plugin
/plugins
/reporting{code}
After installing the parent, mvn help:effective-pom for the child yeilds:
{code:xml} reporting
outputDirectorytarget/site/outputDirectory
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
links
linkchildLink/link
/links
/configuration
/plugin
/plugins
/reporting{code}
I expected it to look like:
{code:xml} reporting
outputDirectorytarget/site/outputDirectory
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
silenttrue/silent
links
linkparentLink/link
linkchildLink/link
/links
/configuration
/plugin
/plugins
/reporting
{code}
I'd be happy to make a test case for this if someone would point me in the
right direction.
was:
'm trying to set up reporting plugin inheritance and not having any luck. I'm
using Maven 2.0.9 on Java 1.6.0_07. Here is my problem:
parent/pom.xml has
reporting
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
silenttrue/silent
links
linkparentLink/link
/links
/configuration
/plugin
/plugins
/reporting
child/pom.xml has
reporting
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
links combine.children=append
linkchildLink/link
/links
/configuration
/plugin
/plugins
/reporting
After installing the parent, mvn help:effective-pom for the child yeilds:
reporting
outputDirectorytarget/site/outputDirectory
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
links
linkchildLink/link
/links
/configuration
/plugin
/plugins
/reporting
I expected it to look like:
reporting
outputDirectorytarget/site/outputDirectory
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
silenttrue/silent
links
linkparentLink/link
linkchildLink/link
/links
/configuration
/plugin
/plugins
/reporting
I'd be happy to make a test case for this if someone would point me in the
right direction.
Report plugins don't inherit configuration
--
Key: MNG-3811
URL: https://jira.codehaus.org/browse/MNG-3811
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 2.0.9, 2.0.11
Environment: Ubuntu x64
java version 1.6.0_0
OpenJDK Runtime Environment (build 1.6.0_0-b11)
OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode)
Reporter: Nik Everett
Assignee: Brett Porter
Priority: Minor
Fix For: 2.0.11, 2.1.0
Attachments: bug.tar.gz, MNG-3811-maven-project.patch
'm trying to set up reporting plugin inheritance and not having any luck.
I'm using Maven 2.0.9 on Java 1.6.0_07. Here is my problem:
parent/pom.xml has
{code:xml}
reporting
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
silenttrue/silent
links
linkparentLink/link
/links
/configuration
/plugin
/plugins
/reporting{code}
child/pom.xml has
{code:xml} reporting
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
links combine.children=append
linkchildLink/link
/links
/configuration
/plugin
/plugins
/reporting{code}
After installing the parent, mvn help:effective-pom for the child yeilds:
{code:xml} reporting
outputDirectorytarget/site/outputDirectory
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
[jira] Created: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
Test classpath resolution fails in mvn check:check when
includeTestSourceDirectory = true
-
Key: MCHECKSTYLE-163
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Chris Whelan
Attachments: resolveTestClasspath.patch
When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
full test classpath should be made available to checkstyle. Patch included to
resolve issue by setting @requiresDependencyResolution to test.
In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
using the classpath string from request.getProject().getTestClasspathElements()
(see DefaultCheckstyleExecutor line 114).
However, the CheckstyleViolationCheckMojo only has
@requiresDependencyResolution compile which means that pom dependencies which
have been declared as scopetest/scope are not returned by
project.getTestClasspathElements().
This is a particular issue for the checkstyle RedundantThrows check
(http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
requires all Exceptions to be available on it's classpath.
If code throws an Exception which has been imported from a maven
scopetest/scope dependency, the exception will not be available on the
classpath and this checkstyle check will fail.
Example:
Include junit as a test scope dependency in the project POM:
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version${junit.version}/version
scopetest/scope
/dependency
Throw any junit exception within project test code, e.g.:
public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
public MyCustomTestRunner(final Class? klass) throws
InitializationError {
If RedundantThrows check is enabled, the following error will be thrown:
[INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @
sample-project ---
[INFO] Starting audit...
C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
warning: Unable to get class information for InitializationError.
Audit done.
[ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
InitializationError.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
