[jira] (MDEP-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306969#comment-306969
]
Tim Moore commented on MDEP-368:
OK with 2.5.1-SNAPSHOT (built locally) and true in
the plugin configuration, my project's build went down from ~7 minutes to
2m26s. (y)
That's about the same as with version 2.4 (actually a little better!) Thanks
again!
> Configure plexus-archiver to use java.io.File methods to set permissions when
> available.
>
>
> Key: MDEP-368
> URL: https://jira.codehaus.org/browse/MDEP-368
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: unpack, unpack-dependencies
>Affects Versions: 2.5
>Reporter: Tim Moore
>Assignee: Olivier Lamy
> Fix For: 2.5.1
>
> Attachments: useJvmChmod.patch
>
>
> We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
> that it slowed down significantly. Our build process involves unpacking
> several large zip files, and profiling the build showed us that the extra
> time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
> executing a {{chmod}} process for each file in the archive.
> We tracked this change to an update of the Plexus Archiver dependency from
> 2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
> http://svn.apache.org/viewvc?view=revision&revision=1292983
> Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
> and {{setExecutable}} methods on {{java.io.File}} instead of executing
> {{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
> using reflection when they are available, falling back on executing {{chmod}}
> when they are not, so it remains backwards compatible with Java 5.
> This configuration is disabled by default, but can be configured via Plexus.
> The attached patch to Maven Dependency Plugin sets the archiver components to
> use the JVM implementation when available.
> The patch doesn't include tests, since the behavior is dependent on the Java
> version used, but when applied all of the existing tests pass in Java 6.
> Credit for the investigation and the patch is due to Vincent Choy
> (vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306958#comment-306958
]
Tim Moore commented on MDEP-368:
Where is this deployed? I get this when building:
{noformat}
[ERROR] BUILD ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.maven.plugins:maven-dependency-plugin
Reason: POM 'org.apache.maven.plugins:maven-dependency-plugin' not found in
repository: Unable to download the artifact from any repository
org.apache.maven.plugins:maven-dependency-plugin:pom:2.5.1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
for project org.apache.maven.plugins:maven-dependency-plugin
{noformat}
I can build it from source but I might not be able to do this before next week.
Thanks for the quick fix, and sorry that I haven't had a chance to test it yet.
> Configure plexus-archiver to use java.io.File methods to set permissions when
> available.
>
>
> Key: MDEP-368
> URL: https://jira.codehaus.org/browse/MDEP-368
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: unpack, unpack-dependencies
>Affects Versions: 2.5
>Reporter: Tim Moore
>Assignee: Olivier Lamy
> Fix For: 2.5.1
>
> Attachments: useJvmChmod.patch
>
>
> We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
> that it slowed down significantly. Our build process involves unpacking
> several large zip files, and profiling the build showed us that the extra
> time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
> executing a {{chmod}} process for each file in the archive.
> We tracked this change to an update of the Plexus Archiver dependency from
> 2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
> http://svn.apache.org/viewvc?view=revision&revision=1292983
> Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
> and {{setExecutable}} methods on {{java.io.File}} instead of executing
> {{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
> using reflection when they are available, falling back on executing {{chmod}}
> when they are not, so it remains backwards compatible with Java 5.
> This configuration is disabled by default, but can be configured via Plexus.
> The attached patch to Maven Dependency Plugin sets the archiver components to
> use the JVM implementation when available.
> The patch doesn't include tests, since the behavior is dependent on the Java
> version used, but when applied all of the existing tests pass in Java 6.
> Credit for the investigation and the patch is due to Vincent Choy
> (vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306615#comment-306615
]
Tim Moore commented on MDEP-368:
I should add the tests pass with Java 5 too, but with a log message indicating
that useJvmChmod doesn't work with the Java version in use.
> Configure plexus-archiver to use java.io.File methods to set permissions when
> available.
>
>
> Key: MDEP-368
> URL: https://jira.codehaus.org/browse/MDEP-368
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: unpack, unpack-dependencies
>Affects Versions: 2.5
>Reporter: Tim Moore
> Attachments: useJvmChmod.patch
>
>
> We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
> that it slowed down significantly. Our build process involves unpacking
> several large zip files, and profiling the build showed us that the extra
> time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
> executing a {{chmod}} process for each file in the archive.
> We tracked this change to an update of the Plexus Archiver dependency from
> 2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
> http://svn.apache.org/viewvc?view=revision&revision=1292983
> Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
> and {{setExecutable}} methods on {{java.io.File}} instead of executing
> {{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
> using reflection when they are available, falling back on executing {{chmod}}
> when they are not, so it remains backwards compatible with Java 5.
> This configuration is disabled by default, but can be configured via Plexus.
> The attached patch to Maven Dependency Plugin sets the archiver components to
> use the JVM implementation when available.
> The patch doesn't include tests, since the behavior is dependent on the Java
> version used, but when applied all of the existing tests pass in Java 6.
> Credit for the investigation and the patch is due to Vincent Choy
> (vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
Tim Moore created MDEP-368:
--
Summary: Configure plexus-archiver to use java.io.File methods to
set permissions when available.
Key: MDEP-368
URL: https://jira.codehaus.org/browse/MDEP-368
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack, unpack-dependencies
Affects Versions: 2.5
Reporter: Tim Moore
Attachments: useJvmChmod.patch
We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found that
it slowed down significantly. Our build process involves unpacking several
large zip files, and profiling the build showed us that the extra time was
spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was executing
a {{chmod}} process for each file in the archive.
We tracked this change to an update of the Plexus Archiver dependency from 2.0
to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
http://svn.apache.org/viewvc?view=revision&revision=1292983
Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
and {{setExecutable}} methods on {{java.io.File}} instead of executing
{{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
using reflection when they are available, falling back on executing {{chmod}}
when they are not, so it remains backwards compatible with Java 5.
This configuration is disabled by default, but can be configured via Plexus.
The attached patch to Maven Dependency Plugin sets the archiver components to
use the JVM implementation when available.
The patch doesn't include tests, since the behavior is dependent on the Java
version used, but when applied all of the existing tests pass in Java 6.
Credit for the investigation and the patch is due to Vincent Choy
(vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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-109) Dependency plugin looses file permissions when unpacking or copying artifact items
[
https://jira.codehaus.org/browse/MDEP-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306541#comment-306541
]
Tim Moore commented on MDEP-109:
Great, Vincent. I'm not actually a committer, so I don't have any permission to
close the issue. This is just something we happened to notice in our own use of
the Maven Dependency Plugin.
The actual change is here:
http://svn.apache.org/viewvc?view=revision&revision=1292983
There's no JIRA issue key referenced in the commit message, so maybe there is
no duplicate issue.
> Dependency plugin looses file permissions when unpacking or copying artifact
> items
> --
>
> Key: MDEP-109
> URL: https://jira.codehaus.org/browse/MDEP-109
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy, copy-dependencies, unpack, unpack-dependencies
>Affects Versions: 2.0-alpha-4
>Reporter: Vincent Massol
>Assignee: Brian Fox
>
> I have to add the following ugly config in my pom.xml to overcome this:
> {code}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> prepare-package
>
> run
>
>
>
>
> file="${project.build.directory}/dependency/bin/windres" perm="ugo+rx"/>
> perm="ugo+rx"/>
> ...
> {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] (MDEP-109) Dependency plugin looses file permissions when unpacking or copying artifact items
[
https://jira.codehaus.org/browse/MDEP-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306421#comment-306421
]
Tim Moore commented on MDEP-109:
It isn't magical, the dependency on plexus-archiver was updated to a version
that runs chmod on each file it unpacks. I discovered this because it caused a
massive performance regression in our builds! (I'll file a bug report with a
patch for that on Monday.)
I don't have an actual test case, I was more intending to prompt the original
reporter to give it a try with 2.5.
> Dependency plugin looses file permissions when unpacking or copying artifact
> items
> --
>
> Key: MDEP-109
> URL: https://jira.codehaus.org/browse/MDEP-109
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy, copy-dependencies, unpack, unpack-dependencies
>Affects Versions: 2.0-alpha-4
>Reporter: Vincent Massol
>Assignee: Brian Fox
>
> I have to add the following ugly config in my pom.xml to overcome this:
> {code}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> prepare-package
>
> run
>
>
>
>
> file="${project.build.directory}/dependency/bin/windres" perm="ugo+rx"/>
> perm="ugo+rx"/>
> ...
> {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] (MDEP-109) Dependency plugin looses file permissions when unpacking or copying artifact items
[
https://jira.codehaus.org/browse/MDEP-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306401#comment-306401
]
Tim Moore commented on MDEP-109:
I think this is fixed in version 2.5.
> Dependency plugin looses file permissions when unpacking or copying artifact
> items
> --
>
> Key: MDEP-109
> URL: https://jira.codehaus.org/browse/MDEP-109
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy, copy-dependencies, unpack, unpack-dependencies
>Affects Versions: 2.0-alpha-4
>Reporter: Vincent Massol
>Assignee: Brian Fox
>
> I have to add the following ugly config in my pom.xml to overcome this:
> {code}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> prepare-package
>
> run
>
>
>
>
> file="${project.build.directory}/dependency/bin/windres" perm="ugo+rx"/>
> perm="ugo+rx"/>
> ...
> {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] Closed: (MCHECKSTYLE-136) Running checkstyle:check on the top-level POM of a multi-module build fails
[
http://jira.codehaus.org/browse/MCHECKSTYLE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Moore closed MCHECKSTYLE-136.
-
Resolution: Duplicate
> Running checkstyle:check on the top-level POM of a multi-module build fails
> ---
>
> Key: MCHECKSTYLE-136
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-136
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Tim Moore
>
> {noformat}
> [INFO] [checkstyle:check]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] basedir /Users/tmoore/Projects/atlassian/JST/src/main/java does not
> exist
> [INFO]
>
> [INFO] Trace
> java.lang.IllegalStateException: basedir
> /Users/tmoore/Projects/atlassian/JST/src/main/java does not exist
> at
> org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:550)
> at
> org.codehaus.plexus.util.FileUtils.getFileAndDirectoryNames(FileUtils.java:1717)
> at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1645)
> at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1627)
> at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1601)
> at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1584)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getFilesToProcess(DefaultCheckstyleExecutor.java:407)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:89)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:393)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> 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.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)
> {noformat}
> This is without an existing report. It appears to be a regression of
> MCHECKSTYLE-25 and MCHECKSTYLE-26
> Probably introduced when the check mojo was refactored to invoke checkstyle
> directly rather than executing the report
> (http://svn.apache.org/viewvc?view=revision&revision=836274)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-136) Running checkstyle:check on the top-level POM of a multi-module build fails
[
http://jira.codehaus.org/browse/MCHECKSTYLE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216256#action_216256
]
Tim Moore commented on MCHECKSTYLE-136:
---
Oliver,
The {{-Dcheckstyle.skipExec}} flag is a bit of a trick. That tells the
{{checkstyle:check}} goal not to run Checkstyle itself, but to check the
existing results of a previous run. The {{checkstyle:checkstyle}} invocation
right before it _does_ run Checkstyle, and doesn't look at the
{{checkstyle.skipExec}} property, so the result is functionally the same, IIUC.
On further investigation, I think this issue is a duplicate of MCHECKSTYLE-130,
which means it is fixed in trunk. I haven't tried yet, as there does not appear
to be a 2.6-SNAPSHOT build available in central, and I haven't had a chance to
build it myself.
> Running checkstyle:check on the top-level POM of a multi-module build fails
> ---
>
> Key: MCHECKSTYLE-136
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-136
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Tim Moore
>
> {noformat}
> [INFO] [checkstyle:check]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] basedir /Users/tmoore/Projects/atlassian/JST/src/main/java does not
> exist
> [INFO]
>
> [INFO] Trace
> java.lang.IllegalStateException: basedir
> /Users/tmoore/Projects/atlassian/JST/src/main/java does not exist
> at
> org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:550)
> at
> org.codehaus.plexus.util.FileUtils.getFileAndDirectoryNames(FileUtils.java:1717)
> at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1645)
> at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1627)
> at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1601)
> at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1584)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getFilesToProcess(DefaultCheckstyleExecutor.java:407)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:89)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:393)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> 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.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)
> {noformat}
> This is without an existing report. It appears to be a regression of
> MCHECKSTYLE-25 and MCHECKSTYLE-26
> Probably introduced when the check mojo was refactored to invoke checkstyle
> directly rather than executing the report
> (http://svn.apache.org/viewvc?view=revision&revision=836274)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-136) Running checkstyle:check on the top-level POM of a multi-module build fails
[
http://jira.codehaus.org/browse/MCHECKSTYLE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215245#action_215245
]
Tim Moore commented on MCHECKSTYLE-136:
---
Workaround, run: '{{mvn checkstyle:checkstyle checkstyle:check
-Dcheckstyle.skipExec}}' instead of '{{mvn checkstyle:check}}'
> Running checkstyle:check on the top-level POM of a multi-module build fails
> ---
>
> Key: MCHECKSTYLE-136
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-136
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Tim Moore
>
> {noformat}
> [INFO] [checkstyle:check]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] basedir /Users/tmoore/Projects/atlassian/JST/src/main/java does not
> exist
> [INFO]
>
> [INFO] Trace
> java.lang.IllegalStateException: basedir
> /Users/tmoore/Projects/atlassian/JST/src/main/java does not exist
> at
> org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:550)
> at
> org.codehaus.plexus.util.FileUtils.getFileAndDirectoryNames(FileUtils.java:1717)
> at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1645)
> at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1627)
> at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1601)
> at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1584)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getFilesToProcess(DefaultCheckstyleExecutor.java:407)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:89)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:393)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> 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.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)
> {noformat}
> This is without an existing report. It appears to be a regression of
> MCHECKSTYLE-25 and MCHECKSTYLE-26
> Probably introduced when the check mojo was refactored to invoke checkstyle
> directly rather than executing the report
> (http://svn.apache.org/viewvc?view=revision&revision=836274)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHECKSTYLE-136) Running checkstyle:check on the top-level POM of a multi-module build fails
Running checkstyle:check on the top-level POM of a multi-module build fails
---
Key: MCHECKSTYLE-136
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-136
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.5
Reporter: Tim Moore
{noformat}
[INFO] [checkstyle:check]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] basedir /Users/tmoore/Projects/atlassian/JST/src/main/java does not exist
[INFO]
[INFO] Trace
java.lang.IllegalStateException: basedir
/Users/tmoore/Projects/atlassian/JST/src/main/java does not exist
at
org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:550)
at
org.codehaus.plexus.util.FileUtils.getFileAndDirectoryNames(FileUtils.java:1717)
at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1645)
at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1627)
at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1601)
at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1584)
at
org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getFilesToProcess(DefaultCheckstyleExecutor.java:407)
at
org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:89)
at
org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:393)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
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.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)
{noformat}
This is without an existing report. It appears to be a regression of
MCHECKSTYLE-25 and MCHECKSTYLE-26
Probably introduced when the check mojo was refactored to invoke checkstyle
directly rather than executing the report
(http://svn.apache.org/viewvc?view=revision&revision=836274)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2552) JUnit 4.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187651#action_187651 ] Tim Moore commented on MAVENUPLOAD-2552: This doesn't seem to have included the "junit-dep" alternate artifact that is there for 4.4 and 4.5 (though not 4.6): http://sourceforge.net/projects/junit/files/junit/4.7/junit-dep-4.7.jar/download Honestly, IMO, the "dep" version should replace the standard junit:junit artifact entirely, since the standard junit artifact contains a bundled Hamcrest dependency that wreaks havoc if you depend on a newer version of Hamcrest elsewhere. But if others disagree, then at least keeping the junit-dep artifact id up-to-date with the junit artifact would be great. > JUnit 4.7 > - > > Key: MAVENUPLOAD-2552 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2552 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Simon Brandhof >Assignee: Carlos Sanchez > Attachments: junit-4.7-bundle.jar > > > Please upload this new version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
