[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-tabpanelfocusedCommentId=358224#comment-358224 ] Michael Osipov commented on MPMD-174: - Thanks for the updated patch. I am a little bit confused by the statement bq. The problem is actually in PMD's code (in RuleSetReferenceId class), where constructor builds rule set filename. Is the problem located in the plugin or PMD itself? I'll have a look at your patch this weekend. 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 Attachments: MPMD-174.patch, MPMD-174.patch, Sonar's main page.jpg 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: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId version3.0.1/version configuration rulesets rulesethttp://my-tools.mycompany.com/sonar/profiles/export?format=pmdamp;language=javaamp;name=MyProfile/ruleset /rulesets /configuration executions execution idpmd/id goalsgoalcheck/goal/goals /execution /executions /plugin 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: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId version3.0.1/version configuration rulesets rulesethttp://nemo.sonarqube.org/profiles/export?format=pmdamp;language=javaamp;name=Nemo/ruleset /rulesets /configuration executions execution idpmd/id goalsgoalcheck/goal/goals /execution /executions /plugin 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
[jira] (MASSEMBLY-736) Files are read using ${file.encoding} instead of configured encoding
[
https://jira.codehaus.org/browse/MASSEMBLY-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358225#comment-358225
]
Kristian Rosenvold commented on MASSEMBLY-736:
--
All regular files are interpolated using project.build.sourceEncoding, as you
expect.
There is an exception for .properties files, which by definition are ISO-8859-1.
There appears to be a bug in this area; it seems like properties files are also
interpolated with project.build.sourceEncoding,
is this the problem you were experiencing ? (You'd get UTF8 written into the
property file, which in turn would be mangled by java when the file is read
back...)
Files are read using ${file.encoding} instead of configured encoding
Key: MASSEMBLY-736
URL: https://jira.codehaus.org/browse/MASSEMBLY-736
Project: Maven Assembly Plugin
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.5.1
Environment: Windows 7 / SLES 11
Reporter: Jörg Sesterhenn
Maven (and the assembly plugin) read files with the encoding that is present
in the system variable file.encoding, although
project.build.sourceEncoding was set to a different value. That leads to
assemblies being dependent on the (build) plattform.
In our build we had a file that got filtered and included in the build, but
due to being read with the wrong encoding during assembly all umlauts got
broken.
Please fix this. project.build.sourceEncoding should be used to read files
into the assembly by default (as documented).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-736) Files are read using ${file.encoding} instead of configured encoding
[
https://jira.codehaus.org/browse/MASSEMBLY-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358226#comment-358226
]
Kristian Rosenvold commented on MASSEMBLY-736:
--
file.encoding is used if project.build.sourceEncoding is not specified, as is
the general convention in maven plugins
Files are read using ${file.encoding} instead of configured encoding
Key: MASSEMBLY-736
URL: https://jira.codehaus.org/browse/MASSEMBLY-736
Project: Maven Assembly Plugin
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.5.1
Environment: Windows 7 / SLES 11
Reporter: Jörg Sesterhenn
Maven (and the assembly plugin) read files with the encoding that is present
in the system variable file.encoding, although
project.build.sourceEncoding was set to a different value. That leads to
assemblies being dependent on the (build) plattform.
In our build we had a file that got filtered and included in the build, but
due to being read with the wrong encoding during assembly all umlauts got
broken.
Please fix this. project.build.sourceEncoding should be used to read files
into the assembly by default (as documented).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-736) Files are read using ${file.encoding} instead of configured encoding
[
https://jira.codehaus.org/browse/MASSEMBLY-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358227#comment-358227
]
Kristian Rosenvold commented on MASSEMBLY-736:
--
Interpolated characters in project.build.sourceEncoding seeping into properties
files fixed in r1642407. properties files are always ISO-8851
Files are read using ${file.encoding} instead of configured encoding
Key: MASSEMBLY-736
URL: https://jira.codehaus.org/browse/MASSEMBLY-736
Project: Maven Assembly Plugin
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.5.1
Environment: Windows 7 / SLES 11
Reporter: Jörg Sesterhenn
Maven (and the assembly plugin) read files with the encoding that is present
in the system variable file.encoding, although
project.build.sourceEncoding was set to a different value. That leads to
assemblies being dependent on the (build) plattform.
In our build we had a file that got filtered and included in the build, but
due to being read with the wrong encoding during assembly all umlauts got
broken.
Please fix this. project.build.sourceEncoding should be used to read files
into the assembly by default (as documented).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-736) Files are read using ${file.encoding} instead of configured encoding
[
https://jira.codehaus.org/browse/MASSEMBLY-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358227#comment-358227
]
Kristian Rosenvold edited comment on MASSEMBLY-736 at 11/29/14 4:00 AM:
Interpolated characters in project.build.sourceEncoding seeping into properties
files fixed in r1642407. properties files are always ISO-8859-1
was (Author: krosenvold):
Interpolated characters in project.build.sourceEncoding seeping into properties
files fixed in r1642407. properties files are always ISO-8851
Files are read using ${file.encoding} instead of configured encoding
Key: MASSEMBLY-736
URL: https://jira.codehaus.org/browse/MASSEMBLY-736
Project: Maven Assembly Plugin
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.5.1
Environment: Windows 7 / SLES 11
Reporter: Jörg Sesterhenn
Maven (and the assembly plugin) read files with the encoding that is present
in the system variable file.encoding, although
project.build.sourceEncoding was set to a different value. That leads to
assemblies being dependent on the (build) plattform.
In our build we had a file that got filtered and included in the build, but
due to being read with the wrong encoding during assembly all umlauts got
broken.
Please fix this. project.build.sourceEncoding should be used to read files
into the assembly by default (as documented).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-735) NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80)
[ https://jira.codehaus.org/browse/MASSEMBLY-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358228#comment-358228 ] Kristian Rosenvold commented on MASSEMBLY-735: -- Is the symlink in question in one of the file elements ? NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80) - Key: MASSEMBLY-735 URL: https://jira.codehaus.org/browse/MASSEMBLY-735 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.1, 2.5.2 Environment: Linux Reporter: Martijn Verburg Priority: Blocker [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single (make-assembly) on project java-simulations: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single (make-assembly) on project java-simulations: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224) 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:116) 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:582) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.apache.maven.plugin.PluginExecutionException: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 19 more Caused by: java.lang.NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:542) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:602) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:389) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:314) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:213) at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940) at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) ... 20 more -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[
https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358229#comment-358229
]
Robert Scholte commented on SUREFIRE-855:
-
Can you control the classloaders? If so, how about adding a WarClassLoader,
which prefixes the name with {{/WEB-INF/classes/}}. Otherwise, only do it for
jars, which should cover most of the usecases.
Allow failsafe to use actual jar file instead of target/classes
---
Key: SUREFIRE-855
URL: https://jira.codehaus.org/browse/SUREFIRE-855
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin
Affects Versions: 2.12
Reporter: Benson Margulies
Priority: Critical
I've got some code that calls Class.getPackage() to see the manifest. I want
to test it. A seemingly logical scheme here would be to have failsafe put the
actual packaged jar into the classpath instead of the unpacked directory --
or some way to get the manifest copied across.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-735) NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80)
[ https://jira.codehaus.org/browse/MASSEMBLY-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358228#comment-358228 ] Kristian Rosenvold edited comment on MASSEMBLY-735 at 11/29/14 4:02 AM: Is the symlink in question in one of the file elements, or is it in one of the unpacked dependency sets ? was (Author: krosenvold): Is the symlink in question in one of the file elements ? NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80) - Key: MASSEMBLY-735 URL: https://jira.codehaus.org/browse/MASSEMBLY-735 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.1, 2.5.2 Environment: Linux Reporter: Martijn Verburg Priority: Blocker [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single (make-assembly) on project java-simulations: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single (make-assembly) on project java-simulations: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224) 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:116) 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:582) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.apache.maven.plugin.PluginExecutionException: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 19 more Caused by: java.lang.NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:542) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:602) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:389) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:314) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:213) at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940) at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486) at
[jira] (MASSEMBLY-720) Fixed Checkstyle reported errors / warnings
[ https://jira.codehaus.org/browse/MASSEMBLY-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-720. Resolution: Fixed Fix Version/s: 2.5.3 Assignee: Kristian Rosenvold There are no checkstyle warnings any more :) Fixed Checkstyle reported errors / warnings --- Key: MASSEMBLY-720 URL: https://jira.codehaus.org/browse/MASSEMBLY-720 Project: Maven Assembly Plugin Issue Type: Improvement Affects Versions: 2.5 Reporter: Karl-Heinz Marbaise Assignee: Kristian Rosenvold Priority: Minor Fix For: 2.5.3 Reduce the checkstyle reported issues. -- 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-tabpanelfocusedCommentId=358231#comment-358231
]
Kristian Rosenvold commented on MASSEMBLY-737:
--
You need to make a small test project if you want /me/ to fix this :)
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
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}
assembly
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;
iddeployable/id
formats
formatwar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
unpacktrue/unpack
useProjectArtifactfalse/useProjectArtifact
/dependencySet
/dependencySets
/assembly
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5626) Avoid negative durations or handle them correctly
[
https://jira.codehaus.org/browse/MNG-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358232#comment-358232
]
Michael Osipov edited comment on MNG-5626 at 11/29/14 4:28 AM:
---
Christian,
I am currently patching the source code and noticed some issues which out of
our control. At [some
points|https://github.com/eclipse/aether-core/search?p=1q=currenttimemillisutf8=%E2%9C%93]
in Eclipse Aether {{System.currentTimeMillis}} is used for start times or
durations. That needs to be changed to nanotime and scaled down to
milliseconds. Please file an issues with Aether and link to this one. I will
continue with our changes.
was (Author: michael-o):
Christian,
I am currently patching the source code and noticed some issues which out of
our control. At [some
points|https://github.com/eclipse/aether-core/search?p=1q=currenttimemillisutf8=%E2%9C%93]
in Eclipse Aether {{System.currentTimeMillis}} is used for start times or
durations. That needs to be changed to nanotime and scaled down to
milliseconds. Please file an issues with Aether and link to this one.
Avoid negative durations or handle them correctly
-
Key: MNG-5626
URL: https://jira.codehaus.org/browse/MNG-5626
Project: Maven
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.1
Reporter: Christian Jung
Assignee: Michael Osipov
Priority: Minor
In issue MNG-5623 we reported an exception when printing the reactor summary
if one of the times was negative.
I saw in one case, that the overall maven build time, as measured from
outside (i.e. by our QuickBuild system) was -10.8 seconds. The corresponding
reactor summary was:
{code}
13:55:25,184 INFO - Reactor Summary:
13:55:25,184 INFO -
13:55:25,184 INFO - module1 ...
SUCCESS [ 5.911 s]
13:55:25,184 INFO - module2 ...
SUCCESS [ 0.255 s]
13:55:25,184 INFO - gpPlaygroundBase-lnx-x64-gcc4 .
SUCCESS [-27.-64 s]
13:55:25,185 INFO -
13:55:25,185 INFO - BUILD SUCCESS
13:55:25,185 INFO -
13:55:25,185 INFO - Total time: -20.-73 s
13:55:25,185 INFO - Finished at: 2014-04-28T13:55:25+01:00
13:55:25,572 INFO - Final Memory: 32M/439M
13:55:25,572 INFO -
{code}
The thing is quite hard to reproduce, the machines were virtual machines that
have been running for quite a long time.
Our administrators suspected that just at this point, the local clock was
synchronized with some outer source.
We should check if such negative durations can be avoided, and if not, they
should be handled correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5626) Avoid negative durations or handle them correctly
[
https://jira.codehaus.org/browse/MNG-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358232#comment-358232
]
Michael Osipov commented on MNG-5626:
-
Christian,
I am currently patching the source code and noticed some issues which out of
our control. At [some
points|https://github.com/eclipse/aether-core/search?p=1q=currenttimemillisutf8=%E2%9C%93]
in Eclipse Aether {{System.currentTimeMillis}} is used for start times or
durations. That needs to be changed to nanotime and scaled down to
milliseconds. Please file an issues with Aether and link to this one.
Avoid negative durations or handle them correctly
-
Key: MNG-5626
URL: https://jira.codehaus.org/browse/MNG-5626
Project: Maven
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.1
Reporter: Christian Jung
Assignee: Michael Osipov
Priority: Minor
In issue MNG-5623 we reported an exception when printing the reactor summary
if one of the times was negative.
I saw in one case, that the overall maven build time, as measured from
outside (i.e. by our QuickBuild system) was -10.8 seconds. The corresponding
reactor summary was:
{code}
13:55:25,184 INFO - Reactor Summary:
13:55:25,184 INFO -
13:55:25,184 INFO - module1 ...
SUCCESS [ 5.911 s]
13:55:25,184 INFO - module2 ...
SUCCESS [ 0.255 s]
13:55:25,184 INFO - gpPlaygroundBase-lnx-x64-gcc4 .
SUCCESS [-27.-64 s]
13:55:25,185 INFO -
13:55:25,185 INFO - BUILD SUCCESS
13:55:25,185 INFO -
13:55:25,185 INFO - Total time: -20.-73 s
13:55:25,185 INFO - Finished at: 2014-04-28T13:55:25+01:00
13:55:25,572 INFO - Final Memory: 32M/439M
13:55:25,572 INFO -
{code}
The thing is quite hard to reproduce, the machines were virtual machines that
have been running for quite a long time.
Our administrators suspected that just at this point, the local clock was
synchronized with some outer source.
We should check if such negative durations can be avoided, and if not, they
should be handled correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5626) Avoid negative durations or handle them correctly
[
https://jira.codehaus.org/browse/MNG-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358232#comment-358232
]
Michael Osipov edited comment on MNG-5626 at 11/29/14 4:45 AM:
---
Christian,
I am currently patching the source code and noticed some issues which out of
our control. At [some
points|https://github.com/eclipse/aether-core/search?p=1q=currenttimemillisutf8=%E2%9C%93]
in Eclipse Aether {{System.currentTimeMillis}} is used for start times or
durations. That needs to be changed to nanotime and scaled down to
milliseconds. Please file an issues with Aether and link to this one.
Having a look at our code and the JavaDoc of {{nanoTime}} it does not look that
simple because {{nanoTime}} is *not* related to the wall clock at all, it is
arbitrary. It would be completely wrong to convert from {{nanoTime}} to
{{currentTimeMillis}}.
Read [this|http://stackoverflow.com/a/1776053/696632] SO answer by a Google
employee.
was (Author: michael-o):
Christian,
I am currently patching the source code and noticed some issues which out of
our control. At [some
points|https://github.com/eclipse/aether-core/search?p=1q=currenttimemillisutf8=%E2%9C%93]
in Eclipse Aether {{System.currentTimeMillis}} is used for start times or
durations. That needs to be changed to nanotime and scaled down to
milliseconds. Please file an issues with Aether and link to this one. I will
continue with our changes.
Avoid negative durations or handle them correctly
-
Key: MNG-5626
URL: https://jira.codehaus.org/browse/MNG-5626
Project: Maven
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.1
Reporter: Christian Jung
Assignee: Michael Osipov
Priority: Minor
In issue MNG-5623 we reported an exception when printing the reactor summary
if one of the times was negative.
I saw in one case, that the overall maven build time, as measured from
outside (i.e. by our QuickBuild system) was -10.8 seconds. The corresponding
reactor summary was:
{code}
13:55:25,184 INFO - Reactor Summary:
13:55:25,184 INFO -
13:55:25,184 INFO - module1 ...
SUCCESS [ 5.911 s]
13:55:25,184 INFO - module2 ...
SUCCESS [ 0.255 s]
13:55:25,184 INFO - gpPlaygroundBase-lnx-x64-gcc4 .
SUCCESS [-27.-64 s]
13:55:25,185 INFO -
13:55:25,185 INFO - BUILD SUCCESS
13:55:25,185 INFO -
13:55:25,185 INFO - Total time: -20.-73 s
13:55:25,185 INFO - Finished at: 2014-04-28T13:55:25+01:00
13:55:25,572 INFO - Final Memory: 32M/439M
13:55:25,572 INFO -
{code}
The thing is quite hard to reproduce, the machines were virtual machines that
have been running for quite a long time.
Our administrators suspected that just at this point, the local clock was
synchronized with some outer source.
We should check if such negative durations can be avoided, and if not, they
should be handled correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5626) Avoid negative durations or handle them correctly
[
https://jira.codehaus.org/browse/MNG-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358232#comment-358232
]
Michael Osipov edited comment on MNG-5626 at 11/29/14 4:53 AM:
---
Christian,
I am currently patching the source code and noticed some issues which out of
our control. At [some
points|https://github.com/eclipse/aether-core/search?p=1q=currenttimemillisutf8=%E2%9C%93]
in Eclipse Aether {{System.currentTimeMillis}} is used for start times or
durations. That needs to be changed to nanotime and scaled down to
milliseconds. Please file an issues with Aether and link to this one.
Having a look at our code and the JavaDoc of {{nanoTime}} it does not look that
simple because {{nanoTime}} is *not* related to the wall clock at all, it is
arbitrary. It would be completely wrong to convert from {{nanoTime}} to
{{currentTimeMillis}}. That would require a major change in Maven thus,
affecting interfaces and users of Maven Embedder. This cannot happen before
3.3. I will raise another issue for that.
Read [this|http://stackoverflow.com/a/1776053/696632] SO answer by a Google
employee.
was (Author: michael-o):
Christian,
I am currently patching the source code and noticed some issues which out of
our control. At [some
points|https://github.com/eclipse/aether-core/search?p=1q=currenttimemillisutf8=%E2%9C%93]
in Eclipse Aether {{System.currentTimeMillis}} is used for start times or
durations. That needs to be changed to nanotime and scaled down to
milliseconds. Please file an issues with Aether and link to this one.
Having a look at our code and the JavaDoc of {{nanoTime}} it does not look that
simple because {{nanoTime}} is *not* related to the wall clock at all, it is
arbitrary. It would be completely wrong to convert from {{nanoTime}} to
{{currentTimeMillis}}.
Read [this|http://stackoverflow.com/a/1776053/696632] SO answer by a Google
employee.
Avoid negative durations or handle them correctly
-
Key: MNG-5626
URL: https://jira.codehaus.org/browse/MNG-5626
Project: Maven
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.1
Reporter: Christian Jung
Assignee: Michael Osipov
Priority: Minor
In issue MNG-5623 we reported an exception when printing the reactor summary
if one of the times was negative.
I saw in one case, that the overall maven build time, as measured from
outside (i.e. by our QuickBuild system) was -10.8 seconds. The corresponding
reactor summary was:
{code}
13:55:25,184 INFO - Reactor Summary:
13:55:25,184 INFO -
13:55:25,184 INFO - module1 ...
SUCCESS [ 5.911 s]
13:55:25,184 INFO - module2 ...
SUCCESS [ 0.255 s]
13:55:25,184 INFO - gpPlaygroundBase-lnx-x64-gcc4 .
SUCCESS [-27.-64 s]
13:55:25,185 INFO -
13:55:25,185 INFO - BUILD SUCCESS
13:55:25,185 INFO -
13:55:25,185 INFO - Total time: -20.-73 s
13:55:25,185 INFO - Finished at: 2014-04-28T13:55:25+01:00
13:55:25,572 INFO - Final Memory: 32M/439M
13:55:25,572 INFO -
{code}
The thing is quite hard to reproduce, the machines were virtual machines that
have been running for quite a long time.
Our administrators suspected that just at this point, the local clock was
synchronized with some outer source.
We should check if such negative durations can be avoided, and if not, they
should be handled correctly.
--
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-tabpanelfocusedCommentId=358233#comment-358233
]
Michael Osipov commented on MASSEMBLY-737:
--
I am aware of that. This is pending next wekk.
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
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}
assembly
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;
iddeployable/id
formats
formatwar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
unpacktrue/unpack
useProjectArtifactfalse/useProjectArtifact
/dependencySet
/dependencySets
/assembly
{code}
--
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-tabpanelfocusedCommentId=358233#comment-358233
]
Michael Osipov edited comment on MASSEMBLY-737 at 11/29/14 6:21 AM:
I am aware of that. This is pending next week.
was (Author: michael-o):
I am aware of that. This is pending next wekk.
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
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}
assembly
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;
iddeployable/id
formats
formatwar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
unpacktrue/unpack
useProjectArtifactfalse/useProjectArtifact
/dependencySet
/dependencySets
/assembly
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-211) wildcard ignore in requireReleaseDeps
[
https://jira.codehaus.org/browse/MENFORCER-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358234#comment-358234
]
Karl-Heinz Marbaise commented on MENFORCER-211:
---
Can you provide a test project which shows the problem? Thanks in advance.
wildcard ignore in requireReleaseDeps
-
Key: MENFORCER-211
URL: https://jira.codehaus.org/browse/MENFORCER-211
Project: Maven Enforcer Plugin
Issue Type: Improvement
Affects Versions: 1.3.1
Reporter: Arne Brix
Priority: Minor
the bannedDependencies rule allows one to specify artifact lists using
wildcards:
{code:xml}
org.apache.*:maven-*:*
{code}
we are using the requireReleaseDeps rule for our release builds.
We would like to exclude dependencies with scope test because they don't
contribute to the final artifact.
We tried the syntax documented for bannedDependencies, but it didn't work:
{code:xml}
configuration
rules
requireReleaseDeps
messageNo Snapshots Allowed!/message
onlyWhenReleasetrue/onlyWhenRelease
excludes
exclude*:*:*:*:test/exclude
/excludes
/requireReleaseDeps
/rules
failtrue/fail
/configuration
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358235#comment-358235 ] Tibor Digana commented on SUREFIRE-855: --- Alright this is possible with WarClassLoader. What about packaging=bundle which is usual in OSGi projects. Even if the content is related to JAR, the packaging=bundle may refer to any content. Are we able to recognize the binary content other way? Allow failsafe to use actual jar file instead of target/classes --- Key: SUREFIRE-855 URL: https://jira.codehaus.org/browse/SUREFIRE-855 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Affects Versions: 2.12 Reporter: Benson Margulies Priority: Critical I've got some code that calls Class.getPackage() to see the manifest. I want to test it. A seemingly logical scheme here would be to have failsafe put the actual packaged jar into the classpath instead of the unpacked directory -- or some way to get the manifest copied across. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-203) dependencyConvergence seems to get tangled in reactor
[
https://jira.codehaus.org/browse/MENFORCER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358236#comment-358236
]
Karl-Heinz Marbaise commented on MENFORCER-203:
---
Hi Benson is it possible to create a sample project to reproduce the
problem..so i can take a deeper look into it..
dependencyConvergence seems to get tangled in reactor
-
Key: MENFORCER-203
URL: https://jira.codehaus.org/browse/MENFORCER-203
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.3.1
Reporter: Benson Margulies
The enforcer is claiming that one of the modules of my project is using the
prior release version of another of the modules of my project.
The problem version, 1.9.112, occurs _nowhere_ in any current POM.
Both modules refer to adm-model with {{$\{project.version\}}} references.
{noformat}
[WARNING]
Dependency convergence error for com.basistech:adm-model:2.0.0-rc1-SNAPSHOT
paths to dependency are:
+-com.basistech:adm-tools:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-model:2.0.0-rc1-SNAPSHOT
and
+-com.basistech:adm-tools:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-json:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-model:1.9.112
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
failed with message:
Failed while enforcing releasability the error(s) are [
Dependency convergence error for com.basistech:adm-model:2.0.0-rc1-SNAPSHOT
paths to dependency are:
+-com.basistech:adm-tools:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-model:2.0.0-rc1-SNAPSHOT
and
+-com.basistech:adm-tools:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-json:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-model:1.9.112
{noformat}
but mvn dependency:tree says in the failing module:
{noformat}
[INFO] --- maven-dependency-plugin:2.5.1:tree (default-cli) @ adm-tools ---
[INFO] com.basistech:adm-tools:jar:2.0.0-rc1-SNAPSHOT
[INFO] +- com.basistech:adm-model:jar:2.0.0-rc1-SNAPSHOT:compile
[INFO] +- com.basistech:adm-json:jar:2.0.0-rc1-SNAPSHOT:compile
[INFO] +- com.basistech:rlp-java-blackboard:jar:12.1:compile
[INFO] | +- com.basistech:rlp:jar:7.10.0:compile
[INFO] | | \- com.basistech:utilities:jar:7.10.0:compile
[INFO] | +-
com.fasterxml.jackson.dataformat:jackson-dataformat-smile:jar:2.4.1:compile
(version managed from 2.3.0)
[INFO] | \- org.javassist:javassist:jar:3.18.0-GA:compile
[INFO] +- com.basistech:common:jar:33:compile
[INFO] +- com.google.guava:guava:jar:16.0.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-core:jar:2.4.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.4.1:compile
[INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.4.1:compile
(version managed from 2.4.0)
[INFO] +- junit:junit:jar:4.11:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] \- args4j:args4j:jar:2.0.26:compile
{noformat}
and in the 'json' module:
{noformat}
--- maven-dependency-plugin:2.5.1:tree (default-cli) @ adm-json ---
[INFO] com.basistech:adm-json:jar:2.0.0-rc1-SNAPSHOT
[INFO] +- com.basistech:adm-model:jar:2.0.0-rc1-SNAPSHOT:compile
[INFO] +- com.basistech:common:jar:33:compile
[INFO] +- com.google.guava:guava:jar:16.0.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-core:jar:2.4.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.4.1:compile
[INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.4.1:compile
(version managed from 2.4.0)
[INFO] \- junit:junit:jar:4.11:test
[INFO]\- org.hamcrest:hamcrest-core:jar:1.3:test
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-203) dependencyConvergence seems to get tangled in reactor
[
https://jira.codehaus.org/browse/MENFORCER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MENFORCER-203:
--
Fix Version/s: waiting-for-feedback
dependencyConvergence seems to get tangled in reactor
-
Key: MENFORCER-203
URL: https://jira.codehaus.org/browse/MENFORCER-203
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.3.1
Reporter: Benson Margulies
Fix For: waiting-for-feedback
The enforcer is claiming that one of the modules of my project is using the
prior release version of another of the modules of my project.
The problem version, 1.9.112, occurs _nowhere_ in any current POM.
Both modules refer to adm-model with {{$\{project.version\}}} references.
{noformat}
[WARNING]
Dependency convergence error for com.basistech:adm-model:2.0.0-rc1-SNAPSHOT
paths to dependency are:
+-com.basistech:adm-tools:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-model:2.0.0-rc1-SNAPSHOT
and
+-com.basistech:adm-tools:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-json:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-model:1.9.112
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
failed with message:
Failed while enforcing releasability the error(s) are [
Dependency convergence error for com.basistech:adm-model:2.0.0-rc1-SNAPSHOT
paths to dependency are:
+-com.basistech:adm-tools:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-model:2.0.0-rc1-SNAPSHOT
and
+-com.basistech:adm-tools:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-json:2.0.0-rc1-SNAPSHOT
+-com.basistech:adm-model:1.9.112
{noformat}
but mvn dependency:tree says in the failing module:
{noformat}
[INFO] --- maven-dependency-plugin:2.5.1:tree (default-cli) @ adm-tools ---
[INFO] com.basistech:adm-tools:jar:2.0.0-rc1-SNAPSHOT
[INFO] +- com.basistech:adm-model:jar:2.0.0-rc1-SNAPSHOT:compile
[INFO] +- com.basistech:adm-json:jar:2.0.0-rc1-SNAPSHOT:compile
[INFO] +- com.basistech:rlp-java-blackboard:jar:12.1:compile
[INFO] | +- com.basistech:rlp:jar:7.10.0:compile
[INFO] | | \- com.basistech:utilities:jar:7.10.0:compile
[INFO] | +-
com.fasterxml.jackson.dataformat:jackson-dataformat-smile:jar:2.4.1:compile
(version managed from 2.3.0)
[INFO] | \- org.javassist:javassist:jar:3.18.0-GA:compile
[INFO] +- com.basistech:common:jar:33:compile
[INFO] +- com.google.guava:guava:jar:16.0.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-core:jar:2.4.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.4.1:compile
[INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.4.1:compile
(version managed from 2.4.0)
[INFO] +- junit:junit:jar:4.11:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] \- args4j:args4j:jar:2.0.26:compile
{noformat}
and in the 'json' module:
{noformat}
--- maven-dependency-plugin:2.5.1:tree (default-cli) @ adm-json ---
[INFO] com.basistech:adm-json:jar:2.0.0-rc1-SNAPSHOT
[INFO] +- com.basistech:adm-model:jar:2.0.0-rc1-SNAPSHOT:compile
[INFO] +- com.basistech:common:jar:33:compile
[INFO] +- com.google.guava:guava:jar:16.0.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-core:jar:2.4.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.4.1:compile
[INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.4.1:compile
(version managed from 2.4.0)
[INFO] \- junit:junit:jar:4.11:test
[INFO]\- org.hamcrest:hamcrest-core:jar:1.3:test
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-199) allow the file based rules to use wildcards on resources
[ https://jira.codehaus.org/browse/MENFORCER-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MENFORCER-199: -- Fix Version/s: more-investigation allow the file based rules to use wildcards on resources Key: MENFORCER-199 URL: https://jira.codehaus.org/browse/MENFORCER-199 Project: Maven Enforcer Plugin Issue Type: Wish Reporter: Bjoern Koos Fix For: more-investigation To check e.g. a maximum file size on multiple resources it would be helpful to use wildcards. Either in the specified files entries or maybe by using a fileSet-like semantics. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-211) wildcard ignore in requireReleaseDeps
[
https://jira.codehaus.org/browse/MENFORCER-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MENFORCER-211:
--
Fix Version/s: waiting-for-feedback
wildcard ignore in requireReleaseDeps
-
Key: MENFORCER-211
URL: https://jira.codehaus.org/browse/MENFORCER-211
Project: Maven Enforcer Plugin
Issue Type: Improvement
Affects Versions: 1.3.1
Reporter: Arne Brix
Priority: Minor
Fix For: waiting-for-feedback
the bannedDependencies rule allows one to specify artifact lists using
wildcards:
{code:xml}
org.apache.*:maven-*:*
{code}
we are using the requireReleaseDeps rule for our release builds.
We would like to exclude dependencies with scope test because they don't
contribute to the final artifact.
We tried the syntax documented for bannedDependencies, but it didn't work:
{code:xml}
configuration
rules
requireReleaseDeps
messageNo Snapshots Allowed!/message
onlyWhenReleasetrue/onlyWhenRelease
excludes
exclude*:*:*:*:test/exclude
/excludes
/requireReleaseDeps
/rules
failtrue/fail
/configuration
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5729) Measure (build time) durations with System.nanoTime only
Michael Osipov created MNG-5729:
---
Summary: Measure (build time) durations with System.nanoTime only
Key: MNG-5729
URL: https://jira.codehaus.org/browse/MNG-5729
Project: Maven
Issue Type: Improvement
Components: Embedding, General, Logging, Performance, Reactor and
workspace
Affects Versions: 3.2.3
Reporter: Michael Osipov
Currently, we solely rely on {{System.currentTimeMillis}} to track start/end
times as well as durations. This is error prone and not guaranteed to deliver a
monotic value with positive durations.
We should consider employing {{System.nanoTime}} throughout the core where the
above mentioned conditions are met. E.g., in some of:
{noformat}
maven-aether-provider/src/test/java/org/apache/maven/repository/internal/util/ConsoleTransferListener.java:
long duration = System.currentTimeMillis() - resource.getTransferStartTime();
maven-compat/src/main/java/org/apache/maven/repository/legacy/MavenArtifact.java:
this.transferStartTime = System.currentTimeMillis();
maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/BuilderCommon.java:
long buildEndTime = System.currentTimeMillis();
maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java:
long buildStartTime = System.currentTimeMillis();
maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java:
long buildEndTime = System.currentTimeMillis();
maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java:
long finish = System.currentTimeMillis();
maven-embedder/src/main/java/org/apache/maven/cli/transfer/AbstractMavenTransferListener.java:
long duration = System.currentTimeMillis() - resource.getTransferStartTime();
maven-embedder/src/main/java/org/apache/maven/cli/transfer/Slf4jMavenTransferListener.java:
long duration = System.currentTimeMillis() - resource.getTransferStartTime();
DefaultMaven.java: request.setStartTime( new Date() );
DefaultMavenExecutionRequest.java: public Date getStartTime()
DefaultMavenExecutionRequest.java: projectBuildingRequest.setBuildStartTime(
getStartTime() );
MavenExecutionRequest.java: Date getStartTime();
MavenSession.java: public Date getStartTime()
MavenSession.java: return request.getStartTime();
ExecutionEventLogger.java: long time = finish -
session.getRequest().getStartTime().getTime();
{noformat}
and all other code spots where {{Date}} or {{long}} is used.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-198) ensure use of latest available released version of artefact
[ https://jira.codehaus.org/browse/MENFORCER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MENFORCER-198. - Resolution: Won't Fix Assignee: Karl-Heinz Marbaise Hi, in MENFORCER-190 there was already such an request by myself but after a discussion about the different pro's and con's i have made a different decision to go for. ensure use of latest available released version of artefact --- Key: MENFORCER-198 URL: https://jira.codehaus.org/browse/MENFORCER-198 Project: Maven Enforcer Plugin Issue Type: Wish Reporter: Bjoern Koos Assignee: Karl-Heinz Marbaise The plugin (if it does not already) should provide means to enforce the use of the latest release version of e.g. a utility library. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-213) big performance degradation after upgrade from 1.1 to 1.3.1
[ https://jira.codehaus.org/browse/MENFORCER-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MENFORCER-213: -- Issue Type: Improvement (was: Bug) big performance degradation after upgrade from 1.1 to 1.3.1 --- Key: MENFORCER-213 URL: https://jira.codehaus.org/browse/MENFORCER-213 Project: Maven Enforcer Plugin Issue Type: Improvement Components: Plugin Affects Versions: 1.3.1 Environment: mvn 3.0.5, MacOsX yosemite, SSD disk Reporter: Milos Kleint Attachments: 2014-11-13_0851.png, 2014-11-13_0852.png mvn validate on our big codebase (142 modules) with 1.1 enforcer - 30.090s mvn validate with (1.3.1 enforcer) - 2:20.074s only enforcer plugin executions happen, bannedDependencies rules both times are on my laptop with profiler snapshot collection turned on. with the 1.3.1 it's obvious that the majority of time is indeed spent in the dependency graph codebase that is missing from 1.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358238#comment-358238 ] Robert Scholte commented on SUREFIRE-855: - I haven't worked with bundles, so I can't help you there. Maybe the answer lies within a OSGi container implementation itself. Allow failsafe to use actual jar file instead of target/classes --- Key: SUREFIRE-855 URL: https://jira.codehaus.org/browse/SUREFIRE-855 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Affects Versions: 2.12 Reporter: Benson Margulies Priority: Critical I've got some code that calls Class.getPackage() to see the manifest. I want to test it. A seemingly logical scheme here would be to have failsafe put the actual packaged jar into the classpath instead of the unpacked directory -- or some way to get the manifest copied across. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358239#comment-358239 ] Benson Margulies commented on SUREFIRE-855: --- I have recently been using pax-exam with failsafe to test OSGi bundles. You need to pass project.build.directory and project.version into the test as system properties, so that you can load the bundle by pathname. If you need other bundles from earlier in the reactor, you have to use the maven-dependency-plugin get them; if you use pax-aether, you end up with old versions. Allow failsafe to use actual jar file instead of target/classes --- Key: SUREFIRE-855 URL: https://jira.codehaus.org/browse/SUREFIRE-855 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Affects Versions: 2.12 Reporter: Benson Margulies Priority: Critical I've got some code that calls Class.getPackage() to see the manifest. I want to test it. A seemingly logical scheme here would be to have failsafe put the actual packaged jar into the classpath instead of the unpacked directory -- or some way to get the manifest copied across. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-205) Upgrade to maven-plugins parent version 27
[ https://jira.codehaus.org/browse/MEAR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-205: - Fix Version/s: 2.10 Upgrade to maven-plugins parent version 27 -- Key: MEAR-205 URL: https://jira.codehaus.org/browse/MEAR-205 Project: Maven Ear Plugin Issue Type: Improvement Affects Versions: 2.10 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: 2.10 Upgrade to maven-plugins parent version 27 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-205) Upgrade to maven-plugins parent version 27
Karl-Heinz Marbaise created MEAR-205: Summary: Upgrade to maven-plugins parent version 27 Key: MEAR-205 URL: https://jira.codehaus.org/browse/MEAR-205 Project: Maven Ear Plugin Issue Type: Improvement Affects Versions: 2.10 Reporter: Karl-Heinz Marbaise Priority: Minor Upgrade to maven-plugins parent version 27 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-205) Upgrade to maven-plugins parent version 27
[ https://jira.codehaus.org/browse/MEAR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MEAR-205. Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1642434|http://svn.apache.org/r1642434] Upgrade to maven-plugins parent version 27 -- Key: MEAR-205 URL: https://jira.codehaus.org/browse/MEAR-205 Project: Maven Ear Plugin Issue Type: Improvement Affects Versions: 2.10 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: 2.10 Upgrade to maven-plugins parent version 27 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-129) Maven PMD plug-in does not have excludemarker property that is available in PMD itself.
[ https://jira.codehaus.org/browse/MPMD-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358241#comment-358241 ] Andreas Dangel commented on MPMD-129: - Created pull request: https://github.com/apache/maven-plugins/pull/32 I named the new property suppressMarker instead of excludemarker, as this is the name in PMD. Maven PMD plug-in does not have excludemarker property that is available in PMD itself. - Key: MPMD-129 URL: https://jira.codehaus.org/browse/MPMD-129 Project: Maven PMD Plugin Issue Type: Improvement Reporter: Svetlomira Manova Attachments: maven-pmd-patch.zip, mychanges.patch Hi all, I am trying to change the string that is used to suppress warnings in PMD report(the default one is NOPMD). I found out that for doing this in PMD itself i have to use excludemarker input param with the custom string. At the moment i think there is not such property in Maven PMD plugin. Best regards, Svetlomira -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-165) target/site/pmd.html created with invalid charset=${outputEncoding}
[
https://jira.codehaus.org/browse/MPMD-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358242#comment-358242
]
Andreas Dangel commented on MPMD-165:
-
Pull request: https://github.com/apache/maven-plugins/pull/33
target/site/pmd.html created with invalid charset=${outputEncoding}
---
Key: MPMD-165
URL: https://jira.codehaus.org/browse/MPMD-165
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0
Environment: Maven 3.0.5, Java 6.0.43 on Windows XP
Reporter: Robert Kish
This problem also occurs for me with 3.1-SNAPSHOT. And it's also occurring
for me using maven-jxr-plugin in the index.html file only (not
allclasses-frame.html for example). So I am theorizing something in common
with both of those plugins has the same issue.
I have configured as a build plugin,
{code}
:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-pmd-plugin/artifactId
version3.1-SNAPSHOT/version
configuration
linkXreftrue/linkXref
targetJdk1.6/targetJdk
rulesetsrulesetruleset.xml/ruleset/rulesets
/configuration
/plugin
:
{code}
I have the following properties:
{code}
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding
/properties
{code}
From mvn -e -X output
{code}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-pmd-plugin:3.1-SNAPSHOT:pmd' with basic
configurator --
[DEBUG] (f) aggregate = false
[DEBUG] (f) compileSourceRoots =
[C:\NCP\NCOServer2\crs-data-crs\src\main\java]
[DEBUG] (f) excludes = [**/com/crs/c/*.java]
[DEBUG] (f) format = xml
[DEBUG] (f) includeTests = false
[DEBUG] (f) includeXmlInSite = false
[DEBUG] (f) language = java
[DEBUG] (f) linkXRef = true
[DEBUG] (f) minimumPriority = 5
[DEBUG] (f) outputDirectory = C:\NCP\NCOServer2\crs-data-crs\target\site
[DEBUG] (f) outputEncoding = UTF-8
[DEBUG] (f) reactorProjects = [MavenProject:
com.cr.crs:crs-data-crs:1.0-SNAPSHOT @ C:\NCP\NCOServer2\crs-data-crs\pom.xml]
[DEBUG] (s) rulesets = [C:\NCP\NCOServer2\ruleset.xml]
[DEBUG] (f) skip = false
[DEBUG] (f) sourceEncoding = UTF-8
[DEBUG] (f) targetDirectory = C:\NCP\NCOServer2\crs-data-crs\target
[DEBUG] (f) targetJdk = 1.6
[DEBUG] (f) testSourceRoots = [C:\NCP\NCOServer2\crs-data-crs\src\test\java]
[DEBUG] (f) typeResolution = false
[DEBUG] (f) xrefLocation = C:\NCP\NCOServer2\crs-data-crs\target\site\xref
[DEBUG] (f) xrefTestLocation =
C:\NCP\NCOServer2\crs-data-crs\target\site\xref-test
[DEBUG] (f) project = MavenProject: com.cr.crs:crs-data-crs:1.0-SNAPSHOT @
C:\NCP\NCOServer2\crs-data-crs\pom.xml
[DEBUG] -- end configuration --
{code}
As you can see output encoding is set to UTF-8.
The top of the pmd.html:
{code}
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
!-- Generated by Apache Maven Doxia Site Renderer 1.3 at Mar 7, 2013 --
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
head
meta http-equiv=Content-Type content=text/html;
charset=${outputEncoding} /
:
{code}
The outputEncoding just doesn't belong there untranslated and I can't figure
out what I'm doing wrong, if it's something I'm doing wrong!
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-193) CPD's sourceEncoding not set since PMD 5.1.1 is used
[ https://jira.codehaus.org/browse/MPMD-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358243#comment-358243 ] Andreas Dangel commented on MPMD-193: - Created a pull request with a unit test: https://github.com/apache/maven-plugins/pull/34 CPD's sourceEncoding not set since PMD 5.1.1 is used Key: MPMD-193 URL: https://jira.codehaus.org/browse/MPMD-193 Project: Maven PMD Plugin Issue Type: Bug Components: CPD Affects Versions: 3.2, 3.3, 3.4 Reporter: Tweea Tang Assignee: Michael Osipov Attachments: CpdReport.java.patch, CpdReport.java(setSourceEncoding).patch Since PMD 5.1.1, CPDConfiguration adds a method postContruct(). This method is used to set the sourceEncoding property used to read source files in PMD. If the sourceEncoding not set, CPD will use the platform default encoding to read the source files and maven-pmd-plugin's encoding has no effects. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://jira.codehaus.org/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358244#comment-358244
]
Andreas Dangel commented on MPMD-171:
-
See pull request for unit test: https://github.com/apache/maven-plugins/pull/35
{quote}
Couldn't reproduce it anymore. The issue was probably fixed with PMD
5.0.3/5.0.4.
The bug report is for m-pmd-p 3.0.1, which uses PMD 5.0.2.
Related bugs are: https://sourceforge.net/p/pmd/bugs/1074/ (rule priority
doesn't work on group definitions) and https://sourceforge.net/p/pmd/bugs/1089/
(When changing priority in a custom ruleset, violations reported twice)
{quote}
Rule properties are ignored when run under MPMD
---
Key: MPMD-171
URL: https://jira.codehaus.org/browse/MPMD-171
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0.1
Environment: Linux
Reporter: Johannes Wienke
For our project I have defined a custom ruleset for PMD in an XML file [1].
This ruleset defines properties for some of the standard PMD rules using this
syntax:
{noformat}
rule ref=rulesets/java/naming.xml/LongVariable
properties
property name=minimum value=25/
/properties
/rule
{noformat}
When I execute PMD using a parallel ant file we maintain, these custom
properties are respected correctly. However, when executing PMD through
maven, the properties are completely ignored.
The pom.xml we are using is available at [2].
[1]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
[2]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-165) target/site/pmd.html created with invalid charset=${outputEncoding}
[
https://jira.codehaus.org/browse/MPMD-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MPMD-165:
---
Assignee: Michael Osipov
target/site/pmd.html created with invalid charset=${outputEncoding}
---
Key: MPMD-165
URL: https://jira.codehaus.org/browse/MPMD-165
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0
Environment: Maven 3.0.5, Java 6.0.43 on Windows XP
Reporter: Robert Kish
Assignee: Michael Osipov
This problem also occurs for me with 3.1-SNAPSHOT. And it's also occurring
for me using maven-jxr-plugin in the index.html file only (not
allclasses-frame.html for example). So I am theorizing something in common
with both of those plugins has the same issue.
I have configured as a build plugin,
{code}
:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-pmd-plugin/artifactId
version3.1-SNAPSHOT/version
configuration
linkXreftrue/linkXref
targetJdk1.6/targetJdk
rulesetsrulesetruleset.xml/ruleset/rulesets
/configuration
/plugin
:
{code}
I have the following properties:
{code}
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding
/properties
{code}
From mvn -e -X output
{code}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-pmd-plugin:3.1-SNAPSHOT:pmd' with basic
configurator --
[DEBUG] (f) aggregate = false
[DEBUG] (f) compileSourceRoots =
[C:\NCP\NCOServer2\crs-data-crs\src\main\java]
[DEBUG] (f) excludes = [**/com/crs/c/*.java]
[DEBUG] (f) format = xml
[DEBUG] (f) includeTests = false
[DEBUG] (f) includeXmlInSite = false
[DEBUG] (f) language = java
[DEBUG] (f) linkXRef = true
[DEBUG] (f) minimumPriority = 5
[DEBUG] (f) outputDirectory = C:\NCP\NCOServer2\crs-data-crs\target\site
[DEBUG] (f) outputEncoding = UTF-8
[DEBUG] (f) reactorProjects = [MavenProject:
com.cr.crs:crs-data-crs:1.0-SNAPSHOT @ C:\NCP\NCOServer2\crs-data-crs\pom.xml]
[DEBUG] (s) rulesets = [C:\NCP\NCOServer2\ruleset.xml]
[DEBUG] (f) skip = false
[DEBUG] (f) sourceEncoding = UTF-8
[DEBUG] (f) targetDirectory = C:\NCP\NCOServer2\crs-data-crs\target
[DEBUG] (f) targetJdk = 1.6
[DEBUG] (f) testSourceRoots = [C:\NCP\NCOServer2\crs-data-crs\src\test\java]
[DEBUG] (f) typeResolution = false
[DEBUG] (f) xrefLocation = C:\NCP\NCOServer2\crs-data-crs\target\site\xref
[DEBUG] (f) xrefTestLocation =
C:\NCP\NCOServer2\crs-data-crs\target\site\xref-test
[DEBUG] (f) project = MavenProject: com.cr.crs:crs-data-crs:1.0-SNAPSHOT @
C:\NCP\NCOServer2\crs-data-crs\pom.xml
[DEBUG] -- end configuration --
{code}
As you can see output encoding is set to UTF-8.
The top of the pmd.html:
{code}
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
!-- Generated by Apache Maven Doxia Site Renderer 1.3 at Mar 7, 2013 --
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
head
meta http-equiv=Content-Type content=text/html;
charset=${outputEncoding} /
:
{code}
The outputEncoding just doesn't belong there untranslated and I can't figure
out what I'm doing wrong, if it's something I'm doing wrong!
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-165) target/site/pmd.html created with invalid charset=${outputEncoding}
[
https://jira.codehaus.org/browse/MPMD-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358245#comment-358245
]
Michael Osipov commented on MPMD-165:
-
Have a look at the comment in GitHub.
target/site/pmd.html created with invalid charset=${outputEncoding}
---
Key: MPMD-165
URL: https://jira.codehaus.org/browse/MPMD-165
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0
Environment: Maven 3.0.5, Java 6.0.43 on Windows XP
Reporter: Robert Kish
Assignee: Michael Osipov
This problem also occurs for me with 3.1-SNAPSHOT. And it's also occurring
for me using maven-jxr-plugin in the index.html file only (not
allclasses-frame.html for example). So I am theorizing something in common
with both of those plugins has the same issue.
I have configured as a build plugin,
{code}
:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-pmd-plugin/artifactId
version3.1-SNAPSHOT/version
configuration
linkXreftrue/linkXref
targetJdk1.6/targetJdk
rulesetsrulesetruleset.xml/ruleset/rulesets
/configuration
/plugin
:
{code}
I have the following properties:
{code}
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding
/properties
{code}
From mvn -e -X output
{code}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-pmd-plugin:3.1-SNAPSHOT:pmd' with basic
configurator --
[DEBUG] (f) aggregate = false
[DEBUG] (f) compileSourceRoots =
[C:\NCP\NCOServer2\crs-data-crs\src\main\java]
[DEBUG] (f) excludes = [**/com/crs/c/*.java]
[DEBUG] (f) format = xml
[DEBUG] (f) includeTests = false
[DEBUG] (f) includeXmlInSite = false
[DEBUG] (f) language = java
[DEBUG] (f) linkXRef = true
[DEBUG] (f) minimumPriority = 5
[DEBUG] (f) outputDirectory = C:\NCP\NCOServer2\crs-data-crs\target\site
[DEBUG] (f) outputEncoding = UTF-8
[DEBUG] (f) reactorProjects = [MavenProject:
com.cr.crs:crs-data-crs:1.0-SNAPSHOT @ C:\NCP\NCOServer2\crs-data-crs\pom.xml]
[DEBUG] (s) rulesets = [C:\NCP\NCOServer2\ruleset.xml]
[DEBUG] (f) skip = false
[DEBUG] (f) sourceEncoding = UTF-8
[DEBUG] (f) targetDirectory = C:\NCP\NCOServer2\crs-data-crs\target
[DEBUG] (f) targetJdk = 1.6
[DEBUG] (f) testSourceRoots = [C:\NCP\NCOServer2\crs-data-crs\src\test\java]
[DEBUG] (f) typeResolution = false
[DEBUG] (f) xrefLocation = C:\NCP\NCOServer2\crs-data-crs\target\site\xref
[DEBUG] (f) xrefTestLocation =
C:\NCP\NCOServer2\crs-data-crs\target\site\xref-test
[DEBUG] (f) project = MavenProject: com.cr.crs:crs-data-crs:1.0-SNAPSHOT @
C:\NCP\NCOServer2\crs-data-crs\pom.xml
[DEBUG] -- end configuration --
{code}
As you can see output encoding is set to UTF-8.
The top of the pmd.html:
{code}
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
!-- Generated by Apache Maven Doxia Site Renderer 1.3 at Mar 7, 2013 --
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
head
meta http-equiv=Content-Type content=text/html;
charset=${outputEncoding} /
:
{code}
The outputEncoding just doesn't belong there untranslated and I can't figure
out what I'm doing wrong, if it's something I'm doing wrong!
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-193) CPD's sourceEncoding not set since PMD 5.1.1 is used
[ https://jira.codehaus.org/browse/MPMD-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358246#comment-358246 ] Michael Osipov commented on MPMD-193: - Andi, I am right to assume that this merge is safe after MPMD-195 is fixed? CPD's sourceEncoding not set since PMD 5.1.1 is used Key: MPMD-193 URL: https://jira.codehaus.org/browse/MPMD-193 Project: Maven PMD Plugin Issue Type: Bug Components: CPD Affects Versions: 3.2, 3.3, 3.4 Reporter: Tweea Tang Assignee: Michael Osipov Attachments: CpdReport.java.patch, CpdReport.java(setSourceEncoding).patch Since PMD 5.1.1, CPDConfiguration adds a method postContruct(). This method is used to set the sourceEncoding property used to read source files in PMD. If the sourceEncoding not set, CPD will use the platform default encoding to read the source files and maven-pmd-plugin's encoding has no effects. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-129) Maven PMD plug-in does not have excludemarker property that is available in PMD itself.
[ https://jira.codehaus.org/browse/MPMD-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MPMD-129: --- Assignee: Michael Osipov Maven PMD plug-in does not have excludemarker property that is available in PMD itself. - Key: MPMD-129 URL: https://jira.codehaus.org/browse/MPMD-129 Project: Maven PMD Plugin Issue Type: Improvement Reporter: Svetlomira Manova Assignee: Michael Osipov Attachments: maven-pmd-patch.zip, mychanges.patch Hi all, I am trying to change the string that is used to suppress warnings in PMD report(the default one is NOPMD). I found out that for doing this in PMD itself i have to use excludemarker input param with the custom string. At the moment i think there is not such property in Maven PMD plugin. Best regards, Svetlomira -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://jira.codehaus.org/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MPMD-171:
---
Assignee: Michael Osipov
Rule properties are ignored when run under MPMD
---
Key: MPMD-171
URL: https://jira.codehaus.org/browse/MPMD-171
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0.1
Environment: Linux
Reporter: Johannes Wienke
Assignee: Michael Osipov
For our project I have defined a custom ruleset for PMD in an XML file [1].
This ruleset defines properties for some of the standard PMD rules using this
syntax:
{noformat}
rule ref=rulesets/java/naming.xml/LongVariable
properties
property name=minimum value=25/
/properties
/rule
{noformat}
When I execute PMD using a parallel ant file we maintain, these custom
properties are respected correctly. However, when executing PMD through
maven, the properties are completely ignored.
The pom.xml we are using is available at [2].
[1]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
[2]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-339) Upgrade plexus-archiver to 2.9
Karl-Heinz Marbaise created MWAR-339: Summary: Upgrade plexus-archiver to 2.9 Key: MWAR-339 URL: https://jira.codehaus.org/browse/MWAR-339 Project: Maven WAR Plugin Issue Type: Improvement Affects Versions: 2.6 Reporter: Karl-Heinz Marbaise Priority: Minor in accordance with this i need to update plexus-io to 2.4. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-339) Upgrade plexus-archiver to 2.9
[ https://jira.codehaus.org/browse/MWAR-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MWAR-339: - Fix Version/s: 2.6 Upgrade plexus-archiver to 2.9 -- Key: MWAR-339 URL: https://jira.codehaus.org/browse/MWAR-339 Project: Maven WAR Plugin Issue Type: Improvement Affects Versions: 2.6 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: 2.6 in accordance with this i need to update plexus-io to 2.4. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-339) Upgrade plexus-archiver to 2.9
[ https://jira.codehaus.org/browse/MWAR-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MWAR-339. Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1642463|http://svn.apache.org/r1642463] Upgrade plexus-archiver to 2.9 -- Key: MWAR-339 URL: https://jira.codehaus.org/browse/MWAR-339 Project: Maven WAR Plugin Issue Type: Improvement Affects Versions: 2.6 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: 2.6 in accordance with this i need to update plexus-io to 2.4. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-337) Upgrade plexus-archiver from 2.8.1 to 2.8.4
[ https://jira.codehaus.org/browse/MWAR-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MWAR-337. Resolution: Won't Fix Fix Version/s: (was: next-release) Assignee: Karl-Heinz Marbaise We have to got to plexus-archiver 2.9 instead cause version 2.8.2, 2.8.3 causing failures. Upgrade plexus-archiver from 2.8.1 to 2.8.4 --- Key: MWAR-337 URL: https://jira.codehaus.org/browse/MWAR-337 Project: Maven WAR Plugin Issue Type: Improvement Affects Versions: 2.6 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor [Release Notes plexus-archiver version 2.8.4|http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11440version=20755] * Bug: ** [PLXCOMP-273] - Normalize file separators for duplicate check [Release Notes plexus-archiver version 2.8.3|http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11440version=20733] * Bug ** [PLXCOMP-271] - Implicit created directories do not obey proper dirMode ** [PLXCOMP-272] - overriding dirmode/filemode breaks symlinks [Release Notes plexus-archiver version 2.8.2|http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11440version=20732] * Bug ** [PLXCOMP-266] - In-place filtering of streams give incorrect content length for tar files -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-167) Final manifest not written to exploded location
[ https://jira.codehaus.org/browse/MWAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358249#comment-358249 ] Karl-Heinz Marbaise commented on MWAR-167: -- Is there still demand for this ? Final manifest not written to exploded location --- Key: MWAR-167 URL: https://jira.codehaus.org/browse/MWAR-167 Project: Maven WAR Plugin Issue Type: Bug Components: manifest Affects Versions: 2.1-alpha-1 Reporter: Paul Benedict Fix For: backlog Attachments: mvn167-with-it.diff, patch.diff When I open up my generated WAR file, the Manifest file contains all the entries I specified. This is correct. However, when I look into the exploded location, it's just the file I had in my project to begin with. The exploded Manifest should be updated with the final contents. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-167) Final manifest not written to exploded location
[ https://jira.codehaus.org/browse/MWAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MWAR-167: - Fix Version/s: (was: backlog) waiting-for-feedback Final manifest not written to exploded location --- Key: MWAR-167 URL: https://jira.codehaus.org/browse/MWAR-167 Project: Maven WAR Plugin Issue Type: Bug Components: manifest Affects Versions: 2.1-alpha-1 Reporter: Paul Benedict Fix For: waiting-for-feedback Attachments: mvn167-with-it.diff, patch.diff When I open up my generated WAR file, the Manifest file contains all the entries I specified. This is correct. However, when I look into the exploded location, it's just the file I had in my project to begin with. The exploded Manifest should be updated with the final contents. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-187) Report is generated even when skip is true
[ https://jira.codehaus.org/browse/MPMD-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358250#comment-358250 ] Andreas Dangel commented on MPMD-187: - New pull request: https://github.com/apache/maven-plugins/pull/36 This is basically the same as in #21 , but additionally for cpd.skip, too and it adds a integration test. Report is generated even when skip is true -- Key: MPMD-187 URL: https://jira.codehaus.org/browse/MPMD-187 Project: Maven PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 3.1 Reporter: Ryan Heinen When pmd.skip is true, the XML and/or HTML reports are still generated. Even though they are empty, generating these files actually takes significant portion of overall build time time because a velocity engine must be instantiated. skipEmptyReports doesn't seem to avoid the cost of initializing the velocity engine. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-315) archiveClasses and archiveClassesFileNameMapping
[
https://jira.codehaus.org/browse/MWAR-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358251#comment-358251
]
Karl-Heinz Marbaise commented on MWAR-315:
--
Do you mean to change the name of the resulting artifact ? Why is needed? Can
you give a real use case? Furthermore it could result into problems if you
create an archive which has a different name than you are not able anymore to
use the defaults which means you need to take a look into the pom of the
original project how the new name has been decided which sounds weird to me?
archiveClasses and archiveClassesFileNameMapping
-
Key: MWAR-315
URL: https://jira.codehaus.org/browse/MWAR-315
Project: Maven WAR Plugin
Issue Type: Improvement
Reporter: Andreas Höhmann
Priority: Minor
I would be nice to use archiveClasses=true and then use an new parameter
to rename the created classes-jar ... something like this ...
archiveClassesFileNameMapping
00-@{artifactId}@-classes.@{extension}@
/archiveClassesFileNameMapping
I need this to bring the classes jar on top of all the other jars in
WEB-INF/lib so that the container classpath is equivalent to the normal
way, where the webapp classes are in WEB-INF/classes (top-classpath-position).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-315) archiveClasses and archiveClassesFileNameMapping
[
https://jira.codehaus.org/browse/MWAR-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MWAR-315:
-
Fix Version/s: waiting-for-feedback
archiveClasses and archiveClassesFileNameMapping
-
Key: MWAR-315
URL: https://jira.codehaus.org/browse/MWAR-315
Project: Maven WAR Plugin
Issue Type: Improvement
Reporter: Andreas Höhmann
Priority: Minor
Fix For: waiting-for-feedback
I would be nice to use archiveClasses=true and then use an new parameter
to rename the created classes-jar ... something like this ...
archiveClassesFileNameMapping
00-@{artifactId}@-classes.@{extension}@
/archiveClassesFileNameMapping
I need this to bring the classes jar on top of all the other jars in
WEB-INF/lib so that the container classpath is equivalent to the normal
way, where the webapp classes are in WEB-INF/classes (top-classpath-position).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-308) packagingExcludes does not work.
[
https://jira.codehaus.org/browse/MWAR-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MWAR-308.
Resolution: Not A Bug
Assignee: Karl-Heinz Marbaise
From the WAR only those jar's well be removed if they have been defined as
dependencies in your EAR project...To prevent a jar being removed from the WAR
you shouldn't define the dependency in the EAR project as described here:
http://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html
So i don't see a problem with packagingExcludes.
Based on that i will close the issue. If you have any objection please reopen
the issue and give more details which describe the problem you have.
packagingExcludes does not work.
--
Key: MWAR-308
URL: https://jira.codehaus.org/browse/MWAR-308
Project: Maven WAR Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.3, 2.4, 2.5
Environment: EAR
Reporter: Paul Alesius
Assignee: Karl-Heinz Marbaise
Priority: Blocker
When creating skinnyWars with maven-ear-plugin, you will end up removing all
libraries from WAR archives. Sometimes I need to keep web-fragment jars in
WEB-INF/lib inside the war otherwise it won't be used as a web-fragment (It
[the web fragment] can't be in the EAR it must be in the WAR).
To do this I use packagingExcludes as such:
packagingExcludes%regex[.*WEB-INF/lib/(?!project-my-webfragment).*.jar$]/packagingExcludes
To exclude everything by the fragment from the WAR in the EAR build. %regex[]
does not work and doesn't seem to have in any version..
The regex is correct:
{quote}
Assert.assertFalse(som/WEB-INF/lib/project-my-webfragment-0.0.1.jar.matches(.*
WEB-INF/lib/(?!project-my-webfragment). *.jar$));
Assert.assertTrue(som/WEB-INF/lib/project-my-library-0.0.1.jar.matches(.*
WEB-INF/lib/(?!project-my-webfragment). *.jar$));
(Had to insert spaces around * so it wouldn't be used for bold text
formatting)
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-308) packagingExcludes does not work.
[
https://jira.codehaus.org/browse/MWAR-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358252#comment-358252
]
Karl-Heinz Marbaise edited comment on MWAR-308 at 11/29/14 1:03 PM:
From the WAR only those jar's will be removed if they have been defined as
dependencies in your EAR project...to prevent a jar from being removed from
the WAR you shouldn't define the dependency in the EAR project as described
here:
http://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html
So i don't see a problem with packagingExcludes.
Based on that i will close the issue. If you have any objection please reopen
the issue and give more details which describe the problem you have.
was (Author: khmarbaise):
From the WAR only those jar's well be removed if they have been defined as
dependencies in your EAR project...To prevent a jar being removed from the WAR
you shouldn't define the dependency in the EAR project as described here:
http://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html
So i don't see a problem with packagingExcludes.
Based on that i will close the issue. If you have any objection please reopen
the issue and give more details which describe the problem you have.
packagingExcludes does not work.
--
Key: MWAR-308
URL: https://jira.codehaus.org/browse/MWAR-308
Project: Maven WAR Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.3, 2.4, 2.5
Environment: EAR
Reporter: Paul Alesius
Assignee: Karl-Heinz Marbaise
Priority: Blocker
When creating skinnyWars with maven-ear-plugin, you will end up removing all
libraries from WAR archives. Sometimes I need to keep web-fragment jars in
WEB-INF/lib inside the war otherwise it won't be used as a web-fragment (It
[the web fragment] can't be in the EAR it must be in the WAR).
To do this I use packagingExcludes as such:
packagingExcludes%regex[.*WEB-INF/lib/(?!project-my-webfragment).*.jar$]/packagingExcludes
To exclude everything by the fragment from the WAR in the EAR build. %regex[]
does not work and doesn't seem to have in any version..
The regex is correct:
{quote}
Assert.assertFalse(som/WEB-INF/lib/project-my-webfragment-0.0.1.jar.matches(.*
WEB-INF/lib/(?!project-my-webfragment). *.jar$));
Assert.assertTrue(som/WEB-INF/lib/project-my-library-0.0.1.jar.matches(.*
WEB-INF/lib/(?!project-my-webfragment). *.jar$));
(Had to insert spaces around * so it wouldn't be used for bold text
formatting)
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-310) Enable skip overlays from command line
[ https://jira.codehaus.org/browse/MWAR-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MWAR-310: - Fix Version/s: next-release Enable skip overlays from command line -- Key: MWAR-310 URL: https://jira.codehaus.org/browse/MWAR-310 Project: Maven WAR Plugin Issue Type: New Feature Components: overlay Affects Versions: 2.4, 2.5 Environment: N/A Reporter: Julio Palma Vázquez Priority: Minor Fix For: next-release Sometimes I need to skip the overlay plugin execution but I don't want to change all my (about one hundred) pom.xml files. I've done this modifing Overlay.java class as below: private boolean skip = true; But I think you could find a more elegant solution such as adding a parameter: import org.apache.maven.plugins.annotations.Parameter; [...] @Parameter( property = skipOverlays, defaultValue = false ) private boolean skip; I've tested this code but for some reason (yes, I know, is my fault) it doesn't work, and unfortunatelly I have no more time to spend in this task. Please, don't let my stupidity prevents you to consider this improvement. Best Regards, -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-167) Final manifest not written to exploded location
[ https://jira.codehaus.org/browse/MWAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358255#comment-358255 ] Alix Warnke commented on MWAR-167: -- I still would like it at least Final manifest not written to exploded location --- Key: MWAR-167 URL: https://jira.codehaus.org/browse/MWAR-167 Project: Maven WAR Plugin Issue Type: Bug Components: manifest Affects Versions: 2.1-alpha-1 Reporter: Paul Benedict Fix For: waiting-for-feedback Attachments: mvn167-with-it.diff, patch.diff When I open up my generated WAR file, the Manifest file contains all the entries I specified. This is correct. However, when I look into the exploded location, it's just the file I had in my project to begin with. The exploded Manifest should be updated with the final contents. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-735) NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80)
[ https://jira.codehaus.org/browse/MASSEMBLY-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358256#comment-358256 ] Kristian Rosenvold commented on MASSEMBLY-735: -- I assume this issue has been fixed with r1642461, when the related PLXCOMP-276 was committed in assembly. The problem (and hence my inability to simply fix a seemingly simple NPE) was the large number of duplicate code paths that were creating plexus-io resources for files and symlinks. With this fix we should be down to 1 code path, which should work :) If you can test 2.5.3-SNAPSHOT (avaiable from repository.apache.org), we can either close this issue or further diagnose it. NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80) - Key: MASSEMBLY-735 URL: https://jira.codehaus.org/browse/MASSEMBLY-735 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.1, 2.5.2 Environment: Linux Reporter: Martijn Verburg Priority: Blocker [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single (make-assembly) on project java-simulations: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single (make-assembly) on project java-simulations: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224) 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:116) 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:582) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.apache.maven.plugin.PluginExecutionException: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 19 more Caused by: java.lang.NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:542) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:602) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:389) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:314) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:213) at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940) at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541) at
[jira] (MASSEMBLY-738) Upgrade to plexus-archiver 2.9 and plexus-io 2.4
Kristian Rosenvold created MASSEMBLY-738: Summary: Upgrade to plexus-archiver 2.9 and plexus-io 2.4 Key: MASSEMBLY-738 URL: https://jira.codehaus.org/browse/MASSEMBLY-738 Project: Maven Assembly Plugin Issue Type: Improvement Affects Versions: 2.5.2 Reporter: Kristian Rosenvold -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-738) Upgrade to plexus-archiver 2.9 and plexus-io 2.4
[ https://jira.codehaus.org/browse/MASSEMBLY-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-738. Resolution: Fixed Fix Version/s: 2.5.3 Assignee: Kristian Rosenvold Fixed in r1642461 Release Notes - Plexus Components - Version plexus-archiver-2.9 ** Bug * [PLXCOMP-277] - Archiver unable to determine file equailty ** Improvement * [PLXCOMP-276] - Reduce number of ways to create a PlexusIoResource Release Notes - Plexus Components - Version plexus-io-2.4 ** Improvement * [PLXCOMP-274] - Simplify use of proxies * [PLXCOMP-275] - Avoid leaky abstractions * [PLXCOMP-276] - Reduce number of ways to create a PlexusIoResource Upgrade to plexus-archiver 2.9 and plexus-io 2.4 Key: MASSEMBLY-738 URL: https://jira.codehaus.org/browse/MASSEMBLY-738 Project: Maven Assembly Plugin Issue Type: Improvement Affects Versions: 2.5.2 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 2.5.3 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-206) Upgrade plexus-archiver to 2.9
Kristian Rosenvold created MEAR-206: --- Summary: Upgrade plexus-archiver to 2.9 Key: MEAR-206 URL: https://jira.codehaus.org/browse/MEAR-206 Project: Maven Ear Plugin Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Kristian Rosenvold -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-206) Upgrade plexus-archiver to 2.9
[ https://jira.codehaus.org/browse/MEAR-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MEAR-206. --- Resolution: Fixed Assignee: Kristian Rosenvold Release Notes - Plexus Components - Version plexus-archiver-2.9 Bug PLXCOMP-277 - Archiver unable to determine file equailty Improvement PLXCOMP-276 - Reduce number of ways to create a PlexusIoResource Release Notes - Plexus Components - Version plexus-io-2.4 Improvement PLXCOMP-274 - Simplify use of proxies PLXCOMP-275 - Avoid leaky abstractions PLXCOMP-276 - Reduce number of ways to create a PlexusIoResource Release Notes - Plexus Components - Version plexus-archiver-2.8.4 ** Bug * [PLXCOMP-273] - Normalize file separators for duplicate check Release Notes - Plexus Components - Version plexus-archiver-2.8.3 ** Bug * [PLXCOMP-271] - Implicit created directories do not obey proper dirMode * [PLXCOMP-272] - overriding dirmode/filemode breaks symlinks Release Notes - Plexus Components - Version plexus-archiver-2.8.2 ** Bug * [PLXCOMP-266] - In-place filtering of streams give incorrect content length for tar files Upgrade plexus-archiver to 2.9 -- Key: MEAR-206 URL: https://jira.codehaus.org/browse/MEAR-206 Project: Maven Ear Plugin Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-735) NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80)
[ https://jira.codehaus.org/browse/MASSEMBLY-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358259#comment-358259 ] Martijn Verburg commented on MASSEMBLY-735: --- Will give it a go thanks! NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80) - Key: MASSEMBLY-735 URL: https://jira.codehaus.org/browse/MASSEMBLY-735 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.1, 2.5.2 Environment: Linux Reporter: Martijn Verburg Priority: Blocker [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single (make-assembly) on project java-simulations: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single (make-assembly) on project java-simulations: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224) 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:116) 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:582) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.apache.maven.plugin.PluginExecutionException: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 19 more Caused by: java.lang.NullPointerException at org.apache.commons.compress.archivers.zip.FallbackZipEncoding.encode(FallbackZipEncoding.java:80) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:542) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:602) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:389) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:314) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:213) at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940) at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) ... 20 more -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-187) Report is generated even when skip is true
[
https://jira.codehaus.org/browse/MPMD-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358260#comment-358260
]
Michael Osipov commented on MPMD-187:
-
Ryan,
bq. skipEmptyReports doesn't seem to avoid the cost of initializing the
velocity engine.
if that is the case, then {{skipEmptyReport}} is incorrectly implemented.
Please file another issue for that.
Report is generated even when skip is true
--
Key: MPMD-187
URL: https://jira.codehaus.org/browse/MPMD-187
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.1
Reporter: Ryan Heinen
When pmd.skip is true, the XML and/or HTML reports are still generated. Even
though they are empty, generating these files actually takes significant
portion of overall build time time because a velocity engine must be
instantiated. skipEmptyReports doesn't seem to avoid the cost of initializing
the velocity engine.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-187) Report is generated even when skip is true
[ https://jira.codehaus.org/browse/MPMD-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MPMD-187: --- Assignee: Michael Osipov Report is generated even when skip is true -- Key: MPMD-187 URL: https://jira.codehaus.org/browse/MPMD-187 Project: Maven PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 3.1 Reporter: Ryan Heinen Assignee: Michael Osipov When pmd.skip is true, the XML and/or HTML reports are still generated. Even though they are empty, generating these files actually takes significant portion of overall build time time because a velocity engine must be instantiated. skipEmptyReports doesn't seem to avoid the cost of initializing the velocity engine. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-206) Upgrade plexus-archiver to 2.9
[ https://jira.codehaus.org/browse/MEAR-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358258#comment-358258 ] Kristian Rosenvold edited comment on MEAR-206 at 11/29/14 2:39 PM: --- Cumulative release notes for archive/io at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.txt was (Author: krosenvold): Release Notes - Plexus Components - Version plexus-archiver-2.9 Bug PLXCOMP-277 - Archiver unable to determine file equailty Improvement PLXCOMP-276 - Reduce number of ways to create a PlexusIoResource Release Notes - Plexus Components - Version plexus-io-2.4 Improvement PLXCOMP-274 - Simplify use of proxies PLXCOMP-275 - Avoid leaky abstractions PLXCOMP-276 - Reduce number of ways to create a PlexusIoResource Release Notes - Plexus Components - Version plexus-archiver-2.8.4 ** Bug * [PLXCOMP-273] - Normalize file separators for duplicate check Release Notes - Plexus Components - Version plexus-archiver-2.8.3 ** Bug * [PLXCOMP-271] - Implicit created directories do not obey proper dirMode * [PLXCOMP-272] - overriding dirmode/filemode breaks symlinks Release Notes - Plexus Components - Version plexus-archiver-2.8.2 ** Bug * [PLXCOMP-266] - In-place filtering of streams give incorrect content length for tar files Upgrade plexus-archiver to 2.9 -- Key: MEAR-206 URL: https://jira.codehaus.org/browse/MEAR-206 Project: Maven Ear Plugin Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-189) Upgrade plexus-archiver dependency to v2.9
[ https://jira.codehaus.org/browse/MJAR-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358261#comment-358261 ] Kristian Rosenvold commented on MJAR-189: - 2.9 in r1642475 Upgrade plexus-archiver dependency to v2.9 -- Key: MJAR-189 URL: https://jira.codehaus.org/browse/MJAR-189 Project: Maven JAR Plugin Issue Type: Bug Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor Fix For: 2.5.1 The plexus-archiver dependency should be upgraded to v2.9 to align with transitive dependency from maven-archiver. Cumulative release notes for archiver at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.txt -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-189) Upgrade plexus-archiver dependency to v2.9
[ https://jira.codehaus.org/browse/MJAR-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MJAR-189: Description: The plexus-archiver dependency should be upgraded to v2.9 to align with transitive dependency from maven-archiver. Cumulative release notes for archiver at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.txt was:The plexus-archiver dependency should be upgraded to v2.8.1 to align with transitive dependency from maven-archiver. Summary: Upgrade plexus-archiver dependency to v2.9 (was: Upgrade plexus-archiver dependency to v2.8.4) Upgrade plexus-archiver dependency to v2.9 -- Key: MJAR-189 URL: https://jira.codehaus.org/browse/MJAR-189 Project: Maven JAR Plugin Issue Type: Bug Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor Fix For: 2.5.1 The plexus-archiver dependency should be upgraded to v2.9 to align with transitive dependency from maven-archiver. Cumulative release notes for archiver at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.txt -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-206) Upgrade plexus-archiver to 2.9
[ https://jira.codehaus.org/browse/MEAR-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358258#comment-358258 ] Kristian Rosenvold edited comment on MEAR-206 at 11/29/14 3:01 PM: --- Cumulative release notes for archive/io at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.md was (Author: krosenvold): Cumulative release notes for archive/io at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.txt Upgrade plexus-archiver to 2.9 -- Key: MEAR-206 URL: https://jira.codehaus.org/browse/MEAR-206 Project: Maven Ear Plugin Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-189) Upgrade plexus-archiver dependency to v2.9
[ https://jira.codehaus.org/browse/MJAR-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MJAR-189: Description: The plexus-archiver dependency should be upgraded to v2.9 to align with transitive dependency from maven-archiver. Cumulative release notes for archiver at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.md was: The plexus-archiver dependency should be upgraded to v2.9 to align with transitive dependency from maven-archiver. Cumulative release notes for archiver at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.txt Upgrade plexus-archiver dependency to v2.9 -- Key: MJAR-189 URL: https://jira.codehaus.org/browse/MJAR-189 Project: Maven JAR Plugin Issue Type: Bug Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor Fix For: 2.5.1 The plexus-archiver dependency should be upgraded to v2.9 to align with transitive dependency from maven-archiver. Cumulative release notes for archiver at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.md -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MECLIPSE-695) Problem of path for additionalConfig with sub-modules
[
https://jira.codehaus.org/browse/MECLIPSE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358262#comment-358262
]
Alexandre Garnier edited comment on MECLIPSE-695 at 11/29/14 3:14 PM:
--
The problem come from
[r8366|https://fisheye.codehaus.org/changelog/plexus?cs=8366] for PLXCOMP-145.
Changing the instantiation strategy to {{instantiation-strategy=per-lookup}}
has for consequence to re-instance the {{FileResourceLoader}} each time and so
forget the path of the parent project as search path.
The solution will be to explicitly add parent project as search path (patch
coming soon).
was (Author: zigarn):
The problem come from
[r8366|https://fisheye.codehaus.org/changelog/plexus?cs=8366] for PLXCOMP-145.
Changing the instantiation strategy to {{instantiation-strategy=per-lookup}}
as for consequence to re-instance the {{FileResourceLoader}} each time and so
forget the path of the parent project as search path.
The solution will be to explicitly add parent project as search path (patch
coming soon).
Problem of path for additionalConfig with sub-modules
-
Key: MECLIPSE-695
URL: https://jira.codehaus.org/browse/MECLIPSE-695
Project: Maven Eclipse Plugin
Issue Type: Bug
Components: Core : Workspace settings
Affects Versions: 2.8
Reporter: Alexandre Garnier
Attachments: MECLIPSE-695.zip
When defining path to additionalConfig files in parent pom (relative to
pom.xml location), sub-modules did not find them.
{code:language=xml}
[...]
modules
modulemodule/module
/module
[...]
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
additionalConfig
file
name.settings/org.eclipse.core.resources.prefs/name
locationsettings/org.eclipse.core.resources.prefs/location
/file
/additionalConfig
/configuration
/plugin
/plugins
/pluginManagement
[...]
{code}
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse (default-cli) on
project module: Unable to resolve resource location:
settings/org.eclipse.core.resources.prefs
{code}
It works fine in 2.7.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MECLIPSE-695) Problem of path for additionalConfig with sub-modules
[
https://jira.codehaus.org/browse/MECLIPSE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358262#comment-358262
]
Alexandre Garnier commented on MECLIPSE-695:
The problem come from
[r8366|https://fisheye.codehaus.org/changelog/plexus?cs=8366] for PLXCOMP-145.
Changing the instantiation strategy to {{instantiation-strategy=per-lookup}}
as for consequence to re-instance the {{FileResourceLoader}} each time and so
forget the path of the parent project as search path.
The solution will be to explicitly add parent project as search path (patch
coming soon).
Problem of path for additionalConfig with sub-modules
-
Key: MECLIPSE-695
URL: https://jira.codehaus.org/browse/MECLIPSE-695
Project: Maven Eclipse Plugin
Issue Type: Bug
Components: Core : Workspace settings
Affects Versions: 2.8
Reporter: Alexandre Garnier
Attachments: MECLIPSE-695.zip
When defining path to additionalConfig files in parent pom (relative to
pom.xml location), sub-modules did not find them.
{code:language=xml}
[...]
modules
modulemodule/module
/module
[...]
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
additionalConfig
file
name.settings/org.eclipse.core.resources.prefs/name
locationsettings/org.eclipse.core.resources.prefs/location
/file
/additionalConfig
/configuration
/plugin
/plugins
/pluginManagement
[...]
{code}
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse (default-cli) on
project module: Unable to resolve resource location:
settings/org.eclipse.core.resources.prefs
{code}
It works fine in 2.7.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-729) Update version of plexus-archiver to 2.9
[ https://jira.codehaus.org/browse/MSITE-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSITE-729: - Description: archiver release notes at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.md was: [Release Notes plexus-archiver 2.5|https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11440version=20630] * Bugs: ** [PLXCOMP-13] - Plexus Archiver fails on certain Jars ** [PLXCOMP-205] - Tar unarchiver does not respect includes/excludes flags ** [PLXCOMP-216] - Unarchiver extracts files into wrong directory ** [PLXCOMP-236] - ZipUnArchiver fails to extract large (4GB) ZIP files ** [PLXCOMP-238] - CRC Failure if compress=false * Improvements: ** [PLXCOMP-153] - TarUnArchiver does not support includes/excludes ** [PLXCOMP-240] - Convert everything to commons-compress Summary: Update version of plexus-archiver to 2.9 (was: Update version of plexus-archiver to 2.6.1) Update version of plexus-archiver to 2.9 Key: MSITE-729 URL: https://jira.codehaus.org/browse/MSITE-729 Project: Maven Site Plugin Issue Type: Improvement Affects Versions: 3.4.1 Reporter: Karl-Heinz Marbaise Assignee: Kristian Rosenvold Fix For: 3.4.1 archiver release notes at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.md -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-729) Update version of plexus-archiver to 2.9
[ https://jira.codehaus.org/browse/MSITE-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358263#comment-358263 ] Kristian Rosenvold commented on MSITE-729: -- 2.9 in r1642477 Update version of plexus-archiver to 2.9 Key: MSITE-729 URL: https://jira.codehaus.org/browse/MSITE-729 Project: Maven Site Plugin Issue Type: Improvement Affects Versions: 3.4.1 Reporter: Karl-Heinz Marbaise Assignee: Kristian Rosenvold Fix For: 3.4.1 archiver release notes at https://github.com/sonatype/plexus-archiver/blob/master/ReleaseNotes.md -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MECLIPSE-695) Problem of path for additionalConfig with sub-modules
[
https://jira.codehaus.org/browse/MECLIPSE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358264#comment-358264
]
Michael Osipov commented on MECLIPSE-695:
-
You should file an issue with Plexus Components.
Problem of path for additionalConfig with sub-modules
-
Key: MECLIPSE-695
URL: https://jira.codehaus.org/browse/MECLIPSE-695
Project: Maven Eclipse Plugin
Issue Type: Bug
Components: Core : Workspace settings
Affects Versions: 2.8
Reporter: Alexandre Garnier
Attachments: MECLIPSE-695.zip
When defining path to additionalConfig files in parent pom (relative to
pom.xml location), sub-modules did not find them.
{code:language=xml}
[...]
modules
modulemodule/module
/module
[...]
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
additionalConfig
file
name.settings/org.eclipse.core.resources.prefs/name
locationsettings/org.eclipse.core.resources.prefs/location
/file
/additionalConfig
/configuration
/plugin
/plugins
/pluginManagement
[...]
{code}
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse (default-cli) on
project module: Unable to resolve resource location:
settings/org.eclipse.core.resources.prefs
{code}
It works fine in 2.7.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MECLIPSE-695) Problem of path for additionalConfig with sub-modules
[
https://jira.codehaus.org/browse/MECLIPSE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Garnier updated MECLIPSE-695:
---
Attachment: MECLIPSE-695-multi-modules.zip
I don't think it's a plexus-resource bug.
In fact it was a potential bug in eclipse-plugin: when using multiple modules,
the additionalConfig where searched in the order of the modules, not only
current module + recursive parents.
A use case in attachment.
Problem of path for additionalConfig with sub-modules
-
Key: MECLIPSE-695
URL: https://jira.codehaus.org/browse/MECLIPSE-695
Project: Maven Eclipse Plugin
Issue Type: Bug
Components: Core : Workspace settings
Affects Versions: 2.8
Reporter: Alexandre Garnier
Attachments: MECLIPSE-695-multi-modules.zip, MECLIPSE-695.zip
When defining path to additionalConfig files in parent pom (relative to
pom.xml location), sub-modules did not find them.
{code:language=xml}
[...]
modules
modulemodule/module
/module
[...]
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
additionalConfig
file
name.settings/org.eclipse.core.resources.prefs/name
locationsettings/org.eclipse.core.resources.prefs/location
/file
/additionalConfig
/configuration
/plugin
/plugins
/pluginManagement
[...]
{code}
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse (default-cli) on
project module: Unable to resolve resource location:
settings/org.eclipse.core.resources.prefs
{code}
It works fine in 2.7.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MECLIPSE-695) Problem of path for additionalConfig with sub-modules
[
https://jira.codehaus.org/browse/MECLIPSE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Garnier updated MECLIPSE-695:
---
Attachment: MECLIPSE-695.patch
Here is a patch to fix this.
I'm working on the corresponding unit-tests.
Problem of path for additionalConfig with sub-modules
-
Key: MECLIPSE-695
URL: https://jira.codehaus.org/browse/MECLIPSE-695
Project: Maven Eclipse Plugin
Issue Type: Bug
Components: Core : Workspace settings
Affects Versions: 2.8
Reporter: Alexandre Garnier
Attachments: MECLIPSE-695-multi-modules.zip, MECLIPSE-695.patch,
MECLIPSE-695.zip
When defining path to additionalConfig files in parent pom (relative to
pom.xml location), sub-modules did not find them.
{code:language=xml}
[...]
modules
modulemodule/module
/module
[...]
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
additionalConfig
file
name.settings/org.eclipse.core.resources.prefs/name
locationsettings/org.eclipse.core.resources.prefs/location
/file
/additionalConfig
/configuration
/plugin
/plugins
/pluginManagement
[...]
{code}
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse (default-cli) on
project module: Unable to resolve resource location:
settings/org.eclipse.core.resources.prefs
{code}
It works fine in 2.7.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-165) target/site/pmd.html created with invalid charset=${outputEncoding}
[
https://jira.codehaus.org/browse/MPMD-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPMD-165.
---
Resolution: Fixed
Fix Version/s: 3.4
Fixed with [r1642483|http://svn.apache.org/r1642483].
target/site/pmd.html created with invalid charset=${outputEncoding}
---
Key: MPMD-165
URL: https://jira.codehaus.org/browse/MPMD-165
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0
Environment: Maven 3.0.5, Java 6.0.43 on Windows XP
Reporter: Robert Kish
Assignee: Michael Osipov
Fix For: 3.4
This problem also occurs for me with 3.1-SNAPSHOT. And it's also occurring
for me using maven-jxr-plugin in the index.html file only (not
allclasses-frame.html for example). So I am theorizing something in common
with both of those plugins has the same issue.
I have configured as a build plugin,
{code}
:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-pmd-plugin/artifactId
version3.1-SNAPSHOT/version
configuration
linkXreftrue/linkXref
targetJdk1.6/targetJdk
rulesetsrulesetruleset.xml/ruleset/rulesets
/configuration
/plugin
:
{code}
I have the following properties:
{code}
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding
/properties
{code}
From mvn -e -X output
{code}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-pmd-plugin:3.1-SNAPSHOT:pmd' with basic
configurator --
[DEBUG] (f) aggregate = false
[DEBUG] (f) compileSourceRoots =
[C:\NCP\NCOServer2\crs-data-crs\src\main\java]
[DEBUG] (f) excludes = [**/com/crs/c/*.java]
[DEBUG] (f) format = xml
[DEBUG] (f) includeTests = false
[DEBUG] (f) includeXmlInSite = false
[DEBUG] (f) language = java
[DEBUG] (f) linkXRef = true
[DEBUG] (f) minimumPriority = 5
[DEBUG] (f) outputDirectory = C:\NCP\NCOServer2\crs-data-crs\target\site
[DEBUG] (f) outputEncoding = UTF-8
[DEBUG] (f) reactorProjects = [MavenProject:
com.cr.crs:crs-data-crs:1.0-SNAPSHOT @ C:\NCP\NCOServer2\crs-data-crs\pom.xml]
[DEBUG] (s) rulesets = [C:\NCP\NCOServer2\ruleset.xml]
[DEBUG] (f) skip = false
[DEBUG] (f) sourceEncoding = UTF-8
[DEBUG] (f) targetDirectory = C:\NCP\NCOServer2\crs-data-crs\target
[DEBUG] (f) targetJdk = 1.6
[DEBUG] (f) testSourceRoots = [C:\NCP\NCOServer2\crs-data-crs\src\test\java]
[DEBUG] (f) typeResolution = false
[DEBUG] (f) xrefLocation = C:\NCP\NCOServer2\crs-data-crs\target\site\xref
[DEBUG] (f) xrefTestLocation =
C:\NCP\NCOServer2\crs-data-crs\target\site\xref-test
[DEBUG] (f) project = MavenProject: com.cr.crs:crs-data-crs:1.0-SNAPSHOT @
C:\NCP\NCOServer2\crs-data-crs\pom.xml
[DEBUG] -- end configuration --
{code}
As you can see output encoding is set to UTF-8.
The top of the pmd.html:
{code}
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
!-- Generated by Apache Maven Doxia Site Renderer 1.3 at Mar 7, 2013 --
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
head
meta http-equiv=Content-Type content=text/html;
charset=${outputEncoding} /
:
{code}
The outputEncoding just doesn't belong there untranslated and I can't figure
out what I'm doing wrong, if it's something I'm doing wrong!
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[
https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358268#comment-358268
]
Tibor Digana commented on SUREFIRE-855:
---
Benson, can you make a temporary workaround proposed by Robert? I want to know
if we break the current PAX users.
The fix seems to be quite doable.
Can somebody tell me if we have an artifact with EAR, WAR ClassLoaders in Maven
project?
I can get the JAR file path quite easily in order to fallback to JAR (if any
exists):
MavenProject#getModel().getBuild().getDirectory()
MavenProject#getModel().getBuild().getFinalName()
If the JAR file does not exist, I will fallback to
${project.build.outputDirectory}.
Allow failsafe to use actual jar file instead of target/classes
---
Key: SUREFIRE-855
URL: https://jira.codehaus.org/browse/SUREFIRE-855
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin
Affects Versions: 2.12
Reporter: Benson Margulies
Priority: Critical
I've got some code that calls Class.getPackage() to see the manifest. I want
to test it. A seemingly logical scheme here would be to have failsafe put the
actual packaged jar into the classpath instead of the unpacked directory --
or some way to get the manifest copied across.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-855: - Assignee: Tibor Digana Allow failsafe to use actual jar file instead of target/classes --- Key: SUREFIRE-855 URL: https://jira.codehaus.org/browse/SUREFIRE-855 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Affects Versions: 2.12 Reporter: Benson Margulies Assignee: Tibor Digana Priority: Critical I've got some code that calls Class.getPackage() to see the manifest. I want to test it. A seemingly logical scheme here would be to have failsafe put the actual packaged jar into the classpath instead of the unpacked directory -- or some way to get the manifest copied across. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-209) Incremental compilation doesn't work unless useIncrementalCompilation is set to 'false'
[
https://jira.codehaus.org/browse/MCOMPILER-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358269#comment-358269
]
Aditya Kishore commented on MCOMPILER-209:
--
As someone who ran into different facet of this issue with different projects,
I have documented my findings here:
http://bcn.adityakishore.com/2014/11/broken-incremental-compilation-with.html
With current assumptions behind this feature, I do not see this to be resolved
by a simple fix. Would you consider changing the default setting for this to
{{false}}?
Incremental compilation doesn't work unless useIncrementalCompilation is set
to 'false'
---
Key: MCOMPILER-209
URL: https://jira.codehaus.org/browse/MCOMPILER-209
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.1
Reporter: Michael Ekstrand
Attachments: SO_AJ_MavenSoftExceptions.zip
The compiler plugin has the
[useIncrementalCompilation|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#useIncrementalCompilation]
flag. However, when this flag is set to {{true}} and using the {{javac}}
compiler, the compilation is not very incremental; the compiler always at
least claims it is rebuilding all source files (and compile times are
consistent with this being what it is actually doing, though it is hard to
tell). If I set {{useIncrementalCompilation}} to {{false}}, then it actually
does report that some modules are up-to-date, and some only need a subset of
their files compiled.
It seems that one or more of the following is happening:
* {{useIncrementalCompilation}} has some meaning that is very different from
what a user would expect, actually controlling whether the compiler plugin
uses some internal incremental compilation mechanism vs. incremental
compilation support built-in to the particular compiler backend. One would
expect this flag to turn on incremental compilation vs. build-everything.
* The log messages do not reflect what it is actually doing; that is, it
seems possible that it's saying Compiling 164 source files when it's really
handing 164 source files off to the compiler for potential compilation. If
this is the case, it is very confusing and misleading.
* The logic of {{useIncrementalCompilation}} is just inverted. Looking at
the source code for the abstract compiler MOJO, it doesn't look like it's
quite this simple, but I also don't know what all the various components at
work are doing.
* There is a bug in the implementation of {{useIncrementalCompilation}}.
The result of all this is incremental compilation with Maven is very
confusing and difficult to understand.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
