[jira] [Commented] (MDEP-425) dependency:list-repositories ignores pluginRepository (only lists repository)

2017-05-11 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on MDEP-425:
-

GitHub user mattnelson opened a pull request:

https://github.com/apache/maven-plugins/pull/113

[MDEP-425] Add list-plugin-repositories goal

https://issues.apache.org/jira/browse/MDEP-425

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mattnelson/maven-plugins mdep-425

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/113.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #113


commit 4b437bde668233f9e1ca8e7ca53817cbdedffd0e
Author: Matt Nelson 
Date:   2017-05-12T00:38:24Z

[MDEP-425] Add list-plugin-repositories goal




> dependency:list-repositories ignores pluginRepository (only lists repository)
> -
>
> Key: MDEP-425
> URL: https://issues.apache.org/jira/browse/MDEP-425
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>Reporter: Michael Vorburger
>
> http://maven.apache.org/plugins/maven-dependency-plugin/list-repositories-mojo.html
>  can be very useful! But unless we've missed something, it seems to only 
> gather & list all  but doesn't know about / ignores 
> any  ?
> What I'm suggesting is more that something like 'mvn 
> org.apache.maven.plugins:maven-dependency-plugin:2.8:list-repositories' also 
> lists plugin repositories (with an indication of which is a plugin vs. a 
> dependency plug-in?) than a new list-plugin-repositories goal (just because I 
> think in practice one would typically want to see both).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-11 Thread M.P. Korstanje (JIRA)

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

M.P. Korstanje commented on SUREFIRE-1372:
--

I've hit a roadblock. I need 
[#1121|https://github.com/cucumber/cucumber-jvm/pull/1121] merged into 
cucumber-jvm to make surefire work but it appears the maintainer is awol.

So I don't expect this will make it into 2.20.1. Should things change I'll 
finish this up.



> Rerunning failing tests fails in combination with 
> Description#createSuiteDescription
> 
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (MNG-6205) Non-ascii chars in name element are displayed as question marks in Win CLI output (regression)

2017-05-11 Thread JIRA

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

Hervé Boutemy edited comment on MNG-6205 at 5/11/17 10:29 PM:
--

yes, I didn't have time to work on the big change to Jansi to avoid requiring 
to guess which encoding to use.
Honestly, the issue has to be tested and tracked at Jansi level, not Maven: I 
just proposed a new PR https://github.com/fusesource/jansi/pull/88 in Jansi to 
have a basic test inside Jansi to check how it behaves in any condition.
>From my first tests, Windows cmd.exe encoding is really strange, even without 
>Jansi...
With that Jansi alone test, everybody should be able to test Jansi and provide 
better algorithms: for the moment, Jansi 1.16 seems to be better than 1.13 when 
used on Oracle JDK, which is the most common case. With IBM JDK, people will 
need to test and propose improvements to Jansi


was (Author: hboutemy):
yes, I didn't have time to work on the big change to Jansi to avoid requiring 
to guess which encoding to use.
Honestly, the issue has to be tested and tracked at Jansi level, not Maven: I 
just proposed a new PR in Jansi to have a basic test inside Jansi to check how 
it behaves in any condition.
>From my first tests, Windows cmd.exe encoding is really strange, even without 
>Jansi...
With that Jansi alone test, everybody should be able to test Jansi and provide 
better algorithms: for the moment, Jansi 1.16 seems to be better than 1.13 when 
used on Oracle JDK, which is the most common case. With IBM JDK, people will 
need to test and propose improvements to Jansi

> Non-ascii chars in name element are displayed as question marks in Win CLI 
> output (regression)
> --
>
> Key: MNG-6205
> URL: https://issues.apache.org/jira/browse/MNG-6205
> Project: Maven
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 3.5.0
> Environment: Windows 7, IBM JDK 7.1, Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426)
>Reporter: Anders Hammar
>Assignee: Hervé Boutemy
> Fix For: 3.5.1
>
> Attachments: jansi-1.16-SNAPSHOT.jar, pom.xml
>
>
> If non-ascii characters (such as Swedish chars å, ä, ö) are used in the pom 
> name element, they are displayed as question mark ('?') in the CLI output 
> when building on Windows. This can been seen e.g. in the Reactor Summary in 
> the end.
> See attached pom for an example.
> This was not an issue in Maven 3.3.9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MNG-6205) Non-ascii chars in name element are displayed as question marks in Win CLI output (regression)

2017-05-11 Thread JIRA

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

Hervé Boutemy commented on MNG-6205:


yes, I didn't have time to work on the big change to Jansi to avoid requiring 
to guess which encoding to use.
Honestly, the issue has to be tested and tracked at Jansi level, not Maven: I 
just proposed a new PR in Jansi to have a basic test inside Jansi to check how 
it behaves in any condition.
>From my first tests, Windows cmd.exe encoding is really strange, even without 
>Jansi...
With that Jansi alone test, everybody should be able to test Jansi and provide 
better algorithms: for the moment, Jansi 1.16 seems to be better than 1.13 when 
used on Oracle JDK, which is the most common case. With IBM JDK, people will 
need to test and propose improvements to Jansi

> Non-ascii chars in name element are displayed as question marks in Win CLI 
> output (regression)
> --
>
> Key: MNG-6205
> URL: https://issues.apache.org/jira/browse/MNG-6205
> Project: Maven
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 3.5.0
> Environment: Windows 7, IBM JDK 7.1, Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426)
>Reporter: Anders Hammar
>Assignee: Hervé Boutemy
> Fix For: 3.5.1
>
> Attachments: jansi-1.16-SNAPSHOT.jar, pom.xml
>
>
> If non-ascii characters (such as Swedish chars å, ä, ö) are used in the pom 
> name element, they are displayed as question mark ('?') in the CLI output 
> when building on Windows. This can been seen e.g. in the Reactor Summary in 
> the end.
> See attached pom for an example.
> This was not an issue in Maven 3.3.9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml

2017-05-11 Thread David J. M. Karlsen (JIRA)

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

David J. M. Karlsen commented on MDEPLOY-221:
-

Same here 
- Nexus Repository Manager 2.14.3-02
- mvn 3.5.0
- "--builder singlethreaded clean deploy -DskipTests=true -DfailIfNoTests=false 
-DdeployAtEnd"

http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd
 for that last parameter

> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}} 
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 24 kB/s)
> [INFO] Downloading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 171 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
>  (18 kB at 591 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
>  (2.2 kB at 71 kB/s)
> [INFO] Downloading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>  (1.2 kB at 92 kB/s)
> [INFO] Downloading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>  (1.2 kB at 92 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 59 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 43 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>  (1.2 kB at 33 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>  (1.2 kB at 40 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
>  (12 kB at 386 kB/s)
> [INFO] Downloading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>  (1.2 kB at 92 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 59 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 65 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded: 

[jira] [Commented] (ARCHETYPE-519) archetype:generate with specified remote archetypeCatalog falls back to internal catalog

2017-05-11 Thread Henry Saputra (JIRA)

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

Henry Saputra commented on ARCHETYPE-519:
-

I would also seconded all the comments from the community here. 

If "purity" of Maven way is the sole reason the change was made, then I would 
respectfully ask for revisit of the approach by at least reverting the changes 
that cause this regression.

> archetype:generate with specified remote archetypeCatalog falls back to 
> internal catalog
> 
>
> Key: ARCHETYPE-519
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-519
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 3.0.0
> Environment: Mac OS X 10.11.6, Apache Maven 3.2.3
>Reporter: Philip Mundt
>Assignee: Robert Scholte
> Fix For: 3.0.1
>
>
> We were surprised to find out that our archetype was "suddenly" not working 
> anymore. It turns out it was the release of 
> {{org.apache.maven.plugins:maven-archetype-plugin:3.0.0}} from 12/Feb/17 that 
> was the culprit.
> When running:
> {{mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate 
> -DarchetypeCatalog=}} we end up with the 
> plugin falling back to the internal catalog:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO] 
> 
> [INFO]
> [INFO] >>> maven-archetype-plugin:3.0.0:generate (default-cli) > 
> generate-sources @ standalone-pom >>>
> [INFO]
> [INFO] <<< maven-archetype-plugin:3.0.0:generate (default-cli) < 
> generate-sources @ standalone-pom <<<
> [INFO]
> [INFO] --- maven-archetype-plugin:3.0.0:generate (default-cli) @ 
> standalone-pom ---
> [INFO] Generating project in Interactive mode
> [INFO] No catalog defined. Using internal catalog
> [INFO] No archetype defined. Using maven-archetype-quickstart 
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> 1: internal -> org.apache.maven.archetypes:maven-archetype-archetype (An 
> archetype which contains a sample archetype.)
> 2: internal -> org.apache.maven.archetypes:maven-archetype-j2ee-simple (An 
> archetype which contains a simplifed sample J2EE application.)
> 3: internal -> org.apache.maven.archetypes:maven-archetype-plugin (An 
> archetype which contains a sample Maven plugin.)
> 4: internal -> org.apache.maven.archetypes:maven-archetype-plugin-site (An 
> archetype which contains a sample Maven plugin site.
>   This archetype can be layered upon an existing Maven plugin project.)
> 5: internal -> org.apache.maven.archetypes:maven-archetype-portlet (An 
> archetype which contains a sample JSR-268 Portlet.)
> 6: internal -> org.apache.maven.archetypes:maven-archetype-profiles ()
> 7: internal -> org.apache.maven.archetypes:maven-archetype-quickstart (An 
> archetype which contains a sample Maven project.)
> 8: internal -> org.apache.maven.archetypes:maven-archetype-site (An archetype 
> which contains a sample Maven site which demonstrates
>   some of the supported document types like APT, XDoc, and FML and 
> demonstrates how
>   to i18n your site. This archetype can be layered upon an existing Maven 
> project.)
> 9: internal -> org.apache.maven.archetypes:maven-archetype-site-simple (An 
> archetype which contains a sample Maven site.)
> 10: internal -> org.apache.maven.archetypes:maven-archetype-webapp (An 
> archetype which contains a sample Maven Webapp project.)
> Choose a number or apply filter (format: [groupId:]artifactId, case sensitive 
> contains):
> {code}
> Version 2.4 works as expected (the archetype catalog exists under given URL 
> and can be downloaded).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MCOMPILER-285) Support test-compile for JDK 9 build b148+

2017-05-11 Thread David M. Lloyd (JIRA)

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

David M. Lloyd commented on MCOMPILER-285:
--

Looks like {{-Xmodule}} has gone away as of April 19 (8178012).  Builds of 
OpenJDK after this time fail in maven-compiler-plugin for test sources:

{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.0:testCompile 
(default-testCompile) on project jboss-modules: Fatal error compiling: invalid 
flag: -Xmodule:null -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.0:testCompile 
(default-testCompile) on project jboss-modules: Fatal error compiling
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Fatal error compiling
at 
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:954)
at 
org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:164)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: org.codehaus.plexus.compiler.CompilerException: invalid flag: 
-Xmodule:null
at 
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:173)
at 
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
at 
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:943)
... 23 more
Caused by: java.lang.IllegalArgumentException: invalid flag: -Xmodule:null
at 
jdk.compiler/com.sun.tools.javac.main.Arguments.error(Arguments.java:911)
at 
jdk.compiler/com.sun.tools.javac.main.Arguments.doProcessArgs(Arguments.java:409)
at 
jdk.compiler/com.sun.tools.javac.main.Arguments.processArgs(Arguments.java:361)
at 
jdk.compiler/com.sun.tools.javac.main.Arguments.init(Arguments.java:246)
at 
jdk.compiler/com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:185)
at 
jdk.compiler/com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:119)
at 
jdk.compiler/com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:68)
at 
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
... 25 more
[ERROR] 
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{noformat}

> Support test-compile for JDK 9 build b148+
> --
>
> Key: MCOMPILER-285
> URL: 

[jira] [Commented] (MDEP-565) Upgrade maven-artifact-transfer to version 0.9.1

2017-05-11 Thread Hudson (JIRA)

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

Hudson commented on MDEP-565:
-

FAILURE: Integrated in Jenkins build maven-plugins #8956 (See 
[https://builds.apache.org/job/maven-plugins/8956/])
[MDEP-567] Upgrade to maven-dependency-tree to 3.0.1
[MDEP-565] Upgrade maven-artifact-transfer to version 0.9.1 (khmarbaise: 
[http://svn.apache.org/viewvc/?view=rev=1794865])
* (edit) maven-dependency-plugin/pom.xml


> Upgrade maven-artifact-transfer to version 0.9.1
> 
>
> Key: MDEP-565
> URL: https://issues.apache.org/jira/browse/MDEP-565
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.1
>
>
> The version 0.9.1 of the maven-artifact-transfer contains a [fix for Maven 
> 3.0|MSHARED-602] which should be part of this release.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MDEP-567) Upgrade to maven-dependency-tree to 3.0.1

2017-05-11 Thread Hudson (JIRA)

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

Hudson commented on MDEP-567:
-

FAILURE: Integrated in Jenkins build maven-plugins #8956 (See 
[https://builds.apache.org/job/maven-plugins/8956/])
[MDEP-567] Upgrade to maven-dependency-tree to 3.0.1
[MDEP-565] Upgrade maven-artifact-transfer to version 0.9.1 (khmarbaise: 
[http://svn.apache.org/viewvc/?view=rev=1794865])
* (edit) maven-dependency-plugin/pom.xml


> Upgrade to maven-dependency-tree to 3.0.1
> -
>
> Key: MDEP-567
> URL: https://issues.apache.org/jira/browse/MDEP-567
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (MDEP-567) Upgrade to maven-dependency-tree to 3.0.1

2017-05-11 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise reassigned MDEP-567:


Assignee: Karl Heinz Marbaise

> Upgrade to maven-dependency-tree to 3.0.1
> -
>
> Key: MDEP-567
> URL: https://issues.apache.org/jira/browse/MDEP-567
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (MDEP-567) Upgrade to maven-dependency-tree to 3.0.1

2017-05-11 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise closed MDEP-567.

Resolution: Fixed

Done in [r1794865|https://svn.apache.org/r1794865]

> Upgrade to maven-dependency-tree to 3.0.1
> -
>
> Key: MDEP-567
> URL: https://issues.apache.org/jira/browse/MDEP-567
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (MDEP-565) Upgrade maven-artifact-transfer to version 0.9.1

2017-05-11 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise closed MDEP-565.

Resolution: Fixed

Done in [r1794865|https://svn.apache.org/r1794865]

> Upgrade maven-artifact-transfer to version 0.9.1
> 
>
> Key: MDEP-565
> URL: https://issues.apache.org/jira/browse/MDEP-565
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.1
>
>
> The version 0.9.1 of the maven-artifact-transfer contains a [fix for Maven 
> 3.0|MSHARED-602] which should be part of this release.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-11 Thread Tibor Digana (JIRA)

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

Tibor Digana commented on SUREFIRE-1372:


[~mpkorstanje]
few weeks, max one month, depends on difficulties.
If you have spare time, please test Surefire with Cucumber with plenty of 
configurations as much as you can. I appreciate it. Thx.

> Rerunning failing tests fails in combination with 
> Description#createSuiteDescription
> 
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (MNG-6169) Lifecycle/binding plugin version updates

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov updated MNG-6169:

Component/s: Dependencies
 core

> Lifecycle/binding plugin version updates
> 
>
> Key: MNG-6169
> URL: https://issues.apache.org/jira/browse/MNG-6169
> Project: Maven
>  Issue Type: Improvement
>  Components: core, Dependencies
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> Regular plugin update to absorb changes if plugin version is not specified in 
> the client POM.
> ||groupId||artifactId||[previous 
> version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
>  version||
> |org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
> |org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
> |org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
> |org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
> |org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
> |org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
> |org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.20|
> |org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
> |org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
> |org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
> |org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
> |org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
> |org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MNG-6169) Lifecycle/binding plugin version updates

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-6169:
-

Some bindings or plugins have not been updated because they cause regressions 
in the ITs. Appropriate spots have been commented in the commit.

> Lifecycle/binding plugin version updates
> 
>
> Key: MNG-6169
> URL: https://issues.apache.org/jira/browse/MNG-6169
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> Regular plugin update to absorb changes if plugin version is not specified in 
> the client POM.
> ||groupId||artifactId||[previous 
> version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
>  version||
> |org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
> |org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
> |org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
> |org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
> |org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
> |org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
> |org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.20|
> |org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
> |org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
> |org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
> |org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
> |org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
> |org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (MNG-6169) Lifecycle/binding plugin version updates

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov updated MNG-6169:

Description: 
Regular plugin update to absorb changes if plugin version is not specified in 
the client POM.

||groupId||artifactId||[previous 
version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
 version||
|org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
|org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
|org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
|org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
|org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
|org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
|org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.20|
|org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
|org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
|org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
|org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
|org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
|org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|




  was:
Regular plugin update to absorb changes if plugin version is not specified in 
the POM.

||groupId||artifactId||[previous 
version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
 version||
|org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
|org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
|org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
|org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
|org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
|org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
|org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.20|
|org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
|org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
|org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
|org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
|org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
|org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|





> Lifecycle/binding plugin version updates
> 
>
> Key: MNG-6169
> URL: https://issues.apache.org/jira/browse/MNG-6169
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> Regular plugin update to absorb changes if plugin version is not specified in 
> the client POM.
> ||groupId||artifactId||[previous 
> version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
>  version||
> |org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
> |org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
> |org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
> |org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
> |org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
> |org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
> |org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.20|
> |org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
> |org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
> |org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
> |org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
> |org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
> |org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (MNG-6169) Lifecycle/binding plugin version updates

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov updated MNG-6169:

Description: 
Regular plugin update to absorb changes if plugin version is not specified in 
the POM.

||groupId||artifactId||[previous 
version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
 version||
|org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
|org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
|org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
|org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
|org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
|org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
|org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.20|
|org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
|org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
|org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
|org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
|org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
|org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|




  was:
Regular plugin update to absorb changes if plugin version is not specified in 
the POM.

||groupId||artifactId||[previous 
version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
 version||
|org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
|org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
|org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
|org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
|org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
|org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
|org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.19.1|
|org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
|org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
|org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
|org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
|org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
|org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|





> Lifecycle/binding plugin version updates
> 
>
> Key: MNG-6169
> URL: https://issues.apache.org/jira/browse/MNG-6169
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> Regular plugin update to absorb changes if plugin version is not specified in 
> the POM.
> ||groupId||artifactId||[previous 
> version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
>  version||
> |org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
> |org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
> |org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
> |org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
> |org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
> |org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
> |org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.20|
> |org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
> |org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
> |org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
> |org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
> |org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
> |org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (MNG-6169) Lifecycle/binding plugin version updates

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov updated MNG-6169:

Description: 
Regular plugin update to absorb changes if plugin version is not specified in 
the POM.

||groupId||artifactId||[previous 
version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
 version||
|org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
|org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
|org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
|org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
|org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
|org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
|org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.19.1|
|org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
|org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
|org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
|org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
|org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
|org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|




  was:
TODO: what is the rationale to the change?

||groupId||artifactId||[previous 
version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
 version||
|org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
|org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
|org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
|org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
|org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
|org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
|org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.19.1|
|org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
|org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
|org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
|org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
|org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
|org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|





> Lifecycle/binding plugin version updates
> 
>
> Key: MNG-6169
> URL: https://issues.apache.org/jira/browse/MNG-6169
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> Regular plugin update to absorb changes if plugin version is not specified in 
> the POM.
> ||groupId||artifactId||[previous 
> version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
>  version||
> |org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
> |org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
> |org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
> |org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
> |org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
> |org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
> |org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.19.1|
> |org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
> |org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
> |org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
> |org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
> |org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
> |org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (MNG-6169) Lifecycle/binding plugin version updates

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov updated MNG-6169:

Description: 
TODO: what is the rationale to the change?

||groupId||artifactId||[previous 
version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
 version||
|org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
|org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
|org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
|org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
|org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
|org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
|org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.19.1|
|org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
|org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
|org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
|org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
|org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
|org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|




  was:
TODO: what is the rationale to the change?

||groupId||artifactId||[previous 
version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
 version||
| | | | |


> Lifecycle/binding plugin version updates
> 
>
> Key: MNG-6169
> URL: https://issues.apache.org/jira/browse/MNG-6169
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> TODO: what is the rationale to the change?
> ||groupId||artifactId||[previous 
> version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target
>  version||
> |org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1|
> |org.apache.maven.plugins |maven-site-plugin|3.3|3.6|
> |org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2|
> |org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2|
> |org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2|
> |org.apache.maven.plugins |maven-compiler-plugin|3.1|3.6.1|
> |org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.19.1|
> |org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2|
> |org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1|
> |org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3|
> |org.apache.maven.plugins |maven-plugin-plugin|2.2|3.0.0|
> |org.apache.maven.plugins |maven-plugin-plugin|2.8|2.9.1|
> |org.apache.maven.plugins |maven-rar-plugin|2.2|2.4|



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-11 Thread M.P. Korstanje (JIRA)

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

M.P. Korstanje commented on SUREFIRE-1372:
--

On what time-frame do you want to finish 2.20.1?

> Rerunning failing tests fails in combination with 
> Description#createSuiteDescription
> 
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-11 Thread M.P. Korstanje (JIRA)

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

M.P. Korstanje commented on SUREFIRE-1372:
--

No problem. I'll add integration tests. 

I'm not cucumber staff. Acting as contributor of cucumber-jvm-parallel-plugin.

Yes this is cucumber related. Cucumber doesn't use test classes and provides 
human readable names where surefire expects a class.

I will also have to fix this issue for junit47 provider.

I'm not aware of any other cucumber-surefire related issues. 

> Rerunning failing tests fails in combination with 
> Description#createSuiteDescription
> 
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MNG-6231) Uploading of any artifact hangs forever

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-6231:
-

Provide a tcpdump of the communication. I'd like to see the TCP socket 
interaction.

> Uploading of any artifact hangs forever
> ---
>
> Key: MNG-6231
> URL: https://issues.apache.org/jira/browse/MNG-6231
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories, Deployment
>Affects Versions: 3.5.0
> Environment: $ uname -a
> Linux 4.10.11-1-ARCH #1 SMP PREEMPT Tue Apr 18 08:39:42 CEST 2017 x86_64 
> GNU/Linux
> $ java -version
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>Reporter: Vyacheslav Mayorov
>Priority: Blocker
> Attachments: test.zip
>
>
> Last log lines:
> {noformat}
> Uploading: 
> http://artifactory.com/repo/libs-snapshot-local/test/test/1.0.0-SNAPSHOT/test-1.0.0-20170511.102118-2.pom
> Progress (1): 4.2 kB  
> {noformat}
> ... hangs here
> Issue can be reproduced on ANY pom (i.e. it is not project specific) - just 
> type {{mvn deploy}})
> maven 3.3.9 works just fine. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (MNG-6231) Uploading of any artifact hangs forever

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov updated MNG-6231:

Fix Version/s: (was: 3.5.1)

> Uploading of any artifact hangs forever
> ---
>
> Key: MNG-6231
> URL: https://issues.apache.org/jira/browse/MNG-6231
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories, Deployment
>Affects Versions: 3.5.0
> Environment: $ uname -a
> Linux 4.10.11-1-ARCH #1 SMP PREEMPT Tue Apr 18 08:39:42 CEST 2017 x86_64 
> GNU/Linux
> $ java -version
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>Reporter: Vyacheslav Mayorov
>Priority: Blocker
> Attachments: test.zip
>
>
> Last log lines:
> {noformat}
> Uploading: 
> http://artifactory.com/repo/libs-snapshot-local/test/test/1.0.0-SNAPSHOT/test-1.0.0-20170511.102118-2.pom
> Progress (1): 4.2 kB  
> {noformat}
> ... hangs here
> Issue can be reproduced on ANY pom (i.e. it is not project specific) - just 
> type {{mvn deploy}})
> maven 3.3.9 works just fine. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-11 Thread Tibor Digana (JIRA)

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

Tibor Digana commented on SUREFIRE-1372:


[~mpkorstanje]
If you want to add something in this PR, pls override the previous commit.

> Rerunning failing tests fails in combination with 
> Description#createSuiteDescription
> 
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-11 Thread Tibor Digana (JIRA)

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

Tibor Digana commented on SUREFIRE-1372:


[~mpkorstanje]
I have to require adding integration test.
Is it Cucumber related staff? Is there more such Cucumber issues to resolve? I 
want to finish version {{2.20.1}} and be idle for some time in order to prepare 
a new version {{3.0.0-alpha-01}}.

> Rerunning failing tests fails in combination with 
> Description#createSuiteDescription
> 
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-11 Thread Tibor Digana (JIRA)

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

Tibor Digana reassigned SUREFIRE-1372:
--

Assignee: Tibor Digana

> Rerunning failing tests fails in combination with 
> Description#createSuiteDescription
> 
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (MNG-6231) Uploading of any artifact hangs forever

2017-05-11 Thread Vyacheslav Mayorov (JIRA)
Vyacheslav Mayorov created MNG-6231:
---

 Summary: Uploading of any artifact hangs forever
 Key: MNG-6231
 URL: https://issues.apache.org/jira/browse/MNG-6231
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories, Deployment
Affects Versions: 3.5.0
 Environment: $ uname -a
Linux 4.10.11-1-ARCH #1 SMP PREEMPT Tue Apr 18 08:39:42 CEST 2017 x86_64 
GNU/Linux

$ java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

Reporter: Vyacheslav Mayorov
Priority: Blocker
 Fix For: 3.5.1
 Attachments: test.zip

Last log lines:

{noformat}
Uploading: 
http://artifactory.com/repo/libs-snapshot-local/test/test/1.0.0-SNAPSHOT/test-1.0.0-20170511.102118-2.pom
Progress (1): 4.2 kB  
{noformat}
... hangs here

Issue can be reproduced on ANY pom (i.e. it is not project specific) - just 
type {{mvn deploy}})

maven 3.3.9 works just fine. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml

2017-05-11 Thread Roland Illig (JIRA)

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

Roland Illig commented on MDEPLOY-221:
--

Regarding your questions:

* Is this the whole output for uploading artifacts?
** Unfortunately, I don't have access to this particular build log anymore (as 
old logs are automatically removed). What I remember is that this is from a 
multi-module project, and there were several lines saying something like 
"deploy will be run at the end".
* Have you checked your build output if you have duplicated 
maven-install-plugin calls?
** Since this is a multi-module build, there is one call of 
{{maven-install-plugin}} per module, as I expect it.
* I saw an artifact obfuscated ? How does the log output look like there?
** Nothing special. It's a jar file, it's built somehow and then uploaded. Why 
could this influence anything?
* Are you using parallelization? (mvn -T ...)
** Yes, we are using {{mvn -T 8}}.
* Which version of Nexus do you use?
** We are using {{Nexus Repository Manager OSS 2.13.0-01}}. I would expect this 
to be irrelevant though, since I assume that the {{maven-metadata.xml}} is just 
uploaded as-is, especially since the timestamp is the same as the other 
uploaded files.

> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}} 
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 24 kB/s)
> [INFO] Downloading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 171 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
>  (18 kB at 591 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
>  (2.2 kB at 71 kB/s)
> [INFO] Downloading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>  (1.2 kB at 92 kB/s)
> [INFO] Downloading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>  (1.2 kB at 92 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 59 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
>  (1.9 kB at 43 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>  (1.2 kB at 33 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>  (1.2 kB at 40 kB/s)
> [INFO] Uploading: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> [INFO] Uploaded: 
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
>  (12 kB at 386 kB/s)
> [INFO] Downloading: 
> 

[jira] [Commented] (MNG-6130) Lost of profile information in workaround for MNG-4900

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-6130:
-

See also: https://gist.github.com/jvanzyl/16da25976f8ad27293fa

> Lost 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
> Environment: Windows
>Reporter: Boris Brodski
>  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
(v6.3.15#6346)


[jira] [Commented] (MNG-6130) Lost of profile information in workaround for MNG-4900

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-6130:
-

That's wrong. The Core ITs are in a seperate project: 
https://github.com/apache/maven-integration-testing

> Lost 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
> Environment: Windows
>Reporter: Boris Brodski
>  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
(v6.3.15#6346)


[jira] [Commented] (MNG-6130) Lost of profile information in workaround for MNG-4900

2017-05-11 Thread Boris Brodski (JIRA)

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

Boris Brodski commented on MNG-6130:


Running

{code}
$ mvn clean install -Prun-its
{code}

on the current origin/master (f4ede96fd06c8d3e1e2b2fb679baec058cce30e1) runs 
successfully. It also says
{code}
[WARNING] The requested profile "run-its" could not be activated because it 
does not exist.
{code}
though.

> Lost 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
> Environment: Windows
>Reporter: Boris Brodski
>  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
(v6.3.15#6346)


[jira] [Created] (ARCHETYPE-526) validationRegex tag not documented and not supported in archetype catalog schema

2017-05-11 Thread Raffaele Litto (JIRA)
Raffaele Litto created ARCHETYPE-526:


 Summary: validationRegex tag not documented and not supported in 
archetype catalog schema
 Key: ARCHETYPE-526
 URL: https://issues.apache.org/jira/browse/ARCHETYPE-526
 Project: Maven Archetype
  Issue Type: Bug
  Components: Archetypes, Documentation
Reporter: Raffaele Litto


http://maven.apache.org/xsd/archetype-catalog-1.0.0.xsd does not support the 
xml tag validationRegex, nor it is anywhere except in the plugin site or in the 
ticket where it was introduced



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MNG-6130) Lost of profile information in workaround for MNG-4900

2017-05-11 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-6130:
-

Did you run your patched version against ITs?

> Lost 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
> Environment: Windows
>Reporter: Boris Brodski
>  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
(v6.3.15#6346)


[jira] [Commented] (MNG-6130) Lost of profile information in workaround for MNG-4900

2017-05-11 Thread JIRA

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

Sebastian Pötzsch commented on MNG-6130:


The bug still exists in maven 3.5.0.

> Lost 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
> Environment: Windows
>Reporter: Boris Brodski
>  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
(v6.3.15#6346)


[jira] [Commented] (MNG-6205) Non-ascii chars in name element are displayed as question marks in Win CLI output (regression)

2017-05-11 Thread Anders Hammar (JIRA)

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

Anders Hammar commented on MNG-6205:


[~hboutemy] I've tested jansi 1.16 and it still doesn't hande non-ascii chars 
correctly with IBM JDK. :-( Tested by patching Maven 3.5.0 and with IBM JDK 1.7.
So, still a regression for us using IBM JDK.

> Non-ascii chars in name element are displayed as question marks in Win CLI 
> output (regression)
> --
>
> Key: MNG-6205
> URL: https://issues.apache.org/jira/browse/MNG-6205
> Project: Maven
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 3.5.0
> Environment: Windows 7, IBM JDK 7.1, Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426)
>Reporter: Anders Hammar
>Assignee: Hervé Boutemy
> Fix For: 3.5.1
>
> Attachments: jansi-1.16-SNAPSHOT.jar, pom.xml
>
>
> If non-ascii characters (such as Swedish chars å, ä, ö) are used in the pom 
> name element, they are displayed as question mark ('?') in the CLI output 
> when building on Windows. This can been seen e.g. in the Reactor Summary in 
> the end.
> See attached pom for an example.
> This was not an issue in Maven 3.3.9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


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

2017-05-11 Thread JIRA

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

Hervé Boutemy commented on MNG-6218:


[~DannyNullZwo], I just proposed a pull request to make jansi.jar executable to 
easily test it in any conditions, without requiring integration in Maven or any 
other end-user tool: see https://github.com/fusesource/jansi/pull/88
For now, you'll need to import the PR and build the lib for yourself to test it 
in any conditions and report the results

> 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
(v6.3.15#6346)