[jira] (MPLUGIN-289) better output when extracting info
Herve Boutemy created MPLUGIN-289:
-
Summary: better output when extracting info
Key: MPLUGIN-289
URL: https://jira.codehaus.org/browse/MPLUGIN-289
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.4
Reporter: Herve Boutemy
Priority: Minor
actual display:
{noformat}[INFO] --- maven-plugin-plugin:3.4:descriptor (default-descriptor) @
hadoop-maven-plugins ---
[INFO] Using 'UTF-8' encoding to read mojo metadata.
[INFO] Mojo extractor with id: java-annotations found 2 mojo descriptors.
[INFO] Mojo extractor with id: java-javadoc found 0 mojo descriptors.{noformat}
instead of {{Mojo extractor with id: java-annotations found 2 mojo
descriptors.}}, something like {{java-annotations Mojo extractor found 2 mojo
descriptors.}} would be more ligthweight
then I don't know why there is this info message {{[INFO] Using 'UTF-8'
encoding to read mojo metadata}}: is it really useful? Shouldn't it be debug
only?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[
https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Williamson updated MPMD-199:
Attachment: JSP_support_201501201523.patch
I have updated the text in the jspReport.apt.vm file, and confirmed that the
double "sample.jsp" entry in the patch file seems to be connected to
TortiseSVN's wanting to create an entry for the new "jsp" directory as well as
the new "sample.jsp" file within it. Removing the directory from the patch
list cured the double-entry problem.
As far as the POM goes, as I said, it does appear to already (version 3.3)
contain the following entry on lines 202-206:
net.sourceforge.pmd
pmd-jsp
${pmdVersion}
So I think we're OK there.
> Support PMD functionality on JSP files
> --
>
> Key: MPMD-199
> URL: https://jira.codehaus.org/browse/MPMD-199
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Affects Versions: 3.3
>Reporter: Tom Williamson
>Priority: Minor
> Attachments: Jsp_support_201501201341.patch,
> JSP_support_201501201523.patch, Patch_for_JSP_support.patch
>
>
> It would be great if this plugin would either support PMD functionality for
> JSP files, or simply enable them as part of the Java support.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[ https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361494#comment-361494 ] Tom Williamson commented on MPMD-199: - I noticed that sample.jsp was in the patch file twice, not being completely familiar with the patch file format I thought it might have something to do with the containing directory being added as well as the file itself. I don't normally use Subversion and have never created patches before, always been a direct committer. I have no idea why it did that, but it was not an edit that I put in - the patch file came directly from TortoiseSVN 1.8.10. You're absolutely right on the second one, but for #3 the POM file already contains a dependency for pmd-jsp in 3.3 - not sure why, but there was no need to add it. I rebuilt the project again with a virgin copy of the original POM and it seems to work fine including the tests. Am I missing something more than that? > Support PMD functionality on JSP files > -- > > Key: MPMD-199 > URL: https://jira.codehaus.org/browse/MPMD-199 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.3 >Reporter: Tom Williamson >Priority: Minor > Attachments: Jsp_support_201501201341.patch, > Patch_for_JSP_support.patch > > > It would be great if this plugin would either support PMD functionality for > JSP files, or simply enable them as part of the Java support. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-282) add info on ruleset used in report intro
[
https://jira.codehaus.org/browse/MCHECKSTYLE-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MCHECKSTYLE-282.
-
Resolution: Fixed
Fix Version/s: 2.14
Assignee: Herve Boutemy
done in [r1653380|http://svn.apache.org/r1653380]
> add info on ruleset used in report intro
>
>
> Key: MCHECKSTYLE-282
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-282
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
> Components: checkstyle:checkstyle, checkstyle:checkstyle-aggregate
>Affects Versions: 2.13
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.14
>
>
> current intro is
> {noformat}The following document contains the results of Checkstyle
> 5.7.{noformat}
> There is no info on the chosen ruleset: ruleset is even more important for
> result than Checkstyle itself!
> Would be better with
> {noformat}The following document contains the results of Checkstyle 5.7 with
> config/maven_checks.xml ruleset.{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[
https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361482#comment-361482
]
Michael Osipov commented on MPMD-199:
-
Tom, way better now. A few issues though:
1. {{sample.jsp}} is added twice, ins't it?
2. You copied the javascript apt file to {{jspReport.apt.vm}} but did not alter
its content.
3. You either need to add the JSP module to the plugins dependencies and/or
make it optional and tell that actually in the docs.
> Support PMD functionality on JSP files
> --
>
> Key: MPMD-199
> URL: https://jira.codehaus.org/browse/MPMD-199
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Affects Versions: 3.3
>Reporter: Tom Williamson
>Priority: Minor
> Attachments: Jsp_support_201501201341.patch,
> Patch_for_JSP_support.patch
>
>
> It would be great if this plugin would either support PMD functionality for
> JSP files, or simply enable them as part of the Java support.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-282) add info on ruleset used in report intro
Herve Boutemy created MCHECKSTYLE-282:
-
Summary: add info on ruleset used in report intro
Key: MCHECKSTYLE-282
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-282
Project: Maven Checkstyle Plugin
Issue Type: Improvement
Components: checkstyle:checkstyle, checkstyle:checkstyle-aggregate
Affects Versions: 2.13
Reporter: Herve Boutemy
current intro is
{noformat}The following document contains the results of Checkstyle
5.7.{noformat}
There is no info on the chosen ruleset: ruleset is even more important for
result than Checkstyle itself!
Would be better with
{noformat}The following document contains the results of Checkstyle 5.7 with
config/maven_checks.xml ruleset.{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[ https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Williamson updated MPMD-199: Attachment: Jsp_support_201501201341.patch New patch file attached, made with SVN from original files, with only the required lines cut/pasted in. Sorry for the additional work this caused. > Support PMD functionality on JSP files > -- > > Key: MPMD-199 > URL: https://jira.codehaus.org/browse/MPMD-199 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.3 >Reporter: Tom Williamson >Priority: Minor > Attachments: Jsp_support_201501201341.patch, > Patch_for_JSP_support.patch > > > It would be great if this plugin would either support PMD functionality for > JSP files, or simply enable them as part of the Java support. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-466) analyze fails on multimodule project (regression)
[ https://jira.codehaus.org/browse/MDEP-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MDEP-466: - Fix Version/s: 2.10 > analyze fails on multimodule project (regression) > - > > Key: MDEP-466 > URL: https://jira.codehaus.org/browse/MDEP-466 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.9 > Environment: Windows 7, Maven 3.0.4, IBM JDK 1.6 & Oracle JDK 1.6.0u39 >Reporter: Anders Hammar > Fix For: 2.10 > > Attachments: analyze-multimodule-project.zip > > > The analyze goal fails on multimodule project with access denied when > analyzing dependency on sibling module. This worked in v2.8 but fails in v2.9. > I've attached a test project (created as an IT). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[ https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361479#comment-361479 ] Tom Williamson commented on MPMD-199: - I will redo the patch and post a corrected one. > Support PMD functionality on JSP files > -- > > Key: MPMD-199 > URL: https://jira.codehaus.org/browse/MPMD-199 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.3 >Reporter: Tom Williamson >Priority: Minor > Attachments: Patch_for_JSP_support.patch > > > It would be great if this plugin would either support PMD functionality for > JSP files, or simply enable them as part of the Java support. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-406) Upgrade maven-shared-utils to 0.7
[ https://jira.codehaus.org/browse/MSHARED-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MSHARED-406. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1653360|http://svn.apache.org/r1653360] > Upgrade maven-shared-utils to 0.7 > - > > Key: MSHARED-406 > URL: https://jira.codehaus.org/browse/MSHARED-406 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-incremental >Affects Versions: maven-shared-incremental-1.1 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: maven-shared-incremental-1.1 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-406) Upgrade maven-shared-utils to 0.7
[ https://jira.codehaus.org/browse/MSHARED-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MSHARED-406: Fix Version/s: maven-shared-incremental-1.1 > Upgrade maven-shared-utils to 0.7 > - > > Key: MSHARED-406 > URL: https://jira.codehaus.org/browse/MSHARED-406 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-incremental >Affects Versions: maven-shared-incremental-1.1 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: maven-shared-incremental-1.1 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-406) Upgrade maven-shared-utils to 0.7
Karl-Heinz Marbaise created MSHARED-406: --- Summary: Upgrade maven-shared-utils to 0.7 Key: MSHARED-406 URL: https://jira.codehaus.org/browse/MSHARED-406 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-incremental Affects Versions: maven-shared-incremental-1.1 Reporter: Karl-Heinz Marbaise Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[ https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361476#comment-361476 ] Dan Tran commented on MPMD-199: --- I reformat the code. Please redo the patch and make sure to use http://maven.apache.org/developers/maven-eclipse-codestyle.xml for the codeslyle > Support PMD functionality on JSP files > -- > > Key: MPMD-199 > URL: https://jira.codehaus.org/browse/MPMD-199 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.3 >Reporter: Tom Williamson >Priority: Minor > Attachments: Patch_for_JSP_support.patch > > > It would be great if this plugin would either support PMD functionality for > JSP files, or simply enable them as part of the Java support. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold reassigned MASSEMBLY-748: Assignee: Kristian Rosenvold > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361474#comment-361474
]
Kristian Rosenvold commented on MASSEMBLY-742:
--
Found the proper culprit this time
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-750) descriptor in "dir" format changes symbolic links in non symlink files
[ https://jira.codehaus.org/browse/MASSEMBLY-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold reassigned MASSEMBLY-750: Assignee: Kristian Rosenvold > descriptor in "dir" format changes symbolic links in non symlink files > -- > > Key: MASSEMBLY-750 > URL: https://jira.codehaus.org/browse/MASSEMBLY-750 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.5.2 > Environment: linux and mac / java 7 >Reporter: Clément Igonet >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > > A descriptor created as dir format changes symlinks as "real" files. > Whereas a descriptor created as tar.gz format keep symlinks as symlinks. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[ https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361473#comment-361473 ] Michael Osipov commented on MPMD-199: - Dan, feel free if you want. Too much changes in the patch consists of whitespace changes that's why I asked Tom to rework the patch. > Support PMD functionality on JSP files > -- > > Key: MPMD-199 > URL: https://jira.codehaus.org/browse/MPMD-199 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.3 >Reporter: Tom Williamson >Priority: Minor > Attachments: Patch_for_JSP_support.patch > > > It would be great if this plugin would either support PMD functionality for > JSP files, or simply enable them as part of the Java support. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-261) Upgrade to Checkstyle 6.1.1
[
https://jira.codehaus.org/browse/MCHECKSTYLE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361472#comment-361472
]
Andrew Gaul commented on MCHECKSTYLE-261:
-
As a workaround, users can specify the Checkstyle dependency manually:
{noformat}
org.apache.maven.plugins
maven-checkstyle-plugin
2.13
com.puppycrawl.tools
checkstyle
5.9
{noformat}
> Upgrade to Checkstyle 6.1.1
> ---
>
> Key: MCHECKSTYLE-261
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-261
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.14
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.15
>
>
> Upgrade to the latest 6.x version of Checkstyle, which at the time of writing
> is 6.1.
> Note that this upgrade will make the Checkstyle plugin require Java 6,
> because Checkstyle requires Java 6 since version 5.9.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-261) Upgrade to Checkstyle 6.1.1
[
https://jira.codehaus.org/browse/MCHECKSTYLE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361471#comment-361471
]
Andrew Gaul commented on MCHECKSTYLE-261:
-
Could you publish a 2.15-SNAPSHOT using Checkstyle 6.1.1? This would allow
users with Java 8 projects with lambdas to use Checkstyle. Presently I see
errors of the form:
{noformat}
/path/SourceFile.java:32:58: unexpected token: >
/path/SourceFile.java:34:13: unexpected token: Clock
{noformat}
> Upgrade to Checkstyle 6.1.1
> ---
>
> Key: MCHECKSTYLE-261
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-261
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.14
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.15
>
>
> Upgrade to the latest 6.x version of Checkstyle, which at the time of writing
> is 6.1.
> Note that this upgrade will make the Checkstyle plugin require Java 6,
> because Checkstyle requires Java 6 since version 5.9.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5510) Maven causing ClassCastException with container plugins when project is using other SLF4J implementation than slf4j-simple
[ https://jira.codehaus.org/browse/MNG-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361470#comment-361470 ] Peter Janes commented on MNG-5510: -- The SonarQube occurrence of this issue mentioned in the second comment may be resolved in 5.1 (SONAR-5701/SONAR-5700). > Maven causing ClassCastException with container plugins when project is using > other SLF4J implementation than slf4j-simple > -- > > Key: MNG-5510 > URL: https://jira.codehaus.org/browse/MNG-5510 > Project: Maven > Issue Type: Bug > Components: Bootstrap & Build, Logging >Affects Versions: 3.1.0 >Reporter: Juan Pablo Santos Rodríguez > Attachments: MNG-5510-sample.zip > > > On our project we're using directly logback to start up a custom mbean to be > able to change log levels dynamically, among other things. Most of these > operations are Logback-specific, they're not available via SLF4J API > For testing we use Jetty, so when we're doing an mvn jetty:run, the mbean > gets init'd and we get an Exception stating "ClassCastException: > org.slf4j.impl.SimpleLoggerFactory cannot be cast to > ch.qos.logback.classic.LoggerContext", due to slf4j-simple being on maven's > lib. This is very likely to happen with other container plugins (tomcat7 et > al) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[ https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361469#comment-361469 ] Dan Tran commented on MPMD-199: --- It is best for a committer reformat and remove unwanted white space first. I can do so, if agree > Support PMD functionality on JSP files > -- > > Key: MPMD-199 > URL: https://jira.codehaus.org/browse/MPMD-199 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.3 >Reporter: Tom Williamson >Priority: Minor > Attachments: Patch_for_JSP_support.patch > > > It would be great if this plugin would either support PMD functionality for > JSP files, or simply enable them as part of the Java support. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1136) Current working directory propagation in forked mode
[ https://jira.codehaus.org/browse/SUREFIRE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian closed SUREFIRE-1136. Resolution: Fixed Your Pull-Request has been reviewed and merged. Thanks, Norbert! > Current working directory propagation in forked mode > > > Key: SUREFIRE-1136 > URL: https://jira.codehaus.org/browse/SUREFIRE-1136 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: Norbert Wnuk >Assignee: Andreas Gudian >Priority: Minor > Fix For: 2.19 > > > Surefire plugin does not resolve surefire.forkNumber variable for working > directory so that the same invalid directory is set for all forked JVMs. The > same time user.dir property is propagated properly which leads to > inconsistent behavior in JDK API - > http://stackoverflow.com/questions/1234795/why-is-the-user-dir-system-property-working-in-java -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1136) Current working directory propagation in forked mode
[ https://jira.codehaus.org/browse/SUREFIRE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian updated SUREFIRE-1136: - Fix Version/s: 2.19 > Current working directory propagation in forked mode > > > Key: SUREFIRE-1136 > URL: https://jira.codehaus.org/browse/SUREFIRE-1136 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: Norbert Wnuk >Assignee: Andreas Gudian >Priority: Minor > Fix For: 2.19 > > > Surefire plugin does not resolve surefire.forkNumber variable for working > directory so that the same invalid directory is set for all forked JVMs. The > same time user.dir property is propagated properly which leads to > inconsistent behavior in JDK API - > http://stackoverflow.com/questions/1234795/why-is-the-user-dir-system-property-working-in-java -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1136) Current working directory propagation in forked mode
[ https://jira.codehaus.org/browse/SUREFIRE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian reassigned SUREFIRE-1136: Assignee: Andreas Gudian > Current working directory propagation in forked mode > > > Key: SUREFIRE-1136 > URL: https://jira.codehaus.org/browse/SUREFIRE-1136 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: Norbert Wnuk >Assignee: Andreas Gudian >Priority: Minor > Fix For: 2.19 > > > Surefire plugin does not resolve surefire.forkNumber variable for working > directory so that the same invalid directory is set for all forked JVMs. The > same time user.dir property is propagated properly which leads to > inconsistent behavior in JDK API - > http://stackoverflow.com/questions/1234795/why-is-the-user-dir-system-property-working-in-java -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[ https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361465#comment-361465 ] Michael Osipov commented on MPMD-199: - Please rework the patch without IntelliJ, there are too many whitespace changes making it hard to read the actual changes. > Support PMD functionality on JSP files > -- > > Key: MPMD-199 > URL: https://jira.codehaus.org/browse/MPMD-199 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.3 >Reporter: Tom Williamson >Priority: Minor > Attachments: Patch_for_JSP_support.patch > > > It would be great if this plugin would either support PMD functionality for > JSP files, or simply enable them as part of the Java support. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-442) Failed to access file due to locked access when using more than one Maven worker thread
[
https://jira.codehaus.org/browse/MDEP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laura Llewellyn updated MDEP-442:
-
Attachment: maven-thread-test-update.zip
Updating the test case; I forgot to run the test with an empty local repo and
needed to adjust the invoker plugin settings so the local artifact repo gets
populated correctly. Sorry about that.
More info - I've run this test with Maven 3.2.2 & Java 7 on a box running Linux
2.6, and haven't yet been able to get it to fail. I haven't gotten it to
succeed in Windows.
> Failed to access file due to locked access when using more than one Maven
> worker thread
> ---
>
> Key: MDEP-442
> URL: https://jira.codehaus.org/browse/MDEP-442
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 2.8
> Environment: MVN 3.0.4, JDK 1.7, Win 7 Pro SP1 64 Bit
>Reporter: Markus KARG
>Priority: Critical
> Attachments: maven-thread-test-update.zip, maven-thread-test.zip
>
>
> My multi-module POM contains of ten modules. Each of that modules does the
> same: Invoke the 'copy' goal of the dependency plugin. The idea is to have
> ten copies of the identical source, which then will end up in ten different
> targets by getting furthere processed.
> As long as I do not use more than one Maven worker thread, everything works
> well always. But when using -T 5 to have five worker threads, rather often
> the reactor fails because the source file (!) is locked:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project
> MYARTIFACT: Unable to resolve artifact. Could not transfer artifact
> mygroup:myartifact:dll:4.36.1-20140415.143537-37 from/to nexus
> (http://nexus/nexus/content/groups/public):
> C:\Users\jenkins.QUIPSY\.m2\repository\mygroup\myartifact\4.36.1-SNAPSHOT\myartifact-4.36.1-20140415.143537-37.dll
> (The process cannot access the file, because it is in use by another process)
> {noformat}
> So it seems that the 'copy' task actually is locking the source file, which
> is not multi-threading-compatible. Hence, either that is a bug and should get
> fixed, or it is on purpose, then this goal has to be marked as
> non-multithreading-able.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-737) Generated WAR file does not contain the same default manifest entries as created by the Maven WAR Plugin
[
https://jira.codehaus.org/browse/MASSEMBLY-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361463#comment-361463
]
Michael Osipov commented on MASSEMBLY-737:
--
Great, I'd be more than happy to try a working trunk version.
> Generated WAR file does not contain the same default manifest entries as
> created by the Maven WAR Plugin
>
>
> Key: MASSEMBLY-737
> URL: https://jira.codehaus.org/browse/MASSEMBLY-737
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest, maven-archiver
>Affects Versions: 2.5.2
>Reporter: Michael Osipov
> Attachments: massembly-737.zip
>
>
> I am repackaging a WAR file with some files exchanged. The original fiel
> contains following manifest entries:
> {noformat}
> Manifest-Version: 1.0
> Built-By: osipovmi
> Build-Jdk: 1.7.0_55
> Created-By: Apache Maven 3.2.2
> Archiver-Version: Plexus Archiver
> {noformat}
> The {{MANIFEST.MF}} generated by this plugin looks like:
> {noformat}
> Manifest-Version: 1.0
> Created-By: 24.55-b03 (Oracle Corporation)
> Archiver-Version: Plexus Archiver
> {noformat}
> while the descriptor looks very simple:
> {code}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> deployable
>
> war
>
> false
>
>
> true
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[ https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Williamson updated MPMD-199: Attachment: Patch_for_JSP_support.patch Patch for JSP support. There are some spurious whitespace/line ending changes in the file - they don't affect functionality. > Support PMD functionality on JSP files > -- > > Key: MPMD-199 > URL: https://jira.codehaus.org/browse/MPMD-199 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.3 >Reporter: Tom Williamson >Priority: Minor > Attachments: Patch_for_JSP_support.patch > > > It would be great if this plugin would either support PMD functionality for > JSP files, or simply enable them as part of the Java support. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-442) Failed to access file due to locked access when using more than one Maven worker thread
[
https://jira.codehaus.org/browse/MDEP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laura Llewellyn updated MDEP-442:
-
Attachment: maven-thread-test.zip
Here is a maven-invoker-test case that demonstrates this problem in my
environment. Output of {{mvn --version}}:
{code}Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
2014-06-17T09:51:42-04:00)
Maven home: c:\dev\maven\apache-maven-3.2.2
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: c:\Program Files\Java\jdk1.7.0_55\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
{code}
I run {{mvn clean verify}} in this project and the {{build.log}} files for the
its have exceptions like this:
{code}
[ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its
dependencies could not be resolved: Failed to read artifact descriptor for
org.apache.maven.plugins:maven-clean-plugin:jar:2.5: Could not transfer
artifact org.apache.maven.plugins:maven-plugins:pom:22 from/to local.central
(file:///c:/dev/artifact-repository):
C:\dev\sandbox\maven-thread-test\target\local-repo\org\apache\maven\plugins\maven-plugins\22\maven-plugins-22.pom
(The process cannot access the file because it is being used by another
process) -> [Help 1]
org.apache.maven.plugin.PluginResolutionException: Plugin
org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its dependencies
could not be resolved: Failed to read artifact descriptor for
org.apache.maven.plugins:maven-clean-plugin:jar:2.5
at
org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:122)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:148)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:267)
at
org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:239)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.setupMojoExecution(DefaultLifecycleExecutionPlanCalculator.java:158)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.setupMojoExecutions(DefaultLifecycleExecutionPlanCalculator.java:145)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:122)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:135)
at
org.apache.maven.lifecycle.internal.builder.BuilderCommon.resolveBuildPlan(BuilderCommon.java:97)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:109)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to
read artifact descriptor for org.apache.maven.plugins:maven-clean-plugin:jar:2.5
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:384)
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:231)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:288)
at
org.apache.maven.plugin.internal.DefaultPlugin
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-748: - Fix Version/s: 2.5.4 > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-750) descriptor in "dir" format changes symbolic links in non symlink files
[ https://jira.codehaus.org/browse/MASSEMBLY-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-750: - Fix Version/s: 2.5.4 > descriptor in "dir" format changes symbolic links in non symlink files > -- > > Key: MASSEMBLY-750 > URL: https://jira.codehaus.org/browse/MASSEMBLY-750 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.5.2 > Environment: linux and mac / java 7 >Reporter: Clément Igonet > Fix For: 2.5.4 > > > A descriptor created as dir format changes symlinks as "real" files. > Whereas a descriptor created as tar.gz format keep symlinks as symlinks. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-746) Warnings about platform dependent paths inconsistent.
[ https://jira.codehaus.org/browse/MASSEMBLY-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-746: - Fix Version/s: 2.5.4 > Warnings about platform dependent paths inconsistent. > - > > Key: MASSEMBLY-746 > URL: https://jira.codehaus.org/browse/MASSEMBLY-746 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.5.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) > Java version: 1.7.0_72, vendor: Oracle Corporation > Default locale: de_DE, platform encoding: UTF-8 > OS name: "windows xp", version: "5.1", arch: "x86", family: "windows" >Reporter: Christian Schulte >Priority: Trivial > Fix For: 2.5.4 > > Attachments: MASSEMBLY-746.zip > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5757) update aether to 1.0.2
[ https://jira.codehaus.org/browse/MNG-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5757. --- Resolution: Fixed Assignee: Igor Fedorenko https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=3db19368aac10fad6b61346946cdcbe998c54117 > update aether to 1.0.2 > -- > > Key: MNG-5757 > URL: https://jira.codehaus.org/browse/MNG-5757 > Project: Maven > Issue Type: Task >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.2.6 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MASSEMBLY-742:
-
Fix Version/s: 2.5.4
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold reopened MASSEMBLY-742:
--
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361457#comment-361457
]
Kristian Rosenvold commented on MASSEMBLY-742:
--
The wonders of duplicated code :=]
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-737) Generated WAR file does not contain the same default manifest entries as created by the Maven WAR Plugin
[
https://jira.codehaus.org/browse/MASSEMBLY-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361456#comment-361456
]
Kristian Rosenvold commented on MASSEMBLY-737:
--
With the changes in commons-compress 1.10 and plexus-archiver 2.10, fixing this
issue should be a much simpler fix, almost trivial. These are not yet released,
so it's a little while off.
> Generated WAR file does not contain the same default manifest entries as
> created by the Maven WAR Plugin
>
>
> Key: MASSEMBLY-737
> URL: https://jira.codehaus.org/browse/MASSEMBLY-737
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest, maven-archiver
>Affects Versions: 2.5.2
>Reporter: Michael Osipov
> Attachments: massembly-737.zip
>
>
> I am repackaging a WAR file with some files exchanged. The original fiel
> contains following manifest entries:
> {noformat}
> Manifest-Version: 1.0
> Built-By: osipovmi
> Build-Jdk: 1.7.0_55
> Created-By: Apache Maven 3.2.2
> Archiver-Version: Plexus Archiver
> {noformat}
> The {{MANIFEST.MF}} generated by this plugin looks like:
> {noformat}
> Manifest-Version: 1.0
> Created-By: 24.55-b03 (Oracle Corporation)
> Archiver-Version: Plexus Archiver
> {noformat}
> while the descriptor looks very simple:
> {code}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> deployable
>
> war
>
> false
>
>
> true
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5757) update aether to 1.0.2
[ https://jira.codehaus.org/browse/MNG-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5757: --- Fix Version/s: 3.2.6 > update aether to 1.0.2 > -- > > Key: MNG-5757 > URL: https://jira.codehaus.org/browse/MNG-5757 > Project: Maven > Issue Type: Task >Reporter: Igor Fedorenko > Fix For: 3.2.6 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-738) SiteDeployMojo#determineDeploySite code/javadoc inconsistent. Javadoc seems more correct
[
https://jira.codehaus.org/browse/MSITE-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grégory Joseph updated MSITE-738:
-
Description:
The javadoc of this method seems to be the desired behavior:
{code}
/**
* Deploy directly to the current project's distribution management site.
*/
@Override
protected Site determineDeploySite()
throws MojoExecutionException
{
return getSite( getTopLevelProject( project ) );
}
{code}
However, the code indicates it goes all the way in the parent pom hierarchy ?
Why ?
* The outcome is inconsistent with the effective-pom
* I'd assume if my pom declares a {{distributionManagement/site}} section, it
should be used, rather than the site plugin trying to be smarter and use the
parent pom's info then somewhat relativize ? This leads to the same issues I
bumped into a couple years ago (when I didn't bother plugging my debugger in) :
http://maven.40175.n5.nabble.com/Site-deployment-url-and-inheritance-td5712737.html
This can cause at least two problems:
* One can't deploy a site to a host that's different than that of the parent pom
* Permissions on the server-side might not be applied correctly (perhaps the
project's deployer doesn't have permissions to deploy into the path configured
in the parent, but does in the path of his project.. however we try to deploy
to {{...parent/../../project/...}}.
Additionally, this just get confusing, because {{mvn help:effective-pom}} gives
me the {{distributionManagement/site}} section I expect, but the site plugin
ends up doing something else.
Reverting to {code}
protected Site determineDeploySite()
throws MojoExecutionException
{
return getSite( project );
}
{code}
Fixes the problem as far as I can tell, since project is already
resolved/effective model, isn't it ? I'm not sure what sure what commit
#1480820 was fixing.
was:
The javadoc of this method seems to be the desired behavior:
{code}
/**
* Deploy directly to the current project's distribution management site.
*/
@Override
protected Site determineDeploySite()
throws MojoExecutionException
{
return getSite( getTopLevelProject( project ) );
}
{code}
However, the code indicates it goes all the way in the parent pom hierarchy ?
Why ?
* The outcome is inconsistent with the effective-pom
* I'd assume if my pom declares a {{distributionManagement/site}} section, it
should be used, rather than the site plugin trying to be smarter and use the
parent pom's info then somewhat relativize ? This leads to the same issues I
bumped into a couple years ago (when I didn't bother plugging my debugger in) :
http://maven.40175.n5.nabble.com/Site-deployment-url-and-inheritance-td5712737.html
This can cause at least two problems:
* One can't deploy a site to a host that's different than that of the parent pom
* Permissions on the server-side might not be applied correctly (perhaps the
project's deployer doesn't have permissions to deploy into the path configured
in the parent, but does in the path of his project.. however we try to deploy
to {{...parent/../../project/...}}.
Additionally, this just get confusing, because {{mvn help:effective-pom}} gives
me the {{distributionManagement/site}} section I expect, but the site plugin
ends up doing something else.
> SiteDeployMojo#determineDeploySite code/javadoc inconsistent. Javadoc seems
> more correct
>
>
> Key: MSITE-738
> URL: https://jira.codehaus.org/browse/MSITE-738
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.4
>Reporter: Grégory Joseph
>
> The javadoc of this method seems to be the desired behavior:
> {code}
> /**
> * Deploy directly to the current project's distribution management site.
> */
> @Override
> protected Site determineDeploySite()
> throws MojoExecutionException
> {
> return getSite( getTopLevelProject( project ) );
> }
> {code}
> However, the code indicates it goes all the way in the parent pom hierarchy ?
> Why ?
> * The outcome is inconsistent with the effective-pom
> * I'd assume if my pom declares a {{distributionManagement/site}} section, it
> should be used, rather than the site plugin trying to be smarter and use the
> parent pom's info then somewhat relativize ? This leads to the same issues I
> bumped into a couple years ago (when I didn't bother plugging my debugger in)
> :
> http://maven.40175.n5.nabble.com/Site-deployment-url-and-inheritance-td5712737.html
> This can cause at least two problems:
> * One can't deploy a site to a host that's different than that of the parent
> pom
> * Permissions on the server-side might not be applied correctl
[jira] (MSITE-738) SiteDeployMojo#determineDeploySite code/javadoc inconsistent. Javadoc seems more correct
Grégory Joseph created MSITE-738:
Summary: SiteDeployMojo#determineDeploySite code/javadoc
inconsistent. Javadoc seems more correct
Key: MSITE-738
URL: https://jira.codehaus.org/browse/MSITE-738
Project: Maven Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.4
Reporter: Grégory Joseph
The javadoc of this method seems to be the desired behavior:
{code}
/**
* Deploy directly to the current project's distribution management site.
*/
@Override
protected Site determineDeploySite()
throws MojoExecutionException
{
return getSite( getTopLevelProject( project ) );
}
{code}
However, the code indicates it goes all the way in the parent pom hierarchy ?
Why ?
* The outcome is inconsistent with the effective-pom
* I'd assume if my pom declares a {{distributionManagement/site}} section, it
should be used, rather than the site plugin trying to be smarter and use the
parent pom's info then somewhat relativize ? This leads to the same issues I
bumped into a couple years ago (when I didn't bother plugging my debugger in) :
http://maven.40175.n5.nabble.com/Site-deployment-url-and-inheritance-td5712737.html
This can cause at least two problems:
* One can't deploy a site to a host that's different than that of the parent pom
* Permissions on the server-side might not be applied correctly (perhaps the
project's deployer doesn't have permissions to deploy into the path configured
in the parent, but does in the path of his project.. however we try to deploy
to {{...parent/../../project/...}}.
Additionally, this just get confusing, because {{mvn help:effective-pom}} gives
me the {{distributionManagement/site}} section I expect, but the site plugin
ends up doing something else.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5757) update aether to 1.0.2
Igor Fedorenko created MNG-5757: --- Summary: update aether to 1.0.2 Key: MNG-5757 URL: https://jira.codehaus.org/browse/MNG-5757 Project: Maven Issue Type: Task Reporter: Igor Fedorenko -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-790) Jazz SCM: Support branch creation
Martin E created SCM-790: Summary: Jazz SCM: Support branch creation Key: SCM-790 URL: https://jira.codehaus.org/browse/SCM-790 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-jazz Reporter: Martin E Priority: Minor Implement the branching command by creating a stream. This feature is not implemented yet because (as stated in JazzBranchCommand.java) the "scm" command doesn't support stream creation. But since RTC 4 it is possibe to create streams... (see http://www-01.ibm.com/support/knowledgecenter/SSYMRC_4.0.5/com.ibm.team.scm.doc/topics/create_stream.html) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-750) descriptor in "dir" format changes symbolic links in non symlink files
Clément Igonet created MASSEMBLY-750: Summary: descriptor in "dir" format changes symbolic links in non symlink files Key: MASSEMBLY-750 URL: https://jira.codehaus.org/browse/MASSEMBLY-750 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.2 Environment: linux and mac / java 7 Reporter: Clément Igonet A descriptor created as dir format changes symlinks as "real" files. Whereas a descriptor created as tar.gz format keep symlinks as symlinks. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
