[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1385:


[~gboue]
I think such like this request was here with feature to provide sys props in 
file several days ago.
It was this month but we said that this this well suited feature in version 3.0 
because of the extensions which would extend current POM configurations.
Pls check the history in Jira.

> System properties defined in the Surefire and Failsafe plugin configuration 
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>
> Consider a build with the following POM configuration for the Maven Failsafe 
> Plugin:
> {code:xml}
> 
>   
> foo
>   
> 
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the 
> tests would be passed a system property with a value of {{bar}} instead of 
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is 
> overriden by the more general properties passed on the command line. I would 
> have expected the closer definition in the POM to override the one passed 
> with the CLI. Furthermore, in the case of the above sample, it would not be 
> possible for the tests run by the Failsafe Plugin to have a system property 
> {{prop}} with a value of {{foo}} if the build happens to already define a 
> system property with the same name. While using a different name to avoid a 
> clash is possible, it still doesn't make the test self-contained and 
> consistent since anyone could run Maven with that other name and compromise 
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and 
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe 
> Plugin take precedence over user properties passed on the command line.
> Proposed commit 
> [4de017b38b101b0b28f9fbed135eae3921b99d0d|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/4de017b3]
>  on SUREFIRE-1385 branch.



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

[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise commented on MASSEMBLY-848:
---

Using the following in your assembly descriptor should work:
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
 http://maven.apache.org/xsd/assembly-1.1.0.xsd;>

  distribution
  ${project.name}-${project.version}

  
zip
  

  

  true
  
false
lib
false

  
false
false
  

  

  

{code}

> Version range dependencies not resolved from the reactor
> 
>
> Key: MASSEMBLY-848
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-848
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9 
> (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T10:17:27+00:00)
> Maven home: /opt/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.8.13-1-arch", arch: "amd64", family: "unix"
>Reporter: Mark Raynsford
> Attachments: mvn.log.gz
>
>
> When using modules that have independent version numbers (that is, modules in 
> the same project may have different version numbers), it's commonplace to 
> specify dependencies between modules with version ranges when using semantic 
> versioning.
> For some reason, when version ranges are used on dependencies that refer to 
> modules that are part of the project (and therefore should be in the 
> reactor), the assembly plugin ignores them and tries to resolve them from the 
> local repository instead.
> The following project reproduces this issue (just "mvn clean package"):
> https://github.com/io7m/independent-versioning-20170207
> Interestingly, this didn't happen with the same assembly plugin on older 
> Maven versions. Here's a successful build on Travis CI:
> https://travis-ci.org/io7m/independent-versioning-20170207



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

[jira] [Commented] (MASSEMBLY-853) jar which are not transitive is not excluding.

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise commented on MASSEMBLY-853:
---

Can you provide a full working example?

> jar which are not transitive is not excluding.
> --
>
> Key: MASSEMBLY-853
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-853
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: maven-archiver
>Affects Versions: 2.4, 3.0.0
>Reporter: S Boot
>
> So here is the thing what I am trying is :
> I have parent pom and I am using maven-assembly-plugin in that like below.
> 
>   maven-assembly-plugin
>   
>   
>   
>   
> src/main/assembly/domainApi.xml
>   
>   
>   
>   
>   dist-assembly 
>   package 
>   
>   single
>   
>   
>   
>   
> I also have assembley file which is listed below.
> 
>   domainApi
>   
>   jar
>   
>   
>   false
>   
>   
>   
> target/classes/com/cac/customer/api
>   .
>   
>   *.class
>   
>   
>
>   
>   
>   
>   
>   false 
>   
> false
>   false
>   false
>   
>   
> 
>   
> Now while building assembley jar I am getting only .class file which I want 
> exactly and pushing this jar 
> to nexus.
> While using this jar with below notation it also download some other jar 
> which is not detect by 
> Please suggest whats the way to exclude parent jar which are not 
> TransitiveDependencies.



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

[jira] [Commented] (MASSEMBLY-855) Remote repositories ignored in a multi-module project

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise commented on MASSEMBLY-855:
---

I assume the jboss repository contains only releases so the configuration:
{code}

true
never

{code}
looks wrong to me? 

> Remote repositories ignored in a multi-module project
> -
>
> Key: MASSEMBLY-855
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-855
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: dependencySet
>Affects Versions: 3.0.0
>Reporter: John Farrelly
> Attachments: test-parent.tar.gz
>
>
> I have attached a small multi-module project to demonstrate the behaviour.
> I have a {{test-parent}} project with a child module, {{test-child}}.
> I have defined a repositories section in {{test-parent}}:
> {code:xml}
> 
>   
>   jboss-public-repository-group
>   JBoss Public Maven Repository Group
>   
> https://repository.jboss.org/nexus/content/groups/public-jboss/
>   default
>   
>   true
>   never
>   
>   
>   true
>   never
>   
>   
> 
> {code}
> I have defined the executing of {{maven-assembly-plugin}} in 
> {{test-child/pom.xml}}:
> {code:xml}
> 
>   maven-assembly-plugin
>   3.0.0
>   
>   
>   src/assembly/repository.xml
>   
>   
>   
>   
>   create-repository
>   package
>   
>   single
>   
>   
>   
> 
> {code}
> When I run {{mvn clean package}} from {{test-child}}, I can see that it is 
> using {{repository.jboss.org}} to resolve dependencies:
> {noformat}
> [test-parent/test-child] $ mvn clean package
> [INFO] Scanning for projects...
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building test-child 1.0.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-child ---
> [INFO] 
> [INFO] --- maven-assembly-plugin:3.0.0:single (create-repository) @ 
> test-child ---
> [INFO] Reading assembly descriptor: src/assembly/repository.xml
> Downloading: 
> https://repository.jboss.org/nexus/content/groups/public-jboss/org/jboss/spec/javax/servlet/jboss-servlet-api_3.0_spec/1.0.0.Beta2/jboss-servlet-api_3.0_spec-1.0.0.Beta2.pom
> {noformat}
> However, if I run {{mvn clean package}} from the parent project 
> {{test-parent}}, it will only try to resolve dependencies from maven central, 
> ignoring all repository settings:
> {noformat}
> [test-parent] $ mvn clean package
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO] 
> [INFO] test-parent
> [INFO] test-child
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building test-parent 1.0.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-parent ---
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building test-child 1.0.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-child ---
> [INFO] Deleting /media/sf_SharedFolder/Temp/test-parent/test-child/target
> [INFO] 
> [INFO] --- maven-assembly-plugin:3.0.0:single (create-repository) @ 
> test-child ---
> [INFO] Reading assembly descriptor: src/assembly/repository.xml
> Downloading: 
> https://repo.maven.apache.org/maven2/org/jboss/spec/javax/servlet/jboss-servlet-api_3.0_spec/1.0.0.Beta2/jboss-servlet-api_3.0_spec-1.0.0.Beta2.pom
> {noformat}
> This causes issues for us when we reference dependencies that don't exist in 
> maven central.
> {panel:title=Note|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> I am using maven version 3.3.3
> {panel}



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

[jira] [Updated] (MDEP-571) JDK9: Issue with list goal fails with java.lang.NoSuchMethodException

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise updated MDEP-571:
-
Affects Version/s: 3.0.1

> JDK9: Issue with list goal fails with java.lang.NoSuchMethodException
> -
>
> Key: MDEP-571
> URL: https://issues.apache.org/jira/browse/MDEP-571
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /usr/local/maven
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.9.0_ea+174.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
>
> Calling: 
> {{mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:list}}
> Fails with the following:
> {code}
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] parent
> [INFO] domain
> [INFO] service-client
> [INFO] webgui
> [INFO] service
> [INFO] app
> [INFO] appasm
> [INFO] shade
> [INFO] assembly
> [INFO]
> [INFO] 
> 
> [INFO] Building parent 3.4.6-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-dependency-plugin:3.0.1:list (default-cli) @ parent ---
> [INFO]
> [INFO] The following files have been resolved:
> [INFO]none
> [INFO]
> [INFO]
> [INFO] 
> 
> [INFO] Building domain 3.4.6-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-dependency-plugin:3.0.1:list (default-cli) @ domain ---
> java.lang.NoSuchMethodException: 
> jdk.internal.module.ModuleReferenceImpl.descriptor()
>   at java.base/java.lang.Class.getDeclaredMethod(Class.java:2451)
>   at 
> org.apache.maven.plugins.dependency.utils.DependencyStatusSets.getModuleDescriptor(DependencyStatusSets.java:272)
>   at 
> org.apache.maven.plugins.dependency.utils.DependencyStatusSets.buildArtifactListOutput(DependencyStatusSets.java:227)
>   at 
> org.apache.maven.plugins.dependency.utils.DependencyStatusSets.getOutput(DependencyStatusSets.java:165)
>   at 
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute(ResolveDependenciesMojo.java:90)
>   at 
> org.apache.maven.plugins.dependency.AbstractDependencyMojo.execute(AbstractDependencyMojo.java:143)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
>   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:564)
>   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 
> 

[jira] [Created] (MDEP-571) JDK9: Issue with list goal fails with java.lang.NoSuchMethodException

[Karl Heinz Marbaise (JIRA)]

Karl Heinz Marbaise created MDEP-571:


 Summary: JDK9: Issue with list goal fails with 
java.lang.NoSuchMethodException
 Key: MDEP-571
 URL: https://issues.apache.org/jira/browse/MDEP-571
 Project: Maven Dependency Plugin
  Issue Type: Bug
 Environment: Apache Maven 3.5.0 
(ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
Maven home: /usr/local/maven
Java version: 9-ea, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.9.0_ea+174.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
Reporter: Karl Heinz Marbaise
Priority: Blocker


Calling: 
{{mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:list}}

Fails with the following:
{code}
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO]
[INFO] parent
[INFO] domain
[INFO] service-client
[INFO] webgui
[INFO] service
[INFO] app
[INFO] appasm
[INFO] shade
[INFO] assembly
[INFO]
[INFO] 
[INFO] Building parent 3.4.6-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-dependency-plugin:3.0.1:list (default-cli) @ parent ---
[INFO]
[INFO] The following files have been resolved:
[INFO]none
[INFO]
[INFO]
[INFO] 
[INFO] Building domain 3.4.6-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-dependency-plugin:3.0.1:list (default-cli) @ domain ---
java.lang.NoSuchMethodException: 
jdk.internal.module.ModuleReferenceImpl.descriptor()
at java.base/java.lang.Class.getDeclaredMethod(Class.java:2451)
at 
org.apache.maven.plugins.dependency.utils.DependencyStatusSets.getModuleDescriptor(DependencyStatusSets.java:272)
at 
org.apache.maven.plugins.dependency.utils.DependencyStatusSets.buildArtifactListOutput(DependencyStatusSets.java:227)
at 
org.apache.maven.plugins.dependency.utils.DependencyStatusSets.getOutput(DependencyStatusSets.java:165)
at 
org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute(ResolveDependenciesMojo.java:90)
at 
org.apache.maven.plugins.dependency.AbstractDependencyMojo.execute(AbstractDependencyMojo.java:143)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
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:564)
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)
[INFO]
{code}



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

[jira] [Commented] (MASSEMBLY-854) Upgrade to Plexus Archiver 3.5

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MASSEMBLY-854:
--

GitHub user snicoll opened a pull request:

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

Upgrade to Plexus Archiver 3.5-SNAPSHOT

See MASSEMBLY-854

Please note that this new release of plexus archiver requires Java7

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

$ git pull https://github.com/snicoll/maven-plugins MASSEMBLY-854

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

https://github.com/apache/maven-plugins/pull/115.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 #115


commit eecf761b2edca2f91e52bf601db51bb86fb679d6
Author: Stephane Nicoll 
Date:   2017-06-16T12:34:03Z

Upgrade to Plexus Archiver 3.5-SNAPSHOT




> Upgrade to Plexus Archiver 3.5
> --
>
> Key: MASSEMBLY-854
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-854
> Project: Maven Assembly Plugin
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
> Fix For: 3.0.1
>
>
> There is a critical regression fixed (see 
> https://github.com/codehaus-plexus/plexus-archiver/issues/53)



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