[jira] [Created] (MPMD-242) RFE: Option to apply different rules for main and test sources

2017-08-22 Thread Mitth'raw'nuruodo (JIRA)
Mitth'raw'nuruodo created MPMD-242:
--

 Summary: RFE: Option to apply different rules for main and test 
sources
 Key: MPMD-242
 URL: https://issues.apache.org/jira/browse/MPMD-242
 Project: Maven PMD Plugin
  Issue Type: Improvement
  Components: PMD
Reporter: Mitth'raw'nuruodo
Priority: Minor


Main code and test code often have different quality requirements. For example, 
if you're using a test framework and a mocking framework and maybe Hamcrest on 
top of that, it's normal to have lots of static imports - but you wouldn't want 
that in main code. It's also normal, even desirable, to have lots of test 
cases, which trips the rule about excessive methods in a class. And the Design 
ruleset probably isn't all that important for test sources.

It would be nice to be able to configure different rulesets for main code and 
test code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9

2017-08-22 Thread Robert Scholte (JIRA)

[ 
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136908#comment-16136908
 ] 

Robert Scholte commented on MANTRUN-200:


Maybe [~igorf] has some ideas. Classworlds looks okay, so we're indeed back to 
Maven Core. [As 
described|https://maven.apache.org/guides/mini/guide-maven-classloading.html] 
there are several layers of ClassLoaders, it looks like some gets lost with the 
plugin realm.

> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
>  Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
> 
> 
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>   
>  
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
> 
>
>   compile
>   compile
>   
>  
> 
>
> 
>  
>   
>   
>  run
>   
>
> 
>  
>   
>
> 
> {code}
> The Ant build file uses a script:
> {code}
> 
> 
>
>   
>
>
>   
>
> 
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on 
> project my-test-app: An Ant BuildException has occured: The following error 
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine 
> for javascript
> around Ant part .. @ 4:47 in 
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax 
> script engine for javascript
> at 
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at 
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at 
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at 
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> 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:547)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at 
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by 
> {{JavaxScriptRunner}} doesn't have any script engines, because the service 
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I 
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens 
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}}, but neither 
> helped.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


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

2017-08-22 Thread Vinay Shankar (JIRA)

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

Vinay Shankar commented on MDEPLOY-221:
---

[~gboue] - I do not see maven 3.5.1 in the release notes. Has it been released 
yet? We upgraded to maven 3.5.0 and we are facing this issue in our CI build. 
We would like to upgrade to 3.5.1 as soon as possible (as reverting to a 
previous version will bring back issues that 3.5.0 solved). 

> 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
>Assignee: Guillaume Boué
>
> 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: 
> 

[jira] [Commented] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver

2017-08-22 Thread Vinay Shankar (JIRA)

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

Vinay Shankar commented on MNG-6240:


Hello - When would maven version 3.5.1 be released? Seems like the two issues 
pending have been marked closed but have not been reviewed yet 
(https://issues.apache.org/jira/projects/MNG/versions/12338964). Is there an 
estimated release date? We upgraded to 3.5.0 and that seemed to solve other 
issues we were facing in the previous versions but it has become a show stopper 
due to this issue (side effect MDEPLOY-221). We would like to upgrade to maven 
3.5.1 as soon as possible. 

> Duplicate components in plugin extension realm when plugin depends on 
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
>  Issue Type: Bug
>  Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
> Fix For: 3.5.1
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the 
> components of this artifact are added into the plugin realm even though Maven 
> Core already provides them. This is a regression introduced by the rename of 
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for 
> compatibility, therefore the old artifact name also needs to be exported by 
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two 
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which 
> are {{SnapshotMetadataGeneratorFactory}} and 
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings, 
> and wrong metadata information is deployed as a consequence. This is due to 
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}} 
> used in the build.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests

2017-08-22 Thread Tibor Digana (JIRA)

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

Tibor Digana commented on SUREFIRE-1264:


[~Prifiz]
[~valyok]
Did you have time to have a look at this issue?
If you remember we spoke about it in the chat of SUREFIRE-1302.

> Some tests can be lost when running in parallel with parameterized tests
> 
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
>
> Hello,
> It appears some tests can be lost when using the parallel mode with 
> parameterized tests. Here is a [small 
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've 
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on 
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [ 
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
>  T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 - 
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 - 
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 - 
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 - 
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 - 
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 - 
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec - 
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec - 
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
>  T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 - 
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 - 
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 - 
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec - 
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec - 
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master 
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's 
> even more frequent/easy to reproduce.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MCOMPILER-296) Add jpms.args to the META-INF folder

2017-08-22 Thread Robert Scholte (JIRA)

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

Robert Scholte closed MCOMPILER-296.

   Resolution: Fixed
Fix Version/s: 3.7.0

Fixed in [r1805828|http://svn.apache.org/viewvc?rev=1805828=rev]

> Add jpms.args to the META-INF folder
> 
>
> Key: MCOMPILER-296
> URL: https://issues.apache.org/jira/browse/MCOMPILER-296
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.7.0
>
>
> When compiling a Java9 project with some specific jigsaw/jpms flag, e.g. to 
> open access to certain modules, those flags are probably also required at 
> runtime. If these flags used for a library, that library-user might need to 
> use that same set of flags, but how could he be aware of these flags?
> I'd like to add {{META-INF/jpms.args}} to store these specific flags. This 
> file provides easy access to these arguments and can be used by other 
> tools/plugins.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MCOMPILER-296) Add jpms.args to the META-INF folder

2017-08-22 Thread Hudson (JIRA)

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

Hudson commented on MCOMPILER-296:
--

SUCCESS: Integrated in Jenkins build maven-plugins #9075 (See 
[https://builds.apache.org/job/maven-plugins/9075/])
[MCOMPILER-296] Add jpms.args to the META-INF folder (rfscholte: 
[http://svn.apache.org/viewvc/?view=rev=1805828])
* (edit) maven-compiler-plugin/pom.xml
* (add) maven-compiler-plugin/src/it/jpms_add-exports
* (add) maven-compiler-plugin/src/it/jpms_add-exports/invoker.properties
* (add) maven-compiler-plugin/src/it/jpms_add-exports/pom.xml
* (add) maven-compiler-plugin/src/it/jpms_add-exports/src
* (add) maven-compiler-plugin/src/it/jpms_add-exports/src/main
* (add) maven-compiler-plugin/src/it/jpms_add-exports/src/main/java
* (add) 
maven-compiler-plugin/src/it/jpms_add-exports/src/main/java/module-info.java
* (add) maven-compiler-plugin/src/it/jpms_add-exports/src/main/java/org
* (add) maven-compiler-plugin/src/it/jpms_add-exports/src/main/java/org/maven
* (add) 
maven-compiler-plugin/src/it/jpms_add-exports/src/main/java/org/maven/test
* (add) 
maven-compiler-plugin/src/it/jpms_add-exports/src/main/java/org/maven/test/Main.java
* (add) maven-compiler-plugin/src/it/jpms_add-exports/verify.groovy
* (add) maven-compiler-plugin/src/it/jpms_patch-module
* (add) maven-compiler-plugin/src/it/jpms_patch-module/invoker.properties
* (add) maven-compiler-plugin/src/it/jpms_patch-module/pom.xml
* (add) maven-compiler-plugin/src/it/jpms_patch-module/src
* (add) maven-compiler-plugin/src/it/jpms_patch-module/src/main
* (add) maven-compiler-plugin/src/it/jpms_patch-module/src/main/java
* (add) 
maven-compiler-plugin/src/it/jpms_patch-module/src/main/java/module-info.java
* (add) maven-compiler-plugin/src/it/jpms_patch-module/src/main/java/org
* (add) maven-compiler-plugin/src/it/jpms_patch-module/src/main/java/org/maven
* (add) 
maven-compiler-plugin/src/it/jpms_patch-module/src/main/java/org/maven/test
* (add) 
maven-compiler-plugin/src/it/jpms_patch-module/src/main/java/org/maven/test/Main.java
* (add) maven-compiler-plugin/src/it/jpms_patch-module/src/test
* (add) maven-compiler-plugin/src/it/jpms_patch-module/src/test/java
* (add) maven-compiler-plugin/src/it/jpms_patch-module/src/test/java/org
* (add) maven-compiler-plugin/src/it/jpms_patch-module/src/test/java/org/maven
* (add) 
maven-compiler-plugin/src/it/jpms_patch-module/src/test/java/org/maven/test
* (add) 
maven-compiler-plugin/src/it/jpms_patch-module/src/test/java/org/maven/test/MainTest.java
* (add) maven-compiler-plugin/src/it/jpms_patch-module/verify.groovy
* (edit) 
maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
* (edit) 
maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java
* (edit) 
maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java
* (add) maven-compiler-plugin/src/site/apt/examples/jpms_args.apt.vm
* (edit) maven-compiler-plugin/src/site/fml/faq.fml


> Add jpms.args to the META-INF folder
> 
>
> Key: MCOMPILER-296
> URL: https://issues.apache.org/jira/browse/MCOMPILER-296
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.7.0
>
>
> When compiling a Java9 project with some specific jigsaw/jpms flag, e.g. to 
> open access to certain modules, those flags are probably also required at 
> runtime. If these flags used for a library, that library-user might need to 
> use that same set of flags, but how could he be aware of these flags?
> I'd like to add {{META-INF/jpms.args}} to store these specific flags. This 
> file provides easy access to these arguments and can be used by other 
> tools/plugins.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9

2017-08-22 Thread Robert Munteanu (JIRA)

[ 
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136516#comment-16136516
 ] 

Robert Munteanu commented on MANTRUN-200:
-

Maybe someone from the Maven core team can comment? [~rfscholte]?

> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
>  Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
> 
> 
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>   
>  
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
> 
>
>   compile
>   compile
>   
>  
> 
>
> 
>  
>   
>   
>  run
>   
>
> 
>  
>   
>
> 
> {code}
> The Ant build file uses a script:
> {code}
> 
> 
>
>   
>
>
>   
>
> 
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on 
> project my-test-app: An Ant BuildException has occured: The following error 
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine 
> for javascript
> around Ant part .. @ 4:47 in 
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax 
> script engine for javascript
> at 
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at 
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at 
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at 
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> 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:547)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at 
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by 
> {{JavaxScriptRunner}} doesn't have any script engines, because the service 
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I 
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens 
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}}, but neither 
> helped.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9

2017-08-22 Thread Robert Scholte (JIRA)

[ 
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136602#comment-16136602
 ] 

Robert Scholte commented on MANTRUN-200:


All analysis looks correct to me. The {{ScriptRunner.generateClassLoader()}}  
gets the {{ClassRealm}} from Maven, and I can see that its parentClassLoader is 
an instance of {{ClassLoaders.AppClassLoader}}. I need to verify first if the 
ClassRealm implementation has an issue, otherwise I'll have ask some Java 9  
developers for advice.

> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
>  Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
> 
> 
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>   
>  
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
> 
>
>   compile
>   compile
>   
>  
> 
>
> 
>  
>   
>   
>  run
>   
>
> 
>  
>   
>
> 
> {code}
> The Ant build file uses a script:
> {code}
> 
> 
>
>   
>
>
>   
>
> 
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on 
> project my-test-app: An Ant BuildException has occured: The following error 
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine 
> for javascript
> around Ant part .. @ 4:47 in 
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax 
> script engine for javascript
> at 
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at 
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at 
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at 
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> 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:547)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at 
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by 
> {{JavaxScriptRunner}} doesn't have any script engines, because the service 
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I 
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens 
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}}, but neither 
> helped.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (WAGON-415) wagon-ssh doesn't load known_hosts from Jenkins home directory

2017-08-22 Thread Gerrit Hohl (JIRA)

[ 
https://issues.apache.org/jira/browse/WAGON-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136408#comment-16136408
 ] 

Gerrit Hohl commented on WAGON-415:
---

I'm sorry as I haven't given any response yet. But in the meantime I worked on 
other projects. And it also seems that I won't have time for testing it in the 
near future. I'm really sorry about this.

Seems that in the meantime even maven-wagon v3.0.0 was released.

> wagon-ssh doesn't load known_hosts from Jenkins home directory
> --
>
> Key: WAGON-415
> URL: https://issues.apache.org/jira/browse/WAGON-415
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-ssh
>Affects Versions: 2.6
> Environment: Windows Server 2008 R2 Standard
> Apache Tomcat 7.0.26 Server
> Jenkins v1.527
> Maven 3.0.4
> maven-site-plugin 3.3
> wagon-ssh 2.6
>Reporter: Gerrit Hohl
>
> For some people this might be only an improvement, for myself it is a bug.
> I'm trying to do a site-deploy using wagon-ssh. I have configured the server 
> including the username and password in the settings.xml of Maven.
> If I try this locally Maven asks me if I want to continue establishing the 
> connection showing me the RSA key fingerprint of the server. If I agree by 
> typing 'yes' it creates the file C:\Users\[MY-USER]\.ssh\known_hosts and 
> doesn't ask me ever again.
> But if I try this using Jenkins I can't accept the RSA key fingerprint as 
> there is no interactive mode. I thought I could copy (or create) the 
> known_hosts file on the server. I tried doing this in 
> [JENKINS-HOME]\.ssh\known_hosts, but it didn't work.
> Then I tried to run Maven in the verbose mode (-X / --debug). I got a huge 
> log file, but I don't see any path in which wagon-ssh expects the 
> known_hosts_file also here. But without that I don't know how I should 
> determine where to put.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (ARCHETYPE-530) [archetype:create-from-project] Proxy configuration from settings.xml is not taken into account

2017-08-22 Thread Vadym Lotar (JIRA)

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

Vadym Lotar updated ARCHETYPE-530:
--
Description: 
Hello,

While trying to create an archetype out of source project applying global 
settings.xml which contains proxy configuration, plugin fails with the 
following error:

{color:red}[INFO] Scanning for projects...
[INFO] Downloading: 
https://repo.maven.apache.org/maven2/org/apache/maven/archetype/archetype-packaging/3.0.1/archetype-packaging-3.0.1.pom
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unresolveable build extension: Plugin 
org.apache.maven.archetype:archetype-packaging:3.0.1 or one of its dependencies 
could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.archetype:archetype-packaging:jar:3.0.1 @ 
[ERROR] Unknown packaging: maven-archetype @ line 8, column 14
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project com.adidas.pc:kafka_consumer-archetype:1.0-SNAPSHOT 
(/opt/jenkins/workspace/PC/pcdsp/archetypes/kafka-consumer-archetype-build/target/generated-sources/archetype/pom.xml)
 has 2 errors
[ERROR] Unresolveable build extension: Plugin 
org.apache.maven.archetype:archetype-packaging:3.0.1 or one of its dependencies 
could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.archetype:archetype-packaging:jar:3.0.1: Could not transfer 
artifact org.apache.maven.archetype:archetype-packaging:pom:3.0.1 from/to 
central (https://repo.maven.apache.org/maven2): Connect to 
repo.maven.apache.org:443 [repo.maven.apache.org/151.101.112.215] failed: 
Connection timed out (Connection timed out) -> [Help 2]
[ERROR] Unknown packaging: maven-archetype @ line 8, column 14{color}

It appeared that the plugin creates new 
org.apache.maven.shared.invoker.InvocationRequest to "package" the archetype 
without applying configuration specified in settings.xml.

Being more precise, I feel like the invocation request itself has to be built 
in a little bit different way here, so local and global settings.xml are passed:
org/apache/maven/archetype/creator/FilesetArchetypeCreator.java:281

Please, let me know if more information needs to be provided.

Best.





{color:red}[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-archetype-plugin:3.0.1:create-from-project 
(default-cli) on project kafka_consumer: Invoker process ended with result 
different than 0! -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-archetype-plugin:3.0.1:create-from-project 
(default-cli) on project kafka_consumer: Invoker process ended with result 
different than 0!
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 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 
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.MojoFailureException: Invoker process ended 
with result different than 0!
at 
org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:261)
at 

[jira] [Created] (ARCHETYPE-530) [archetype:create-from-project] Proxy configuration from settings.xml is not taken into account

2017-08-22 Thread Vadym Lotar (JIRA)
Vadym Lotar created ARCHETYPE-530:
-

 Summary: [archetype:create-from-project] Proxy configuration from 
settings.xml is not taken into account
 Key: ARCHETYPE-530
 URL: https://issues.apache.org/jira/browse/ARCHETYPE-530
 Project: Maven Archetype
  Issue Type: Bug
  Components: Plugin
Affects Versions: 3.0.1
Reporter: Vadym Lotar


Hello,

While trying to create an archetype out of source project applying global 
settings.xml which contains proxy configuration, plugin fails with the 
following error:

{color:red}[INFO] Scanning for projects...
[INFO] Downloading: 
https://repo.maven.apache.org/maven2/org/apache/maven/archetype/archetype-packaging/3.0.1/archetype-packaging-3.0.1.pom
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unresolveable build extension: Plugin 
org.apache.maven.archetype:archetype-packaging:3.0.1 or one of its dependencies 
could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.archetype:archetype-packaging:jar:3.0.1 @ 
[ERROR] Unknown packaging: maven-archetype @ line 8, column 14
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project com.adidas.pc:kafka_consumer-archetype:1.0-SNAPSHOT 
(/opt/jenkins/workspace/PC/pcdsp/archetypes/kafka-consumer-archetype-build/target/generated-sources/archetype/pom.xml)
 has 2 errors
[ERROR] Unresolveable build extension: Plugin 
org.apache.maven.archetype:archetype-packaging:3.0.1 or one of its dependencies 
could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.archetype:archetype-packaging:jar:3.0.1: Could not transfer 
artifact org.apache.maven.archetype:archetype-packaging:pom:3.0.1 from/to 
central (https://repo.maven.apache.org/maven2): Connect to 
repo.maven.apache.org:443 [repo.maven.apache.org/151.101.112.215] failed: 
Connection timed out (Connection timed out) -> [Help 2]
[ERROR] Unknown packaging: maven-archetype @ line 8, column 14{color}

It appeared that the plugin creates new 
org.apache.maven.shared.invoker.InvocationRequest to "package" the archetype 
without applying configuration specified in settings.xml.

Being more precise, I feel like the invocation request itself has to be built 
in a little bit different way here, so local and global settings.xml are passed:
org/apache/maven/archetype/creator/FilesetArchetypeCreator.java:281

Please, let me know if more information needs to be provided.

Best.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)