[jira] (MPMD-174) Using a permalink from Sonar as a ruleset does not work
[ https://jira.codehaus.org/browse/MPMD-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361774#comment-361774 ] Jochen Ehret commented on MPMD-174: --- Can you please tell us when the maven-pmd-plugin 3.4 will be released and available on Maven Central? We've just migrated to SonarQube 4.5.1 and now lots of users get the "[WARNING] Failure executing PMD" problem mentioned above, so we really need to update. Thanks and Best Regards, Jochen. > Using a permalink from Sonar as a ruleset does not work > --- > > Key: MPMD-174 > URL: https://jira.codehaus.org/browse/MPMD-174 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Cremers stijn >Assignee: Michael Osipov > Fix For: 3.4 > > Attachments: MPMD-174-2.patch, MPMD-174-3.patch, MPMD-174-4.patch, > MPMD-174.patch, MPMD-174.patch, Sonar's main page.jpg, test.log > > > I am trying to use a permalink from sonar with the pmd configuration from > sonar as a rulest in the maven-pmd-plugin. > This is my maven configuration: > > org.apache.maven.plugins > maven-pmd-plugin > 3.0.1 > > > > http://my-tools.mycompany.com/sonar/profiles/export?format=pmd&language=java&name=MyProfile > > > > > pmd > check > > > > But i get the following error when i run "mvn clean install": > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.0.1:pmd (pmd) on project my-pmd: > An error has occurred in PMD Report report generation. Could not find > resource 'rulesets/http://my/tools.mycompany.com/sonar/profiles.xml'. -> > [Help 1] > I have tried to use the link from the sonar demo site: > > org.apache.maven.plugins > maven-pmd-plugin > 3.0.1 > > > > http://nemo.sonarqube.org/profiles/export?format=pmd&language=java&name=Nemo > > > > > pmd > check > > > > But then i get the following error: > [INFO] --- maven-pmd-plugin:3.0.1:pmd (pmd) @ my-pmd --- > [WARNING] Unable to locate Source XRef to link to - DISABLED > [WARNING] Failure executing PMD: Couldn't find the class White spaces are > required between publicId and systemId. > java.lang.RuntimeException: Couldn't find the class White spaces are required > between publicId and systemId. > at > net.sourceforge.pmd.RuleSetFactory.classNotFoundProblem(RuleSetFactory.java:244) > at > net.sourceforge.pmd.RuleSetFactory.parseRuleSetNode(RuleSetFactory.java:238) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSet(RuleSetFactory.java:161) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:126) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:111) > at > net.sourceforge.pmd.processor.AbstractPMDProcessor.createRuleSets(AbstractPMDProcessor.java:56) > at > net.sourceforge.pmd.processor.MonoThreadProcessor.processFiles(MonoThreadProcessor.java:41) > at net.sourceforge.pmd.PMD.processFiles(PMD.java:271) > at > org.apache.maven.plugin.pmd.PmdReport.generateReport(PmdReport.java:296) > at org.apache.maven.plugin.pmd.PmdReport.execute(PmdReport.java:194) > at > org.apache.maven.plugin.pmd.PmdReport.executeReport(PmdReport.java:168) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190) > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:99) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:364) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:198) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[jira] (MPMD-174) Using a permalink from Sonar as a ruleset does not work
[ https://jira.codehaus.org/browse/MPMD-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361781#comment-361781 ] Michael Osipov commented on MPMD-174: - Hi Jochen, my intention was to wait for the patch for MPMD-199 and then start a release. You are welcome to improve the patch in that ticket. > Using a permalink from Sonar as a ruleset does not work > --- > > Key: MPMD-174 > URL: https://jira.codehaus.org/browse/MPMD-174 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Cremers stijn >Assignee: Michael Osipov > Fix For: 3.4 > > Attachments: MPMD-174-2.patch, MPMD-174-3.patch, MPMD-174-4.patch, > MPMD-174.patch, MPMD-174.patch, Sonar's main page.jpg, test.log > > > I am trying to use a permalink from sonar with the pmd configuration from > sonar as a rulest in the maven-pmd-plugin. > This is my maven configuration: > > org.apache.maven.plugins > maven-pmd-plugin > 3.0.1 > > > > http://my-tools.mycompany.com/sonar/profiles/export?format=pmd&language=java&name=MyProfile > > > > > pmd > check > > > > But i get the following error when i run "mvn clean install": > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.0.1:pmd (pmd) on project my-pmd: > An error has occurred in PMD Report report generation. Could not find > resource 'rulesets/http://my/tools.mycompany.com/sonar/profiles.xml'. -> > [Help 1] > I have tried to use the link from the sonar demo site: > > org.apache.maven.plugins > maven-pmd-plugin > 3.0.1 > > > > http://nemo.sonarqube.org/profiles/export?format=pmd&language=java&name=Nemo > > > > > pmd > check > > > > But then i get the following error: > [INFO] --- maven-pmd-plugin:3.0.1:pmd (pmd) @ my-pmd --- > [WARNING] Unable to locate Source XRef to link to - DISABLED > [WARNING] Failure executing PMD: Couldn't find the class White spaces are > required between publicId and systemId. > java.lang.RuntimeException: Couldn't find the class White spaces are required > between publicId and systemId. > at > net.sourceforge.pmd.RuleSetFactory.classNotFoundProblem(RuleSetFactory.java:244) > at > net.sourceforge.pmd.RuleSetFactory.parseRuleSetNode(RuleSetFactory.java:238) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSet(RuleSetFactory.java:161) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:126) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:111) > at > net.sourceforge.pmd.processor.AbstractPMDProcessor.createRuleSets(AbstractPMDProcessor.java:56) > at > net.sourceforge.pmd.processor.MonoThreadProcessor.processFiles(MonoThreadProcessor.java:41) > at net.sourceforge.pmd.PMD.processFiles(PMD.java:271) > at > org.apache.maven.plugin.pmd.PmdReport.generateReport(PmdReport.java:296) > at org.apache.maven.plugin.pmd.PmdReport.execute(PmdReport.java:194) > at > org.apache.maven.plugin.pmd.PmdReport.executeReport(PmdReport.java:168) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190) > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:99) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:364) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:198) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) >
[jira] (WAGON-230) make it easier to set the HTTP user agent in a configurable way across HTTP wagons, and provide a default for Wagon
[ https://jira.codehaus.org/browse/WAGON-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361786#comment-361786 ] Brett Porter commented on WAGON-230: sure, looks good to me! > make it easier to set the HTTP user agent in a configurable way across HTTP > wagons, and provide a default for Wagon > --- > > Key: WAGON-230 > URL: https://jira.codehaus.org/browse/WAGON-230 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-http-lightweight, wagon-webdav >Affects Versions: 1.0-beta-3 >Reporter: Brett Porter > Fix For: 1.1 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-230) make it easier to set the HTTP user agent in a configurable way across HTTP wagons, and provide a default for Wagon
[ https://jira.codehaus.org/browse/WAGON-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-230. -- Resolution: Duplicate Fix Version/s: (was: 1.1) > make it easier to set the HTTP user agent in a configurable way across HTTP > wagons, and provide a default for Wagon > --- > > Key: WAGON-230 > URL: https://jira.codehaus.org/browse/WAGON-230 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-http-lightweight, wagon-webdav >Affects Versions: 1.0-beta-3 >Reporter: Brett Porter > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1137) Problem with Umlauts in stdout
Jürgen Zeller created SUREFIRE-1137: --- Summary: Problem with Umlauts in stdout Key: SUREFIRE-1137 URL: https://jira.codehaus.org/browse/SUREFIRE-1137 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.18 Environment: Linux Reporter: Jürgen Zeller Attachments: surefire-test.zip When using Cp1252 as file encoding, the generated Surefire stdout report contains invalid characters when run on Linux. When running the same test on Windows, everything is fine. A simular Problem was reported in SUREFIRE-998 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1137) Problem with Umlauts in stdout
[ https://jira.codehaus.org/browse/SUREFIRE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361801#comment-361801 ] Jürgen Zeller commented on SUREFIRE-1137: - In the ZIP both the XML generated on Windows as well as on Linux is included. > Problem with Umlauts in stdout > -- > > Key: SUREFIRE-1137 > URL: https://jira.codehaus.org/browse/SUREFIRE-1137 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18 > Environment: Linux >Reporter: Jürgen Zeller > Attachments: surefire-test.zip > > > When using Cp1252 as file encoding, the generated Surefire stdout report > contains invalid characters when run on Linux. When running the same test on > Windows, everything is fine. > A simular Problem was reported in SUREFIRE-998 -- 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=361807#comment-361807
]
Dawid Weiss commented on MASSEMBLY-742:
---
On which project's trunk? From what I see I've been working with the latest
commit to plexus-archiver (867eee8e47ee297 on 2.x line), the master branch is
older than that.
> 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] (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=361823#comment-361823 ] Tom Williamson commented on MPMD-199: - I hope to have a new patch for you tomorrow unless the other committer (on MPMD-174) wants to take care of it first in which case I am happy to let him. > 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] (MNG-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project
[ https://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361824#comment-361824 ] Paul Benedict commented on MNG-1991: Yes, that's how I have seen it done. You add the "war" to get the artifact and the war's "pom" to get its dependencies. > Can't get transitive dependencies from a war pom when this war is added as a > depdency of a project > -- > > Key: MNG-1991 > URL: https://jira.codehaus.org/browse/MNG-1991 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.2 >Reporter: Emmanuel Venisse > Attachments: war-deps.tar > > > I have a project (continuum-core-it) that need to use all transitive > dependencies of a war (continuum-webapp). If i add the war as a dependency of > the project with packaging war, war dependencies aren't shown by project, > maven doesn't try to resolve them and doesn't add them in classpath. > If if replace packaging from war to pom, all dependencies are resolved and > added to classpath. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies reopened MCOMPILER-120:
I'm reopening this because the 'fix' has a pretty major problem: no message os
printed explaining why the compilation fails. Adding -e and -X do not lead to
the actual message arriving.
{noformat}
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 179 source files to /Users/benson/x/gcoref/core/target/classes
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.000 s
[INFO] Finished at: 2015-01-26T13:50:23-05:00
[INFO] Final Memory: 30M/705M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on
project res-core: Compilation failure -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
{noformat}
Here's the effective pom of note:
{code}
default-compile
compile
compile
-Werror
-Xlint:all
true
true
true
true
utf-8
1.7
1.7
256M
true
true
{code}
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361831#comment-361831
]
Benson Margulies edited comment on MCOMPILER-120 at 1/26/15 12:52 PM:
--
I'm reopening this because the 'fix' has a pretty major problem: no message is
printed explaining why the compilation fails. Adding -e and -X do not lead to
the actual message arriving.
{noformat}
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 179 source files to /Users/benson/x/gcoref/core/target/classes
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.000 s
[INFO] Finished at: 2015-01-26T13:50:23-05:00
[INFO] Final Memory: 30M/705M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on
project res-core: Compilation failure -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
{noformat}
Here's the effective pom of note:
{code}
default-compile
compile
compile
-Werror
-Xlint:all
true
true
true
true
utf-8
1.7
1.7
256M
true
true
{code}
was (Author: bmargulies):
I'm reopening this because the 'fix' has a pretty major problem: no message os
printed explaining why the compilation fails. Adding -e and -X do not lead to
the actual message arriving.
{noformat}
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 179 source files to /Users/benson/x/gcoref/core/target/classes
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.000 s
[INFO] Finished at: 2015-01-26T13:50:23-05:00
[INFO] Final Memory: 30M/705M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on
project res-core: Compilation failure -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
{noformat}
Here's the effective pom of note:
{code}
default-compile
compile
compile
-Werror
-Xlint:all
true
true
true
true
utf-8
1.7
1.7
256M
true
true
{code}
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1137) Problem with Umlauts in stdout
[ https://jira.codehaus.org/browse/SUREFIRE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361833#comment-361833 ] Andreas Gudian commented on SUREFIRE-1137: -- File-Encoding and Timezones are the two things that will keep all of us busy until the universe collapses. Jürgen, as I have no Linux system at hand right now, could you please: * check if there is a difference in the system default encoding on both of your systems? (I see that you try to switch it for the fork, but still). * Also, please check what happens if you run the tests with forkCount=0. * What happens if you add -Dfile.encoding=Cp1252 to your MAVEN_OPTS? * Can you check what happens if you use UTF-8 as encoding? (don't forget to convert the AppTest.java appropriately) Thanks! > Problem with Umlauts in stdout > -- > > Key: SUREFIRE-1137 > URL: https://jira.codehaus.org/browse/SUREFIRE-1137 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18 > Environment: Linux >Reporter: Jürgen Zeller > Attachments: surefire-test.zip > > > When using Cp1252 as file encoding, the generated Surefire stdout report > contains invalid characters when run on Linux. When running the same test on > Windows, everything is fine. > A simular Problem was reported in SUREFIRE-998 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1137) Problem with Umlauts in stdout
[ https://jira.codehaus.org/browse/SUREFIRE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian reassigned SUREFIRE-1137: Assignee: Andreas Gudian > Problem with Umlauts in stdout > -- > > Key: SUREFIRE-1137 > URL: https://jira.codehaus.org/browse/SUREFIRE-1137 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18 > Environment: Linux >Reporter: Jürgen Zeller >Assignee: Andreas Gudian > Attachments: surefire-test.zip > > > When using Cp1252 as file encoding, the generated Surefire stdout report > contains invalid characters when run on Linux. When running the same test on > Windows, everything is fine. > A simular Problem was reported in SUREFIRE-998 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1137) Problem with Umlauts in stdout
[ https://jira.codehaus.org/browse/SUREFIRE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361834#comment-361834 ] Andreas Gudian commented on SUREFIRE-1137: -- Oh and to be on the safe side: please also check with Surefire 2.18.1 (although I think we didn't change anything in that area). > Problem with Umlauts in stdout > -- > > Key: SUREFIRE-1137 > URL: https://jira.codehaus.org/browse/SUREFIRE-1137 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18 > Environment: Linux >Reporter: Jürgen Zeller >Assignee: Andreas Gudian > Attachments: surefire-test.zip > > > When using Cp1252 as file encoding, the generated Surefire stdout report > contains invalid characters when run on Linux. When running the same test on > Windows, everything is fine. > A simular Problem was reported in SUREFIRE-998 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-186) Class Name with slash is omitted from exclusions on pmd:check
[ https://jira.codehaus.org/browse/MPMD-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Shepard updated MPMD-186: Attachment: maven-pmd-plugin.patch Patch with a fix for the issue described. > Class Name with slash is omitted from exclusions on pmd:check > - > > Key: MPMD-186 > URL: https://jira.codehaus.org/browse/MPMD-186 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.1 > Environment: Ubuntu 13.04 Jdk 1.7 Maven 3.1.1 >Reporter: Diego Almeida >Priority: Critical > Attachments: maven-pmd-plugin.patch > > > The method getFileName on class Violation returns the class name with slash > or back slash. On the method extractClassName in the Class > PmdViolationCheckMojo the backslashes are replaced with dots in order to > compose the package name, but some > classes do not meet this condition and stay with the original class name and > are not found on the map excludeFromFailureClasses that contains the classes > and the rules with exceptions. > This generates an error even if the class and the rule are included on the > exception file. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-186) Class Name with slash is omitted from exclusions on pmd:check
[ https://jira.codehaus.org/browse/MPMD-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361836#comment-361836 ] Justin Shepard commented on MPMD-186: - This issue has been affecting my MacBook as well (along with coworkers who are using MacBooks), so I took some time and implemented a fix for the issue, in the hopes that this might speed along getting the issue fixed. The patch is based on trunk. > Class Name with slash is omitted from exclusions on pmd:check > - > > Key: MPMD-186 > URL: https://jira.codehaus.org/browse/MPMD-186 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.1 > Environment: Ubuntu 13.04 Jdk 1.7 Maven 3.1.1 >Reporter: Diego Almeida >Priority: Critical > Attachments: maven-pmd-plugin.patch > > > The method getFileName on class Violation returns the class name with slash > or back slash. On the method extractClassName in the Class > PmdViolationCheckMojo the backslashes are replaced with dots in order to > compose the package name, but some > classes do not meet this condition and stay with the original class name and > are not found on the map excludeFromFailureClasses that contains the classes > and the rules with exceptions. > This generates an error even if the class and the rule are included on the > exception file. -- 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=361837#comment-361837
]
Kristian Rosenvold commented on MASSEMBLY-742:
--
Hmm. You mean a9488efe9af883114cebad784893731c6b6a0fa1 still does not fix your
problem, even with plexus-io 2.5 ?
> 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=361837#comment-361837
]
Kristian Rosenvold edited comment on MASSEMBLY-742 at 1/26/15 2:50 PM:
---
Hmm. You mean a9488efe9af883114cebad784893731c6b6a0fa1 still does not fix your
problem, even with plexus-io 2.5. I would think head of 2.x branch on archiver
+ io 2.5 should work
(Head of archiver now actually points to the staged commons-compress 1.10, so
it might be a bad time to test)
was (Author: krosenvold):
Hmm. You mean a9488efe9af883114cebad784893731c6b6a0fa1 still does not fix your
problem, even with plexus-io 2.5. I would think head of 2.x branch on archiver
+ io 2.5 should work
> 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=361837#comment-361837
]
Kristian Rosenvold edited comment on MASSEMBLY-742 at 1/26/15 2:50 PM:
---
Hmm. You mean a9488efe9af883114cebad784893731c6b6a0fa1 still does not fix your
problem, even with plexus-io 2.5. I would think head of 2.x branch on archiver
+ io 2.5 should work
was (Author: krosenvold):
Hmm. You mean a9488efe9af883114cebad784893731c6b6a0fa1 still does not fix your
problem, even with plexus-io 2.5 ?
> 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=361837#comment-361837
]
Kristian Rosenvold edited comment on MASSEMBLY-742 at 1/26/15 2:51 PM:
---
Hmm. You mean a9488efe9af883114cebad784893731c6b6a0fa1 still does not fix your
problem, even with plexus-io 2.5. I would think head of 2.x branch on archiver
+ io 2.5 should work
(Head of archiver now actually points to the staged commons-compress 1.10, so
it might be a bad time to test from head of 2.x but
867eee8e47ee2979971b71d28519f2f0161569f7 should work with any recent
1.10-SNAPSHOT)
was (Author: krosenvold):
Hmm. You mean a9488efe9af883114cebad784893731c6b6a0fa1 still does not fix your
problem, even with plexus-io 2.5. I would think head of 2.x branch on archiver
+ io 2.5 should work
(Head of archiver now actually points to the staged commons-compress 1.10, so
it might be a bad time to test)
> 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.m
[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=361838#comment-361838
]
Dawid Weiss commented on MASSEMBLY-742:
---
I am looking at the lastest commit of AbstractArchiver and I don't see how it
can work --
https://github.com/sonatype/plexus-archiver/blob/2.x/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L493
Even if the resource iterator returned from:
{code}
ioResourceIter = currentResourceCollection.getResources();
{code}
is Closeable, it will never be closed and its resources are returned as part of
ResourceIterator (which isn't closeable). It's actually a fairly easy bug to
reproduce using my attached example project; if you put a breakpoint here:
https://github.com/sonatype/plexus-archiver/blob/2.x/src/main/java/org/codehaus/plexus/archiver/zip/PlexusIoZipFileResourceCollection.java#L31
and go up the call stack you'll end up in that AbstractArchiver's loop, from
which the closeable escapes without being closed.
> 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.c
[jira] (MCHANGES-351) No paging when maxEntries is reached
[
https://jira.codehaus.org/browse/MCHANGES-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361840#comment-361840
]
Bernd Eckenfels commented on MCHANGES-351:
--
The ASF INFRA team does not want to raise that limit on their Jira instance:
https://issues.apache.org/jira/browse/INFRA-9059
> No paging when maxEntries is reached
>
>
> Key: MCHANGES-351
> URL: https://jira.codehaus.org/browse/MCHANGES-351
> Project: Maven Changes Plugin
> Issue Type: Wish
> Components: jira
>Affects Versions: 2.11
> Environment: Maven 3.2.5; Java 1.7.0_72 x64 on win7, german
>Reporter: Bernd Eckenfels
>
> I try to generate a JIRA changes report for apache commons VFS. If I set the
> maxEntries to 600 it wont work. It looks like the Apache Instance only allows
> to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
> case there are 141 bugs in the current fixversion and the query finds 295).
> According to the JIRA docu you can query with different offsets, so would it
> be possible to query startAt=0-99,100-199,... and so on?
> Here is the request and the response:
> {code}
> Address: https://issues.apache.org/jira/rest/api/2/search
> Http-Method: POST
> Content-Type: application/json
> Headers: {Accept=[application/json], Content-Type=[application/json],
> Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
> (1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
> key DESC","maxResults":600,"fields":["*all"]...
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json;charset=UTF-8
> Headers: \{Cache-Control=[no-cache, no-store, no-transform],
> connection=[Keep-Alive], content-type=[application/json;charset=UTF-8],
> Date=[Mon, 19 Jan 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96],
> Server=[Apache-Coyote/1.1],
> Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; Path=/jira/; Secure;
> HttpOnly], transfer-encoding=[chunked], X-AREQUESTID=[110x29767730x2],
> X-ASEN=[SEN-2062203], X-AUSERNAME=[anonymous],
> X-Content-Type-Options=[nosniff]}
> Messages:
> Message (saved to tmp file):
> Filename:
> C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp
> (message truncated to 102400 bytes)
> Payload:
> {"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ...
> {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: jsp_support_20150126_1633.patch I have attached a new patch (jsp_support_20150126_1633.patch) which addresses your concerns: 1) Fixed the javascript reference in the text and reverted the POM snippet to the same format as used by the Javascript example. (As a side note, I have not been able to produce an actual report from our in-house project using this format, but I trust you that this is the correct way to do it.) 2) Removed the PMD dependency in jsp-configuration-plugin-config.xml (the same dependency exists in the javascript version, by the way.) I hope this conforms to what you wanted. > 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, jsp_support_20150126_1633.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)
