[jira] [Commented] (MPMD-244) Maven PMD plugin fails but no reason is given for the failure
[
https://issues.apache.org/jira/browse/MPMD-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16343136#comment-16343136
]
Hudson commented on MPMD-244:
-
Build succeeded in Jenkins: Maven TLP » maven-pmd-plugin » master #19
See https://builds.apache.org/job/maven-box/job/maven-pmd-plugin/job/master/19/
> Maven PMD plugin fails but no reason is given for the failure
> -
>
> Key: MPMD-244
> URL: https://issues.apache.org/jira/browse/MPMD-244
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.8
> Environment: Maven 3.5.0
> PMD 5.8.1
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Fedora 23
>Reporter: Goldstein Lyor
>Assignee: Andreas Dangel
>Priority: Blocker
> Fix For: 3.9.0
>
>
> After upgrading used PMD version from 5.6.1 to 5.8.1, Maven PMD plugin fails
> with no specific reason except {{Failed to process...}}. Furthermore, there
> is no PMD report or other file that indicates what is wrong.
> P.S. The file that it complains about passes without a problem for version
> 5.6.1
> {noformat}
> $ mvn -X -Dpmd.verbose=true clean install
> Maven home: /home/lyor/Software/apache-maven-3.5.0
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-2.b14.fc22.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.14-200.fc22.x86_64", arch: "amd64", family:
> "unix"
> .
> ..
> [INFO] --- maven-pmd-plugin:3.8:pmd (pmd) @ cb4-common-util ---
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=1,
> ConflictMarker.markTime=0, ConflictMarker.nodeCount=280,
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0,
> ConflictIdSorter.conflictIdCount=70, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=2, ConflictResolver.conflictItemCount=152,
> DefaultDependencyCollector.collectTime=38,
> DefaultDependencyCollector.transformTime=3}
> [DEBUG] org.apache.maven.plugins:maven-pmd-plugin:jar:3.8:
> [DEBUG]net.sourceforge.pmd:pmd-core:jar:5.8.1:runtime
> [DEBUG] com.beust:jcommander:jar:1.48:runtime
> [DEBUG] jaxen:jaxen:jar:1.1.6:runtime
> [DEBUG] net.java.dev.javacc:javacc:jar:5.0:runtime
> [DEBUG] net.sourceforge.saxon:saxon:jar:9.1.0.8:runtime
> [DEBUG] org.apache.commons:commons-lang3:jar:3.4:runtime
> [DEBUG] org.ow2.asm:asm:jar:5.0.4:runtime
> [DEBUG] com.google.code.gson:gson:jar:2.5:runtime
> [DEBUG] net.sourceforge.saxon:saxon:jar:dom:9.1.0.8:runtime
> [DEBUG]net.sourceforge.pmd:pmd-java:jar:5.8.1:runtime
> [DEBUG]net.sourceforge.pmd:pmd-javascript:jar:5.8.1:runtime
> [DEBUG] org.mozilla:rhino:jar:1.7.7:runtime
> [DEBUG]net.sourceforge.pmd:pmd-jsp:jar:5.8.1:runtime
> [DEBUG]org.apache.maven:maven-artifact:jar:2.2.1:compile
> [DEBUG]org.apache.maven:maven-model:jar:2.2.1:compile
> [DEBUG]org.apache.maven:maven-plugin-api:jar:2.2.1:compile
> [DEBUG]org.apache.maven:maven-project:jar:2.2.1:compile
> [DEBUG] org.apache.maven:maven-settings:jar:2.2.1:compile
> [DEBUG] org.apache.maven:maven-profile:jar:2.2.1:compile
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.2.1:compile
> [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.2.1:compile
> [DEBUG]
> backport-util-concurrent:backport-util-concurrent:jar:3.1:compile
> [DEBUG] org.apache.maven:maven-plugin-registry:jar:2.2.1:compile
> [DEBUG] org.codehaus.plexus:plexus-interpolation:jar:1.11:compile
> [DEBUG]
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
> [DEBUG] junit:junit:jar:3.8.1:compile
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2:compile
> [DEBUG]org.apache.maven.doxia:doxia-sink-api:jar:1.4:compile
> [DEBUG] org.apache.maven.doxia:doxia-logging-api:jar:1.4:compile
> [DEBUG]org.apache.maven.doxia:doxia-decoration-model:jar:1.4:compile
> [DEBUG] org.codehaus.plexus:plexus-component-annotations:jar:1.6:compile
> [DEBUG]org.apache.maven.doxia:doxia-site-renderer:jar:1.4:compile
> [DEBUG] org.apache.maven.doxia:doxia-core:jar:1.4:compile
> [DEBUG] xerces:xercesImpl:jar:2.9.1:compile
> [DEBUG] commons-lang:commons-lang:jar:2.4:compile
> [DEBUG] org.apache.maven.doxia:doxia-module-xhtml:jar:1.4:compile
> [DEBUG] org.apache.maven.doxia:doxia-module-fml:jar:1.4:compile
> [DEBUG] org.codehaus.plexus:plexus-i18n:jar:1.0-beta-7:compile
> [DEBUG] org.codehaus.plexus:plexus-velocity:jar:1.1.7:compile
> [DEBUG] org.apache.velocity:velocity:jar:1.5:compile
> [DEBUG] oro:oro:jar:2.0.8:compile
> [DEBUG] org.apache.velocity:velocity-
[jira] [Closed] (MNG-6284) inside should raise a warning
[ https://issues.apache.org/jira/browse/MNG-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6284. -- Resolution: Not A Problem Closing this "Not A Problem". Just watch out for MNG-5339 if things seem confusing. > inside should raise a warning > - > > Key: MNG-6284 > URL: https://issues.apache.org/jira/browse/MNG-6284 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.5 > Environment: Ubuntu 14.04.3 >Reporter: Chris Hennick >Priority: Major > > When I was setting up my project's pom.xml, I was unaware that there was a > difference between project/build/pluginManagement/plugins and > project/build/plugins. These StackOverflow questions indicate I'm not the > only one who was confused: > * > https://stackoverflow.com/questions/18557245/not-able-to-bind-plugin-goals-to-maven-lifecycle-phases > * > https://stackoverflow.com/questions/23785443/binding-to-lifecycle-in-maven-does-not-work-on-failsafe-and-integration-test > If we have to have such a confusing schema, then can we please at least raise > a warning when the confusion inevitably occurs, given how easy it is to > detect (since AFAICT there'd be no reason to put an executions tag inside > pluginManagement/plugins/plugin)? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-6284) inside should raise a warning
[ https://issues.apache.org/jira/browse/MNG-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16343167#comment-16343167 ] Christian Schulte edited comment on MNG-6284 at 1/29/18 10:16 AM: -- Closing this "Not A Problem". Just watch out for MNG-5359 if things seem confusing. was (Author: schulte77): Closing this "Not A Problem". Just watch out for MNG-5339 if things seem confusing. > inside should raise a warning > - > > Key: MNG-6284 > URL: https://issues.apache.org/jira/browse/MNG-6284 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.5 > Environment: Ubuntu 14.04.3 >Reporter: Chris Hennick >Priority: Major > > When I was setting up my project's pom.xml, I was unaware that there was a > difference between project/build/pluginManagement/plugins and > project/build/plugins. These StackOverflow questions indicate I'm not the > only one who was confused: > * > https://stackoverflow.com/questions/18557245/not-able-to-bind-plugin-goals-to-maven-lifecycle-phases > * > https://stackoverflow.com/questions/23785443/binding-to-lifecycle-in-maven-does-not-work-on-failsafe-and-integration-test > If we have to have such a confusing schema, then can we please at least raise > a warning when the confusion inevitably occurs, given how easy it is to > detect (since AFAICT there'd be no reason to put an executions tag inside > pluginManagement/plugins/plugin)? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6246) Inconsistent override behaivor with BOM vs dependency
[ https://issues.apache.org/jira/browse/MNG-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6246. -- Resolution: Duplicate > Inconsistent override behaivor with BOM vs dependency > - > > Key: MNG-6246 > URL: https://issues.apache.org/jira/browse/MNG-6246 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.5.0 > Environment: osx jdk 1.8 >Reporter: Jay mann >Priority: Major > Attachments: mvn-bug.tar.gz > > > Consider we have 2 BOM files: > bom1 - dependency version 1 > bom2 - dependency version 2' > When a bom1 is imported into a parent and bom2 is imported into a child of > parernt, child correctly overrides the dependency and uses "verision 2". > When parent does not import bom1 but explicitly states "dependency 1" in the > section, and child imports bom2, "version 1" of > dependency is used (bom2 in child does not override the dependency) > This seems like inconsistent behavior as documentation explains that a BOM > basically imports the section of the bom into the > current pom. > If this is expected behavior it should be documented as we recently moved all > our dependencyManagement section into a BOM for organizational reasons and it > did not work as expected. > Attached is a sample, to test simply extract and run: > mvn install -f bom1/pom.xml > mvn install -f bom2/pom.xml > mvn dependency:tree -f project/child/pom.xml > mvn dependency:tree -f project2/child/pom.xml > project uses bom in parent and child and is overridden correctly. > project2 parent uses dependency instead of bom, child uses bom but dependency > is NOT overridden. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6161) Dependencies' management via import should take precedence over inherited definitions
[ https://issues.apache.org/jira/browse/MNG-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6161. -- Resolution: Duplicate > Dependencies' management via import should take precedence > over inherited definitions > > > Key: MNG-6161 > URL: https://issues.apache.org/jira/browse/MNG-6161 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00) > Maven home: /usr/local/Cellar/maven/3.3.9/libexec > Java version: 1.8.0_60, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.2", arch: "x86_64", family: "mac" >Reporter: Daniel McGreal >Priority: Major > > Hi, I would like to suggest an improvement to the way in which > import dependencies are handled. > Currently, if I have four projects: > * 'version' which sets a dependency on X with a version of Y, and is a parent > pom > * 'depender' which inherits from 'version' and declares a dependency on X > * 'provider' which manages X to scope provided > * 'last' which depends on 'depender' and imports 'provider's managed > dependencies > then the 'provider' definition is ignored and 'version's is chosen. > The use case I'm trying to achieve is where some dependencies are excluded > from a plugin's activities, and using provided is the best way > for me to achieve this. Using import to override > hierarchically defined dependency management would be a nice way of > organising this in a way that supports the multi-tired architecture my real > use case would require. > In short, it feels to me that a definition with > import should be 'closer' to the current bundle's dependency > resolution than its parents. > Thanks for your consideration, > Dan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SUREFIRE-1468) JUnit categories: 'groups' user parameter conflicts with javadoc plugin
Steve Arch created SUREFIRE-1468:
Summary: JUnit categories: 'groups' user parameter conflicts with
javadoc plugin
Key: SUREFIRE-1468
URL: https://issues.apache.org/jira/browse/SUREFIRE-1468
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Reporter: Steve Arch
The user parameter for setting JUnit test groups (-Dgroups=com.foo.Bar)
conflicts with the
[groups|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#groups]
parameter in the javadoc plugin as they both use the same 'groups' parameter
name.
This means that the javadoc plugin will try to interpret the same argument that
was intended for the surefire plugin, resulting in the following error:
{code:java}
Unable to parse configuration of mojo
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:javadoc for parameter #:
Cannot find default setter in class
org.apache.maven.plugin.javadoc.options.Group{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1468) JUnit categories: 'groups' user parameter conflicts with javadoc plugin
[
https://issues.apache.org/jira/browse/SUREFIRE-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Arch updated SUREFIRE-1468:
-
Description:
The user parameter for setting [JUnit test
groups|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#groups]
(-Dgroups=com.foo.Bar) conflicts with the
[groups|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#groups]
parameter in the javadoc plugin as they both use the same 'groups' parameter
name.
This means that the javadoc plugin will try to interpret the same argument that
was intended for the surefire plugin, resulting in the following error:
{code:java}
Unable to parse configuration of mojo
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:javadoc for parameter #:
Cannot find default setter in class
org.apache.maven.plugin.javadoc.options.Group{code}
was:
The user parameter for setting JUnit test groups (-Dgroups=com.foo.Bar)
conflicts with the
[groups|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#groups]
parameter in the javadoc plugin as they both use the same 'groups' parameter
name.
This means that the javadoc plugin will try to interpret the same argument that
was intended for the surefire plugin, resulting in the following error:
{code:java}
Unable to parse configuration of mojo
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:javadoc for parameter #:
Cannot find default setter in class
org.apache.maven.plugin.javadoc.options.Group{code}
> JUnit categories: 'groups' user parameter conflicts with javadoc plugin
> ---
>
> Key: SUREFIRE-1468
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1468
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Reporter: Steve Arch
>Priority: Minor
>
> The user parameter for setting [JUnit test
> groups|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#groups]
> (-Dgroups=com.foo.Bar) conflicts with the
> [groups|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#groups]
> parameter in the javadoc plugin as they both use the same 'groups' parameter
> name.
> This means that the javadoc plugin will try to interpret the same argument
> that was intended for the surefire plugin, resulting in the following error:
>
> {code:java}
> Unable to parse configuration of mojo
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:javadoc for parameter #:
> Cannot find default setter in class
> org.apache.maven.plugin.javadoc.options.Group{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1468) JUnit categories: 'groups' user parameter conflicts with javadoc plugin
[
https://issues.apache.org/jira/browse/SUREFIRE-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Arch updated SUREFIRE-1468:
-
Description:
The user parameter for setting [JUnit test
groups|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#groups]
(-Dgroups=com.foo.Bar) conflicts with the
[groups|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#groups]
parameter in the javadoc plugin as they both use the same 'groups' parameter
name.
This means that if you run a build that uses both the surefire and the javadoc
plugin, the javadoc plugin will try to interpret the same argument that was
intended for the surefire plugin, resulting in the following error:
{code:java}
Unable to parse configuration of mojo
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:javadoc for parameter #:
Cannot find default setter in class
org.apache.maven.plugin.javadoc.options.Group{code}
was:
The user parameter for setting [JUnit test
groups|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#groups]
(-Dgroups=com.foo.Bar) conflicts with the
[groups|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#groups]
parameter in the javadoc plugin as they both use the same 'groups' parameter
name.
This means that the javadoc plugin will try to interpret the same argument that
was intended for the surefire plugin, resulting in the following error:
{code:java}
Unable to parse configuration of mojo
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:javadoc for parameter #:
Cannot find default setter in class
org.apache.maven.plugin.javadoc.options.Group{code}
> JUnit categories: 'groups' user parameter conflicts with javadoc plugin
> ---
>
> Key: SUREFIRE-1468
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1468
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Reporter: Steve Arch
>Priority: Minor
>
> The user parameter for setting [JUnit test
> groups|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#groups]
> (-Dgroups=com.foo.Bar) conflicts with the
> [groups|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#groups]
> parameter in the javadoc plugin as they both use the same 'groups' parameter
> name.
> This means that if you run a build that uses both the surefire and the
> javadoc plugin, the javadoc plugin will try to interpret the same argument
> that was intended for the surefire plugin, resulting in the following error:
>
> {code:java}
> Unable to parse configuration of mojo
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:javadoc for parameter #:
> Cannot find default setter in class
> org.apache.maven.plugin.javadoc.options.Group{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6350) Maven 3.5.2 Command Line mvn.cmd fails on path names containing round bracket "()" chars
Markus Hoffrogge created MNG-6350:
-
Summary: Maven 3.5.2 Command Line mvn.cmd fails on path names
containing round bracket "()" chars
Key: MNG-6350
URL: https://issues.apache.org/jira/browse/MNG-6350
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 3.5.2
Environment: Windows OS
Reporter: Markus Hoffrogge
Attachments: mvn.cmd_roundBrackets_1.png, mvn.cmd_roundBrackets_2.png
If the absolute path name of the -f command line parameter contains round
bracket characters "(" or ")", then the command line mvn.cmd fails with "...
was unexpected at this time".
The issue can be easily fixed in mvn.cmd, 3.5.2 for he appropriate echo
statements:
line 120: enclose %FILE_ARGS% by "" -> "%FILE_ARGS%"
line 129: same for %POM_DIR% and %FILE_ARGS%
The screenshots attached have been created with env var MAVEN_BATCH_ECHO=on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6350) Maven 3.5.2 Command Line mvn.cmd fails on path names containing round bracket "()" chars
[
https://issues.apache.org/jira/browse/MNG-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16343570#comment-16343570
]
Markus Hoffrogge commented on MNG-6350:
---
After creation I saw that this is a duplicate of MNG-6256 - which is fixed
already.
> Maven 3.5.2 Command Line mvn.cmd fails on path names containing round bracket
> "()" chars
>
>
> Key: MNG-6350
> URL: https://issues.apache.org/jira/browse/MNG-6350
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.2
> Environment: Windows OS
>Reporter: Markus Hoffrogge
>Priority: Major
> Labels: windows
> Attachments: mvn.cmd_roundBrackets_1.png, mvn.cmd_roundBrackets_2.png
>
>
> If the absolute path name of the -f command line parameter contains round
> bracket characters "(" or ")", then the command line mvn.cmd fails with "...
> was unexpected at this time".
> The issue can be easily fixed in mvn.cmd, 3.5.2 for he appropriate echo
> statements:
> line 120: enclose %FILE_ARGS% by "" -> "%FILE_ARGS%"
> line 129: same for %POM_DIR% and %FILE_ARGS%
> The screenshots attached have been created with env var MAVEN_BATCH_ECHO=on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPMD-128) Xref link generation regression with Maven 3
[
https://issues.apache.org/jira/browse/MPMD-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel updated MPMD-128:
Fix Version/s: (was: 3.9.0)
> Xref link generation regression with Maven 3
>
>
> Key: MPMD-128
> URL: https://issues.apache.org/jira/browse/MPMD-128
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: CPD, PMD
>Affects Versions: 2.5
> Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100)
> Java version: 1.6.0_20
> Java home: /usr/lib/jvm/java-6-openjdk/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux" version: "2.6.32-27-generic" arch: "i386" Family: "unix"
>Reporter: Marc Rohlfs
>Assignee: Andreas Dangel
>Priority: Minor
> Attachments: MPMD-128-IT.patch, MPMD-128_sample.zip
>
>
> When the site reports are created with Maven 3, the PMD plugin doesn't
> generate the links to the Source Xref pages, when the JXR Plugin hasn't been
> executed before.
> The plugin looks for the {{xrefLocation}} directory and if it doesn't exist,
> it checks if the JXR plugin is configured for the project (see
> http://maven.apache.org/plugins/maven-pmd-plugin/xref/org/apache/maven/plugin/pmd/AbstractPmdReport.html#240).
> To properly generate the Xref links when the report is created with Maven 3,
> the plugin should also check the {{reportPlugins}} paramerter of the Site
> plugin configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPMD-243) excludeFromFailureFile configuration does not work
[
https://issues.apache.org/jira/browse/MPMD-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel updated MPMD-243:
Fix Version/s: (was: 3.9.0)
> excludeFromFailureFile configuration does not work
> --
>
> Key: MPMD-243
> URL: https://issues.apache.org/jira/browse/MPMD-243
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.2, 3.5, 3.7, 3.8
>Reporter: Benedikt Ritter
>Assignee: Andreas Dangel
>Priority: Major
>
> The excludeFromFailureFile configruation is ignored since version 3.1 of
> Maven PMD plugin. Here is my plugin configuration:
> {code}
>
> maven-pmd-plugin
>
> 3.8
>
> true
>
>
>
>
> check
>
>
>
> ${basedir}/config/pmd/pmd-exclude.properties
>
>
>
>
> {code}
> The pmd-exclude.properties file has the following content:
> {code}
> com.example.ClassWithLotsOfStaticImports=TooManyStaticImports
> {code}
> When I execude mvn clean pmd:check, I get a violation for
> ClassWithLotsOfStaticImports. It works with 3.0 and 3.1. I've testet several
> version above 3.1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1469) EnvironmentVariables not respected when forkCount=0
Richard Lindner created SUREFIRE-1469: - Summary: EnvironmentVariables not respected when forkCount=0 Key: SUREFIRE-1469 URL: https://issues.apache.org/jira/browse/SUREFIRE-1469 Project: Maven Surefire Issue Type: Bug Reporter: Richard Lindner I have to switch a number of tests over from a parallel environment to a non-parallel one. In the process, I observed that when I run my tests with "-DforkCount=0", I don't have the environment variables that are configured through surefire. I suspect this is a bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6350) Maven 3.5.2 Command Line mvn.cmd fails on path names containing round bracket "()" chars
[
https://issues.apache.org/jira/browse/MNG-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6350.
---
Resolution: Duplicate
Assignee: Robert Scholte
> Maven 3.5.2 Command Line mvn.cmd fails on path names containing round bracket
> "()" chars
>
>
> Key: MNG-6350
> URL: https://issues.apache.org/jira/browse/MNG-6350
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.2
> Environment: Windows OS
>Reporter: Markus Hoffrogge
>Assignee: Robert Scholte
>Priority: Major
> Labels: windows
> Attachments: mvn.cmd_roundBrackets_1.png, mvn.cmd_roundBrackets_2.png
>
>
> If the absolute path name of the -f command line parameter contains round
> bracket characters "(" or ")", then the command line mvn.cmd fails with "...
> was unexpected at this time".
> The issue can be easily fixed in mvn.cmd, 3.5.2 for he appropriate echo
> statements:
> line 120: enclose %FILE_ARGS% by "" -> "%FILE_ARGS%"
> line 129: same for %POM_DIR% and %FILE_ARGS%
> The screenshots attached have been created with env var MAVEN_BATCH_ECHO=on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MASSEMBLY-875) Maven 3.x is about 10x slower than 2.6
Stu created MASSEMBLY-875:
-
Summary: Maven 3.x is about 10x slower than 2.6
Key: MASSEMBLY-875
URL: https://issues.apache.org/jira/browse/MASSEMBLY-875
Project: Maven Assembly Plugin
Issue Type: Bug
Reporter: Stu
In all our java projects, we have a fairly basic assembly configuration,
something like this:
{code:java}
maven-assembly-plugin
2.6
org.x.x.x
jar-with-dependencies
make-assembly
package
single
{code}
They all take about 10x longer with any 3.x.x version of the maven assembly
plugin than the 2.6 version.
This has been noticed by others:
[https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
But not reported as a bug that I could find.
Although I could only justify "Minor" for the priority, this is really is a
blocker for us moving to 3.x.x
The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-875) Maven 3.x is about 10x slower than 2.6
[
https://issues.apache.org/jira/browse/MASSEMBLY-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu updated MASSEMBLY-875:
--
Description:
In all our java projects, we have a fairly basic assembly configuration,
something like this:
{code:java}
maven-assembly-plugin
2.6
org.x.x.x
jar-with-dependencies
make-assembly
package
single
{code}
They all take about 10x longer with any 3.x.x version of the maven assembly
plugin than the 2.6 version.
This has been noticed by others:
[https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
But not reported as a bug that I could find.
Although I could only justify "Minor" for the priority, this is really is a
blocker for us moving to 3.x.x
The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
(For this particular build, it went from about ~ 7 sec to ~ 57 sec.
was:
In all our java projects, we have a fairly basic assembly configuration,
something like this:
{code:java}
maven-assembly-plugin
2.6
org.x.x.x
jar-with-dependencies
make-assembly
package
single
{code}
They all take about 10x longer with any 3.x.x version of the maven assembly
plugin than the 2.6 version.
This has been noticed by others:
[https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
But not reported as a bug that I could find.
Although I could only justify "Minor" for the priority, this is really is a
blocker for us moving to 3.x.x
The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
> Maven 3.x is about 10x slower than 2.6
> --
>
> Key: MASSEMBLY-875
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-875
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Reporter: Stu
>Priority: Minor
>
> In all our java projects, we have a fairly basic assembly configuration,
> something like this:
> {code:java}
>
> maven-assembly-plugin
> 2.6
>
>
>
> org.x.x.x
>
>
>
> jar-with-dependencies
>
>
>
>
> make-assembly
> package
>
> single
>
>
>
> {code}
> They all take about 10x longer with any 3.x.x version of the maven assembly
> plugin than the 2.6 version.
> This has been noticed by others:
> [https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
> But not reported as a bug that I could find.
> Although I could only justify "Minor" for the priority, this is really is a
> blocker for us moving to 3.x.x
> The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
> (For this particular build, it went from about ~ 7 sec to ~ 57 sec.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-875) Maven 3.x is about 10x slower than 2.6
[
https://issues.apache.org/jira/browse/MASSEMBLY-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu updated MASSEMBLY-875:
--
Description:
In all our java projects, we have a fairly basic assembly configuration,
something like this:
{code:java}
maven-assembly-plugin
2.6
org.x.x.x
jar-with-dependencies
make-assembly
package
single
{code}
They all take about 10x longer with any 3.x.x version of the maven assembly
plugin than the 2.6 version.
This has been noticed by others:
[https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
But not reported as a bug that I could find.
Although I could only justify "Minor" for the priority, this is really is a
blocker for us moving to 3.x.x
The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
(For this particular build, it went from about ~ 7 sec to ~ 57 sec.)
was:
In all our java projects, we have a fairly basic assembly configuration,
something like this:
{code:java}
maven-assembly-plugin
2.6
org.x.x.x
jar-with-dependencies
make-assembly
package
single
{code}
They all take about 10x longer with any 3.x.x version of the maven assembly
plugin than the 2.6 version.
This has been noticed by others:
[https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
But not reported as a bug that I could find.
Although I could only justify "Minor" for the priority, this is really is a
blocker for us moving to 3.x.x
The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
(For this particular build, it went from about ~ 7 sec to ~ 57 sec.
> Maven 3.x is about 10x slower than 2.6
> --
>
> Key: MASSEMBLY-875
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-875
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Reporter: Stu
>Priority: Minor
>
> In all our java projects, we have a fairly basic assembly configuration,
> something like this:
> {code:java}
>
> maven-assembly-plugin
> 2.6
>
>
>
> org.x.x.x
>
>
>
> jar-with-dependencies
>
>
>
>
> make-assembly
> package
>
> single
>
>
>
> {code}
> They all take about 10x longer with any 3.x.x version of the maven assembly
> plugin than the 2.6 version.
> This has been noticed by others:
> [https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
> But not reported as a bug that I could find.
> Although I could only justify "Minor" for the priority, this is really is a
> blocker for us moving to 3.x.x
> The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
> (For this particular build, it went from about ~ 7 sec to ~ 57 sec.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-875) Maven 3.x is about 10x slower than 2.6
[
https://issues.apache.org/jira/browse/MASSEMBLY-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16343977#comment-16343977
]
Karl Heinz Marbaise commented on MASSEMBLY-875:
---
I recommend to first check via
https://github.com/khmarbaise/maven-buildtime-profiler apart from that the link
you have mentioned is about 5 years old and is related to maven-assembly-plugin
2.2 furthermore which maven version are you using ? How are the memory
settings? How many modules are you building ? How long is the build time
overall ?
> Maven 3.x is about 10x slower than 2.6
> --
>
> Key: MASSEMBLY-875
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-875
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Reporter: Stu
>Priority: Minor
>
> In all our java projects, we have a fairly basic assembly configuration,
> something like this:
> {code:java}
>
> maven-assembly-plugin
> 2.6
>
>
>
> org.x.x.x
>
>
>
> jar-with-dependencies
>
>
>
>
> make-assembly
> package
>
> single
>
>
>
> {code}
> They all take about 10x longer with any 3.x.x version of the maven assembly
> plugin than the 2.6 version.
> This has been noticed by others:
> [https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
> But not reported as a bug that I could find.
> Although I could only justify "Minor" for the priority, this is really is a
> blocker for us moving to 3.x.x
> The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
> (For this particular build, it went from about ~ 7 sec to ~ 57 sec.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSHARED-679) Make all classes package private in internal package
Karl Heinz Marbaise created MSHARED-679:
---
Summary: Make all classes package private in internal package
Key: MSHARED-679
URL: https://issues.apache.org/jira/browse/MSHARED-679
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-artifact-transfer
Affects Versions: maven-artifact-transfer-0.9.1
Reporter: Karl Heinz Marbaise
Fix For: maven-artifact-transfer-1.0.0
Make all classes in package {{*.internal}} package only visible and not public.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] maven-indexer pull request #25: support zip files next to jar and war
GitHub user fuss86 opened a pull request: https://github.com/apache/maven-indexer/pull/25 support zip files next to jar and war You can merge this pull request into a Git repository by running: $ git pull https://github.com/carlspring/maven-indexer support_zip_file_contents_index_creator Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-indexer/pull/25.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #25 commit 8bd8ea0d58ac3a76601cb7b8f64318cc5ebfc93c Author: Przemyslaw Fusik Date: 2018-01-24T23:31:14Z support zip files next to jar and war ---
[GitHub] maven-indexer issue #25: support zip files next to jar and war
Github user fuss86 commented on the issue: https://github.com/apache/maven-indexer/pull/25 Hi guys, would you mind enabling support for `.zip` artifact packages, to be able to index Java class names from a ZIP Maven artifacts too ? ---
[GitHub] robseidel commented on issue #1: fix DeployAtEnd failures
robseidel commented on issue #1: fix DeployAtEnd failures URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-361500100 Great work. The Deploy Maven Plugin 2.8.2 deployAtEnd feature is not working with Maven 3 due to the different class realms (http://maven.apache.org/guides/mini/guide-maven-classloading.html) - so the static instance variables are useless. Hopefully this gets merged and released soon (since 2.8.2 was released before more than 3 years). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
