[jira] [Commented] (SUREFIRE-1622) failure to run tests if classpath gets too long (?)

[Carsten Hammer (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741832#comment-16741832
 ] 

Carsten Hammer commented on SUREFIRE-1622:
--

Hi [~tibor17],

there is no executable in folder "target/surefire" after running maven using 
the "-X" option. 
{noformat}
jenkins@jenkins:~/jobs/myprojecttrunksvn/workspace/buildhelper$ ls -l 
target/surefire/
insgesamt 304
-rw-r--r-- 1 jenkins jenkins    322 Jan 13 23:25 
surefire_17655213480496640844tmp
-rw-r--r-- 1 jenkins jenkins 305123 Jan 13 23:25 surefire6978277818649899267tmp
jenkins@jenkins:~/jobs/myprojecttrunksvn/workspace/buildhelper$
{noformat}
What I have is a executable shell script in "target/test-classes".
{noformat}
jenkins@jenkins:~/jobs/myprojecttrunksvn/workspace/buildhelper$ ls -l 
target/test-classes/
insgesamt 284
drwxr-xr-x 3 jenkins jenkins   4096 Jan 13 23:25 com
drwxr-xr-x 2 jenkins jenkins   4096 Jan 13 23:25 config
-rwxr-xr-x 1 jenkins jenkins    317 Jan 13 23:25 javac.sh
-rw-r--r-- 1 jenkins jenkins   2548 Jan 13 23:25 log4j2-test.xml
-rw-r--r-- 1 jenkins jenkins 274107 Jan 13 23:25 
org.codehaus.plexus.compiler.javac.JavacCompiler7240092760610409518arguments
jenkins@jenkins:~/jobs/myprojecttrunksvn/workspace/buildhelper$
{noformat}
This can be executed and runs successful (compiling the sources) in contrast to 
the same file in the old copy of the project with a space in path 
("myproject_trunk svn" instead of "myprojecttrunksvn") where this shell script 
fails because the path is not quoted.

But after all the build still fails:
{noformat}
[DEBUG] Forking command line: /bin/sh -c cd 
/var/lib/jenkins/jobs/myprojecttrunksvn/workspace/buildhelper && 
/var/lib/jenkins/tools/hudson.model.JDK/java8/jre/bin/java 
-Dfile.encoding=UTF-8 org.apache.maven.surefire.booter.ForkedBooter 
/var/lib/jenkins/jobs/myprojecttrunksvn/workspace/buildhelper/target/surefire 
2019-01-13T23-17-38_169-jvmRun1 surefire6978277818649899267tmp 
surefire_17655213480496640844tmp
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[ERROR] There are test failures.

Please refer to 
/var/lib/jenkins/jobs/myprojecttrunksvn/workspace/buildhelper/target/surefire-reports
 for the individual test results.
Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump 
and [date].dumpstream.
The forked VM terminated without properly saying goodbye. VM crash or 
System.exit called?
Command was /bin/sh -c cd 
/var/lib/jenkins/jobs/myprojecttrunksvn/workspace/buildhelper && 
/var/lib/jenkins/tools/hudson.model.JDK/java8/jre/bin/java 
-Dfile.encoding=UTF-8 org.apache.maven.surefire.booter.ForkedBooter 
/var/lib/jenkins/jobs/myprojecttrunksvn/workspace/buildhelper/target/surefire 
2019-01-13T23-17-38_169-jvmRun1 surefire6978277818649899267tmp 
surefire_17655213480496640844tmp

Error while executing forked tests.Error while executing process.Cannot run 
program "/bin/sh" (in directory 
"/var/lib/jenkins/jobs/myprojecttrunksvn/workspace/buildhelper"): error=7, Die 
Argumentliste ist zu 
langorg.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineException:
 Error while executing process.
    at 
org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.Commandline.execute(Commandline.java:438)
    at 
org.apache.maven.plugin.surefire.booterclient.lazytestprovider.OutputStreamFlushableCommandline.execute(OutputStreamFlushableCommandline.java:65)
    at 
org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils.executeCommandLineAsCallable(CommandLineUtils.java:248)
    at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:610)
    at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
    at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
    at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
    at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
    at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
    at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
    at 

[jira] [Updated] (MCOMPILER-310) Different behaviour between JDK 8 / JDK 9 related to annotation processor usage

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MCOMPILER-310:
---
Description: 
Based on the [SO 
question|https://stackoverflow.com/questions/46500984/immutables-dont-generate-code-with-java-9-with-modules]
 is looks like we have a difference in behaviour between JDK 8 / JDK 9 related 
to the picking up of annotation processors.
If you run the following code under JDK 8 (except for a module-info.java file):
{code:xml}

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

example
jigsaw
1.0-SNAPSHOT


  UTF-8



org.immutables
value
2.5.6
provided




  

  org.apache.maven.plugins
  maven-compiler-plugin
  3.7.0

  


{code}
The maven-compiler-plugin will automatically pickup the annotation processor 
and produce the classed from the annotation.
If you run the same with JDK 9 this will not work anymore. Only if you 
explicitly add the annotation processor configuration to maven-compiler-plugin 
it will work as expected:
{code:xml}

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

example
jigsaw
1.0-SNAPSHOT


  UTF-8



org.immutables
value
2.5.6
provided




  

  org.apache.maven.plugins
  maven-compiler-plugin
  3.7.0
  
9
9

  
  org.immutables
  value
  2.5.6
  

  

  


{code}
I'm not sure if this is based on the usage of modules (module-path instead of 
classpath)?

  was:
Based on the 
[https://stackoverflow.com/questions/46500984/immutables-dont-generate-code-with-java-9-with-modules|SO
 question] is looks like we have a difference in behaviour between JDK 8 / JDK 
9 related to the picking up of annotation processors.
If you run the following code under JDK 8 (except for a module-info.java file):
{code:xml}

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

example
jigsaw
1.0-SNAPSHOT


  UTF-8



org.immutables
value
2.5.6
provided




  

  org.apache.maven.plugins
  maven-compiler-plugin
  3.7.0

  


{code}
The maven-compiler-plugin will automatically pickup the annotation processor 
and produce the classed from the annotation.
If you run the same with JDK 9 this will not work anymore. Only if you 
explicitly add the annotation processor configuration to maven-compiler-plugin 
it will work as expected:

{code:xml}

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

example
jigsaw
1.0-SNAPSHOT


  UTF-8



org.immutables
value
2.5.6
provided




  

  org.apache.maven.plugins
  maven-compiler-plugin
  3.7.0
  
9
9

  
  org.immutables
  value
  2.5.6
  

  

  


{code}
I'm not sure if this is based on the usage of modules (module-path instead of 
classpath)? 


> Different behaviour between JDK 8 / JDK 9 related to annotation processor 
> usage
> ---
>
> Key: MCOMPILER-310
> URL: https://issues.apache.org/jira/browse/MCOMPILER-310
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Based on the [SO 
> question|https://stackoverflow.com/questions/46500984/immutables-dont-generate-code-with-java-9-with-modules]
>  is looks like we have a difference in behaviour between JDK 8 / JDK 9 
> related to the picking up of annotation processors.
> If you run the following code under JDK 8 

[GitHub] slachiewicz opened a new pull request #232: MNG-5577 Migrate to JSR 300 - easy part1

[GitBox]

slachiewicz opened a new pull request #232: MNG-5577 Migrate to JSR 300 - easy 
part1
URL: https://github.com/apache/maven/pull/232
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Closed] (MNG-5522) properties project.parent.xxx not supported under Linux

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-5522.
-
Resolution: Auto Closed

> properties project.parent.xxx not supported under Linux
> ---
>
> Key: MNG-5522
> URL: https://issues.apache.org/jira/browse/MNG-5522
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap  Build, POM
>Affects Versions: 3.0.5
> Environment: Few Linuxes tested, work under Windows
>Reporter: Pavel
>Priority: Major
> Attachments: maven-MNG-5522.zip
>
>
> Initially it was there: 
> https://jira.codehaus.org/browse/MRM-1772#comment-333654 . But It is maven 
> problem itself.
> It is reproducible on two our Linux machines (Fedora and Gentoo), so it may 
> be Linux relative. On all our colleagues on windows it does not reproduced.
> Some details.
> Parent pom among others have:
> {code}
>   1.5.300-SNAPSHOT
>   imus
> ...
>   
>   2.5.6
>   3.2.2.RELEASE
>   2.1.1
>   1.7.0
>   windows-1251
>   none
>   1.7
>   1.7
>   ${basedir}
>   QWERTY
>   
> {code}
> First child module:
> {code}
>   
>   
>   
>   org.apache.maven.plugins
>   maven-antrun-plugin
>   1.1
>   
>   
>   validate
>   
>   run
>   
>   
>   
>   
> [project.parent.rootProjectPath]: 
> ${project.parent.rootProjectPath}
>   
> [project.parent.getRootProjectPath()]: 
> ${project.parent.getRootProjectPath()}
>   
> [project.parent.rootProjectPath1]: 
> ${project.parent.rootProjectPath1}
>   
> [project.parent.spring3.version]: 
> ${project.parent.spring3.version}
>   
> [project.parent.properties.spring3.version]: 
> ${project.parent.properties.spring3.version}
>   
> [project.parent.properties.rootProjectPath]: 
> ${project.parent.properties.rootProjectPath}
>   
> [project.parent.properties.rootProjectPath1]: 
> ${project.parent.properties.rootProjectPath1}
>   
> [project.parent.name]: ${project.parent.name}
>   
> [project.parent.properties]: ${project.parent.properties}
>   
>   
>   
>   
>   
>   
>   
> {code}
> *In out I see what project.parent.name resolved and even 
> project.parent.properties, but not any property in collection (f.e. 
> project.parent.rootProjectPath or project.parent.properties.rootProjectPath) 
> as it should [by documentation|http://maven.apache.org/pom.html#Properties]*:
> {code}
> [INFO] --- maven-antrun-plugin:1.1:run (default) @ antinform-lib-parent ---
> [INFO] Executing tasks
>  [echo] [project.parent.rootProjectPath]: 
> ${project.parent.rootProjectPath}
>  [echo] [project.parent.getRootProjectPath()]: 
> ${project.parent.getRootProjectPath()}
>  [echo] [project.parent.rootProjectPath1]: 
> ${project.parent.rootProjectPath1}
>  [echo] [project.parent.spring3.version]: 
> ${project.parent.spring3.version}
>  [echo] [project.parent.properties.spring3.version]: 
> ${project.parent.properties.spring3.version}
>  [echo] [project.parent.properties.rootProjectPath]: 
> ${project.parent.properties.rootProjectPath}
>  [echo] [project.parent.properties.rootProjectPath1]: 
> ${project.parent.properties.rootProjectPath1}
>  [echo] [project.parent.name]: imus
>  [echo] [project.parent.properties]: {rootProjectPath1=QWERTY, 
> spring3.version=3.2.2.RELEASE, mule.version=2.1.1, aspectj.version=1.7.0, 
> maven.compiler.target=1.7, source.encoding=windows-1251, 
> maven.test.include=none, maven.compiler.source=1.7, spring.version=2.5.6, 
> 

[jira] [Updated] (MNG-6211) Improve relocation message

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6211:
--
Fix Version/s: 3.x / Backlog

> Improve relocation message
> --
>
> Key: MNG-6211
> URL: https://issues.apache.org/jira/browse/MNG-6211
> Project: Maven
>  Issue Type: Improvement
>  Components: Dependencies
>Reporter: Robert Scholte
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> Consider the following setup:
> {noformat}
> A:1.0 -> B:1.1
> C:1.1 -> B:1.0
> B:1.4 >>> D:1.4
> My -> A:1.0, B:1.3, C:1.1
> {noformat}
> When upgrading My B to 1.4, I'll get a warning about the relocation. But when 
> I replace B:1.4 with D:1.4, B:1.1 will be pulled in because it is a 
> transitive dependency of A and because D is not aware being the relocation of 
> B.
> In this case the relocation should be INFO, because following the instruction 
> will have an unpleasant surprise.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6159) Child path adjustments break git scm urls

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6159:
--
Fix Version/s: 3.6.x-candidate

> Child path adjustments break git scm urls
> -
>
> Key: MNG-6159
> URL: https://issues.apache.org/jira/browse/MNG-6159
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Aistleitner
>Priority: Minor
> Fix For: 3.6.x-candidate
>
> Attachments: 0001-Skip-child-path-adjustments-for-git-scm-urls.patch
>
>
> While child path adjustments make sense for some scms, child path
> adjustment break git scm urls.
> Consider a parent project Foo which is available at 
> http://github.com:ExampleOrg/Foo and uses
> [...]
> scm:git:g...@github.com:ExampleOrg/${project.artifactId}.git
> [...]
> 
> If a project Bar in the repo at http://github.com:ExampleOrg/Bar uses Foo as 
> parent and inherits , it ends up with the value
> 
>   scm:git:g...@github.com:ExampleOrg/${project.artifactId}.git/Foo
> 
> which is not usable due to the child path adjustment.
> While this bit us, we're not alone. Looking at the reported URLs, child path 
> adjustments for git scm urls are also caused issues in these places:
> https://github.com/vorburger/MariaDB4j/issues/43
> https://gist.github.com/escowles/f46d158cdaf955e34282
> http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2014/%23aerogear.2014-07-03.log.html
>  (search for "not a valid repository name")



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MRESOLVER-33) New class 'DefaultDependencyManager' managing dependencies on all levels supporting transitive dependency management.

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MRESOLVER-33:
--
Fix Version/s: version-next

> New class 'DefaultDependencyManager' managing dependencies on all levels 
> supporting transitive dependency management.
> -
>
> Key: MRESOLVER-33
> URL: https://issues.apache.org/jira/browse/MRESOLVER-33
> Project: Maven Resolver
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Priority: Trivial
> Fix For: version-next
>
>
> The {{ClassicDependencyManager}} ignores the dependency management from 
> transitive dependencies to maintain backwards compatibility with Maven 2, 
> then Maven 3 (objective when extracting Aether was to keep compatibility).
> The {{TransitiveDependencyManager}} will use that dependency management and 
> will still support management overrides from inside {{}} 
> elements. See the linked issues.
> The {{DefaultDependencyManager}} will no longer support such overrides and 
> can be considered the default implementation from a resolver point of view.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6141:
--
Fix Version/s: 3.x / Backlog

> Dependency management overrides are not transitive and should be considered 
> an anti-pattern.
> 
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: MNG-6141-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}} 
> section, the overridden value will not be preserved transitively. It makes no 
> sense to be able to override the dependency management in a module if that is 
> only effective in that module and nowhere else. Overriding the dependency 
> management from inside a {{}} element should be considered an 
> anti-pattern. Maven should provide a warning when it is used. During the 
> development of Maven 3.4, there have been quite a few discussions on dev@ 
> about build issues which were all caused by overriding the dependency 
> management that way without noticing this is not supported transitively.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-6130) Loss of profile information in workaround for MNG-4900

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-6130.
-
   Resolution: Won't Fix
Fix Version/s: (was: waiting-for-feedback)

> Loss of profile information in workaround for MNG-4900
> --
>
> Key: MNG-6130
> URL: https://issues.apache.org/jira/browse/MNG-6130
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.3.9, 3.5.0
> Environment: Windows
>Reporter: Boris Brodski
>Priority: Major
>  Labels: easyfix, patch
> Attachments: MNG-6130.patch
>
>
> Please, forgive me not providing example project reproducing the bug.
> It's very tricky and hopefully not necessary, since the 1-line fix is 
> provided.
> Using profiles together with maven-javadoc-plugin results in the following 
> problem:
> - Configuration from active profiles is not considered during dependency 
> resolution started problematically from the maven-javadoc-plugin.
> This leads to unpredictable behavior, that is somewhat hard to reproduce.
> Here is the technical inside and the 1-line fix:
> In the DefaultMavenProjectBuilder.toRequest():
> {noformat}
> if ( profileManager != null ) {
>...
> } else {
>   ...
>   /*
>* MNG-4900: Hack to workaround deficiency of legacy API which makes it 
> impossible for plugins to access the
>* global profile manager which is required to build a POM like a CLI 
> invocation does. Failure to consider
>* the activated profiles can cause repo declarations to be lost which in 
> turn will result in artifact
>* resolution failures, in particular when using the enhanced local repo 
> which guards access to local files
>* based on the configured remote repos.
>*/
> request.setActiveProfileIds( req.getActiveProfiles() );
> request.setInactiveProfileIds( req.getInactiveProfiles() );
> }
> {noformat}
> Here we copy active and inactive profile ids, but we don't copy the list of 
> all profile ids. Missing line:
> {noformat}
> request.setProfiles( req.getProfiles() );
> {noformat}
> As the result the method DefaultProfileManager.getActiveProfiles() always 
> returns an empty list:
> {noformat}
>   List activeProfiles = new ArrayList<>( profiles.size() );
>   for ( Profile profile : profiles ) {
>  ...
>   }
>   return activeProfiles;
> {noformat}
> "profiles" here is empty, since it wasn't copied together with 
> "getActiveProfiles()" and "getInactiveProfiles()"
> Adding the missing line fixes the problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6107) Add support for "includes" in dependencyManagement

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6107:
--
Fix Version/s: Issues to be reviewed for 4.x

> Add support for "includes" in dependencyManagement
> --
>
> Key: MNG-6107
> URL: https://issues.apache.org/jira/browse/MNG-6107
> Project: Maven
>  Issue Type: New Feature
>  Components: POM
>Reporter: Christofer Dutz
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> There are quite a number of artifacts that reference no-deps artifacts which 
> pull in undesired content. I usually exclude these in dependencyManagment 
> sections, but manually add artifacts that provide the excluded nodeps 
> content. The problem is, that if someone in the company uses the library for 
> which I have excluded the no-deps artifacts will probably not know about this 
> and not manually add the missing artifacts. Therefore it would be great if 
> the dependencyManagment section would allow not only "excludes" but 
> "includes" that would allow to auto-include dependencies if a given artifact 
> is used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6101) Dependency plugin bypasses reactor when resolving dependencies

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-6101:
---

Still valid with Maven 3.6.1-SNAPSHOT and maven-dependency-plugin:2.8

> Dependency plugin bypasses reactor when resolving dependencies
> --
>
> Key: MNG-6101
> URL: https://issues.apache.org/jira/browse/MNG-6101
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Reactor and workspace
>Affects Versions: 3.3.9
>Reporter: Tuure Laurinolli
>Priority: Major
> Fix For: 3.x / Backlog
>
> Attachments: resolution.zip
>
>
> When running {{mvn dependency:tree}} on a multi-module project, inter-module 
> dependencies are not resolved through reactor. Using another goal in the same 
> build (e.g. {{mvn compile dependency:tree}}) as suggested in 
> http://www.mail-archive.com/users@maven.apache.org/msg104341.html resolves 
> the immediate issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6101) Dependency plugin bypasses reactor when resolving dependencies

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6101:
--
Fix Version/s: 3.x / Backlog

> Dependency plugin bypasses reactor when resolving dependencies
> --
>
> Key: MNG-6101
> URL: https://issues.apache.org/jira/browse/MNG-6101
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies, Reactor and workspace
>Affects Versions: 3.3.9
>Reporter: Tuure Laurinolli
>Priority: Major
> Fix For: 3.x / Backlog
>
> Attachments: resolution.zip
>
>
> When running {{mvn dependency:tree}} on a multi-module project, inter-module 
> dependencies are not resolved through reactor. Using another goal in the same 
> build (e.g. {{mvn compile dependency:tree}}) as suggested in 
> http://www.mail-archive.com/users@maven.apache.org/msg104341.html resolves 
> the immediate issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5588) Scope import in pluginManagement

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5588:
--
Fix Version/s: 4.0.x-candidate

> Scope import in pluginManagement
> 
>
> Key: MNG-5588
> URL: https://issues.apache.org/jira/browse/MNG-5588
> Project: Maven
>  Issue Type: Wish
>  Components: Dependencies, FDPFC, POM
>Affects Versions: 3.1.1
>Reporter: Romain N
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> I can do this in dependencyManagement to define dependencies versions:
> {code}
> 
>   test
>   test
> 1
>import
>pom
> 
> {code}
> It could be great to can do the same things in pluginManagements to define 
> version plugin and default behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-6060) better and precise error reporting when project is not found e.g. with -rf option

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-6060.
-
Resolution: Not A Problem

> better and precise error reporting when project is not found e.g. with -rf 
> option
> -
>
> Key: MNG-6060
> URL: https://issues.apache.org/jira/browse/MNG-6060
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line, Errors, POM, Reactor and workspace
>Affects Versions: 3.3.9
> Environment: Linux 4.6.2 with Oracle JDK 8
>Reporter: Gregor B. Rosenauer
>Priority: Trivial
>  Labels: maven
>
> when building a multi-module project with -rf and the project is not found, 
> Maven explodes all over your face and prints the *entire* POM instead of just 
> pointing out the missing project - it does, but hides it before the POM dump 
> so the info is easily lost:
> {{[ERROR] [ERROR] Could not find project to resume reactor build from: 
> :missing-in-action vs [MavenProject: (entire POM dumped here)}}
> Good old make would just tell you this precise and helpful message, instead 
> of dumping the entire makefile:
> {{make: *** No rule to make target 'some-nonexisting-target'.  Stop.}}
> Please make maven a bit more user friendly when reporting errors...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6060) better and precise error reporting when project is not found e.g. with -rf option

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-6060:
---

With latest Maven, output is simpler:

{noformat}
[INFO] Scanning for projects...
[ERROR] Could not find project to resume reactor build from: :xx vs 
org.apache.maven:maven, org.apache.maven:maven-model, 
org.apache.maven:maven-artifact, org.apache.maven:maven-plugin-api, 
org.apache.maven:maven-builder-support, org.apache.maven:maven-model-builder, 
org.apache.maven:maven-settings, org.apache.maven:maven-settings-builder, 
org.apache.maven:maven-repository-metadata, 
org.apache.maven:maven-resolver-provider, org.apache.maven:maven-core, 
org.apache.maven:maven-slf4j-provider, org.apache.maven:maven-embedder, 
org.apache.maven:maven-compat, org.apache.maven:apache-maven @
[ERROR] Could not find project to resume reactor build from: :xx vs 
org.apache.maven:maven, org.apache.maven:maven-model, 
org.apache.maven:maven-artifact, org.apache.maven:maven-plugin-api, 
org.apache.maven:maven-builder-support, org.apache.maven:maven-model-builder, 
org.apache.maven:maven-settings, org.apache.maven:maven-settings-builder, 
org.apache.maven:maven-repository-metadata, 
org.apache.maven:maven-resolver-provider, org.apache.maven:maven-core, 
org.apache.maven:maven-slf4j-provider, org.apache.maven:maven-embedder, 
org.apache.maven:maven-compat, org.apache.maven:apache-maven -> [Help 
1]{noformat}

> better and precise error reporting when project is not found e.g. with -rf 
> option
> -
>
> Key: MNG-6060
> URL: https://issues.apache.org/jira/browse/MNG-6060
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line, Errors, POM, Reactor and workspace
>Affects Versions: 3.3.9
> Environment: Linux 4.6.2 with Oracle JDK 8
>Reporter: Gregor B. Rosenauer
>Priority: Trivial
>  Labels: maven
>
> when building a multi-module project with -rf and the project is not found, 
> Maven explodes all over your face and prints the *entire* POM instead of just 
> pointing out the missing project - it does, but hides it before the POM dump 
> so the info is easily lost:
> {{[ERROR] [ERROR] Could not find project to resume reactor build from: 
> :missing-in-action vs [MavenProject: (entire POM dumped here)}}
> Good old make would just tell you this precise and helpful message, instead 
> of dumping the entire makefile:
> {{make: *** No rule to make target 'some-nonexisting-target'.  Stop.}}
> Please make maven a bit more user friendly when reporting errors...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5587) When the build fails emit any errors without the user having to specify -e or -X

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-5587:
---

[~rfscholte] what is current direction here?

> When the build fails emit any errors without the user having to specify -e or 
> -X
> 
>
> Key: MNG-5587
> URL: https://issues.apache.org/jira/browse/MNG-5587
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Jason van Zyl
>Assignee: Jason van Zyl
>Priority: Major
> Fix For: 3.6.x-candidate, 3.x / Backlog
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5584) log credentials source when failing to access a repository

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5584:
--
Fix Version/s: 3.x / Backlog

> log credentials source when failing to access a repository
> --
>
> Key: MNG-5584
> URL: https://issues.apache.org/jira/browse/MNG-5584
> Project: Maven
>  Issue Type: Improvement
>  Components: Dependencies, Deployment
>Affects Versions: 3.x / Backlog
>Reporter: nicolas de loof
>Priority: Major
> Fix For: waiting-for-feedback, 3.x / Backlog
>
>
> When some repository authentication fail, maven just logs the status :
> {noformat}Could not transfer artifact  from/to  (): Not 
> authorized, ReasonPhrase:Unauthorized.{noformat}
> but don't let user know if credentials are well set and which one it used. 
> I'd like it logs credentials source it used trying to access repository, like
> {{using server credentials  from }}, source being some 
> settings.xml path or equivalent.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5522) properties project.parent.xxx not supported under Linux

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-5522:
---

This issue has been auto closed because it has been inactive for a long period 
of time. If you think this issue still applies, retest your problem with the 
most recent version of Maven and the affected component, reopen and post your 
results.

> properties project.parent.xxx not supported under Linux
> ---
>
> Key: MNG-5522
> URL: https://issues.apache.org/jira/browse/MNG-5522
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap  Build, POM
>Affects Versions: 3.0.5
> Environment: Few Linuxes tested, work under Windows
>Reporter: Pavel
>Priority: Major
> Attachments: maven-MNG-5522.zip
>
>
> Initially it was there: 
> https://jira.codehaus.org/browse/MRM-1772#comment-333654 . But It is maven 
> problem itself.
> It is reproducible on two our Linux machines (Fedora and Gentoo), so it may 
> be Linux relative. On all our colleagues on windows it does not reproduced.
> Some details.
> Parent pom among others have:
> {code}
>   1.5.300-SNAPSHOT
>   imus
> ...
>   
>   2.5.6
>   3.2.2.RELEASE
>   2.1.1
>   1.7.0
>   windows-1251
>   none
>   1.7
>   1.7
>   ${basedir}
>   QWERTY
>   
> {code}
> First child module:
> {code}
>   
>   
>   
>   org.apache.maven.plugins
>   maven-antrun-plugin
>   1.1
>   
>   
>   validate
>   
>   run
>   
>   
>   
>   
> [project.parent.rootProjectPath]: 
> ${project.parent.rootProjectPath}
>   
> [project.parent.getRootProjectPath()]: 
> ${project.parent.getRootProjectPath()}
>   
> [project.parent.rootProjectPath1]: 
> ${project.parent.rootProjectPath1}
>   
> [project.parent.spring3.version]: 
> ${project.parent.spring3.version}
>   
> [project.parent.properties.spring3.version]: 
> ${project.parent.properties.spring3.version}
>   
> [project.parent.properties.rootProjectPath]: 
> ${project.parent.properties.rootProjectPath}
>   
> [project.parent.properties.rootProjectPath1]: 
> ${project.parent.properties.rootProjectPath1}
>   
> [project.parent.name]: ${project.parent.name}
>   
> [project.parent.properties]: ${project.parent.properties}
>   
>   
>   
>   
>   
>   
>   
> {code}
> *In out I see what project.parent.name resolved and even 
> project.parent.properties, but not any property in collection (f.e. 
> project.parent.rootProjectPath or project.parent.properties.rootProjectPath) 
> as it should [by documentation|http://maven.apache.org/pom.html#Properties]*:
> {code}
> [INFO] --- maven-antrun-plugin:1.1:run (default) @ antinform-lib-parent ---
> [INFO] Executing tasks
>  [echo] [project.parent.rootProjectPath]: 
> ${project.parent.rootProjectPath}
>  [echo] [project.parent.getRootProjectPath()]: 
> ${project.parent.getRootProjectPath()}
>  [echo] [project.parent.rootProjectPath1]: 
> ${project.parent.rootProjectPath1}
>  [echo] [project.parent.spring3.version]: 
> ${project.parent.spring3.version}
>  [echo] [project.parent.properties.spring3.version]: 
> ${project.parent.properties.spring3.version}
>  [echo] [project.parent.properties.rootProjectPath]: 
> ${project.parent.properties.rootProjectPath}
>  [echo] [project.parent.properties.rootProjectPath1]: 
> ${project.parent.properties.rootProjectPath1}
>  [echo] [project.parent.name]: imus
>  [echo] [project.parent.properties]: {rootProjectPath1=QWERTY, 
> 

[jira] [Updated] (MNG-5512) Deploy uses passwords that failed decryption; retries even if login fails

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5512:
--
Fix Version/s: 3.x / Backlog

> Deploy uses passwords that failed decryption; retries even if login fails
> -
>
> Key: MNG-5512
> URL: https://issues.apache.org/jira/browse/MNG-5512
> Project: Maven
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
> Fix For: 3.x / Backlog
>
> Attachments: mng5512.zip
>
>
> [See MDEPLOY-130 which was closed as being an issue in Maven core]
> If passwords have been encrypted, deploy fails to notice if the password 
> decryption failed.
> Furthermore, it carries on trying to login even after a login failure.
> This is true even if the decryption succeeded but the password was incorrect 
> or no encryption was used and the password is incorrect.
> This is bad as it can result in lockout due to the multiple failed logins - 
> deploy needs to login several times - and may cause unnecessary work for 
> system admins.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5606) maven should use JDK_HOME env var if present

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5606:
--
Labels:   (was: close-pending)

> maven should use JDK_HOME env var if present
> 
>
> Key: MNG-5606
> URL: https://issues.apache.org/jira/browse/MNG-5606
> Project: Maven
>  Issue Type: Wish
> Environment: windows 7
>Reporter: guai
>Priority: Trivial
>
> JAVA_HOME is for jre, but maven searches for javac there.
> One can add
> @if not "%JDK_HOME%" == "" set JAVA_HOME="%JDK_HOME%"
> to mvn.bat
> and the analogue string to .sh script



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-5606) maven should use JDK_HOME env var if present

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-5606.
-
Resolution: Auto Closed

> maven should use JDK_HOME env var if present
> 
>
> Key: MNG-5606
> URL: https://issues.apache.org/jira/browse/MNG-5606
> Project: Maven
>  Issue Type: Wish
> Environment: windows 7
>Reporter: guai
>Priority: Trivial
>  Labels: close-pending
>
> JAVA_HOME is for jre, but maven searches for javac there.
> One can add
> @if not "%JDK_HOME%" == "" set JAVA_HOME="%JDK_HOME%"
> to mvn.bat
> and the analogue string to .sh script



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-5448) Putting dll/so-type dependencies on java.library.path by default

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-5448.
-
Resolution: Auto Closed

> Putting dll/so-type dependencies on java.library.path by default
> 
>
> Key: MNG-5448
> URL: https://issues.apache.org/jira/browse/MNG-5448
> Project: Maven
>  Issue Type: Bug
>Reporter: Markus Karg
>Priority: Major
>
> Many people are using Maven to build products that are using native 
> dependencies (e. g. using JNI directly or indirectly). These people have to 
> declare in some way this dependency, so Maven will download the DLL/SO to 
> [target]. But what they also need is to tell Java that the target folder has 
> to be scanned for the DLL/SO, hence they need to set java.library path.
> There are several solutions but all of them lack one thing: They are no 
> default but always do "tricks". This is a problem, because:
> * m2e needs to tell Eclipse where to find DLLs.
> * There might be other tools that want to read or write the POM.
> * How should different tools understand that DLL dependencies are to be put 
> on java.library.path if there is no STANDARD way to find this information in 
> the POM?
> The only "real" solution would be that Maven 3.1 clearly defines the one and 
> only unique way!
> In my opinion the way clearly means:
> * Clearly define that any dll and 
> exe dependencies MUST be put to [target/native] and 
> that [target/native] MUST be part of java.library.path!
> That way, it will become most simple to use any DLL/SO as a dependency, 
> either Maven-built or not. And it will be absolutely clear to m2e and any 
> other tools that such dependencies must be told to Eclipse and other 
> environments as to be put on the java.library.path!
> I do not say that it must exactly work THIS way, but what I really like to 
> say is that Maven MUST provide ONE and EXACTLY ONE clear and unambiguous way 
> to tell ANY POM-reading tool that a dependency is a DLL/SO and MUST be found 
> on java.library.path in turn.
> This is NOT up to the POM author, as it is pretty clear that ANY DLL/SO that 
> is a dependency only serves the single and simple purpose of BEING on 
> java.library.path -- otherwise one would not have made it a dependency!
> I mean, ANY JAR dependency is put on the CLASSPATH already, so it makes 
> pretty much sense to do the same with DLL/SO dependency and java.library.path!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5448) Putting dll/so-type dependencies on java.library.path by default

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-5448:
---

This issue has been auto closed because it has been inactive for a long period 
of time. If you think this issue still applies, retest your problem with the 
most recent version of Maven and the affected component, reopen and post your 
results.

> Putting dll/so-type dependencies on java.library.path by default
> 
>
> Key: MNG-5448
> URL: https://issues.apache.org/jira/browse/MNG-5448
> Project: Maven
>  Issue Type: Bug
>Reporter: Markus Karg
>Priority: Major
>
> Many people are using Maven to build products that are using native 
> dependencies (e. g. using JNI directly or indirectly). These people have to 
> declare in some way this dependency, so Maven will download the DLL/SO to 
> [target]. But what they also need is to tell Java that the target folder has 
> to be scanned for the DLL/SO, hence they need to set java.library path.
> There are several solutions but all of them lack one thing: They are no 
> default but always do "tricks". This is a problem, because:
> * m2e needs to tell Eclipse where to find DLLs.
> * There might be other tools that want to read or write the POM.
> * How should different tools understand that DLL dependencies are to be put 
> on java.library.path if there is no STANDARD way to find this information in 
> the POM?
> The only "real" solution would be that Maven 3.1 clearly defines the one and 
> only unique way!
> In my opinion the way clearly means:
> * Clearly define that any dll and 
> exe dependencies MUST be put to [target/native] and 
> that [target/native] MUST be part of java.library.path!
> That way, it will become most simple to use any DLL/SO as a dependency, 
> either Maven-built or not. And it will be absolutely clear to m2e and any 
> other tools that such dependencies must be told to Eclipse and other 
> environments as to be put on the java.library.path!
> I do not say that it must exactly work THIS way, but what I really like to 
> say is that Maven MUST provide ONE and EXACTLY ONE clear and unambiguous way 
> to tell ANY POM-reading tool that a dependency is a DLL/SO and MUST be found 
> on java.library.path in turn.
> This is NOT up to the POM author, as it is pretty clear that ANY DLL/SO that 
> is a dependency only serves the single and simple purpose of BEING on 
> java.library.path -- otherwise one would not have made it a dependency!
> I mean, ANY JAR dependency is put on the CLASSPATH already, so it makes 
> pretty much sense to do the same with DLL/SO dependency and java.library.path!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6024) maven-antrun-plugin:instrument failing NoClassDefFoundError: org/slf4j/LoggerFactory

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-6024:
---

ok, lets close issue as it would be hard to do something with not supported 
cobertura.

> maven-antrun-plugin:instrument failing NoClassDefFoundError: 
> org/slf4j/LoggerFactory
> 
>
> Key: MNG-6024
> URL: https://issues.apache.org/jira/browse/MNG-6024
> Project: Maven
>  Issue Type: Bug
>  Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
> Environment: Window 7, JDK 1.8.0_40
>Reporter: S V Mohana Rao
>Priority: Major
> Attachments: maven-core-slf4j-issue.zip, mvn-coreslf4j-issue.txt
>
>
> Related issues : MNG-5783, MNG-5817. I was using maven-antrun-plugin added 
> dependency cobertura which requires slf4j-api dependent jar. Even i tried 
> using 3.4.0-SNAPSHOT version but problem persists. As i was observed it's 
> been excluded from the child dependent artifacts of cobertura cause it's part 
> maven core. But it's not referring from maven core which hasn't been added 
> class path. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5438) cli parameter to use a custom path settings-security.xml

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5438:
--
Fix Version/s: 3.x / Backlog
   3.6.x-candidate

> cli parameter to use a custom path settings-security.xml
> 
>
> Key: MNG-5438
> URL: https://issues.apache.org/jira/browse/MNG-5438
> Project: Maven
>  Issue Type: New Feature
>  Components: Command Line
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Sarah Haselbauer
>Priority: Major
> Fix For: 3.6.x-candidate, 3.x / Backlog
>
> Attachments: MNG-5438-maven-embedder.patch, 
> apache-maven-3.0.4-ssec-bin.tar.gz, apache-maven-3.0.4-ssec-bin.zip, 
> maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch, 
> maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch
>
>
> added -ssec as cli param, so that you have the same flexibility to place your 
> settings-security.xml as you have to point to a custom settings.xml file
> mvn -s /path/to/my/custom/settings.xml -ssec 
> /path/to/my/custom/settings-security.xml
> I attached to patches: one that can be run on the maven-3.0.4 tag and one 
> that can be run on trunk (latest code state of today).
> I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the 
> feature and test it yourself.
> if you like the idea, I would welcome to have this feature merged into one of 
> the next releases. I need it to write a puppet-maven module that allows to 
> download artifacts from maven repositories with encrypted passwords in the 
> puppet recipe.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5378) Use maven-shared-utils in Maven core to replace plexus-utils

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-5378:
---

Think of _org.apache.maven.plugin.internal.PlexusUtilsInjector_ - we always 
inject plexus-utils to every plugin.

> Use maven-shared-utils in Maven core to replace plexus-utils
> 
>
> Key: MNG-5378
> URL: https://issues.apache.org/jira/browse/MNG-5378
> Project: Maven
>  Issue Type: Task
>Reporter: Jason van Zyl
>Assignee: Kristian Rosenvold
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> see http://maven.apache.org/shared/maven-shared-utils/ for the rationale



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-6045) Document Jansi's native support limitation

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-6045.
-
Resolution: Auto Closed

> Document Jansi's native support limitation
> --
>
> Key: MNG-6045
> URL: https://issues.apache.org/jira/browse/MNG-6045
> Project: Maven
>  Issue Type: Sub-task
>  Components: Bootstrap  Build, Command Line, Documentation:  
> General
>Affects Versions: needing-scrub-3.4.0-fallout
>Reporter: Michael Osipov
>Priority: Minor
>
> Jansi supports only Linux, Windows and OS X by default with native functions. 
> We must document that for the users and point how they can build a native 
> library for their platform.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-6024) maven-antrun-plugin:instrument failing NoClassDefFoundError: org/slf4j/LoggerFactory

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-6024.
-
Resolution: Auto Closed

> maven-antrun-plugin:instrument failing NoClassDefFoundError: 
> org/slf4j/LoggerFactory
> 
>
> Key: MNG-6024
> URL: https://issues.apache.org/jira/browse/MNG-6024
> Project: Maven
>  Issue Type: Bug
>  Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
> Environment: Window 7, JDK 1.8.0_40
>Reporter: S V Mohana Rao
>Priority: Major
> Attachments: maven-core-slf4j-issue.zip, mvn-coreslf4j-issue.txt
>
>
> Related issues : MNG-5783, MNG-5817. I was using maven-antrun-plugin added 
> dependency cobertura which requires slf4j-api dependent jar. Even i tried 
> using 3.4.0-SNAPSHOT version but problem persists. As i was observed it's 
> been excluded from the child dependent artifacts of cobertura cause it's part 
> maven core. But it's not referring from maven core which hasn't been added 
> class path. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6012) Missing profile is only notified at the end of a run

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6012:
--
Fix Version/s: 3.7.0-candidate

> Missing profile is only notified at the end of a run
> 
>
> Key: MNG-6012
> URL: https://issues.apache.org/jira/browse/MNG-6012
> Project: Maven
>  Issue Type: New Feature
>Affects Versions: 3.3.9
>Reporter: Sebb
>Priority: Major
> Fix For: needing-scrub-3.4.0-fallout, 3.7.0-candidate
>
>
> A missing profile is only notified at the end of a run.
> Since this may mean that the run is useless, it would be helpful if:
> 1) It was also noted near the start, so the user could cancel the run.
> It's still helpful at the end, as it saves scrolling back to see if there was 
> a problem.
> 2) There were an option to fail a run if a profile is not found. This option 
> should be settable in a POM and in settings.xml



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5974) ComparableVersion fails with semver.org-style milestone versions

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5974:
--
Fix Version/s: 3.x / Backlog

> ComparableVersion fails with semver.org-style milestone versions
> 
>
> Key: MNG-5974
> URL: https://issues.apache.org/jira/browse/MNG-5974
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Tuure Laurinolli
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> ComparableVersion does not correctly parse semver.org-style milestone 
> versions where the "m" is separated from the milestyne number by a dot, like 
> "1.0.0-m.3".
> It seems that Maven only recognizes the "m" alias for "milestone" if it's 
> immediately followed by a digit. I don't think this is according to the class 
> javadoc, which does not mention that some aliases require the alias to be 
> followed by a number to be effective.
> Test case:
> {code}
> import org.apache.maven.artifact.versioning.ComparableVersion;
> import org.junit.Test;
> import static org.junit.Assert.assertTrue;
> public class VersionTest {
> @Test
> public void testSortVersions() throws Exception {
> final ComparableVersion m2 = new ComparableVersion("1.2.3-m.2");
> final ComparableVersion rc1 = new ComparableVersion("1.2.3-rc.1");
> assertTrue(rc1.compareTo(m2) > 0);
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-5949) NPE when running with -T2 under Jenkins

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-5949.
-
Resolution: Auto Closed

> NPE when running with -T2 under Jenkins
> ---
>
> Key: MNG-5949
> URL: https://issues.apache.org/jira/browse/MNG-5949
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
> Environment: Linux x64, JDK 8, Jenkins
>Reporter: Axel Fontaine
>Priority: Major
>
> When running single threaded everything works fine. When I enable -T2 the 
> resource plugin fails to create the output directory of the second module due 
> to this NPE:
> java.lang.NullPointerException
>   at 
> org.apache.maven.execution.MavenSession.getPluginContext(MavenSession.java:195)
>   at 
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:561)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   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.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
>   at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5949) NPE when running with -T2 under Jenkins

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-5949:
---

This issue has been auto closed because it has been inactive for a long period 
of time. If you think this issue still applies, retest your problem with the 
most recent version of Maven and the affected component, reopen and post your 
results.

> NPE when running with -T2 under Jenkins
> ---
>
> Key: MNG-5949
> URL: https://issues.apache.org/jira/browse/MNG-5949
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
> Environment: Linux x64, JDK 8, Jenkins
>Reporter: Axel Fontaine
>Priority: Major
>
> When running single threaded everything works fine. When I enable -T2 the 
> resource plugin fails to create the output directory of the second module due 
> to this NPE:
> java.lang.NullPointerException
>   at 
> org.apache.maven.execution.MavenSession.getPluginContext(MavenSession.java:195)
>   at 
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:561)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   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.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
>   at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5857) Arguments from command line should override those in .mvn/maven.config

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5857:
--
Description: Because of the way the command line args are added at the 
*start* of the list here: 
[MavenCli#410|https://gitbox.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java;h=4d142ee4c9a7f4f1c6311fcc87aacb59ba14fc23;hb=HEAD#l410],
 they get overwritten by the settings in .mvn/maven.config. I would have 
thought this should be the other way round.  (was: Because of the way the 
command line args are added at the *start* of the list here: 
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java;h=034cb004a1f431089de5c66aab15ddbf5b784c30;hb=HEAD#l403,
 they get overwritten by the settings in .mvn/maven.config. I would have 
thought this should be the other way round.)

> Arguments from command line should override those in .mvn/maven.config
> --
>
> Key: MNG-5857
> URL: https://issues.apache.org/jira/browse/MNG-5857
> Project: Maven
>  Issue Type: Bug
>Reporter: Dave Syer
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> Because of the way the command line args are added at the *start* of the list 
> here: 
> [MavenCli#410|https://gitbox.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java;h=4d142ee4c9a7f4f1c6311fcc87aacb59ba14fc23;hb=HEAD#l410],
>  they get overwritten by the settings in .mvn/maven.config. I would have 
> thought this should be the other way round.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-5847) Maven controls java.library.path

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-5847.
-
Resolution: Auto Closed

> Maven controls java.library.path
> 
>
> Key: MNG-5847
> URL: https://issues.apache.org/jira/browse/MNG-5847
> Project: Maven
>  Issue Type: Wish
>Reporter: Markus Karg
>Priority: Major
>  Labels: dill, jni, lib, native, so
>
> We have many Java projects that are dependent of other Java projects which 
> make use of JNI. Hence, when we do "mvn test" in our project, we fail 
> frequently as the native part of the dependency is missing, even if we 
> declare the native part as an explicit dependency. There are several ideas 
> how to solve that, but non of them is complete or sufficient.
> The solution users expect would look like this:
> * MyProject has one dependency to OtherProject of * (asterisk 
> means: Maven selects best fit).
> * OtherProject offers many different packages, e. g. win-x86-dll, 
> win-x64-dll, linux-so-64, etc.
> * When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
> dependency's coordinates, and select that package that is the best fit for 
> the current execution enviroment. For example, it select "win-x86-dll" when 
> run on Windows (32 Bit), or selects "linux-so-64" when run on Linux (64 Bit) 
> etc. This mechanism should be extensible by future extension plugin, so a 
> third party vendor can simply provide addtional mappings via Maven Central.
> * Just as Maven does a configuration of the ClassPath from all JAR 
> dependencies, it now will now do a configuration of all native dependencies. 
> That means, it copies the selected native dependencies to target/dependencies 
> and builds a synthetic java.library.path system property.
> * As a result, adding a native dependency will work on any platform without 
> any complex pom.xml tweaks.
> * The solution shall not be a Java-only solution, but it shall work with any 
> kind of toolset. So a toolset plugin shall be able to utilize the core 
> mechanism and adapt it to its own needs, which includes for example the fact 
> that setting java.library.path is job of the Java Toolset Plugin, while 
> providing a similar lookup mechanism is job a hypothetical different Toolset 
> Plugin.
> We would really beg the Maven team to provide such a solution, as JNI is an 
> integral part of Java for really long time, and we have this problem every 
> other day.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5857) Arguments from command line should override those in .mvn/maven.config

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5857:
--
Fix Version/s: 3.x / Backlog

> Arguments from command line should override those in .mvn/maven.config
> --
>
> Key: MNG-5857
> URL: https://issues.apache.org/jira/browse/MNG-5857
> Project: Maven
>  Issue Type: Bug
>Reporter: Dave Syer
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> Because of the way the command line args are added at the *start* of the list 
> here: 
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java;h=034cb004a1f431089de5c66aab15ddbf5b784c30;hb=HEAD#l403,
>  they get overwritten by the settings in .mvn/maven.config. I would have 
> thought this should be the other way round.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5356) Make encrypt/decrypt logic pluggable

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5356:
--
Fix Version/s: 3.x / Backlog

> Make encrypt/decrypt logic pluggable
> 
>
> Key: MNG-5356
> URL: https://issues.apache.org/jira/browse/MNG-5356
> Project: Maven
>  Issue Type: Improvement
> Environment: n/a
>Reporter: Anders Hammar
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> It would be good if Maven Core facilitated the encryption (and decryption) 
> logic to be replaceable. Today's solution is very much hard-coded to the 
> plexus logic.
> This would make it possible for enterprise environments to re-use existing 
> solutions, like for eg smart cards, for this. The default should be the 
> current implementation though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5847) Maven controls java.library.path

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-5847:
---

This issue has been auto closed because it has been inactive for a long period 
of time. If you think this issue still applies, retest your problem with the 
most recent version of Maven and the affected component, reopen and post your 
complete example with results.

> Maven controls java.library.path
> 
>
> Key: MNG-5847
> URL: https://issues.apache.org/jira/browse/MNG-5847
> Project: Maven
>  Issue Type: Wish
>Reporter: Markus Karg
>Priority: Major
>  Labels: dill, jni, lib, native, so
>
> We have many Java projects that are dependent of other Java projects which 
> make use of JNI. Hence, when we do "mvn test" in our project, we fail 
> frequently as the native part of the dependency is missing, even if we 
> declare the native part as an explicit dependency. There are several ideas 
> how to solve that, but non of them is complete or sufficient.
> The solution users expect would look like this:
> * MyProject has one dependency to OtherProject of * (asterisk 
> means: Maven selects best fit).
> * OtherProject offers many different packages, e. g. win-x86-dll, 
> win-x64-dll, linux-so-64, etc.
> * When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
> dependency's coordinates, and select that package that is the best fit for 
> the current execution enviroment. For example, it select "win-x86-dll" when 
> run on Windows (32 Bit), or selects "linux-so-64" when run on Linux (64 Bit) 
> etc. This mechanism should be extensible by future extension plugin, so a 
> third party vendor can simply provide addtional mappings via Maven Central.
> * Just as Maven does a configuration of the ClassPath from all JAR 
> dependencies, it now will now do a configuration of all native dependencies. 
> That means, it copies the selected native dependencies to target/dependencies 
> and builds a synthetic java.library.path system property.
> * As a result, adding a native dependency will work on any platform without 
> any complex pom.xml tweaks.
> * The solution shall not be a Java-only solution, but it shall work with any 
> kind of toolset. So a toolset plugin shall be able to utilize the core 
> mechanism and adapt it to its own needs, which includes for example the fact 
> that setting java.library.path is job of the Java Toolset Plugin, while 
> providing a similar lookup mechanism is job a hypothetical different Toolset 
> Plugin.
> We would really beg the Maven team to provide such a solution, as JNI is an 
> integral part of Java for really long time, and we have this problem every 
> other day.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (MNG-5356) Make encrypt/decrypt logic pluggable

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz reopened MNG-5356:
---
  Assignee: (was: Anders Hammar)

> Make encrypt/decrypt logic pluggable
> 
>
> Key: MNG-5356
> URL: https://issues.apache.org/jira/browse/MNG-5356
> Project: Maven
>  Issue Type: Improvement
> Environment: n/a
>Reporter: Anders Hammar
>Priority: Major
>
> It would be good if Maven Core facilitated the encryption (and decryption) 
> logic to be replaceable. Today's solution is very much hard-coded to the 
> plexus logic.
> This would make it possible for enterprise environments to re-use existing 
> solutions, like for eg smart cards, for this. The default should be the 
> current implementation though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5838) Maven on No-File-Lock Systems

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-5838:
---

We have calls to lock() also in maven_-resolver-_impl in 
_org.eclipse.aether.internal.impl.TrackingFileManager#lock_

> Maven on No-File-Lock Systems
> -
>
> Key: MNG-5838
> URL: https://issues.apache.org/jira/browse/MNG-5838
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Dylan Hutchison
>Priority: Major
>
> I work on a Lustre file system that does not support file locking.  Maven 
> emits tons of warnings when it cannot lock a file due to IOExceptions.  In my 
> case this is not a problem because I only run one maven process at a time and 
> the .m2 directory inside my home directory is not shared, so there is no need 
> to lock files.
> Maven built correctly despite the warnings when using Maven 3.2.3. Then, when 
> I upgraded to Maven 3.3.3, Maven failed on most goals, even clean.  I'd like 
> to at least compile my code with mvn on this system with no file locking, 
> even if it can't run project tests.
> I uploaded log files for running with 3.2.3 and 3.3.3 here:
> 
> Scroll down halfway for the second file.
> Is there an option to disable file locking?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5750) Sporadic failures in concurrent build

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5750:
--
Fix Version/s: 3.x / Backlog

> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle 
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Priority: Critical
> Fix For: 3.x / Backlog
>
>
> We have a large project of 300+ modules which regularly fails with different 
> kind of errors in different places. The issue is reliably reproduced with 
> parallel build and is not happens in single threaded. The optimal concurrency 
> level for our project ~10 threads. At this level ~%20 of builds fail. To 
> workaround the issue we reduced concurrency to 4 in development builds and 
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points 
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all 
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package 
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package 
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static 
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package 
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static 
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly 
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in 
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly 
> to trace this down. Unfortunately i cannot submit my project - it is 
> proprietary.
> Thanks in advance, Alexander



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5960) MojoExecutor overriding resolved artifacts of concurrently built MavenProject

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5960:
--
Fix Version/s: 3.x / Backlog

> MojoExecutor overriding resolved artifacts of concurrently built MavenProject
> -
>
> Key: MNG-5960
> URL: https://issues.apache.org/jira/browse/MNG-5960
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.3.9, needing-scrub-3.4.0-fallout
> Environment: Linux 4.2.0-23-generic #28-Ubuntu SMP Sun Dec 27 
> 17:47:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> (Ubuntu 15.10)
> Maven 3.3.9/3.4.0-SNAPSHOT
>Reporter: Fabian van der Veen
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> I have found an issue with respect to the {{MojoExecutor}} in {{maven-core}} 
> when building with multiple threads (e.g. {{-T1C}}).
> I have created a small reproduction project here: 
> https://github.com/fvanderveen/maven-mojo-jojo (in the readme is some more 
> explanation of what I found to be the problem)
> The reproduction, using the above code:
> 1. Clone this repository (`git clone 
> https://github.com/fvanderveen/maven-mojo-jojo.git`)
> 2. Make sure the clone works single-threaded: `mvn clean package`. (This 
> should succeed)
> 3. Clean the workspace (`mvn clean`)
> 4. Attempt multi-threaded compilation with at least 2 threads (`mvn package 
> -T2`)
> Boiled down, it seems like the {{MojoExecutor#ensureDependenciesAreResolved}} 
> will cause an invocation to 
> {{LifecycleDependencyResolver#resolveProjectDependencies}} for _all_ projects 
> in the current {{MavenSession}} if it's configuring a plugin that defines 
> {{@Mojo(aggregator = true)}} and 
> {{DependencyContext#isResolutionRequiredForAggregatedProjects}} return true.
> This resolving may, if triggered at an unfortunate time, override resolved 
> artifacts for projects that are being built concurrently.
> In our case, a {{test-compile}} execution of the {{maven-compiler-plugin}} 
> was just configured (setting the resolved artifacts to the test-scope 
> artifacts), and right before its execution, the resolved artifacts got set 
> back to the compile-scope artifacts due to a aggregator plugin being 
> configured at around the same time.
> Given the way the `ensureDependenciesAreResolved` is structured and what 
> aggregator plugins should do/depend on, I think it would make more sense to 
> _only_ invoke {{LifecycleDependencyResolver#resolveProjectDependencies}} for 
> the modules that are a (grand-)child of the current project.
> I've created a maven extension (which can be placed in lib/ext) as a 
> temporary workaround using said change; which may be found here if any one 
> else is having the same problems: 
> https://github.com/fvanderveen/maven-non-destructive-mojo-executor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5626) Avoid negative durations or handle them correctly

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5626:
--
Fix Version/s: Issues to be reviewed for 4.x

> Avoid negative durations or handle them correctly
> -
>
> Key: MNG-5626
> URL: https://issues.apache.org/jira/browse/MNG-5626
> Project: Maven
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 3.2.1
>Reporter: Christian Jung
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
>
> In issue MNG-5623 we reported an exception when printing the reactor summary 
> if one of the times was negative.
> I saw in one case, that the overall maven build time, as measured from 
> outside (i.e. by our QuickBuild system) was -10.8 seconds. The corresponding 
> reactor summary was:
> {code}
> 13:55:25,184 INFO  - Reactor Summary:
> 13:55:25,184 INFO  -
> 13:55:25,184 INFO  - module1 ... 
> SUCCESS [ 5.911 s]
> 13:55:25,184 INFO  - module2 ... 
> SUCCESS [ 0.255 s]
> 13:55:25,184 INFO  - gpPlaygroundBase-lnx-x64-gcc4 . 
> SUCCESS [-27.-64 s]
> 13:55:25,185 INFO  - 
> 
> 13:55:25,185 INFO  - BUILD SUCCESS
> 13:55:25,185 INFO  - 
> 
> 13:55:25,185 INFO  - Total time: -20.-73 s
> 13:55:25,185 INFO  - Finished at: 2014-04-28T13:55:25+01:00
> 13:55:25,572 INFO  - Final Memory: 32M/439M
> 13:55:25,572 INFO  - 
> 
> {code}
> The thing is quite hard to reproduce, the machines were virtual machines that 
> have been running for quite a long time.
> Our administrators suspected that just at this point, the local clock was 
> synchronized with some outer source.
> We should check if such negative durations can be avoided, and if not, they 
> should be handled correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-6218) Jansi 1.13 does not recognize MinGW bash

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-6218.
-
   Resolution: Auto Closed
Fix Version/s: (was: waiting-for-feedback)

In Maven 3.6.0 we use JAnsi 1.17. 1 - please reopen the issue if the described 
problem still exists.

> Jansi 1.13 does not recognize MinGW bash
> 
>
> Key: MNG-6218
> URL: https://issues.apache.org/jira/browse/MNG-6218
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows Git Bash(MinGW)
>Reporter: Daniel Heinrich
>Priority: Minor
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Jansi checks if the platform is Windows to decide if coloring needs to be 
> handled differently. In the case that MinGW is detected it will handle 
> coloring as if it was running on Unix.
> The test in Jansi 1.13 is if the enviroment variable TERM == "xterm", but 
> MinGW returns "xterm-256color".
> Since Jansi 1.14 it checks if TERM starts with "xterm".
> see: 
> https://github.com/fusesource/jansi/blob/jansi-project-1.14/jansi/src/main/java/org/fusesource/jansi/AnsiConsole.java#L123
> An upgrade to Jansi 1.14 or even 1.15 fixes this issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6225) Application cannot output ANSI colors when run by Maven

[Gili (JIRA)]

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

Gili commented on MNG-6225:
---

Here is the follow-up issue for Surefire: SUREFIRE-1371

> Application cannot output ANSI colors when run by Maven
> ---
>
> Key: MNG-6225
> URL: https://issues.apache.org/jira/browse/MNG-6225
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line, core
>Affects Versions: 3.5.0
>Reporter: Gili
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> I'm not sure which Maven component this bug report belongs to (please 
> reassign if needed).
> This is a follow-up to https://issues.apache.org/jira/browse/SUREFIRE-1369
> To recap: someone (probably Maven core) is redirecting the native stdout 
> handle when running plugins such as Surefire. This prevents applications from 
> outputting ANSI colors under Windows 10 because:
> * Applications must explicitly enable ANSI support using JNI.
> * The JNI calls fail if the stdout handle has been redirected.
> If I run the exact same application outside of Maven, JNI no longer detects 
> that stdout has been redirected and ANSI colors as expected.
> Any idea who is doing the redirection, and how to disable it?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6225) Application cannot output ANSI colors when run by Maven

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6225:
--
Fix Version/s: 3.x / Backlog

> Application cannot output ANSI colors when run by Maven
> ---
>
> Key: MNG-6225
> URL: https://issues.apache.org/jira/browse/MNG-6225
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line, core
>Affects Versions: 3.5.0
>Reporter: Gili
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> I'm not sure which Maven component this bug report belongs to (please 
> reassign if needed).
> This is a follow-up to https://issues.apache.org/jira/browse/SUREFIRE-1369
> To recap: someone (probably Maven core) is redirecting the native stdout 
> handle when running plugins such as Surefire. This prevents applications from 
> outputting ANSI colors under Windows 10 because:
> * Applications must explicitly enable ANSI support using JNI.
> * The JNI calls fail if the stdout handle has been redirected.
> If I run the exact same application outside of Maven, JNI no longer detects 
> that stdout has been redirected and ANSI colors as expected.
> Any idea who is doing the redirection, and how to disable it?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6239) jansi messes up System.err and System.out

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-6239:
---

One more place with output bufferig is in logging. Please try to set 
_org.slf4j.simpleLogger.*cacheOutputStream=false*_ in 
_conf/logging/simplelogger.properties_

> jansi messes up System.err and System.out
> -
>
> Key: MNG-6239
> URL: https://issues.apache.org/jira/browse/MNG-6239
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.5.0
> Environment: Java 1.8.0_131, Ubuntu 17.04
>Reporter: Simone Bordet
>Priority: Minor
> Attachments: mvn-jansi.tgz
>
>
> I use the Maven Exec Plugin to run a class that asks for interactive input 
> from the user. This was working in 3.3.9, but does not work in 3.5.0.
> Anything printed on {{System.err}} or {{System.out}} without a newline is not 
> printed immediately on the terminal window.
> Example:
> {code:java}
> BufferedReader console = new BufferedReader(new InputStreamReader(System.in));
> System.err.printf("listen port: ");
> String value = console.readLine().trim();
> {code}
> The example above would not print {{listen port:}} on the terminal.
> Attached you can find a project that reproduces this issue.
> Unpack the project and then run:
> {noformat}
> $ mvn install && mvn exec:exec
> {noformat}
> The expected output of the reproducer would be:
> {noformat}
> err.println
> out.println
> err.printerr.printfout.printout.printf
> {noformat}
> instead I get:
> {noformat}
> err.println
> out.println
> {noformat}
> Removing {{jansi-1.13.jar}} from {{$MAVEN/lib/}} fixes the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6262) getCanonicalFile() is not used consistently during project resolution

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-6262:
---

This problem should be fixed in MNG-6261 and will be included in Maven 3.6.1. 
If You have time, please verify version compiled from our master.

> getCanonicalFile() is not used consistently during project resolution
> -
>
> Key: MNG-6262
> URL: https://issues.apache.org/jira/browse/MNG-6262
> Project: Maven
>  Issue Type: Bug
>  Components: core, Reactor and workspace
>Affects Versions: 3.0-alpha-1, 3.5.0
> Environment: Windows 7
>Reporter: Gene Smith
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.x-candidate
>
> Attachments: test-inconsistent-canonicalization.zip
>
>
> This bug manifests with...
>  * maven 3.5.0 *AND WITH* maven built from 3.5.1's unreleased sources
>  * on Windows 7 when the "Drive Letter" is configured with the wrong case.
>  * in projects which descend from a pom which does not reference them.
> On Windows getCanonicalFile() is used on module File objects before they
> are wrapped in a FileSource and cached. But DefaultModelBuilder compares
> its cache hits against a File which has not been made cananonical.
> Normally it does not matter on Windows, because the lack of symbolic links
> makes it difficult to find an "Absolute File" which is not the same as its
> "Canonical File", but there is at least one use case it happens in...
> If invoking scripts use a "lower case drive letter" (ex: c:\, d:\, etc...)
> then the "Canonical File" has an "upper case drive letter".
> The error only seems to occur if a POM references a parent which does not list
> the referencing POM as a child. In other words, when there is POM inheritance
> without a reactor module relationship. In my use case there is a Dependency
> Management POM which does not reference all the modules which list it as their
> parent.
> A simple work around is...
> Make sure all your Windows Environments have capital drive letters in the
> Jenkins node configuration, and scripting.
> ..
> {noformat}
> Testing from sources:
> https://git-wip-us.apache.org/repos/asf/maven.git
> origin/master
> b10025751 (HEAD -> master, origin/master, origin/MNG-5457_2, 
> origin/HEAD) [MNG-5457] Show repository id when downloading or uploading 
> from/to a remote repository
> https://git-wip-us.apache.org/repos/asf/maven-resolver.git
> origin/master
> c9212232 (HEAD -> master, origin/master, origin/HEAD) 
> [maven-release-plugin] prepare for next development iteration
> {noformat}
> I found {{DefaultModelBuilder}} compares a POM's Non-Canonical File's URI 
> against a
> cached Model's POM's Canonical File's URI.
> {code:java}
> org.apache.maven.model.building.DefaultModelBuilder
> File pomFile = parentData.getModel().getPomFile();
> if ( pomFile != null )
> {
> ModelSource expectedParentSource = getParentPomFile( childModel, 
> childSource );
> if ( expectedParentSource instanceof ModelSource2
> && !pomFile.toURI().equals( ( (ModelSource2) 
> expectedParentSource ).getLocationURI() ) )
> {
> parentData = readParentExternally( childModel, request, 
> problems );
> }
> }
> {code}
> Where {{ModelSource2}} is a {{org.apache.maven.building.FileSource}} which 
> has been
> made from a canonical file.
> In my test environment it composed and compared these two URIs for
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and found they did not match:
>  
> [file:/C:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
>  
> [file:/c:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
> resulting in this error output:
> {noformat}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for 
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find 
> artifact 
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT 
> and 'parent.relativePath' points at wrong local POM @ 
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT, 
> C:\Jenkins\workspace\test\reactor\pom.xml, line 5, column 11
>  @ 
> [ERROR] The build could not read 1 project -> [Help 1]
> org.apache.maven.project.ProjectBuildingException: Some problems were 
> encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for 
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find 
> artifact 
> 

[jira] [Updated] (MNG-6262) getCanonicalFile() is not used consistently during project resolution

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6262:
--
Fix Version/s: (was: 3.x / Backlog)
   3.6.x-candidate

> getCanonicalFile() is not used consistently during project resolution
> -
>
> Key: MNG-6262
> URL: https://issues.apache.org/jira/browse/MNG-6262
> Project: Maven
>  Issue Type: Bug
>  Components: core, Reactor and workspace
>Affects Versions: 3.0-alpha-1, 3.5.0
> Environment: Windows 7
>Reporter: Gene Smith
>Priority: Minor
> Fix For: 3.6.x-candidate
>
> Attachments: test-inconsistent-canonicalization.zip
>
>
> This bug manifests with...
>  * maven 3.5.0 *AND WITH* maven built from 3.5.1's unreleased sources
>  * on Windows 7 when the "Drive Letter" is configured with the wrong case.
>  * in projects which descend from a pom which does not reference them.
> On Windows getCanonicalFile() is used on module File objects before they
> are wrapped in a FileSource and cached. But DefaultModelBuilder compares
> its cache hits against a File which has not been made cananonical.
> Normally it does not matter on Windows, because the lack of symbolic links
> makes it difficult to find an "Absolute File" which is not the same as its
> "Canonical File", but there is at least one use case it happens in...
> If invoking scripts use a "lower case drive letter" (ex: c:\, d:\, etc...)
> then the "Canonical File" has an "upper case drive letter".
> The error only seems to occur if a POM references a parent which does not list
> the referencing POM as a child. In other words, when there is POM inheritance
> without a reactor module relationship. In my use case there is a Dependency
> Management POM which does not reference all the modules which list it as their
> parent.
> A simple work around is...
> Make sure all your Windows Environments have capital drive letters in the
> Jenkins node configuration, and scripting.
> ..
> {noformat}
> Testing from sources:
> https://git-wip-us.apache.org/repos/asf/maven.git
> origin/master
> b10025751 (HEAD -> master, origin/master, origin/MNG-5457_2, 
> origin/HEAD) [MNG-5457] Show repository id when downloading or uploading 
> from/to a remote repository
> https://git-wip-us.apache.org/repos/asf/maven-resolver.git
> origin/master
> c9212232 (HEAD -> master, origin/master, origin/HEAD) 
> [maven-release-plugin] prepare for next development iteration
> {noformat}
> I found {{DefaultModelBuilder}} compares a POM's Non-Canonical File's URI 
> against a
> cached Model's POM's Canonical File's URI.
> {code:java}
> org.apache.maven.model.building.DefaultModelBuilder
> File pomFile = parentData.getModel().getPomFile();
> if ( pomFile != null )
> {
> ModelSource expectedParentSource = getParentPomFile( childModel, 
> childSource );
> if ( expectedParentSource instanceof ModelSource2
> && !pomFile.toURI().equals( ( (ModelSource2) 
> expectedParentSource ).getLocationURI() ) )
> {
> parentData = readParentExternally( childModel, request, 
> problems );
> }
> }
> {code}
> Where {{ModelSource2}} is a {{org.apache.maven.building.FileSource}} which 
> has been
> made from a canonical file.
> In my test environment it composed and compared these two URIs for
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and found they did not match:
>  
> [file:/C:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
>  
> [file:/c:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
> resulting in this error output:
> {noformat}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for 
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find 
> artifact 
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT 
> and 'parent.relativePath' points at wrong local POM @ 
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT, 
> C:\Jenkins\workspace\test\reactor\pom.xml, line 5, column 11
>  @ 
> [ERROR] The build could not read 1 project -> [Help 1]
> org.apache.maven.project.ProjectBuildingException: Some problems were 
> encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for 
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find 
> artifact 
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT 
> and 'parent.relativePath' points at wrong local POM @ 
> 

[jira] [Assigned] (MNG-6262) getCanonicalFile() is not used consistently during project resolution

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz reassigned MNG-6262:
-

Assignee: Sylwester Lachiewicz

> getCanonicalFile() is not used consistently during project resolution
> -
>
> Key: MNG-6262
> URL: https://issues.apache.org/jira/browse/MNG-6262
> Project: Maven
>  Issue Type: Bug
>  Components: core, Reactor and workspace
>Affects Versions: 3.0-alpha-1, 3.5.0
> Environment: Windows 7
>Reporter: Gene Smith
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.x-candidate
>
> Attachments: test-inconsistent-canonicalization.zip
>
>
> This bug manifests with...
>  * maven 3.5.0 *AND WITH* maven built from 3.5.1's unreleased sources
>  * on Windows 7 when the "Drive Letter" is configured with the wrong case.
>  * in projects which descend from a pom which does not reference them.
> On Windows getCanonicalFile() is used on module File objects before they
> are wrapped in a FileSource and cached. But DefaultModelBuilder compares
> its cache hits against a File which has not been made cananonical.
> Normally it does not matter on Windows, because the lack of symbolic links
> makes it difficult to find an "Absolute File" which is not the same as its
> "Canonical File", but there is at least one use case it happens in...
> If invoking scripts use a "lower case drive letter" (ex: c:\, d:\, etc...)
> then the "Canonical File" has an "upper case drive letter".
> The error only seems to occur if a POM references a parent which does not list
> the referencing POM as a child. In other words, when there is POM inheritance
> without a reactor module relationship. In my use case there is a Dependency
> Management POM which does not reference all the modules which list it as their
> parent.
> A simple work around is...
> Make sure all your Windows Environments have capital drive letters in the
> Jenkins node configuration, and scripting.
> ..
> {noformat}
> Testing from sources:
> https://git-wip-us.apache.org/repos/asf/maven.git
> origin/master
> b10025751 (HEAD -> master, origin/master, origin/MNG-5457_2, 
> origin/HEAD) [MNG-5457] Show repository id when downloading or uploading 
> from/to a remote repository
> https://git-wip-us.apache.org/repos/asf/maven-resolver.git
> origin/master
> c9212232 (HEAD -> master, origin/master, origin/HEAD) 
> [maven-release-plugin] prepare for next development iteration
> {noformat}
> I found {{DefaultModelBuilder}} compares a POM's Non-Canonical File's URI 
> against a
> cached Model's POM's Canonical File's URI.
> {code:java}
> org.apache.maven.model.building.DefaultModelBuilder
> File pomFile = parentData.getModel().getPomFile();
> if ( pomFile != null )
> {
> ModelSource expectedParentSource = getParentPomFile( childModel, 
> childSource );
> if ( expectedParentSource instanceof ModelSource2
> && !pomFile.toURI().equals( ( (ModelSource2) 
> expectedParentSource ).getLocationURI() ) )
> {
> parentData = readParentExternally( childModel, request, 
> problems );
> }
> }
> {code}
> Where {{ModelSource2}} is a {{org.apache.maven.building.FileSource}} which 
> has been
> made from a canonical file.
> In my test environment it composed and compared these two URIs for
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and found they did not match:
>  
> [file:/C:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
>  
> [file:/c:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
> resulting in this error output:
> {noformat}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for 
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find 
> artifact 
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT 
> and 'parent.relativePath' points at wrong local POM @ 
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT, 
> C:\Jenkins\workspace\test\reactor\pom.xml, line 5, column 11
>  @ 
> [ERROR] The build could not read 1 project -> [Help 1]
> org.apache.maven.project.ProjectBuildingException: Some problems were 
> encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for 
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find 
> artifact 
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT 
> and 'parent.relativePath' points at wrong local POM @ 
> 

[jira] [Updated] (MNG-6268) When a reactor build fails Maven should include -f (if used) in command line suggestion

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6268:
--
Fix Version/s: 3.6.x-candidate

> When a reactor build fails Maven should include -f (if used) in command line 
> suggestion
> ---
>
> Key: MNG-6268
> URL: https://issues.apache.org/jira/browse/MNG-6268
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Andreas Sewe
>Priority: Trivial
> Fix For: 3.6.x-candidate
>
>
> When a reactor build fails, Maven prints out a helpful suggestion on how to 
> resume.
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :example
> {noformat}
> Unfortunately, when running {{mvn}} with {{-f}}, this suggestion is wrong; 
> Maven will either pick the wrong {{pom.xml}} or simply won’t find any; in 
> either case, the {{pom.xml}} specified with {{-f}} is *crucial* information 
> that was left out of the suggestion.
> FYI, this is related to MNG-6028, but covers a different bit of info that 
> IMHO should be part of the suggestion. Hence this separate issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-6313) Update dependences and default plugins to latest version

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-6313.
-
Resolution: Won't Fix

> Update dependences and default plugins to latest version
> 
>
> Key: MNG-6313
> URL: https://issues.apache.org/jira/browse/MNG-6313
> Project: Maven
>  Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Priority: Minor
>
> Still on Java 7
> default-bindings.xml
> maven-install-plugin 2.4 -> 2.5.2 (2014)
> maven-deploy-plugin 2.7 -> 2.8.2 (2014)
> *maven-resources-plugin* 2.6 -> 3.0.2 (2016)
> maven-compiler-plugin 3.1 -> 3.7 (?) (2017)
> maven-surefire-plugin 2.12.4 -> 2.20.1 (?) (2017)
> *maven-jar-plugin* 2.4 -> 3.0.2 (2017)
> *maven-war-plugin* 2.2 -> 3.2 (2017)
> Update
> parent-pom 27 -> 30 to aligh with other maven projects
> maven-shared-utils to 3.1 -> 3.2
> commons-lang 3.5 -> 3.6
> guice 4.0 -> 4.1 (?)
> commons-io -> 2.6
> logback-classic 1.2.1 -> 1.2.3
> Plugins - internal use (maybe some update to parent-pom)
> maven-release-plugin 2.5.3
> maven-surefire-plugin 2.20.1 (more colors) ;-)
> maven-bundle-plugin 2.5.4
> maven-site-plugin 3.6
> apache-rat-plugin 0.12
> findbugs-maven-plugin 3.0.5
> maven-assembly-plugin 3.0 -> 3.1
> maven-jxr-plugin 2.5
> maven-jar-plugin 3.0.2
> maven-compiler-plugin 3.7
> animal-sniffer-maven-plugin 1.15 -> 1.16
> Will be good to know which plugins must be migrated to 3.x line 
> i.e. add link to maven webpage for dev to 
> [Wiki|https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-5315) Artifact resolution sporadically fails in parallel builds

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-5315.
-
   Resolution: Auto Closed
Fix Version/s: (was: Issues to be reviewed for 4.x)

Close because it is no longer seen by users with the latest Maven versions.

> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://issues.apache.org/jira/browse/MNG-5315
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan Dubrov
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded 
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same 
> artifact concurrently. This problem never happens once I have all 
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading: 
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
>  12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2, 
> already updated during this session.
> [DEBUG] Skipped remote update check for 
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this 
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4, 
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4, 
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve 
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The 
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2, 
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, 
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to 
> find commons-cli:commons-cli:jar:1.2 in 
> http://nexus/content/repositories/thirdparty was cached in the local 
> repository, resolution will not be reattempted until the update interval of 
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal on project util: Could not resolve dependencies for project 
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not 
> be resolved: commons-cli:commons-cli:jar:1.2, 
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, 
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to 
> find commons-cli:commons-cli:jar:1.2 in 
> http://nexus/content/repositories/thirdparty was cached in the local 
> repository, resolution will not be reattempted until the update interval of 
> gw.thirdparty has elapsed or updates are forced
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at 
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at 
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at 

[jira] [Updated] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5222:
--
Fix Version/s: 3.x / Backlog

> Maven 3 no longer logs warnings about deprecated plugin parameters.
> ---
>
> Key: MNG-5222
> URL: https://issues.apache.org/jira/browse/MNG-5222
> Project: Maven
>  Issue Type: Wish
>  Components: Plugins and Lifecycle
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: 3.x / Backlog
>
>
> Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log 
> a warning. Currently Maven 3 does not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6069) Migrate to non deprecated parts of Commons CLI

[Hudson (JIRA)]

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

Hudson commented on MNG-6069:
-

Build succeeded in Jenkins: Maven TLP » maven » master #137

See https://builds.apache.org/job/maven-box/job/maven/job/master/137/

> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
>  Issue Type: Improvement
>  Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in 
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information" 
> ).build()
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-4537) --update-snapshots command line option flag is misleading, as it actually updates releases too

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-4537.
-
   Resolution: Auto Closed
Fix Version/s: (was: Issues to be reviewed for 3.x)

> --update-snapshots command line option flag is misleading, as it actually 
> updates releases too
> --
>
> Key: MNG-4537
> URL: https://issues.apache.org/jira/browse/MNG-4537
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 2.0.9, 2.0.10, 2.2.1, 3.0-alpha-5, 3.0-alpha-6
>Reporter: Matthew McCullough
>Priority: Major
> Attachments: remove-misleading-updatesnapshots-option.patch
>
>
> Had a discussion with Brett Porter, Brian Fox, and Benjamin Bentmann on IRC 
> about how the --update-snapshots command line option is misleading.  I, as 
> well as some of my students, we using -up, expecting downloads that 
> previously failed to be tried again.  However, that flag only checks for 
> metadata updates to see if a newer version of the plugin has been released.  
> What we were after is the -U flag (synonymous with --update-snapshots) which 
> also checks again remotely for SNAPSHOT and RELEASE downloads that previously 
> failed.
> Brett and Brian suggested that we either deprecate the old --update-snapshots 
> long option, but that's not entirely possible since the short and long 
> options are tied together.  So, as a compromise solution, I'm indicating that 
> the --update-snapshots option flag (name) may go away in the future and 
> adding a migrate-to option called --update-all which was suggested in the 
> above IRC conversation.  Functionally, this long flag performs the same 
> operation as --update-snapshots, but the name much more effectively 
> communicates that it updates all artifacts from remote repos, not just 
> snapshots.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6558) ToolchainsBuildingResult event is not sent on EventSpy

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-6558:
---

+1 to merge

> ToolchainsBuildingResult event is not sent on EventSpy
> --
>
> Key: MNG-6558
> URL: https://issues.apache.org/jira/browse/MNG-6558
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Guy Brand
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On the {{EventSpy}} we get the {{ToolchainsBuildingRequest}} event twice and 
> the {{ToolchainsBuildingResult}} is not sent. The problem is 
> [here|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1268]
>  where the {{ToolchainsBuildingRequest}} event is sent twice to the 
> {{eventSpyDispatcher}} instead of the {{ToolchainsBuildingResult}} event.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-6069) Migrate to non deprecated parts of Commons CLI

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz closed MNG-6069.
-
Resolution: Fixed

> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
>  Issue Type: Improvement
>  Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in 
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information" 
> ).build()
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6069) Migrate to non deprecated parts of Commons CLI

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-6069:
---

Done in 
[396291bba06073603c5c6d637bd4964873bfdc70|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=396291bba06073603c5c6d637bd4964873bfdc70]

> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
>  Issue Type: Improvement
>  Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in 
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information" 
> ).build()
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] slachiewicz closed pull request #153: [MNG-6069] Migrate to non deprecated parts of Commons CLI

[GitBox]

slachiewicz closed pull request #153: [MNG-6069] Migrate to non deprecated 
parts of Commons CLI
URL: https://github.com/apache/maven/pull/153
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff has been
sent to your commit mailing list, comm...@maven.apache.org

 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Updated] (MNG-6522) Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6522:
--
Fix Version/s: (was: 3.6.1)
   3.6.x-candidate

> Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea
> --
>
> Key: MNG-6522
> URL: https://issues.apache.org/jira/browse/MNG-6522
> Project: Maven
>  Issue Type: Improvement
>  Components: Integration Tests
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> * JDK 12 Windows and Linux (/)
>  - JDK 13 in progress



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6294) Convert MavenPluginValidator into a plexus component

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6294:
--
Fix Version/s: (was: 3.6.1)
   3.6.x-candidate

> Convert MavenPluginValidator into a plexus component
> 
>
> Key: MNG-6294
> URL: https://issues.apache.org/jira/browse/MNG-6294
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Reporter: Michael Simacek
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> [XMvn|https://github.com/fedora-java/xmvn] is a maven extension that helps 
> with creating RPM packages. In order to comply with packaging requirements, 
> it needs to relax some checks that maven does. One of those is plugin 
> validation done in MavenPluginValidator class. Currently, it overrides that 
> by shadowing the class on the classpath, which is a hack. It would help if 
> MavenPluginValidator was a plexus component and thus the implementation could 
> be selected by configuration.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6071) GetResource ('/) returns 'null' if build is started with -f

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-6071:
--
Fix Version/s: (was: 3.6.1)
   3.6.x-candidate

> GetResource ('/) returns 'null' if build is started with -f
> ---
>
> Key: MNG-6071
> URL: https://issues.apache.org/jira/browse/MNG-6071
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.3.1, 3.3.9
> Environment: Windows 10 x64
> Tested in cmd.exe, git bash.
>Reporter: Alexander Bender
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> I set up a very simple test maven project with only a dependency to testNG.
> {code}
> public class TestTest {
> @Test
> public void test() {
> System.out.println(getClass().getResource("/"));
> {code}
> Depending on how I build this, the call either returns null or the expected 
> directory. How is that?
> {code}
> // Prints: file:/C:/workspace/test/testproject/target/test-classes/
> mvn clean test -Dtest=TestTest -f pom.xml
> // Prints: file:/C:/workspace/test/testproject/target/test-classes/
> mvn clean test -Dtest=TestTest -f testproject/pom.xml
> // Prints: null
> mvn clean test -Dtest=TestTest -f ./pom.xml
> // Prints: null
> mvn clean test -Dtest=TestTest -f ./testproject/pom.xml
> {code}
> Note that the second call includes "./" after -f.
> I actually want to find out the /target folder regardless of scenario (testNG 
> in IntelliJ, Maven, Jenkins Buid, ...). So far, this way has proven the most 
> reliable.
> {code}
> System.out.println(getClass().getResource("./"));
> {code}
> This seems to reliably point to 
> file:/C:/workspace/test/testproject/target/test-classes/com/testproject/test. 
> Would this be safer to use?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SUREFIRE-1622) failure to run tests if classpath gets too long (?)

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741629#comment-16741629
 ] 

Tibor Digana edited comment on SUREFIRE-1622 at 1/13/19 7:38 PM:
-

[~chammer2]
If you still have the files in {{target/surefire}}, try to run the same command 
in Shell script. What happens? It should hang until timeout which is right 
behavior in this case because the parent process is the script and not Maven 
process.


was (Author: tibor17):
[~chammer2]
If you still have the files in {{target/surefire}}, try to run the same command 
in Shell scrip. What happens? It should hang until timeout which is right 
behavior in this case because the parent process is the script and not Maven 
process.

> failure to run tests if classpath gets too long (?)
> ---
>
> Key: SUREFIRE-1622
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1622
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.1
> Environment: debian linux
> Linux jenkins 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
> x86_64 GNU/Linux
> Jenkins 2.157
>Reporter: Carsten Hammer
>Priority: Major
>
> We have an aggregating plugin where the classpath of a lot of different 
> projects are combined for integration tests. We now have problems since one 
> point in time with failing tests:
> {noformat}
> Please refer to /var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire-reports for the individual test 
> results.
> Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump 
> and [date].dumpstream.
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> Command was /bin/sh -c cd "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper" && 
> /var/lib/jenkins/tools/hudson.model.JDK/java8/jre/bin/java 
> -Dfile.encoding=UTF-8 org.apache.maven.surefire.booter.ForkedBooter 
> '/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire' 2019-01-08T17-09-39_970-jvmRun1 
> surefire76194600426378498tmp surefire_18239836832627501299tmp
> Error while executing forked tests.Error while executing process.Cannot run 
> program "/bin/sh" (in directory "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper"): error=7, Die Argumentliste ist zu 
> langorg.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineException:
>  Error while executing process.
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.Commandline.execute(Commandline.java:412)
>     at 
> org.apache.maven.plugin.surefire.booterclient.lazytestprovider.OutputStreamFlushableCommandline.execute(OutputStreamFlushableCommandline.java:65)
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils.executeCommandLineAsCallable(CommandLineUtils.java:229)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:609)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
>     at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>     at 
> org.jvnet.hudson.maven3.launcher.Maven35Launcher.main(Maven35Launcher.java:130)
>     at 

[jira] [Commented] (SUREFIRE-1622) failure to run tests if classpath gets too long (?)

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741627#comment-16741627
 ] 

Tibor Digana commented on SUREFIRE-1622:


[~chammer2]
javac does not come into play in the commandline 
/var/lib/jenkins/tools/hudson.model.JDK/java8/jre/bin/java
The surefire is bound with default lifecycle and all prior phases of the build 
were triggered as e.g. compiler plugin. If there is no change in sources, the 
compiler plugin does nothing.

> failure to run tests if classpath gets too long (?)
> ---
>
> Key: SUREFIRE-1622
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1622
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.1
> Environment: debian linux
> Linux jenkins 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
> x86_64 GNU/Linux
> Jenkins 2.157
>Reporter: Carsten Hammer
>Priority: Major
>
> We have an aggregating plugin where the classpath of a lot of different 
> projects are combined for integration tests. We now have problems since one 
> point in time with failing tests:
> {noformat}
> Please refer to /var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire-reports for the individual test 
> results.
> Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump 
> and [date].dumpstream.
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> Command was /bin/sh -c cd "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper" && 
> /var/lib/jenkins/tools/hudson.model.JDK/java8/jre/bin/java 
> -Dfile.encoding=UTF-8 org.apache.maven.surefire.booter.ForkedBooter 
> '/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire' 2019-01-08T17-09-39_970-jvmRun1 
> surefire76194600426378498tmp surefire_18239836832627501299tmp
> Error while executing forked tests.Error while executing process.Cannot run 
> program "/bin/sh" (in directory "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper"): error=7, Die Argumentliste ist zu 
> langorg.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineException:
>  Error while executing process.
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.Commandline.execute(Commandline.java:412)
>     at 
> org.apache.maven.plugin.surefire.booterclient.lazytestprovider.OutputStreamFlushableCommandline.execute(OutputStreamFlushableCommandline.java:65)
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils.executeCommandLineAsCallable(CommandLineUtils.java:229)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:609)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
>     at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>     at 
> org.jvnet.hudson.maven3.launcher.Maven35Launcher.main(Maven35Launcher.java:130)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:498)
>     at 

[jira] [Commented] (SUREFIRE-1622) failure to run tests if classpath gets too long (?)

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741629#comment-16741629
 ] 

Tibor Digana commented on SUREFIRE-1622:


[~chammer2]
If you still have the files in {{target/surefire}}, try to run the same command 
in Shell scrip. What happens? It should hang until timeout which is right 
behavior in this case because the parent process in the script and not Maven 
process.

> failure to run tests if classpath gets too long (?)
> ---
>
> Key: SUREFIRE-1622
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1622
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.1
> Environment: debian linux
> Linux jenkins 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
> x86_64 GNU/Linux
> Jenkins 2.157
>Reporter: Carsten Hammer
>Priority: Major
>
> We have an aggregating plugin where the classpath of a lot of different 
> projects are combined for integration tests. We now have problems since one 
> point in time with failing tests:
> {noformat}
> Please refer to /var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire-reports for the individual test 
> results.
> Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump 
> and [date].dumpstream.
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> Command was /bin/sh -c cd "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper" && 
> /var/lib/jenkins/tools/hudson.model.JDK/java8/jre/bin/java 
> -Dfile.encoding=UTF-8 org.apache.maven.surefire.booter.ForkedBooter 
> '/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire' 2019-01-08T17-09-39_970-jvmRun1 
> surefire76194600426378498tmp surefire_18239836832627501299tmp
> Error while executing forked tests.Error while executing process.Cannot run 
> program "/bin/sh" (in directory "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper"): error=7, Die Argumentliste ist zu 
> langorg.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineException:
>  Error while executing process.
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.Commandline.execute(Commandline.java:412)
>     at 
> org.apache.maven.plugin.surefire.booterclient.lazytestprovider.OutputStreamFlushableCommandline.execute(OutputStreamFlushableCommandline.java:65)
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils.executeCommandLineAsCallable(CommandLineUtils.java:229)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:609)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
>     at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>     at 
> org.jvnet.hudson.maven3.launcher.Maven35Launcher.main(Maven35Launcher.java:130)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:498)
>     at 
> 

[jira] [Comment Edited] (SUREFIRE-1622) failure to run tests if classpath gets too long (?)

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741629#comment-16741629
 ] 

Tibor Digana edited comment on SUREFIRE-1622 at 1/13/19 7:37 PM:
-

[~chammer2]
If you still have the files in {{target/surefire}}, try to run the same command 
in Shell scrip. What happens? It should hang until timeout which is right 
behavior in this case because the parent process is the script and not Maven 
process.


was (Author: tibor17):
[~chammer2]
If you still have the files in {{target/surefire}}, try to run the same command 
in Shell scrip. What happens? It should hang until timeout which is right 
behavior in this case because the parent process in the script and not Maven 
process.

> failure to run tests if classpath gets too long (?)
> ---
>
> Key: SUREFIRE-1622
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1622
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.1
> Environment: debian linux
> Linux jenkins 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
> x86_64 GNU/Linux
> Jenkins 2.157
>Reporter: Carsten Hammer
>Priority: Major
>
> We have an aggregating plugin where the classpath of a lot of different 
> projects are combined for integration tests. We now have problems since one 
> point in time with failing tests:
> {noformat}
> Please refer to /var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire-reports for the individual test 
> results.
> Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump 
> and [date].dumpstream.
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> Command was /bin/sh -c cd "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper" && 
> /var/lib/jenkins/tools/hudson.model.JDK/java8/jre/bin/java 
> -Dfile.encoding=UTF-8 org.apache.maven.surefire.booter.ForkedBooter 
> '/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire' 2019-01-08T17-09-39_970-jvmRun1 
> surefire76194600426378498tmp surefire_18239836832627501299tmp
> Error while executing forked tests.Error while executing process.Cannot run 
> program "/bin/sh" (in directory "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper"): error=7, Die Argumentliste ist zu 
> langorg.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineException:
>  Error while executing process.
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.Commandline.execute(Commandline.java:412)
>     at 
> org.apache.maven.plugin.surefire.booterclient.lazytestprovider.OutputStreamFlushableCommandline.execute(OutputStreamFlushableCommandline.java:65)
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils.executeCommandLineAsCallable(CommandLineUtils.java:229)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:609)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
>     at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>     at 
> org.jvnet.hudson.maven3.launcher.Maven35Launcher.main(Maven35Launcher.java:130)
>     at 

[jira] [Updated] (MNG-5995) Maven itself cannot run without maven-compat

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5995:
--
Fix Version/s: (was: 3.6.1)
   3.6.x-candidate

> Maven itself cannot run without maven-compat
> 
>
> Key: MNG-5995
> URL: https://issues.apache.org/jira/browse/MNG-5995
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap  Build, core
>Affects Versions: 3.3.9
>Reporter: Robert Scholte
>Assignee: Sylwester Lachiewicz
>Priority: Critical
> Fix For: 3.6.x-candidate
>
>
> For all the 3.0 versions of the maven-plugins we require to not depend on 
> maven-compat anymore. However, the Maven distribution still requires 
> maven-compat. A simple proof: remove {{lib/maven-compat-3.x.y}} and execute 
> {{mvn validate}}.
> You'll get the following exception: 
> {noformat}[WARNING] Error injecting: 
> org.apache.maven.project.DefaultProjectBuildingHelper
> com.google.inject.ProvisionException: Unable to provision, see the following 
> errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was 
> bound.
>   while locating 
> org.apache.maven.project.DefaultProjectBuildingHelper{noformat}
> Reason: there's only one implementation: o.a.m.r.l.LegacyRepositorySystem, 
> which is part of maven-compat.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5693) Change logging of MojoExceptions to console

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated MNG-5693:
--
Fix Version/s: (was: 3.6.1)
   3.6.x-candidate

> Change logging of MojoExceptions to console
> ---
>
> Key: MNG-5693
> URL: https://issues.apache.org/jira/browse/MNG-5693
> Project: Maven
>  Issue Type: Improvement
>  Components: FDPFC, Plugin API
>Reporter: Robert Scholte
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.x-candidate
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If a plugin fails for any reason, a general message is logged with a 
> reference to a wiki page, which never contains the real reason why the plugin 
> failed.
> For new users this is very confusing. Even when we teach them to read, and 
> they finally see a link, it's quite frustrating for them that they still 
> don't know what happened.
> {{MojoExecutionException}} and {{MojoFailureException}} should never refer to 
> a wikipage anymore.
> Plugin writers should get more control over the message written to the 
> console.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] rfscholte commented on a change in pull request #7: [MPIR-375] add plugin excludes feature for plugin-management report

[GitBox]

rfscholte commented on a change in pull request #7: [MPIR-375] add plugin 
excludes feature for plugin-management report
URL: 
https://github.com/apache/maven-project-info-reports-plugin/pull/7#discussion_r247358087
 
 

 ##
 File path: 
src/main/java/org/apache/maven/report/projectinfo/PluginManagementReport.java
 ##
 @@ -255,5 +283,41 @@ public int compare( Plugin a1, Plugin a2 )
 }
 };
 }
+
+private boolean isExcluded( Artifact pluginArtifact )
+{
+if ( excludes == null )
+{
+return false;
+}
+
+for ( String pattern : excludes )
+{
+String[] subStrings = pattern.split( ":" );
 
 Review comment:
   I don't see a reason to cleanup the pattern. This is already a list, not a 
single comma-separated String.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] rfscholte commented on a change in pull request #7: [MPIR-375] add plugin excludes feature for plugin-management report

[GitBox]

rfscholte commented on a change in pull request #7: [MPIR-375] add plugin 
excludes feature for plugin-management report
URL: 
https://github.com/apache/maven-project-info-reports-plugin/pull/7#discussion_r247357917
 
 

 ##
 File path: 
src/main/java/org/apache/maven/report/projectinfo/PluginManagementReport.java
 ##
 @@ -200,13 +220,21 @@ private void renderSectionPluginManagement()
 
 Artifact pluginArtifact = 
repositorySystem.createProjectArtifact( plugin.getGroupId(), plugin
 .getArtifactId(), versionRange.toString() );
-
+
 try
 {
-MavenProject pluginProject = projectBuilder.build( 
pluginArtifact, buildingRequest ).getProject();
-
-tableRow( getPluginRow( pluginProject.getGroupId(), 
pluginProject.getArtifactId(), pluginProject
-.getVersion(), pluginProject.getUrl() ) );
+if ( isExcluded( pluginArtifact ) )
+{
+log.debug( "Excluding plugin " + 
pluginArtifact.getId() + " from report" );
+}
+else
+{
+MavenProject pluginProject =
 
 Review comment:
   Can you the try-catch statement inside the else-statement, not around the 
whole if-else statement


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] rfscholte commented on a change in pull request #7: [MPIR-375] add plugin excludes feature for plugin-management report

[GitBox]

rfscholte commented on a change in pull request #7: [MPIR-375] add plugin 
excludes feature for plugin-management report
URL: 
https://github.com/apache/maven-project-info-reports-plugin/pull/7#discussion_r247358442
 
 

 ##
 File path: 
src/test/resources/plugin-configs/plugin-management-plugin-config-MPIR-375.xml
 ##
 @@ -0,0 +1,89 @@
+
+
+http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+  4.0.0
+  org.apache.maven.plugin.projectinfo.tests
+  plugin-management
+  1.0-SNAPSHOT
+  jar
+  plugin management project info
+  
 
 Review comment:
   Try to remove all unrequired stuff, like dependencies


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] rfscholte commented on a change in pull request #7: [MPIR-375] add plugin excludes feature for plugin-management report

[GitBox]

rfscholte commented on a change in pull request #7: [MPIR-375] add plugin 
excludes feature for plugin-management report
URL: 
https://github.com/apache/maven-project-info-reports-plugin/pull/7#discussion_r247358392
 
 

 ##
 File path: 
src/main/java/org/apache/maven/report/projectinfo/PluginManagementReport.java
 ##
 @@ -255,5 +283,41 @@ public int compare( Plugin a1, Plugin a2 )
 }
 };
 }
+
+private boolean isExcluded( Artifact pluginArtifact )
+{
+if ( excludes == null )
+{
+return false;
+}
+
+for ( String pattern : excludes )
+{
+String[] subStrings = pattern.split( ":" );
+subStrings = StringUtils.stripAll( subStrings );
+String resultPattern = StringUtils.join( subStrings, ":" );
+
+if ( compareDependency( resultPattern, pluginArtifact ) )
+{
+return true;
+}
+}
+
+return false;
+}
+
+/**
+ * Compares the given pattern against the given artifact. The pattern 
should follow the format
+ * groupId:artifactId:type:classifier:version.
+ * 
+ * @param pattern The pattern to compare the artifact with.
+ * @param artifact the artifact
+ * @return true if the artifact matches the pattern
+ */
+protected boolean compareDependency( String pattern, Artifact artifact 
)
+{
 
 Review comment:
   Use org.apache.maven.shared.artifact.filter.PatternExcludesArtifactFilter 
instead


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] rfscholte commented on a change in pull request #7: [MPIR-375] add plugin excludes feature for plugin-management report

[GitBox]

rfscholte commented on a change in pull request #7: [MPIR-375] add plugin 
excludes feature for plugin-management report
URL: 
https://github.com/apache/maven-project-info-reports-plugin/pull/7#discussion_r247357835
 
 

 ##
 File path: src/it/MPIR-375/pom.xml
 ##
 @@ -0,0 +1,125 @@
+
+
+
+http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+  4.0.0
+
+  org.apache.maven.plugins.project-info-reports.its
+  MPIR-375
+  1.0-SNAPSHOT
+  jar
+  http://maven.apache.org/plugins/it/${project.artifactId}
+
+  
+1.7
+1.7
+UTF-8
+UTF-8
+  
+
+  
+
+  
+
+
+  org.eclipse.m2e
+  lifecycle-mapping
+  1.0.0
+  
+
+  
+
+  
+org.codehaus.mojo
+keytool-maven-plugin
+[1.5,)
+
+  clean
+
+  
+  
+
+  
+
+  
+
+  
+
+
+  org.apache.maven.plugins
+  maven-javadoc-plugin
+  3.0.1
+
+  
+
+
+
+  
+org.apache.maven.plugins
+maven-site-plugin
+@sitePluginVersion@
+  
+  
+  
 
 Review comment:
   Can you remove this plugin, I don't see the need for it in this IT


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1622) failure to run tests if classpath gets too long (?)

[Carsten Hammer (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741625#comment-16741625
 ] 

Carsten Hammer commented on SUREFIRE-1622:
--

I created a copy of the project in question with a different path that does not 
contain a space. I get the same error
error=7, Die Argumentliste ist zu lang
{noformat}
Command was /bin/sh -c cd 
/var/lib/jenkins/jobs/myprojecttrunksvn/workspace/buildhelper && 
/var/lib/jenkins/tools/hudson.model.JDK/java8/jre/bin/java 
-Dfile.encoding=UTF-8 org.apache.maven.surefire.booter.ForkedBooter 
/var/lib/jenkins/jobs/myprojecttrunksvn/workspace/buildhelper/target/surefire 
2019-01-13T19-14-44_041-jvmRun1 surefire5288250206770680443tmp 
surefire_19126886075942275053tmp{noformat}
That means the space in the path has nothing to do with the problem.

I don't understand why the compiler comes into play anyway in the 
"*maven-surefire-plugin:3.0.0-M3:test*" step as the 
"*maven-compiler-plugin:3.8.0:compile*" and the 
"*maven-compiler-plugin:3.8.0:testCompile*" steps have been finished at that 
point with no visible problem.

 

 

> failure to run tests if classpath gets too long (?)
> ---
>
> Key: SUREFIRE-1622
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1622
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.1
> Environment: debian linux
> Linux jenkins 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
> x86_64 GNU/Linux
> Jenkins 2.157
>Reporter: Carsten Hammer
>Priority: Major
>
> We have an aggregating plugin where the classpath of a lot of different 
> projects are combined for integration tests. We now have problems since one 
> point in time with failing tests:
> {noformat}
> Please refer to /var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire-reports for the individual test 
> results.
> Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump 
> and [date].dumpstream.
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> Command was /bin/sh -c cd "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper" && 
> /var/lib/jenkins/tools/hudson.model.JDK/java8/jre/bin/java 
> -Dfile.encoding=UTF-8 org.apache.maven.surefire.booter.ForkedBooter 
> '/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper/target/surefire' 2019-01-08T17-09-39_970-jvmRun1 
> surefire76194600426378498tmp surefire_18239836832627501299tmp
> Error while executing forked tests.Error while executing process.Cannot run 
> program "/bin/sh" (in directory "/var/lib/jenkins/jobs/myproject_trunk 
> svn/workspace/buildhelper"): error=7, Die Argumentliste ist zu 
> langorg.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineException:
>  Error while executing process.
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.Commandline.execute(Commandline.java:412)
>     at 
> org.apache.maven.plugin.surefire.booterclient.lazytestprovider.OutputStreamFlushableCommandline.execute(OutputStreamFlushableCommandline.java:65)
>     at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils.executeCommandLineAsCallable(CommandLineUtils.java:229)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:609)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
>     at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
>     at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
>     at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>     at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>    

[GitHub] rfscholte commented on issue #6: [MJLINK-6] Add 'sourceJdkModules' configuration parameter.

[GitBox]

rfscholte commented on issue #6: [MJLINK-6] Add 'sourceJdkModules' 
configuration parameter.
URL: https://github.com/apache/maven-jlink-plugin/pull/6#issuecomment-453854790
 
 
   Jenkins at ASF is happy too. If you can remove the configuration from 
maven-compiler-plugin, add yourself as contributor to the pom.xml (if desired) 
and squash the commits, I'll merge them into master.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent

[JIRA]

Hervé Boutemy created MNG-6562:
--

 Summary: WARN if plugins injected by default lifecycle bindings 
don't have their version locked in pom.xml or parent
 Key: MNG-6562
 URL: https://issues.apache.org/jira/browse/MNG-6562
 Project: Maven
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Affects Versions: 3.6.0
Reporter: Hervé Boutemy
 Fix For: 3.7.0-candidate


Currently, when building from a basic pom.xml:
{code:xml}
  4.0.0
  com.mycompany.app
  my-app
  1.0-SNAPSHOT
{code}
many plugins are used, but their version is not locked by the user: the default 
plugins versions depend on Maven version used, which is not stable over 
different Maven versions.

Adding a warning for this stability issue will help users know that they need 
to lock down plugins versions in their pom (or parent), something like:
{noformat}[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
com.mycompany.app:my-app:jar:1.0-SNAPSHOT
[WARNING] Plugins versions not defined for [maven-clean-plugin, 
maven-install-plugin, maven-resources-plugin, maven-surefire-plugin, 
maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin, 
maven-site-plugin], you should define versions in pluginManagement section of 
your pom.xml or parent
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHARED-666) Custom pom properties file for maven archiver has no effect

[Michael Osipov (JIRA)]

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

Michael Osipov updated MSHARED-666:
---
Fix Version/s: waiting-for-feedback

> Custom pom properties file for maven archiver has no effect
> ---
>
> Key: MSHARED-666
> URL: https://issues.apache.org/jira/browse/MSHARED-666
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.2.0
>Reporter: Mohamed Raiyan
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Giving a custom pom properties file does not have any effect on the archive. 
> It always takes the project artifact id, group id and version.
> I used maven assembly plugin, whch in turn uses maven archiver. This is the 
> plugin configuration. 
> {code:xml}
>  
> maven-assembly-plugin
> 3.1.0
> 
> 
> 
> src/main/resources/pom.properties
> 
> 
> jar-with-dependencies
> 
> 
> 
> 
> make-assembly
> package
> 
> single
> 
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHARED-362) Support removing default manifest entries with Maven Archiver

[Michael Osipov (JIRA)]

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

Michael Osipov updated MSHARED-362:
---
Fix Version/s: maven-archiver-3.3.1

> Support removing default manifest entries with Maven Archiver
> -
>
> Key: MSHARED-362
> URL: https://issues.apache.org/jira/browse/MSHARED-362
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-archiver
>Affects Versions: maven-archiver-2.4.2, maven-archiver-2.5
>Reporter: Richard Neish
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: maven-archiver-3.3.1
>
> Attachments: MSHARED-362-01.patch
>
>
> As described in the StackOverflow question at 
> http://stackoverflow.com/q/25098307/274350 maven-archiver should allow the 
> user to remove the default manifest entries, such as "Built-By:"
> Currently it is possible to set an empty value for these default entries, but 
> not to remove them from the manifest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHARED-666) Custom pom properties file for maven archiver has no effect

[Michael Osipov (JIRA)]

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

Michael Osipov commented on MSHARED-666:


Waiting for feedback. Justification for the current behavior has been provided.

> Custom pom properties file for maven archiver has no effect
> ---
>
> Key: MSHARED-666
> URL: https://issues.apache.org/jira/browse/MSHARED-666
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.2.0
>Reporter: Mohamed Raiyan
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Giving a custom pom properties file does not have any effect on the archive. 
> It always takes the project artifact id, group id and version.
> I used maven assembly plugin, whch in turn uses maven archiver. This is the 
> plugin configuration. 
> {code:xml}
>  
> maven-assembly-plugin
> 3.1.0
> 
> 
> 
> src/main/resources/pom.properties
> 
> 
> jar-with-dependencies
> 
> 
> 
> 
> make-assembly
> package
> 
> single
> 
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHARED-362) Support removing default manifest entries with Maven Archiver

[Michael Osipov (JIRA)]

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

Michael Osipov commented on MSHARED-362:


Haven't received any feedback on MSHARED-787. I will perform the merge 
somewhere next week.

> Support removing default manifest entries with Maven Archiver
> -
>
> Key: MSHARED-362
> URL: https://issues.apache.org/jira/browse/MSHARED-362
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-archiver
>Affects Versions: maven-archiver-2.4.2, maven-archiver-2.5
>Reporter: Richard Neish
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: maven-archiver-3.3.1
>
> Attachments: MSHARED-362-01.patch
>
>
> As described in the StackOverflow question at 
> http://stackoverflow.com/q/25098307/274350 maven-archiver should allow the 
> user to remove the default manifest entries, such as "Built-By:"
> Currently it is possible to set an empty value for these default entries, but 
> not to remove them from the manifest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SCM-777) scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741597#comment-16741597
 ] 

Michael Osipov commented on SCM-777:


[~hboutemy], did you get a chance to have a look at?

> scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of 
> system property
> --
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.11.2
>
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl() 
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}  
> ...in order to check if it should check the repository on scm:validate.  This 
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option, 
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
> 
> org.apache.maven.plugins
> maven-scm-plugin
> 
> true  
> 
> 
> 
>   validate
>   
> true 
> 
>   
>   
> validate
>   
> 
> 
> 
> {code}
> *Workaround:* Use  section.  Tried  
> and for some reason that didn't appear to work.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSITE-832) stage-deploy fails with maven-site-plugin 3.7.1 and wagon-webdav-jackrabbit 3.3.1: NoSuchMethodError:org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCa

[Michael Osipov (JIRA)]

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

Michael Osipov updated MSITE-832:
-
Fix Version/s: waiting-for-feedback

> stage-deploy fails with maven-site-plugin 3.7.1 and wagon-webdav-jackrabbit 
> 3.3.1: 
> NoSuchMethodError:org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I
> 
>
> Key: MSITE-832
> URL: https://issues.apache.org/jira/browse/MSITE-832
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: site:stage(-deploy)
>Affects Versions: 3.7.1
>Reporter: Enrico Olivelli
>Assignee: Michael Osipov
>Priority: Blocker
> Fix For: waiting-for-feedback
>
>
> I have this error with Maven 3.6.0 and maven-site-plugin 3.7.1 and
>  wagon-webdav-jackrabbit 3.3.1
>  
>   java.lang.NoSuchMethodError:
>  
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I
>      at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.access$000
>  (AbstractHttpClientWagon.java:112)
>      at 
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon$RequestEntityImplementation.writeTo
>  (AbstractHttpClientWagon.java:185)
>      at org.apache.http.impl.DefaultBHttpClientConnection.sendRequestEntity
>  (DefaultBHttpClientConnection.java:156)
>  
>  
>  Is there anyworkaround ?
>  I am trying to force all of the dependencies in the site plugin
>  
>  
>      org.apache.maven.plugins
>      maven-site-plugin
>      3.7.1
>      
>      
>        org.apache.maven.wagon
>        wagon-http
>        3.3.1
>      
>      
>        org.apache.maven.wagon
>        wagon
>        3.3.1
>        pom
>      
>      
>        org.apache.maven.wagon
>        wagon-http-shared
>        3.3.1
>      
>      
>        org.apache.maven.wagon
>        wagon-webdav-jackrabbit
>        3.3.1
>      
>            
>  
>  But no result...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MDEP-586) Unpacking different resources into different location from the same artifact doesn't work

[Hudson (JIRA)]

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

Hudson commented on MDEP-586:
-

Build failed in Jenkins: Maven TLP » maven-dependency-plugin » master #56

See 
https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/56/

> Unpacking different resources into different location from the same artifact 
> doesn't work
> -
>
> Key: MDEP-586
> URL: https://issues.apache.org/jira/browse/MDEP-586
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: unpack-dependencies
>Affects Versions: 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files (x86)\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_111\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Tomas Tulka
>Assignee: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Attachments: pom.xml
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I have one artifact, in the simplest case only with two resources inside:
> ResourceArtifact-1.0.jar
> /resource1.dat
> /resource2.dat
> I want to unpack one resource into one location and the second in a different 
> location, all this with one pom.xml:
> {code:xml}
> 
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.0.2
> 
>   
> unpack-resource1
> 
>   unpack-dependencies
> 
> 
>   ResourceArtifact
>   resource1.dat
>   resources1
> 
>   
>   
> unpack-resource2
> 
>   unpack-dependencies
> 
> 
>   ResourceArtifact
>   resource2.dat
>   resources2
> 
>   
>   
> 
> {code}
> When I +*don't*+ use (which makes not so much sense, because in fact there's 
> nothing to overwrite):
> {code:xml}
> true
> true
> {code}
> Then I get an info (even not a warning):
> {noformat}
> [INFO] --- maven-dependency-plugin:3.0.2:unpack-dependencies 
> (unpack-resource2) @ maven-unpack-same-artifact ---
> [INFO] test:ResourceArtifact:jar:1.0 already exists in destination.
> {noformat}
> And the second resource is not unpacked.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] rfscholte commented on issue #4: [MJAR-254] Finish the fix of MJAR-198.

[GitBox]

rfscholte commented on issue #4: [MJAR-254] Finish the fix of MJAR-198.
URL: https://github.com/apache/maven-jar-plugin/pull/4#issuecomment-453838665
 
 
   For me there's no evidence that the right file is being installed/deployed. 
The fix might be good, but I have this feeling that it is still possible to 
attach a different file.
   And there's probably another bug: what if the file was called 
`com.jarhead.ear`?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Closed] (MDEP-586) Unpacking different resources into different location from the same artifact doesn't work

[Robert Scholte (JIRA)]

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

Robert Scholte closed MDEP-586.
---
Resolution: Cannot Reproduce
  Assignee: Robert Scholte

With 
[9bcd5f20a6a4d951ac920f24fbe5e22ab07f1e7b|https://gitbox.apache.org/repos/asf?p=maven-dependency-plugin.git;a=commit;h=9bcd5f20a6a4d951ac920f24fbe5e22ab07f1e7b]
 an integration test is added, which shows that it does work.
Thanks for the patch!

> Unpacking different resources into different location from the same artifact 
> doesn't work
> -
>
> Key: MDEP-586
> URL: https://issues.apache.org/jira/browse/MDEP-586
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: unpack-dependencies
>Affects Versions: 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files (x86)\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_111\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Tomas Tulka
>Assignee: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Attachments: pom.xml
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I have one artifact, in the simplest case only with two resources inside:
> ResourceArtifact-1.0.jar
> /resource1.dat
> /resource2.dat
> I want to unpack one resource into one location and the second in a different 
> location, all this with one pom.xml:
> {code:xml}
> 
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.0.2
> 
>   
> unpack-resource1
> 
>   unpack-dependencies
> 
> 
>   ResourceArtifact
>   resource1.dat
>   resources1
> 
>   
>   
> unpack-resource2
> 
>   unpack-dependencies
> 
> 
>   ResourceArtifact
>   resource2.dat
>   resources2
> 
>   
>   
> 
> {code}
> When I +*don't*+ use (which makes not so much sense, because in fact there's 
> nothing to overwrite):
> {code:xml}
> true
> true
> {code}
> Then I get an info (even not a warning):
> {noformat}
> [INFO] --- maven-dependency-plugin:3.0.2:unpack-dependencies 
> (unpack-resource2) @ maven-unpack-same-artifact ---
> [INFO] test:ResourceArtifact:jar:1.0 already exists in destination.
> {noformat}
> And the second resource is not unpacked.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] rfscholte closed pull request #9: [MDEP-586] Unpacking different resources into different location from the same artifact do work.

[GitBox]

rfscholte closed pull request #9: [MDEP-586] Unpacking different resources into 
different location from the same artifact do work.
URL: https://github.com/apache/maven-dependency-plugin/pull/9
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff has been
sent to your commit mailing list, comm...@maven.apache.org

 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MNG-6556) Packaging 'maven-plugin' binding plugin upgrades

[Michael Osipov (JIRA)]

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

Michael Osipov commented on MNG-6556:
-

[~hboutemy], these are the failures I told you about. I assume that those are 
either bugs in the plugins or the ITs are too old.

> Packaging 'maven-plugin' binding plugin upgrades
> 
>
> Key: MNG-6556
> URL: https://issues.apache.org/jira/browse/MNG-6556
> Project: Maven
>  Issue Type: Sub-task
>  Components: core, Dependencies
>Affects Versions: 3.5.0, 3.6.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: diff in mc.png
>
>
> This affects:
> ||groupId||artifactId||[previous 
> version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]||target
>  version||
> |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0|
> |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.0|
> |org.apache.maven.plugins|maven-plugin-plugin|3.2|3.6.0|
> |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M3|
> |org.apache.maven.plugins|maven-jar-plugin|2.4|3.1.1|
> |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1|
> |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1|



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6559) Mailing list URL is incorrect in CONTRIBUTING.md

[Hudson (JIRA)]

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

Hudson commented on MNG-6559:
-

Build succeeded in Jenkins: Maven TLP » maven » master #135

See https://builds.apache.org/job/maven-box/job/maven/job/master/135/

> Mailing list URL is incorrect in CONTRIBUTING.md
> 
>
> Key: MNG-6559
> URL: https://issues.apache.org/jira/browse/MNG-6559
> Project: Maven
>  Issue Type: Bug
>  Components: Documentation:  General
>Reporter: John Lin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The mailing list URL in CONTRIBUTING.md is currently 
> [https://maven.apache.org/mail-lists.html], but it should have been 
> [https://maven.apache.org/mailing-lists.html].
> Besides, I also found that problem in 
> [https://github.com/apache/maven/tree/master/apache-maven|https://github.com/apache/maven/tree/master/apache-maven].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (MNG-6559) Mailing list URL is incorrect in CONTRIBUTING.md

[*$^¨%`£]

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

Olivier Lamy (*$^¨%`£) resolved MNG-6559.
-
Resolution: Fixed

> Mailing list URL is incorrect in CONTRIBUTING.md
> 
>
> Key: MNG-6559
> URL: https://issues.apache.org/jira/browse/MNG-6559
> Project: Maven
>  Issue Type: Bug
>  Components: Documentation:  General
>Reporter: John Lin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The mailing list URL in CONTRIBUTING.md is currently 
> [https://maven.apache.org/mail-lists.html], but it should have been 
> [https://maven.apache.org/mailing-lists.html].
> Besides, I also found that problem in 
> [https://github.com/apache/maven/tree/master/apache-maven|https://github.com/apache/maven/tree/master/apache-maven].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] olamy closed pull request #230: [MNG-6559] Fix mailing list URL

[GitBox]

olamy closed pull request #230: [MNG-6559] Fix mailing list URL
URL: https://github.com/apache/maven/pull/230
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d22ffd9a12..9989fb163b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -32,7 +32,7 @@ Getting Started
 + Make sure you have a [JIRA account](https://issues.apache.org/jira/).
 + Make sure you have a [GitHub account](https://github.com/signup/free).
 + If you're planning to implement a new feature, it makes sense to discuss 
your changes 
-  on the [dev list](https://maven.apache.org/mail-lists.html) first. 
+  on the [dev list](https://maven.apache.org/mailing-lists.html) first.
   This way you can make sure you're not wasting your time on something that 
isn't 
   considered to be in Apache Maven's scope.
 + Submit a ticket for your issue, assuming one does not already exist.
@@ -85,7 +85,7 @@ Additional Resources
 + [Apache Maven Twitter Account](https://twitter.com/ASFMavenProject)
 + #Maven IRC channel on freenode.org
 
-[dev-ml-list]: https://maven.apache.org/mail-lists.html
+[dev-ml-list]: https://maven.apache.org/mailing-lists.html
 [code-style]: https://maven.apache.org/developers/conventions/code.html
 [cla]: https://www.apache.org/licenses/#clas
 [maven-wiki]: https://cwiki.apache.org/confluence/display/MAVEN/Index
diff --git a/apache-maven/README.txt b/apache-maven/README.txt
index 8bd4feb107..3e93a8433a 100644
--- a/apache-maven/README.txt
+++ b/apache-maven/README.txt
@@ -72,7 +72,7 @@
   Home Page:  https://maven.apache.org/
   Downloads:  https://maven.apache.org/download.html
   Release Notes:  https://maven.apache.org/docs/history.html
-  Mailing Lists:  https://maven.apache.org/mail-lists.html
+  Mailing Lists:  https://maven.apache.org/mailing-lists.html
   Source Code:https://gitbox.apache.org/repos/asf/maven.git
   Issue Tracking: https://issues.apache.org/jira/browse/MNG
   Wiki:   https://cwiki.apache.org/confluence/display/MAVEN/


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Assigned] (MNG-6559) Mailing list URL is incorrect in CONTRIBUTING.md

[*$^¨%`£]

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

Olivier Lamy (*$^¨%`£) reassigned MNG-6559:
---

Assignee: Olivier Lamy (*$^¨%`£)

> Mailing list URL is incorrect in CONTRIBUTING.md
> 
>
> Key: MNG-6559
> URL: https://issues.apache.org/jira/browse/MNG-6559
> Project: Maven
>  Issue Type: Bug
>  Components: Documentation:  General
>Reporter: John Lin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The mailing list URL in CONTRIBUTING.md is currently 
> [https://maven.apache.org/mail-lists.html], but it should have been 
> [https://maven.apache.org/mailing-lists.html].
> Besides, I also found that problem in 
> [https://github.com/apache/maven/tree/master/apache-maven|https://github.com/apache/maven/tree/master/apache-maven].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)