[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

2017-10-19 Thread Julian Reschke (JIRA) 

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

Julian Reschke commented on SUREFIRE-1424:
--

Note there's a similar problem with javax.transaction.UserTransaction - see 
.

> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



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

[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

2017-10-19 Thread Alan Bateman (JIRA) 

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

Alan Bateman commented on SUREFIRE-1424:


It's the same issue. If you run with `--add-modules $XXX` where XXX is any of 
"java.transaction", "java.corba", "java.se.ee" or "ALL-SYSTEM" then you'll load 
the java.transaction module from the JDK. I think you are instead hoping that 
the Java Transaction classes on the class path will be loaded and this will 
work if the `--add-modules` is dropped.

This will all be much similar once the JDK jettisons these modules, the first 
steps in that direction happened in JDK 9. Running with `--add-modules` to use 
the java.transaction in the JDK unwinds that, and makes it harder to upgrade.

> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



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

[jira] [Comment Edited] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

2017-10-19 Thread Alan Bateman (JIRA) 

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

Alan Bateman edited comment on SUREFIRE-1424 at 10/19/17 10:26 AM:
---

It's the same issue. If you run with {{--add-modules $XXX` where XXX }} is any 
of "java.transaction", "java.corba", "java.se.ee" or "ALL-SYSTEM" then you'll 
load the java.transaction module from the JDK. I think you are instead hoping 
that the Java Transaction classes on the class path will be loaded and this 
will work if the {{--add-modules}} is dropped.

This will all be much similar once the JDK jettisons these modules, the first 
steps in that direction happened in JDK 9. Running with {{--add-modules}} to 
use the java.transaction in the JDK unwinds that, and makes it harder to 
upgrade.


was (Author: alanbateman):
It's the same issue. If you run with `--add-modules $XXX` where XXX is any of 
"java.transaction", "java.corba", "java.se.ee" or "ALL-SYSTEM" then you'll load 
the java.transaction module from the JDK. I think you are instead hoping that 
the Java Transaction classes on the class path will be loaded and this will 
work if the `--add-modules` is dropped.

This will all be much similar once the JDK jettisons these modules, the first 
steps in that direction happened in JDK 9. Running with `--add-modules` to use 
the java.transaction in the JDK unwinds that, and makes it harder to upgrade.

> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



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

[jira] [Comment Edited] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

2017-10-19 Thread Alan Bateman (JIRA) 

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

Alan Bateman edited comment on SUREFIRE-1424 at 10/19/17 10:27 AM:
---

It's the same issue. If you run with {{-add-modules $XXX` where XXX }} is any 
of "java.transaction", "java.corba", "java.se.ee" or "ALL-SYSTEM" then you'll 
load the java.transaction module from the JDK. I think you are instead hoping 
that the Java Transaction classes on the class path will be loaded and this 
will work if the {{-add-modules}} is dropped.

This will all be much similar once the JDK jettisons these modules, the first 
steps in that direction happened in JDK 9. Running with {{-add-modules}} to use 
the java.transaction in the JDK unwinds that, and makes it harder to upgrade.


was (Author: alanbateman):
It's the same issue. If you run with {{--add-modules $XXX` where XXX }} is any 
of "java.transaction", "java.corba", "java.se.ee" or "ALL-SYSTEM" then you'll 
load the java.transaction module from the JDK. I think you are instead hoping 
that the Java Transaction classes on the class path will be loaded and this 
will work if the {{--add-modules}} is dropped.

This will all be much similar once the JDK jettisons these modules, the first 
steps in that direction happened in JDK 9. Running with {{--add-modules}} to 
use the java.transaction in the JDK unwinds that, and makes it harder to 
upgrade.

> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



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

[jira] [Comment Edited] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

2017-10-19 Thread Alan Bateman (JIRA) 

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

Alan Bateman edited comment on SUREFIRE-1424 at 10/19/17 10:27 AM:
---

It's the same issue. If you run with - -add-modules $XXX where XXX is any of 
"java.transaction", "java.corba", "java.se.ee" or "ALL-SYSTEM" then you'll load 
the java.transaction module from the JDK. I think you are instead hoping that 
the Java Transaction classes on the class path will be loaded and this will 
work if the - -add-modules is dropped.

This will all be much similar once the JDK jettisons these modules, the first 
steps in that direction happened in JDK 9. Running with - -add-modules to use 
the java.transaction in the JDK unwinds that, and makes it harder to upgrade.


was (Author: alanbateman):
It's the same issue. If you run with {{-add-modules $XXX` where XXX }} is any 
of "java.transaction", "java.corba", "java.se.ee" or "ALL-SYSTEM" then you'll 
load the java.transaction module from the JDK. I think you are instead hoping 
that the Java Transaction classes on the class path will be loaded and this 
will work if the {{-add-modules}} is dropped.

This will all be much similar once the JDK jettisons these modules, the first 
steps in that direction happened in JDK 9. Running with {{-add-modules}} to use 
the java.transaction in the JDK unwinds that, and makes it harder to upgrade.

> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



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

[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

2017-10-19 Thread Julian Reschke (JIRA) 

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

Julian Reschke commented on SUREFIRE-1424:
--

I think the magic to include --add-modules was indeed well-intended, but if the 
edge cases affect you it's becoming hard to use 2.20.1 with Java 9. A potential 
compromise would be to leave the magic in, but to have a way to disable it.

> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



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

[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

2017-10-19 Thread Julian Reschke (JIRA) 

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

Julian Reschke commented on SUREFIRE-1424:
--

FWIW, I've for now worked around the issue by always specifying:
{noformat}
-XX:+IgnoreUnrecognizedVMOptions --add-modules=java.xml.bind
{noformat}

(Note the "=" because otherwise Java 8 will see two arguments)

> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



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

[jira] [Created] (MDEP-587) test-jar type is incorrectly translated to jar artifact when resolving dependencies

2017-10-19 Thread Michael O'Connor (JIRA) 
Michael O'Connor created MDEP-587:
-

 Summary: test-jar type is incorrectly translated to jar artifact 
when resolving dependencies
 Key: MDEP-587
 URL: https://issues.apache.org/jira/browse/MDEP-587
 Project: Maven Dependency Plugin
  Issue Type: Bug
Affects Versions: 3.0.2
Reporter: Michael O'Connor


When attempting to download a test-jar artifact there seems to be an error in 
how the artifact coordinates get translated. I think, for example, that 
{code}foo:bar:1.0.0-SNAPSHOT:test-jar{code} should be translated to 
{code}foo:bar:1.0.0-SNAPSHOT:jar:tests{code} but instead the plugin is 
translating it to {code}foo:bar:1.0.0-SNAPSHOT:jar{code} which results in 
getting an incorrect artifact

To test, I'll use a random artifact from central that has an uploaded tests jar
{code}mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.2:copy 
-Dartifact=org.neo4j:neo4j-collections:3.3.0:test-jar 
-DoutputDirectory=/tmp/{code} if you compare this to the size of the actual 
test jar and the production jar, (and also watch the url that it downloads 
from) it gets the wrong jar



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

[jira] [Updated] (MDEP-587) test-jar type is incorrectly translated to jar artifact when resolving dependencies

2017-10-19 Thread Michael O'Connor (JIRA) 

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

Michael O'Connor updated MDEP-587:
--
Affects Version/s: 3.0.0
   3.0.1

> test-jar type is incorrectly translated to jar artifact when resolving 
> dependencies
> ---
>
> Key: MDEP-587
> URL: https://issues.apache.org/jira/browse/MDEP-587
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
>Reporter: Michael O'Connor
>
> When attempting to download a test-jar artifact there seems to be an error in 
> how the artifact coordinates get translated. I think, for example, that 
> {code}foo:bar:1.0.0-SNAPSHOT:test-jar{code} should be translated to 
> {code}foo:bar:1.0.0-SNAPSHOT:jar:tests{code} but instead the plugin is 
> translating it to {code}foo:bar:1.0.0-SNAPSHOT:jar{code} which results in 
> getting an incorrect artifact
> To test, I'll use a random artifact from central that has an uploaded tests 
> jar
> {code}mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.2:copy 
> -Dartifact=org.neo4j:neo4j-collections:3.3.0:test-jar 
> -DoutputDirectory=/tmp/{code} if you compare this to the size of the actual 
> test jar and the production jar, (and also watch the url that it downloads 
> from) it gets the wrong jar



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

[jira] [Commented] (MNG-6090) CI friendly properties break submodule builds

2017-10-19 Thread Jon Wilmoth (JIRA) 

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

Jon Wilmoth commented on MNG-6090:
--

FYI - I still see this broken behavior in 3.5.0 (i.e. cd submodule; mvn clean 
install results in error that the could not find the parent artifact with a 
pom:${revision} ):
 
mvn -v
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
2017-04-03T12:39:06-07:00)
Maven home: /usr/local/Cellar/maven/3.5.0/libexec
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.5", arch: "x86_64", family: "mac"


> CI friendly properties break submodule builds
> -
>
> Key: MNG-6090
> URL: https://issues.apache.org/jira/browse/MNG-6090
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.3.9
>Reporter: Harald Wellmann
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.0-beta-1, 3.5.0
>
>
> h3. Scenario
> A multi-module project where the parent version is one of the CI friendly 
> properties, e.g. $\{revision\} as outlined in 
> http://blog.soebes.de/blog/2016/08/08/maven-how-to-create-a-release/.
> There are two submodules submodule1 and submodule2 such that submodule2 
> depends on submodule1.
> h3. Expected behaviour
> Each submodule can be built by itself, e.g.
> {code}
> mvn clean install -Drevision=1.0.0-SNAPSHOT -pl submodule2
> {code}
> or
> {code}
> cd submodule2; mvn clean install -Drevision=1.0.0-SNAPSHOT
> {code}
> h3. Actual behaviour
> This does not work for submodule2 or in general any module that depends on a 
> module from the same reactor.
> Maven cannot resolve the property variable in the referenced parent POM 
> version and fails the build:
> {code}
> [ERROR] Failed to execute goal on project submodule2: Could not resolve 
> dependencies for project com.example:submodule2:jar:1.0.0-SNAPSHOT: Failed to 
> collect dependencies at com.example:submodule1:jar:1.0.0-SNAPSHOT: Failed to 
> read artifact descriptor for com.example:submodule1:jar:1.0.0-SNAPSHOT: Could 
> not find artifact com.exammple:parent:pom:${revision} -> [Help 1]
> {code}
>  
> There is no problem building submodule1 or the entire reactor.
> Same problem observed with a local build from master (3.4.0-SNAPSHOT).



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

[jira] [Commented] (MNG-6090) CI friendly properties break submodule builds

2017-10-19 Thread Jon Wilmoth (JIRA) 

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

Jon Wilmoth commented on MNG-6090:
--

Adding the flatten-maven-plugin to the parent pom did allow the submodule to 
build successfully.  The 
https://maven.apache.org/maven-ci-friendly.html#Install__Deploy section of the 
docs suggests this is only necessary to support older versions of maven.

> CI friendly properties break submodule builds
> -
>
> Key: MNG-6090
> URL: https://issues.apache.org/jira/browse/MNG-6090
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.3.9
>Reporter: Harald Wellmann
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.0-beta-1, 3.5.0
>
>
> h3. Scenario
> A multi-module project where the parent version is one of the CI friendly 
> properties, e.g. $\{revision\} as outlined in 
> http://blog.soebes.de/blog/2016/08/08/maven-how-to-create-a-release/.
> There are two submodules submodule1 and submodule2 such that submodule2 
> depends on submodule1.
> h3. Expected behaviour
> Each submodule can be built by itself, e.g.
> {code}
> mvn clean install -Drevision=1.0.0-SNAPSHOT -pl submodule2
> {code}
> or
> {code}
> cd submodule2; mvn clean install -Drevision=1.0.0-SNAPSHOT
> {code}
> h3. Actual behaviour
> This does not work for submodule2 or in general any module that depends on a 
> module from the same reactor.
> Maven cannot resolve the property variable in the referenced parent POM 
> version and fails the build:
> {code}
> [ERROR] Failed to execute goal on project submodule2: Could not resolve 
> dependencies for project com.example:submodule2:jar:1.0.0-SNAPSHOT: Failed to 
> collect dependencies at com.example:submodule1:jar:1.0.0-SNAPSHOT: Failed to 
> read artifact descriptor for com.example:submodule1:jar:1.0.0-SNAPSHOT: Could 
> not find artifact com.exammple:parent:pom:${revision} -> [Help 1]
> {code}
>  
> There is no problem building submodule1 or the entire reactor.
> Same problem observed with a local build from master (3.4.0-SNAPSHOT).



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