[jira] [Commented] (MCOMPILER-372) Unable to compile modularized test code depending on test-jar

[Jira]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997955#comment-16997955
 ] 

François Loison commented on MCOMPILER-372:
---

Fix found and tested OK with 'verify'. I'm trying to create a pull request.

> Unable to compile modularized test code depending on test-jar
> -
>
> Key: MCOMPILER-372
> URL: https://issues.apache.org/jira/browse/MCOMPILER-372
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0
> Environment: Manjaro Linux 64 bit, Open JDK 11, Apache-Maven-3.6.0
>Reporter: Jeronimo Backes
>Priority: Blocker
> Attachments: maven-compiler-plugin.MCOMPILER-372.patch, 
> univocity-all.zip
>
>
> I'm refactoring 
> [univocity-parsers|https://github.com/uniVocity/univocity-parsers] into 
> multiple projects with modules (attached a zip with everything I got)
> However I'm unable to reliably build the attached project with its unit 
> tests. Unpack then cd into "univocity-all-parent", then run "mvn clean 
> install".
>  
> All projects generate test-jars, but for some reason class 
> *com.univocity.parsers.core.routine.ResultSetWritingRoutine* inside 
> "univocity-parsers-core/src/test/java/" is not found when compiling the tests 
> of projects "univocity-csv", "univocity-tsv" and "univocity-fixedwidth".
>  
> Interestingly, the issue doesn't seem to be consistent as I got 
> "univocity-csv" and "univocity-tsv" building without errors a few times. 
> "univocity-fixedwidth" however failed consistently every single time.
> Some of the errors I get are:
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:testCompile 
> (default-testCompile) on project univocity-csv: Compilation failure: 
> Compilation failure: }}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[27,49]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: package com.univocity.parsers.core.routine}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,52]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetTest}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,45]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetTest}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,52]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[124,68]
>  package ResultSetWritingRoutine does not exist}}
>  
> I was also getting errors saying that the "Example" class was not found, or 
> that the "printAndValidate" method was not found (that one comes from the 
> univocity-output-tester dependency)..
>  
> There's something very weird going on and it's not consistently reproducible. 
> If you for example change the code in the failing tests use "*import static 
> com.univocity.parsers.core.routine.ResultSetWritingRoutine.** " you may get a 
> different set of errors. It's pretty intractable.
> I hope this provides enough information, let me know if you need anything 
> else.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MJAVADOC-626) Detect stale files and skip generation if not needed

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997919#comment-16997919
 ] 

Hudson commented on MJAVADOC-626:
-

Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » master #68

See 
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/68/

> Detect stale files and skip generation if not needed
> 
>
> Key: MJAVADOC-626
> URL: https://issues.apache.org/jira/browse/MJAVADOC-626
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 3.1.1
>Reporter: Guillaume Nodet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In Apache Camel, we do use javadoc during the build as we have a few things 
> that are generated from the javadoc.  However, javadoc can take quite some 
> time to build, so I came up with a stale file/config detection mechanism in 
> order to avoid recomputing the javadoc if there is no change.
>  
> The idea is to compute an _input_ _state_ consisting of all the command line 
> options (flattening the {{@xxx}} options) and the list of all input files 
> along with their last modification date.  Before actually executing the 
> command line, we compare the current state with the last saved state and skip 
> the execution if there is no change.
> The code is visible in this commit mainly: 
> [https://github.com/apache/camel/pull/3233/commits/57903a94f82413022afc594e374fb3dff4f7578a]
>  and if there is an agreement, I can create a correct PR to incorporate the 
> change.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MJAVADOC-626) Detect stale files and skip generation if not needed

[Olivier Lamy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MJAVADOC-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MJAVADOC-626.
-
Resolution: Fixed

> Detect stale files and skip generation if not needed
> 
>
> Key: MJAVADOC-626
> URL: https://issues.apache.org/jira/browse/MJAVADOC-626
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 3.1.1
>Reporter: Guillaume Nodet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In Apache Camel, we do use javadoc during the build as we have a few things 
> that are generated from the javadoc.  However, javadoc can take quite some 
> time to build, so I came up with a stale file/config detection mechanism in 
> order to avoid recomputing the javadoc if there is no change.
>  
> The idea is to compute an _input_ _state_ consisting of all the command line 
> options (flattening the {{@xxx}} options) and the list of all input files 
> along with their last modification date.  Before actually executing the 
> command line, we compare the current state with the last saved state and skip 
> the execution if there is no change.
> The code is visible in this commit mainly: 
> [https://github.com/apache/camel/pull/3233/commits/57903a94f82413022afc594e374fb3dff4f7578a]
>  and if there is an agreement, I can create a correct PR to incorporate the 
> change.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MJAVADOC-626) Detect stale files and skip generation if not needed

[Olivier Lamy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MJAVADOC-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy updated MJAVADOC-626:
--
Fix Version/s: 3.2.0

> Detect stale files and skip generation if not needed
> 
>
> Key: MJAVADOC-626
> URL: https://issues.apache.org/jira/browse/MJAVADOC-626
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 3.1.1
>Reporter: Guillaume Nodet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In Apache Camel, we do use javadoc during the build as we have a few things 
> that are generated from the javadoc.  However, javadoc can take quite some 
> time to build, so I came up with a stale file/config detection mechanism in 
> order to avoid recomputing the javadoc if there is no change.
>  
> The idea is to compute an _input_ _state_ consisting of all the command line 
> options (flattening the {{@xxx}} options) and the list of all input files 
> along with their last modification date.  Before actually executing the 
> command line, we compare the current state with the last saved state and skip 
> the execution if there is no change.
> The code is visible in this commit mainly: 
> [https://github.com/apache/camel/pull/3233/commits/57903a94f82413022afc594e374fb3dff4f7578a]
>  and if there is an agreement, I can create a correct PR to incorporate the 
> change.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (MJAVADOC-626) Detect stale files and skip generation if not needed

[Olivier Lamy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MJAVADOC-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy reassigned MJAVADOC-626:
-

Assignee: Olivier Lamy

> Detect stale files and skip generation if not needed
> 
>
> Key: MJAVADOC-626
> URL: https://issues.apache.org/jira/browse/MJAVADOC-626
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 3.1.1
>Reporter: Guillaume Nodet
>Assignee: Olivier Lamy
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In Apache Camel, we do use javadoc during the build as we have a few things 
> that are generated from the javadoc.  However, javadoc can take quite some 
> time to build, so I came up with a stale file/config detection mechanism in 
> order to avoid recomputing the javadoc if there is no change.
>  
> The idea is to compute an _input_ _state_ consisting of all the command line 
> options (flattening the {{@xxx}} options) and the list of all input files 
> along with their last modification date.  Before actually executing the 
> command line, we compare the current state with the last saved state and skip 
> the execution if there is no change.
> The code is visible in this commit mainly: 
> [https://github.com/apache/camel/pull/3233/commits/57903a94f82413022afc594e374fb3dff4f7578a]
>  and if there is an agreement, I can create a correct PR to incorporate the 
> change.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-javadoc-plugin] olamy merged pull request #33: [MJAVADOC-626] Add a stale javadoc detection mechanism

[GitBox]

olamy merged pull request #33: [MJAVADOC-626] Add a stale javadoc detection 
mechanism
URL: https://github.com/apache/maven-javadoc-plugin/pull/33
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[jira] [Commented] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997680#comment-16997680
 ] 

Elliotte Rusty Harold commented on MNG-5980:


OK, not a bash wildcard and in that case the orde rof jar files is not 
specified. (Not ideal, but not going to change that here.)

however in the case of an explicit -cp such as -cp A.jar:B.jar I still think 
A.jar comes before B.jar. In this case the order of the jar files is specified. 

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MASSEMBLY-925) Detailed error message on assembly failure

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997637#comment-16997637
 ] 

Michael Osipov commented on MASSEMBLY-925:
--

Did  {{mvn -X}} not help?

> Detailed error message on assembly failure
> --
>
> Key: MASSEMBLY-925
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-925
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.0
>Reporter: Christian Domsch
>Priority: Major
>
> If the assembly fails during processing of its dependencySets/fileSets, it 
> would be very convenient to get the current set/item it is trying to work on 
> while it fails.
> I just lost about a couple days worth of tracking down, why my assembly 
> failed with the message: "Failed to create assembly: Error creating assembly 
> archive base: archive is not a ZIP archive -> [Help 1]"
> Long story short, in our package feed (we are building our software in Azure) 
> one dependency that we used had a corrupt ZIP archive. Since this assembly is 
> the final one we use to build our installers, it contains 50 dependencySets 
> and some files and filesets. Which means, tracking down which of those was 
> causing the issue while one build roughly takes 40mins, is very time 
> consuming.
> In order to improve this, it would be very helpful, if in the event of an 
> error, the plugin would tell you which module/dependency/file it actually 
> failed on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5932) Per-user and per-project logging configuration

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997632#comment-16997632
 ] 

Michael Osipov commented on MNG-5932:
-

The very first obstacle is that  every logging framework has a different 
approach to logging configuration. How shall we provide a unified configuration 
for disjoint backends?


> Per-user and per-project logging configuration
> --
>
> Key: MNG-5932
> URL: https://issues.apache.org/jira/browse/MNG-5932
> Project: Maven
>  Issue Type: Improvement
>  Components: Logging
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Brian Oxley
>Priority: Major
>
> It would be of much use to support per-user and per-project logging 
> configuration.  This supports cases where different projects have different 
> maven logging requirements (e.g., post-processing maven output as part of a 
> pipeline).  Currently I need to change the maven installation to, for 
> example, swap out logback for simplelogger, or to change the simplelogger 
> settings.
> As a workaround on simplelogger I can use .mvn/jvm.config to pass system 
> properties for simplelogger, but this is non-obvious and does not help with 
> changing SLF4J implementation.
> I would like to be able to use something like .mvn/logging/ akin 
> to conf/logging under $M2_HOME and/or lib/ext.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MNG-6080) New scope for non-functional dependencies

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997626#comment-16997626
 ] 

Michael Osipov edited comment on MNG-6080 at 12/16/19 8:44 PM:
---

Would it be sufficient to add type {{asset}} with extension {{zip}} to [this 
file|https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml]?


was (Author: michael-o):
Would it be sufficient to add type {{asset}} with extension {{zip}} to this 
file: 
https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml?

> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
>  Issue Type: New Feature
>  Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the 
> classpath. The classpath is the path that the Java Runtime Environment (JRE) 
> searches for classes and other resource files. Given that the classpath is 
> Java specific, this feature request can be generalized to accommodate 
> artifacts that are not code related (directly or indirectly). It is neither 
> code that executes (like a .class file = "directly") nor a resource file 
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that 
> contains common look-and-feel elements to brand all their web applications. 
> This project could be a ZIP archive to be included in downstream projects, in 
> which each build explodes the archive into their respective web application 
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}. 
> They are nearly equal but have a different slight emphasis. The {{"asset"}} 
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes 
> purpose within the build. The Maven Team should decide among these two or 
> propose a third. 
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6080) New scope for non-functional dependencies

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997626#comment-16997626
 ] 

Michael Osipov commented on MNG-6080:
-

Would it be sufficient to add type {{asset}} with extension {{zip}} to this 
file: 
https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml?

> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
>  Issue Type: New Feature
>  Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the 
> classpath. The classpath is the path that the Java Runtime Environment (JRE) 
> searches for classes and other resource files. Given that the classpath is 
> Java specific, this feature request can be generalized to accommodate 
> artifacts that are not code related (directly or indirectly). It is neither 
> code that executes (like a .class file = "directly") nor a resource file 
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that 
> contains common look-and-feel elements to brand all their web applications. 
> This project could be a ZIP archive to be included in downstream projects, in 
> which each build explodes the archive into their respective web application 
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}. 
> They are nearly equal but have a different slight emphasis. The {{"asset"}} 
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes 
> purpose within the build. The Maven Team should decide among these two or 
> propose a third. 
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997622#comment-16997622
 ] 

Michael Osipov commented on MNG-5980:
-

No, that's wrong.

 
{quote}For example, if directory mydir contains a.jar and b.JAR, then the class 
path element {{mydir/*}} is expanded to a A.jar:b.JAR, except that the order of 
jar files is unspecified. All jar files in the specified directory, even hidden 
ones, are included in the list. A class path entry consisting simply of {{*}} 
expands to a list of all the jar files in the current directory.
{quote}
From: 
[https://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html#CBBIJCHG]

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MPLUGIN-316) improve mojo description for user properties

[Herve Boutemy (Jira)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997504#comment-16997504
 ] 

Herve Boutemy commented on MPLUGIN-316:
---

for example 
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html

> improve mojo description for user properties
> 
>
> Key: MPLUGIN-316
> URL: https://issues.apache.org/jira/browse/MPLUGIN-316
> Project: Maven Plugin Tools
>  Issue Type: Improvement
>  Components: Plugin Plugin
>Affects Versions: 3.5
>Reporter: Herve Boutemy
>Priority: Major
>
> currently, we generate in the parameter description a little text:
> bq. User property is: parameter-name.
> perhaps this info should be put in the name more than the description.
> And we should make it clear that this can be used either in pom properties, 
> either on CLI {{-Dparameter-name=}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARCHETYPE-495) rename ArchetypeGenerator.generateArchetype() to ProjectGenerator.generateProject()

[Herve Boutemy (Jira)]

[ 
https://issues.apache.org/jira/browse/ARCHETYPE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997503#comment-16997503
 ] 

Herve Boutemy commented on ARCHETYPE-495:
-

for such internal API, no strong strategy: the only question is to know if this 
could cause an issue for an IDE plugin, for example
and even for that, I suppose we could add a deprecated class extending the new 
one to mimic the old API

> rename ArchetypeGenerator.generateArchetype() to 
> ProjectGenerator.generateProject()
> ---
>
> Key: ARCHETYPE-495
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-495
> Project: Maven Archetype
>  Issue Type: Improvement
>  Components: Generator
>Affects Versions: 2.4
>Reporter: Herve Boutemy
>Assignee: Petar Tahchiev
>Priority: Major
> Fix For: backlog
>
>
> {{ArchetypeGenerator.generateArchetype()}} is really misleading: it's not 
> about generating an archetype, but about generating *a project from* an 
> archetype
> this API cause strong confusion in the archetype lifecycle: sample project -> 
> archetype project -> archetype artifact -> generated project



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHARED-491) DependencyGraphBuilders should use reactorProjects first when resolving dependencies

[Robert Scholte (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997498#comment-16997498
 ] 

Robert Scholte commented on MSHARED-491:


Yes, still true. But there's a chance this will move the 
maven-artifact-transfer.

> DependencyGraphBuilders should use reactorProjects first when resolving 
> dependencies
> 
>
> Key: MSHARED-491
> URL: https://issues.apache.org/jira/browse/MSHARED-491
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-dependency-tree
>Affects Versions: maven-dependency-tree-3.0
>Reporter: Robert Scholte
>Priority: Major
>
> Based on the code it seems that reactor projects are only used in case there 
> are unresolved dependencies, like a fallback.
> Reactor projects should always have a higher priority compared to repository 
> stored artifacts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[elharo (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997477#comment-16997477
 ] 

elharo edited comment on MNG-5980 at 12/16/19 5:34 PM:
---

Consider the case where class com.example.Foo is found in A.jar and B.jar, both 
in the classpath, which can happen in Java 8 and earlier. Is it arbitrary which 
version of the class is loaded?

I don't think{{ java -cp '*.jar' }}will even run since it doesn't separate the 
entries with colons. 

The issue with Tomcat is, I suspect, that Tomcat doesn't guarantee the order in 
which it places jars in the WEB-INF directory into the classpath, not that the 
class loading is indeterminate once the classpath is formed. 


was (Author: elh...@metalab.unc.edu):
Consider the case where class com.example.Foo is found in A.jar and B.jar, both 
in the classpath, which can happen in Java 8 and earlier. Is it arbitrary which 
version of the class is loaded?

I don't think{{ java -cp '*.jar' }}will even run since it doesn't separate the 
entries with colons. 

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[elharo (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997477#comment-16997477
 ] 

elharo edited comment on MNG-5980 at 12/16/19 5:31 PM:
---

Consider the case where class com.example.Foo is found in A.jar and B.jar, both 
in the classpath, which can happen in Java 8 and earlier. Is it arbitrary which 
version of the class is loaded?

I don't think{{ java -cp '*.jar' }}will even run since it doesn't separate the 
entries with colons. 


was (Author: elh...@metalab.unc.edu):
Consider the case where class com.example.Foo is found in A.jar and B.jar, both 
in the claspath, which can happen in Java 8 and earlier. Is it arbitrary which 
version of the class is loaded?

I don't think `java -cp '*.jar'` will even run since it doesn't separate the 
entries with colons. 

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[elharo (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997477#comment-16997477
 ] 

elharo commented on MNG-5980:
-

Consider the case where class com.example.Foo is found in A.jar and B.jar, both 
in the claspath, which can happen in Java 8 and earlier. Is it arbitrary which 
version of the class is loaded?

I don't think `java -cp '*.jar'` will even run since it doesn't separate the 
entries with colons. 

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (MSHADE-284) Shaded test JARs are always empty

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reassigned MSHADE-284:


Assignee: Mark Struberg

> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Major
> Attachments: shadeTestJar.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. 
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I 
> have tested it manually on my project and it works.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-284) Shaded test JARs are always empty

[Mark Struberg (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997413#comment-16997413
 ] 

Mark Struberg commented on MSHADE-284:
--

I'll gonna look into it tonight or in the next 2 days.

> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Major
> Attachments: shadeTestJar.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. 
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I 
> have tested it manually on my project and it works.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997408#comment-16997408
 ] 

Michael Osipov commented on MNG-5980:
-

I think there are several issues here:

* Our documentation is not good, agreed.
* At current state our dependency resolution mechanism is order-dependent
* **But** classpaths are not order-dependent, Mark Thomas would competely 
disagree. Consider that {{java -cp '*.jar'}} would produce different results. 
There were several tickets against Tomcat where people relied of classpath 
order and Mark Thomas closed them for good reasons because the application is 
broken and relies on ordering.

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-3608) Reporting Encoding Configuration: ${project.reporting.outputEncoding}

[Herve Boutemy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MNG-3608:
---
Description: see [Reporting Encoding Configuration 
proposal|https://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration]
  (was: see [Reporting Encoding Configuration 
proposal|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration])

>  Reporting Encoding Configuration: ${project.reporting.outputEncoding}
> --
>
> Key: MNG-3608
> URL: https://issues.apache.org/jira/browse/MNG-3608
> Project: Maven
>  Issue Type: Sub-task
>  Components: POM, POM::Encoding
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> see [Reporting Encoding Configuration 
> proposal|https://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (MNG-3608) Reporting Encoding Configuration: ${project.reporting.outputEncoding}

[Herve Boutemy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy reopened MNG-3608:


ok, Wiki moved from Codehaus to ASF: here is the new location 
https://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration
I'll update the issue description

>  Reporting Encoding Configuration: ${project.reporting.outputEncoding}
> --
>
> Key: MNG-3608
> URL: https://issues.apache.org/jira/browse/MNG-3608
> Project: Maven
>  Issue Type: Sub-task
>  Components: POM, POM::Encoding
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> see [Reporting Encoding Configuration 
> proposal|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] jon-bell commented on issue #253: Fixes [SUREFIRE-1516]: Poor performance in reuseForks=false

[GitBox]

jon-bell commented on issue #253: Fixes [SUREFIRE-1516]: Poor performance in 
reuseForks=false
URL: https://github.com/apache/maven-surefire/pull/253#issuecomment-566096777
 
 
   @Tibor17 please note that all of the tests are now passing. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[jira] [Commented] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[elharo (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997292#comment-16997292
 ] 

elharo commented on MNG-5980:
-

If we don't document the order dependency, that would be a good bug against 
MVNSITE. However classpaths are by their nature ordered and the specific 
algorithm by which dependency trees are converted into classpaths is baked 
pretty firmly into Maven itself and most projects built with it. I don't think 
we could change it now.

 

Per 
[https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
 (which is confusing, and I need to rewrite)

 

I don't think we say there that if dependency A comes before dependency B in 
pom.xml then the classpath looks like A:B and not B:A

 

We probably should.

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997281#comment-16997281
 ] 

Michael Osipov commented on MNG-5980:
-

[~elharo], unless we don't document the order dependency we cannot say that 
this is not a bug.

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-4457) dependency:resolve decides to take older (incompatible) version for transitive dep

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold closed MNG-4457.
--

> dependency:resolve decides to take older (incompatible) version for 
> transitive dep
> --
>
> Key: MNG-4457
> URL: https://issues.apache.org/jira/browse/MNG-4457
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
>Reporter: paolo.compieta
>Assignee: Jason van Zyl
>Priority: Major
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: m2FairTransitiveDepResolve.zip, 
> m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net 
> to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and 
> resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to 
> commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or 
> declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because 
> in this example B is the only one using commons-net (maybe exploiting 
> 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or 
> ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, 
> different behaviours and runtime errors) with this kind silent 
> down-resolution of version.
> Regards,
> Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MNG-4457) dependency:resolve decides to take older (incompatible) version for transitive dep

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold resolved MNG-4457.

Resolution: Not A Bug

working as intended and documented (though not as well as it could be)

> dependency:resolve decides to take older (incompatible) version for 
> transitive dep
> --
>
> Key: MNG-4457
> URL: https://issues.apache.org/jira/browse/MNG-4457
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
>Reporter: paolo.compieta
>Assignee: Jason van Zyl
>Priority: Major
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: m2FairTransitiveDepResolve.zip, 
> m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net 
> to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and 
> resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to 
> commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or 
> declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because 
> in this example B is the only one using commons-net (maybe exploiting 
> 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or 
> ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, 
> different behaviours and runtime errors) with this kind silent 
> down-resolution of version.
> Regards,
> Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997263#comment-16997263
 ] 

Elliotte Rusty Harold commented on MNG-4142:


Poor description, but I've seen this myself. 

> Maven doesn't try to download a dependency when it already exists a version 
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud Heritier
>Priority: Critical
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier, 
> and not the principal artifact, it won't try in a reactor to download the 
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in 
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of 
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file 
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1 
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>   mvn deploy:deploy-file 
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1 
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency:
> 1) 
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2) 
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
>   org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
>   central (http://maven-proxy.groupe.generali.fr/all),
>   remote-repo 
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it 
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I 
> thought it was due to a problem with metadata sent by archiva, but after 
> migrating to nexus the problem always occurs. 
> I don't know if the problem is in metadata or in the reactor itself. I think 
> it is the second one. There are many issues opened about the reactor and 
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MASSEMBLY-925) Detailed error message on assembly failure

[Christian Domsch (Jira)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Domsch updated MASSEMBLY-925:
---
Description: 
If the assembly fails during processing of its dependencySets/fileSets, it 
would be very convenient to get the current set/item it is trying to work on 
while it fails.

I just lost about a couple days worth of tracking down, why my assembly failed 
with the message: "Failed to create assembly: Error creating assembly archive 
base: archive is not a ZIP archive -> [Help 1]"
Long story short, in our package feed (we are building our software in Azure) 
one dependency that we used had a corrupt ZIP archive. Since this assembly is 
the final one we use to build our installers, it contains 50 dependencySets and 
some files and filesets. Which means, tracking down which of those was causing 
the issue while one build roughly takes 40mins, is very time consuming.

In order to improve this, it would be very helpful, if in the event of an 
error, the plugin would tell you which module/dependency/file it actually 
failed on.

  was:
If the assembly fails during processing of its dependencySets/fileSets, it 
would be very convenient to get the current set/item it is trying to work on 
while it fails.

I just lost about a couple days worth of tracking down, why my assembly failed 
with the message: "Failed to create assembly: Error creating assembly archive 
base: archive is not a ZIP archive -> [Help 1]"
Long story short, in our package feed (we are building our software in Azure) 
one dependency that we used had a corrupt ZIP archive. Since this assembly is 
the final one we use to build our installers, it contains 50 dependencySets and 
some files and filesets. Which means, tracking down which of those was causing 
the issue while one build roughly takes 40mins is very time consuming.

In order to improve this, it would be very helpful, if in the event of an 
error, the plugin would tell you which module/dependency/file it actually 
failed on.


> Detailed error message on assembly failure
> --
>
> Key: MASSEMBLY-925
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-925
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.0
>Reporter: Christian Domsch
>Priority: Major
>
> If the assembly fails during processing of its dependencySets/fileSets, it 
> would be very convenient to get the current set/item it is trying to work on 
> while it fails.
> I just lost about a couple days worth of tracking down, why my assembly 
> failed with the message: "Failed to create assembly: Error creating assembly 
> archive base: archive is not a ZIP archive -> [Help 1]"
> Long story short, in our package feed (we are building our software in Azure) 
> one dependency that we used had a corrupt ZIP archive. Since this assembly is 
> the final one we use to build our installers, it contains 50 dependencySets 
> and some files and filesets. Which means, tracking down which of those was 
> causing the issue while one build roughly takes 40mins, is very time 
> consuming.
> In order to improve this, it would be very helpful, if in the event of an 
> error, the plugin would tell you which module/dependency/file it actually 
> failed on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MASSEMBLY-925) Detailed error message on assembly failure

[Christian Domsch (Jira)]

Christian Domsch created MASSEMBLY-925:
--

 Summary: Detailed error message on assembly failure
 Key: MASSEMBLY-925
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-925
 Project: Maven Assembly Plugin
  Issue Type: Improvement
Affects Versions: 3.2.0
Reporter: Christian Domsch


If the assembly fails during processing of its dependencySets/fileSets, it 
would be very convenient to get the current set/item it is trying to work on 
while it fails.

I just lost about a couple days worth of tracking down, why my assembly failed 
with the message: "Failed to create assembly: Error creating assembly archive 
base: archive is not a ZIP archive -> [Help 1]"
Long story short, in our package feed (we are building our software in Azure) 
one dependency that we used had a corrupt ZIP archive. Since this assembly is 
the final one we use to build our installers, it contains 50 dependencySets and 
some files and filesets. Which means, tracking down which of those was causing 
the issue while one build roughly takes 40mins is very time consuming.

In order to improve this, it would be very helpful, if in the event of an 
error, the plugin would tell you which module/dependency/file it actually 
failed on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARCHETYPE-495) rename ArchetypeGenerator.generateArchetype() to ProjectGenerator.generateProject()

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/ARCHETYPE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997232#comment-16997232
 ] 

Elliotte Rusty Harold commented on ARCHETYPE-495:
-

What are our rules about incompatible API changes? 

> rename ArchetypeGenerator.generateArchetype() to 
> ProjectGenerator.generateProject()
> ---
>
> Key: ARCHETYPE-495
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-495
> Project: Maven Archetype
>  Issue Type: Improvement
>  Components: Generator
>Affects Versions: 2.4
>Reporter: Herve Boutemy
>Assignee: Petar Tahchiev
>Priority: Major
> Fix For: backlog
>
>
> {{ArchetypeGenerator.generateArchetype()}} is really misleading: it's not 
> about generating an archetype, but about generating *a project from* an 
> archetype
> this API cause strong confusion in the archetype lifecycle: sample project -> 
> archetype project -> archetype artifact -> generated project



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNGSITE-271) CLONE - Better documentation related to repository order

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997233#comment-16997233
 ] 

Elliotte Rusty Harold commented on MNGSITE-271:
---

I concur

> CLONE - Better documentation related to repository order
> 
>
> Key: MNGSITE-271
> URL: https://issues.apache.org/jira/browse/MNGSITE-271
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Jakub Bochenski
>Priority: Major
>
> I was not able to find clear documentation describing the order of 
> repositories used during a build.  For example, the documentation should 
> answer the following questions.
> 1. Which repositories are used first, the ones defined in settings.xml or in 
> the pom.xml or super pom?
> 2. The order of repositories defined in the settings.xml profiles seems to be 
> the reverse of what one would expect when viewed in the effective-pom, why is 
> this?
> 3. If a repository ID in settings.xml matches one defined in pom.xml which 
> one takes priority?
> Some additional information is available in the JBoss build forum.
> http://community.jboss.org/thread/160185



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold closed MNG-5980.
--

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MNG-5980) DependencyGraphBuilder gives different results depending on the order of dependencies in the pom

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold resolved MNG-5980.

Resolution: Not A Bug

POMs are order dependent. This is working as intended. 

> DependencyGraphBuilder gives different results depending on the order of 
> dependencies in the pom
> 
>
> Key: MNG-5980
> URL: https://issues.apache.org/jira/browse/MNG-5980
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Plugin API
> Environment: Kubuntu 14.10
> Java 8
> Maven 3.0.5/3.3.9
> maven-dependency-tree 2.1/3.0
>Reporter: Gerrit Daniels
>Priority: Major
> Attachments: dependency-graph-builder-bug.zip
>
>
> I'm getting different results when using DependencyGraphBuilder in a plugin 
> depending on the order in which the dependencies are defined in the pom of 
> the project the plugin is running on. I have created some test projects to 
> reproduce the bug.
> - actual-dependency: This is the dependency that moves when changing the 
> order in the pom.
> - test-dependency: Depends on the actual-dependency with compile scope.
> - compile-dependency: Also depends on the actual-dependency with compile 
> scope.
> - main-project: Depends on the test-dependency with test scope and on the 
> compile-dependency with compile scope. Has the plugin configured.
> - plugin: Builds the dependency graph.
> When running maven with the -X switch on the main project with the 
> test-dependency declared first in the pom I get the following dependency 
> graph:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> {code}
> When I change the order of the dependencies I get:
> {code}
> [DEBUG] com.qmino:main-project:jar:1.0-SNAPSHOT
> [DEBUG]com.qmino:compile-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]   com.qmino:actual-dependency:jar:1.0-SNAPSHOT:compile
> [DEBUG]com.qmino:test-dependency:jar:1.0-SNAPSHOT:test
> {code}
> It seems to me that the order of the dependencies shouldn't change the 
> results. In both cases I would expect the second output, since the compile 
> scope should overrule the test scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHARED-491) DependencyGraphBuilders should use reactorProjects first when resolving dependencies

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997231#comment-16997231
 ] 

Elliotte Rusty Harold commented on MSHARED-491:
---

still true?

> DependencyGraphBuilders should use reactorProjects first when resolving 
> dependencies
> 
>
> Key: MSHARED-491
> URL: https://issues.apache.org/jira/browse/MSHARED-491
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-dependency-tree
>Affects Versions: maven-dependency-tree-3.0
>Reporter: Robert Scholte
>Priority: Major
>
> Based on the code it seems that reactor projects are only used in case there 
> are unresolved dependencies, like a fallback.
> Reactor projects should always have a higher priority compared to repository 
> stored artifacts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (SUREFIRE-1236) Surefire 2.19.1 hangs when building maven on Win 2012 server

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold resolved SUREFIRE-1236.
-
Resolution: Cannot Reproduce

> Surefire 2.19.1 hangs when building maven on Win 2012 server
> 
>
> Key: SUREFIRE-1236
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1236
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: TestNG support
>Affects Versions: 2.19.1
> Environment: Windows 2012 server- 64 bit
>Reporter: Vijay
>Assignee: Tibor Digana
>Priority: Major
> Attachments: Pom.zip, SUREFIRE-1236.zip
>
>
> Description : Surefire 2.19.1 hangs when building maven on Win 2012 server 
> machine using TFS build process. Please find the stack results below.
> Note : When I build it locally ( WIN 8.1, 64 bit), it works without any issue
> 2016-03-09 15:02:36
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode):
> "Thread-3" prio=6 tid=0x0a4d7000 nid=0x21e0 runnable 
> [0x0c5df000]
>java.lang.Thread.State: RUNNABLE
>   at java.io.FileInputStream.readBytes(Native Method)
>   at java.io.FileInputStream.read(FileInputStream.java:272)
>   at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
>   at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
>   at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
>   - locked <0xf394cc38> (a java.io.InputStreamReader)
>   at java.io.InputStreamReader.read(InputStreamReader.java:184)
>   at java.io.BufferedReader.fill(BufferedReader.java:154)
>   at java.io.BufferedReader.readLine(BufferedReader.java:317)
>   - locked <0xf394cc38> (a java.io.InputStreamReader)
>   at java.io.BufferedReader.readLine(BufferedReader.java:382)
>   at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)
>Locked ownable synchronizers:
>   - None
> "Thread-2" prio=6 tid=0x0a7b8800 nid=0xaa0 runnable 
> [0x0c4de000]
>java.lang.Thread.State: RUNNABLE
>   at java.io.FileInputStream.readBytes(Native Method)
>   at java.io.FileInputStream.read(FileInputStream.java:272)
>   at java.io.BufferedInputStream.read1(BufferedInputStream.java:273)
>   at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
>   - locked <0xf3973da0> (a java.io.BufferedInputStream)
>   at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
>   at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
>   at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
>   - locked <0xf3973d88> (a java.io.InputStreamReader)
>   at java.io.InputStreamReader.read(InputStreamReader.java:184)
>   at java.io.BufferedReader.fill(BufferedReader.java:154)
>   at java.io.BufferedReader.readLine(BufferedReader.java:317)
>   - locked <0xf3973d88> (a java.io.InputStreamReader)
>   at java.io.BufferedReader.readLine(BufferedReader.java:382)
>   at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)
>Locked ownable synchronizers:
>   - None
> "ThreadedStreamConsumer" daemon prio=6 tid=0x0a7b7800 nid=0x18d0 
> waiting on condition [0x0c2df000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf394f620> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:71)
>   at java.lang.Thread.run(Thread.java:744)
>Locked ownable synchronizers:
>   - None
> "ping-timer-10sec" daemon prio=6 tid=0x0a7b3000 nid=0x1aa0 waiting on 
> condition [0x0befe000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3981d20> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
>  

[jira] [Closed] (SUREFIRE-1236) Surefire 2.19.1 hangs when building maven on Win 2012 server

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold closed SUREFIRE-1236.
---

> Surefire 2.19.1 hangs when building maven on Win 2012 server
> 
>
> Key: SUREFIRE-1236
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1236
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: TestNG support
>Affects Versions: 2.19.1
> Environment: Windows 2012 server- 64 bit
>Reporter: Vijay
>Assignee: Tibor Digana
>Priority: Major
> Attachments: Pom.zip, SUREFIRE-1236.zip
>
>
> Description : Surefire 2.19.1 hangs when building maven on Win 2012 server 
> machine using TFS build process. Please find the stack results below.
> Note : When I build it locally ( WIN 8.1, 64 bit), it works without any issue
> 2016-03-09 15:02:36
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode):
> "Thread-3" prio=6 tid=0x0a4d7000 nid=0x21e0 runnable 
> [0x0c5df000]
>java.lang.Thread.State: RUNNABLE
>   at java.io.FileInputStream.readBytes(Native Method)
>   at java.io.FileInputStream.read(FileInputStream.java:272)
>   at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
>   at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
>   at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
>   - locked <0xf394cc38> (a java.io.InputStreamReader)
>   at java.io.InputStreamReader.read(InputStreamReader.java:184)
>   at java.io.BufferedReader.fill(BufferedReader.java:154)
>   at java.io.BufferedReader.readLine(BufferedReader.java:317)
>   - locked <0xf394cc38> (a java.io.InputStreamReader)
>   at java.io.BufferedReader.readLine(BufferedReader.java:382)
>   at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)
>Locked ownable synchronizers:
>   - None
> "Thread-2" prio=6 tid=0x0a7b8800 nid=0xaa0 runnable 
> [0x0c4de000]
>java.lang.Thread.State: RUNNABLE
>   at java.io.FileInputStream.readBytes(Native Method)
>   at java.io.FileInputStream.read(FileInputStream.java:272)
>   at java.io.BufferedInputStream.read1(BufferedInputStream.java:273)
>   at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
>   - locked <0xf3973da0> (a java.io.BufferedInputStream)
>   at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
>   at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
>   at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
>   - locked <0xf3973d88> (a java.io.InputStreamReader)
>   at java.io.InputStreamReader.read(InputStreamReader.java:184)
>   at java.io.BufferedReader.fill(BufferedReader.java:154)
>   at java.io.BufferedReader.readLine(BufferedReader.java:317)
>   - locked <0xf3973d88> (a java.io.InputStreamReader)
>   at java.io.BufferedReader.readLine(BufferedReader.java:382)
>   at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)
>Locked ownable synchronizers:
>   - None
> "ThreadedStreamConsumer" daemon prio=6 tid=0x0a7b7800 nid=0x18d0 
> waiting on condition [0x0c2df000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf394f620> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:71)
>   at java.lang.Thread.run(Thread.java:744)
>Locked ownable synchronizers:
>   - None
> "ping-timer-10sec" daemon prio=6 tid=0x0a7b3000 nid=0x1aa0 waiting on 
> condition [0x0befe000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3981d20> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
>   at 
> 

[jira] [Commented] (MPMD-221) Support all languages that PMD supports

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MPMD-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997226#comment-16997226
 ] 

Elliotte Rusty Harold commented on MPMD-221:


How much support do we offer for non-Java?

> Support all languages that PMD supports
> ---
>
> Key: MPMD-221
> URL: https://issues.apache.org/jira/browse/MPMD-221
> Project: Maven PMD Plugin
>  Issue Type: New Feature
>  Components: CPD, PMD
>Affects Versions: 3.6
>Reporter: Andreas Dangel
>Priority: Major
>
> PMD supports now many different languages besides Java, JavaScript, JSP.
> There are XML, XSL and also some rules for Maven POM files :)
> CPD supports even more languages, like C, C++, C#, PHP, Swift, ...
> Currently, maven-pmd-plugin only supports java, javascript, jsp: 
> http://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html#language
> and http://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#language
> In theory, PMD can determine the language type on its own by using the file 
> extensions. Ideally, the maven-pmd-plugin would not restrict the possible 
> languages.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6004) Emit better error message for simple XML typos

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997225#comment-16997225
 ] 

Elliotte Rusty Harold commented on MNG-6004:


Yes, this could be done. Ideally we won't use JAXB at all, (deprecated in java 
9+ and it was not a good idea in the first place) but short of ripping it out 
and replacing it with something better, we could add a preprocessing validation 
step with better error messages. 

> Emit better error message for simple XML typos
> --
>
> Key: MNG-6004
> URL: https://issues.apache.org/jira/browse/MNG-6004
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.3.9
> Environment: Maven 3.2.5
>Reporter: Archie Cobbs
>Priority: Minor
>
> When porting a project from ant to maven, I accidentally said this:
> {noformat}
> 
>   
> http://www.slf4j.org/api/"/>
>   
> 
> {noformat}
> instead of this:
> {noformat}
> 
>   
> http://www.slf4j.org/api/
>   
> 
> {noformat}
> Easy enough mistake to make. However, the error message was utterly 
> mystifying:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (attach-javadocs) on 
> project msrp4j: Execution attach-javadocs of goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar failed. 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar 
> (attach-javadocs) on project msrp4j: Execution attach-javadocs of goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar 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:355)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> attach-javadocs of goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar 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.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:921)
>   at 
> org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:785)
>   at 
> org.apache.maven.plugin.javadoc.options.io.xpp3.JavadocOptionsXpp3Writer.writeJavadocOptions(JavadocOptionsXpp3Writer.java:268)
>   at 
> org.apache.maven.plugin.javadoc.options.io.xpp3.JavadocOptionsXpp3Writer.write(JavadocOptionsXpp3Writer.java:70)
>   at 
> org.apache.maven.plugin.javadoc.AbstractJavadocMojo.buildJavadocOptions(AbstractJavadocMojo.java:5867)
>   at 
> org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1857)
>   at 
> org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:181)
>   at 
> 

[jira] [Updated] (MNG-6004) Emit better error message for simple XML typos

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold updated MNG-6004:
---
Priority: Major  (was: Minor)

> Emit better error message for simple XML typos
> --
>
> Key: MNG-6004
> URL: https://issues.apache.org/jira/browse/MNG-6004
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.3.9
> Environment: Maven 3.2.5
>Reporter: Archie Cobbs
>Priority: Major
>
> When porting a project from ant to maven, I accidentally said this:
> {noformat}
> 
>   
> http://www.slf4j.org/api/"/>
>   
> 
> {noformat}
> instead of this:
> {noformat}
> 
>   
> http://www.slf4j.org/api/
>   
> 
> {noformat}
> Easy enough mistake to make. However, the error message was utterly 
> mystifying:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (attach-javadocs) on 
> project msrp4j: Execution attach-javadocs of goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar failed. 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar 
> (attach-javadocs) on project msrp4j: Execution attach-javadocs of goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar 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:355)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> attach-javadocs of goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar 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.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:921)
>   at 
> org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:785)
>   at 
> org.apache.maven.plugin.javadoc.options.io.xpp3.JavadocOptionsXpp3Writer.writeJavadocOptions(JavadocOptionsXpp3Writer.java:268)
>   at 
> org.apache.maven.plugin.javadoc.options.io.xpp3.JavadocOptionsXpp3Writer.write(JavadocOptionsXpp3Writer.java:70)
>   at 
> org.apache.maven.plugin.javadoc.AbstractJavadocMojo.buildJavadocOptions(AbstractJavadocMojo.java:5867)
>   at 
> org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1857)
>   at 
> org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:181)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
>   ... 20 more
> {noformat}
> Suggestion: include code that performs basic structural checks so as to make 
> it impossible for a cryptic {{NullPointerException}} to occur simply due to 
> incorrect POM input.



--
This 

[jira] [Commented] (MENFORCER-251) Enhance requireReleaseDeps rule to allow SNAPSHOTS that have not been released

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997222#comment-16997222
 ] 

Elliotte Rusty Harold commented on MENFORCER-251:
-

This seems counter to the goal of the rule. I'm inclined to close it. 

> Enhance requireReleaseDeps rule to allow SNAPSHOTS that have not been released
> --
>
> Key: MENFORCER-251
> URL: https://issues.apache.org/jira/browse/MENFORCER-251
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>  Components: Standard Rules
>Affects Versions: 1.4.1
>Reporter: Jason W. Thompson
>Priority: Major
>
> When managing dependencies that are used by many projects, it is sometimes 
> helpful to know when a SNAPSHOT dependency is released. I would like to fail 
> a build which depends on a dependency such as 1.3-SNAPSHOT when there exists 
> a 1.3. However, I do not want to fail if 1.3 has not been released.
> Essentially, it would be helpful to have something to behave similar to 
> [versions:use-releases|http://www.mojohaus.org/versions-maven-plugin/use-releases-mojo.html]
>  except instead of modifying the pom, it would fail the build.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MDEP-525) Dependency:analyze-only complains about unused dependency on super class

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEP-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997221#comment-16997221
 ] 

Elliotte Rusty Harold commented on MDEP-525:


still an issue?

> Dependency:analyze-only complains about unused dependency on super class
> 
>
> Key: MDEP-525
> URL: https://issues.apache.org/jira/browse/MDEP-525
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.10
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_79
>Reporter: Eugene Rubanov
>Priority: Major
>
> Dependence:analyze-only complains about unused dependency on super class 
> artifact when 
> * superclass and subclass package are in separate artifacts 
> * subclass is used explicitly in target maven module
> * superclass is used only by subclass internals
> In this case java compiler requires superclass to be provided during 
> compilation, but dependency plugin reports superclass package as unused. 
> Please look at following example: https://github.com/venikkin/mdp-issue



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-6005) not able to pass map kind of variables to maven goal through command line

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold updated MNG-6005:
---
Priority: Minor  (was: Critical)

> not able to pass map kind of variables to maven goal through command line
> -
>
> Key: MNG-6005
> URL: https://issues.apache.org/jira/browse/MNG-6005
> Project: Maven
>  Issue Type: New Feature
>  Components: Command Line
>Affects Versions: 3.2.1
> Environment: java 7, maven 3.2.1,Mac Yosimite,
>Reporter: gangadhar mamillapalli
>Priority: Minor
>  Labels: command-line, commandline, maven3,
>
> am trying to pass Map kind of parameters to my maven plugin through command 
> line. Here is how i tried,
> bq. $mvn -U -X sample.plugin:hello-maven-plugin:1.0-SNAPSHOT:sayhi 
> -Dsayhi.myMap=key1=value1
> bq. $mvn -U -X sample.plugin:hello-maven-plugin:1.0-SNAPSHOT:sayhi 
> -Dsayhi.myMap={key1=value1}
> None of these are working and getting following error:
> {color:red}
> Caused by:
> org.codehaus.plexus.component.configurator.ComponentConfigurationException:
> Cannot assign configuration entry 'myMap' with value '${sayhi.myMap}' of type
> java.lang.String to property of type java.util.Map
> {color:red}
> Here is my parameter in Mojo:
> {quote}
> /**
>  * My Map.
>  */
> @Parameter(property = "sayhi.myMap", required = false)
> private Map myMap = new HashMap();
> {quote}
> followed instructions at ==> 
> https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Collections,
>  but no luck., i think am missing something very small. am working on maven 
> v3.2.1
> is am missing anything here ? am blocked on this.
> i have also posted same question stackoverflow.
> http://stackoverflow.com/questions/36678630/not-able-to-pass-map-kind-of-variables-to-maven-goal-through-command-line
> thanks 
> Gangadhar M



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-6005) not able to pass map kind of variables to maven goal through command line

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold updated MNG-6005:
---
Issue Type: New Feature  (was: Bug)

> not able to pass map kind of variables to maven goal through command line
> -
>
> Key: MNG-6005
> URL: https://issues.apache.org/jira/browse/MNG-6005
> Project: Maven
>  Issue Type: New Feature
>  Components: Command Line
>Affects Versions: 3.2.1
> Environment: java 7, maven 3.2.1,Mac Yosimite,
>Reporter: gangadhar mamillapalli
>Priority: Critical
>  Labels: command-line, commandline, maven3,
>
> am trying to pass Map kind of parameters to my maven plugin through command 
> line. Here is how i tried,
> bq. $mvn -U -X sample.plugin:hello-maven-plugin:1.0-SNAPSHOT:sayhi 
> -Dsayhi.myMap=key1=value1
> bq. $mvn -U -X sample.plugin:hello-maven-plugin:1.0-SNAPSHOT:sayhi 
> -Dsayhi.myMap={key1=value1}
> None of these are working and getting following error:
> {color:red}
> Caused by:
> org.codehaus.plexus.component.configurator.ComponentConfigurationException:
> Cannot assign configuration entry 'myMap' with value '${sayhi.myMap}' of type
> java.lang.String to property of type java.util.Map
> {color:red}
> Here is my parameter in Mojo:
> {quote}
> /**
>  * My Map.
>  */
> @Parameter(property = "sayhi.myMap", required = false)
> private Map myMap = new HashMap();
> {quote}
> followed instructions at ==> 
> https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Collections,
>  but no luck., i think am missing something very small. am working on maven 
> v3.2.1
> is am missing anything here ? am blocked on this.
> i have also posted same question stackoverflow.
> http://stackoverflow.com/questions/36678630/not-able-to-pass-map-kind-of-variables-to-maven-goal-through-command-line
> thanks 
> Gangadhar M



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHARED-519) Maven31DependencyGraphBuilder (and others?) should not download dependencies other than the pom

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold updated MSHARED-519:
--
Description: 
Hi,

It seems that when using Maven31DependencyGraphBuilder to build  a dependency 
tree of a maven module, the main artifact of the dependencies are downloaded 
while only the pom should be logically needed to infer the dependency tree.

This is problematic I think, see for example 
https://github.com/ferstl/depgraph-maven-plugin/issues/8

  was:
Hi,

It seems that when using Maven31DependencyGraphBuilder to build  a dependency 
tree of a maven module, the main artefact of the dependencies are downloaded 
while only the pom should be logically needed to infer the dependency tree.

This is problematic I think, see for example 
https://github.com/ferstl/depgraph-maven-plugin/issues/8


> Maven31DependencyGraphBuilder (and others?) should not download dependencies 
> other than the pom
> ---
>
> Key: MSHARED-519
> URL: https://issues.apache.org/jira/browse/MSHARED-519
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-dependency-tree
>Affects Versions: maven-dependency-tree-3.0
>Reporter: Victor
>Priority: Major
>
> Hi,
> It seems that when using Maven31DependencyGraphBuilder to build  a dependency 
> tree of a maven module, the main artifact of the dependencies are downloaded 
> while only the pom should be logically needed to infer the dependency tree.
> This is problematic I think, see for example 
> https://github.com/ferstl/depgraph-maven-plugin/issues/8



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNGSITE-291) Documentation about version comparison and what can be used

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997220#comment-16997220
 ] 

Elliotte Rusty Harold commented on MNGSITE-291:
---

sounds useful

> Documentation about version comparison and what can be used
> ---
>
> Key: MNGSITE-291
> URL: https://issues.apache.org/jira/browse/MNGSITE-291
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> Currently there is no documentation about the version comparison existing on 
> the site from a user perspective...Furthermore which kind of versions are 
> possible etc. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6080) New scope for non-functional dependencies

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997219#comment-16997219
 ] 

Elliotte Rusty Harold commented on MNG-6080:


"asset" sounds good

reactor is not a term I was familiar with as a user of maven

> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
>  Issue Type: New Feature
>  Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the 
> classpath. The classpath is the path that the Java Runtime Environment (JRE) 
> searches for classes and other resource files. Given that the classpath is 
> Java specific, this feature request can be generalized to accommodate 
> artifacts that are not code related (directly or indirectly). It is neither 
> code that executes (like a .class file = "directly") nor a resource file 
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that 
> contains common look-and-feel elements to brand all their web applications. 
> This project could be a ZIP archive to be included in downstream projects, in 
> which each build explodes the archive into their respective web application 
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}. 
> They are nearly equal but have a different slight emphasis. The {{"asset"}} 
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes 
> purpose within the build. The Maven Team should decide among these two or 
> propose a third. 
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRESOURCES-232) Resource copy filtering should use different encoding for source and output

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOURCES-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997216#comment-16997216
 ] 

Elliotte Rusty Harold commented on MRESOURCES-232:
--

agreed

> Resource copy filtering should use different encoding for source and output
> ---
>
> Key: MRESOURCES-232
> URL: https://issues.apache.org/jira/browse/MRESOURCES-232
> Project: Maven Resources Plugin
>  Issue Type: New Feature
>  Components: copy, filtering
>Affects Versions: 3.0.1
> Environment: Ubuntu 16.04 JDK 1.8 maven 3.3.4
>Reporter: Peng Cheng
>Priority: Major
>  Labels: maven
>
> In copy-resources goal. The configuration option 'encoding' is documented to 
> be capable of changing the encoding of source files and copy to output 
> directory, e.g.:
> {code}
> 
> 
> ${project.basedir}/sbin-ebcdic
> 
> 
> ${project.basedir}/sbin
> 
> 
> IBM037
> 
> {code}
> However, it is pointed out in the answer section of this post:
> http://stackoverflow.com/questions/40095716/why-maven-resources-plugin-ignores-my-charset-encoding-setting
> that this option affects both reading of source file and writing of output 
> file, resulting in most of the file encodings not converted. This should be 
> corrected by dividing this option into 2:
> sourceEncoding & outputEncoding, which controls reading and writing 
> separately. This is the most simple way to make encoding conversion practical.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6120) Allow changing of default scope and change the default scope

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997215#comment-16997215
 ] 

Elliotte Rusty Harold commented on MNG-6120:


I think setting the default to runtime would be a non starter for most 
projects. 

> Allow changing of default scope and change the default scope
> 
>
> Key: MNG-6120
> URL: https://issues.apache.org/jira/browse/MNG-6120
> Project: Maven
>  Issue Type: Wish
>Reporter: Caleb Cushing
>Priority: Major
>
> Recently I've realized that a lot of what jigsaw will provide regarding 
> transient dependencies can be resolved in maven if you use 
>  and set the default scope for each dep to runtime, and 
> then override that where you actually want compile time dependencies. I think 
> it would be nice if you could easily set the default scope for all modules 
> (meaning those that don't specify scope) to runtime (or compile, or 
> whatever), and then set the default to runtime in the next major maven 
> version (4?).
> Even if I only got the ability to set that default scope that'd be great.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MPLUGIN-316) improve mojo description for user properties

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997214#comment-16997214
 ] 

Elliotte Rusty Harold commented on MPLUGIN-316:
---

where is this?

> improve mojo description for user properties
> 
>
> Key: MPLUGIN-316
> URL: https://issues.apache.org/jira/browse/MPLUGIN-316
> Project: Maven Plugin Tools
>  Issue Type: Improvement
>  Components: Plugin Plugin
>Affects Versions: 3.5
>Reporter: Herve Boutemy
>Priority: Major
>
> currently, we generate in the parameter description a little text:
> bq. User property is: parameter-name.
> perhaps this info should be put in the name more than the description.
> And we should make it clear that this can be used either in pom properties, 
> either on CLI {{-Dparameter-name=}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6131) Support pom without coordinate

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997212#comment-16997212
 ] 

Elliotte Rusty Harold commented on MNG-6131:


I'm skeptical. I've written some tooling that would be quite surprised if it 
encountered a POM without a GAV. Plus, it seems simpler to state the rule as 
every pom has a GAV, instead of some POMs have GAV but these sorts of POM in 
these conditions can omit it but not those POMs that you use for something 
else. 

> Support pom without coordinate
> --
>
> Key: MNG-6131
> URL: https://issues.apache.org/jira/browse/MNG-6131
> Project: Maven
>  Issue Type: Improvement
>  Components: FDPFC, POM
>Reporter: Robert Scholte
>Priority: Major
>
> In some cases the GAV is only there because Maven expects it, even though 
> these coordinates will never be used.
> The most common case is an aggregator: it will only trigger module without 
> being part of a multimodule project.
> Another case I'm thinking of are test-cases, where you want to show the 
> behavior of some plugins. This project self will (or should!) never be 
> installed or deployed.
> In general: the GAV is only required when another project will refer to it or 
> if you want to distribute the project via a M2-repository manager.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6132) Parent pom should support plugin configuration/executions per packaging-types

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997213#comment-16997213
 ] 

Elliotte Rusty Harold commented on MNG-6132:


seems nice

> Parent pom should support plugin configuration/executions per packaging-types
> -
>
> Key: MNG-6132
> URL: https://issues.apache.org/jira/browse/MNG-6132
> Project: Maven
>  Issue Type: Improvement
>  Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Priority: Major
>
> The parent-pom has the ability to preconfigure a lot for all the projects 
> referring to it. However, the parent be used for all kinds of project types 
> (jar, war,ear, etc). There are plugins which you would like to configure at 
> parent level, but not for every type. It would be great if you could specify 
> for which packaging the plugin execution should be activated.
> On the other hand, it would also be nice if the plugin goals could specify 
> its default packaging types. I explicitly say default, I know a discussion 
> with the checkstyle team regarding the supported languages. It is possible to 
> verify XML with the checkstyle engine, though their focus is very strong on 
> Java only.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRELEASE-971) release:branch does not create release.properties so release:perform fails

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997211#comment-16997211
 ] 

Elliotte Rusty Harold commented on MRELEASE-971:


Is this still happening?

> release:branch does not create release.properties so release:perform fails
> --
>
> Key: MRELEASE-971
> URL: https://issues.apache.org/jira/browse/MRELEASE-971
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: branch, perform
>Affects Versions: 2.5.3
>Reporter: Carsten Hilber
>Priority: Major
>
> I am using the release plugin to release through a CI server. What I do is 
> creat a branch with 
> mvn release:branch --batch-mode -DbranchName=0.1.11 
> -Dproject.net.aim:releaseTest=0.1.11 
> -Dproject.net.aim:releaseTest=0.1.12-SNAPSHOT -DupdateBranchVersions=true
> A branch is created and the current dev branch is getting to the next 
> SNAPSHOT Version, so far so good. 
> To complete the version I need to do the next step. I want to do a 
> release:perform to release the newly created branch. This fails with the 
> following error message:
> $ mvn release:perform
> [INFO] Scanning for projects...
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building releaseTest 0.1.11-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> [INFO] --- maven-release-plugin:2.5.3:perform (default-cli) @ releaseTest ---
> [ERROR] No SCM URL was provided to perform the release from
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.846 s
> [INFO] Finished at: 2016-12-07T19:02:29+01:00
> [INFO] Final Memory: 13M/309M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on 
> project releaseTest: No SCM URL was provided to perform the release from -> 
> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MRELEASE-919) Link to plugin's web site is reported as redirected by maven linkcheck plugin.

[Elliotte Rusty Harold (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRELEASE-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold updated MRELEASE-919:
---
Priority: Minor  (was: Major)

> Link to plugin's web site is reported as redirected by maven linkcheck plugin.
> --
>
> Key: MRELEASE-919
> URL: https://issues.apache.org/jira/browse/MRELEASE-919
> Project: Maven Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.2
> Environment: maven release plugin, checkstyle
>Reporter: Andrei Selkin
>Priority: Minor
>
> Hello!
> We use maven linkcheck plugin to check links on checkstyle's website: 
> http://checkstyle.sourceforge.net/ . The plugin reports that on page 
> http://checkstyle.sourceforge.net/plugins.html the following link 
> http://maven.apache.org/plugins/maven-release-plugin/ is redirected (301) at 
> http://maven.apache.org/maven-release/maven-release-plugin/
> Links on plugins.html are generated by Apache Maven Project Info Reports 
> Plugin. All URLs are grabbed from effective POMs of plugins.
> Here is the code:
> https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/PluginsReport.java#L239
> https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/PluginsReport.java#L269
> In effective POM.xml of maven release plugin the problematic link is:
> http://maven.apache.org/plugins/maven-release-plugin/
> As a result, we do not have an ability to change plugins urls on that page, 
> because those links are specified by plugins developers.
> So, please correct the link, because there are contradictions between 
> linkcheck and maven release plugin.
> Thank in advance!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-javadoc-plugin] olamy commented on issue #33: [MJAVADOC-626] Add a stale javadoc detection mechanism

[GitBox]

olamy commented on issue #33: [MJAVADOC-626] Add a stale javadoc detection 
mechanism
URL: 
https://github.com/apache/maven-javadoc-plugin/pull/33#issuecomment-566008716
 
 
   @gnodet all looks good, I will have another last review tomorrow and merge 
it. Sorry for delay!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[GitHub] [maven-javadoc-plugin] gnodet commented on issue #33: [MJAVADOC-626] Add a stale javadoc detection mechanism

[GitBox]

gnodet commented on issue #33: [MJAVADOC-626] Add a stale javadoc detection 
mechanism
URL: 
https://github.com/apache/maven-javadoc-plugin/pull/33#issuecomment-565987073
 
 
   Apart from the java 8 requirement which I removed, any other comment on this 
PR ?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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