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

2017-10-21 Thread Curtis Rueden (JIRA) 

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

Curtis Rueden commented on MNG-6141:


Hmm, I guess the issue I stumbled over is something different then? Sorry for 
the noise.

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



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

[jira] [Created] (MINVOKER-227) install goal cannot install extraArtifacts from local repository

2017-10-21 Thread Ilya Gorbunov (JIRA) 
Ilya Gorbunov created MINVOKER-227:
--

 Summary: install goal cannot install extraArtifacts from local 
repository
 Key: MINVOKER-227
 URL: https://issues.apache.org/jira/browse/MINVOKER-227
 Project: Maven Invoker Plugin
  Issue Type: Bug
Affects Versions: 3.0.1, 3.0.0
 Environment: Apache Maven 3.5.0 
(ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T22:39:06+03:00)
Maven home: C:\Tools\mvn3.5.0\bin\..
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_144\jre
Default locale: en_US, platform encoding: Cp1251
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Reporter: Ilya Gorbunov
 Attachments: invoker-install-fail.zip

Installing extra artifacts from local maven repository worked with 
maven-invoker-plugin 2.0.0, but stopped to work in 3.0.0.

Steps to reproduce:
- extract archive
- in project1 run {{mvn install}} to install it to local maven repository
- in project2 run {{mvn invoker:install}}. It fails to install project1 to a 
custom repository when it is specified as an extra artifact.



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

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

2017-10-21 Thread Christian Schulte (JIRA) 

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

Christian Schulte updated MNG-6141:
---
Description: 
Overriding the dependency management in a module's {{}} section, 
the overridden value will not be preserved transitively. It makes no sense to 
be able to override the dependency management in a module if that is only 
effective in that module and nowhere else. Overriding the dependency management 
from inside a {{}} element should be considered an anti-pattern. 
Maven should provide a warning when it is used. During the development of Maven 
3.4, there have been quite a few discussions on dev@ about build issues which 
were all caused by overriding the dependency management that way without 
noticing this is not supported transitively.


  was:
Overriding the dependency management in a module, the overridden value will not 
be preserved transitively. It makes no sense to be able to override the 
dependency management in a module if that is only effective in that module and 
nowhere else. Overriding the dependency management should be considered an 
anti-pattern. Maven should provide a warning when it is used. During the 
development of Maven 3.4, there have been quite a few discussions on dev@ about 
build issues which were all caused by overriding the dependency management 
without noticing this is not supported transitively.



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



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

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

2017-10-21 Thread Christian Schulte (JIRA) 
Christian Schulte created MRESOLVER-33:
--

 Summary: New class 'DefaultDependencyManager' managing 
dependencies on all levels supporting transitive dependency management.
 Key: MRESOLVER-33
 URL: https://issues.apache.org/jira/browse/MRESOLVER-33
 Project: Maven Resolver
  Issue Type: New Feature
Reporter: Christian Schulte
Priority: Trivial


The {{ClassicDependencyManager}} ignores the dependency management from 
transitive dependencies to maintain backwards compatibility with Maven 2, then 
Maven 3 (objective when extracting Aether was to keep compatibility).

The {{TransitiveDependencyManager}} will use that dependency management and 
will still support management overrides from inside {{}} 
elements. See the linked issues.

The {{DefaultDependencyManager}} will no longer support such overrides and can 
be considered the default implementation from a resolver point of view.



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

[jira] [Updated] (MRESOLVER-10) New class 'TransitiveDependencyManager' supporting transitive dependency management.

2017-10-21 Thread Christian Schulte (JIRA) 

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

Christian Schulte updated MRESOLVER-10:
---
Description: 
The {{ClassicDependencyManager}} ignores the dependency management from 
transitive dependencies to maintain backwards compatibility with Maven 2, then 
Maven 3 (objective when extracting Aether was to keep compatibility).

The new {{TransitiveDependencyManager}} will use that dependency management: 
this new behaviour is expected to be a better choice. Once it is integrated 
into Maven core (version to be defined) as default new behaviour = a behaviour 
that is more predictible/logical, but that will break some previously working 
builds.


  was:
The {{ClassicDependencyManager}} ignores the dependency management from 
transitive dependencies to maintain backwards compatibility with Maven 2, then 
Maven 3 (objective when extracting Aether was to keep compatibility).

The new {{TransitiveDependencyManager}} will use that dependency management: 
this new behaviour is expected to be a better choice.
It could also be named {{DefaultDependencyManager}}, once it is integrated into 
Maven core (version to be defined) as default new behaviour = a behaviour that 
is more predictible/logical, but that will break some previously working builds.



> New class 'TransitiveDependencyManager' supporting transitive dependency 
> management.
> 
>
> Key: MRESOLVER-10
> URL: https://issues.apache.org/jira/browse/MRESOLVER-10
> Project: Maven Resolver
>  Issue Type: New Feature
>  Components: resolver
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> The {{ClassicDependencyManager}} ignores the dependency management from 
> transitive dependencies to maintain backwards compatibility with Maven 2, 
> then Maven 3 (objective when extracting Aether was to keep compatibility).
> The new {{TransitiveDependencyManager}} will use that dependency management: 
> this new behaviour is expected to be a better choice. Once it is integrated 
> into Maven core (version to be defined) as default new behaviour = a 
> behaviour that is more predictible/logical, but that will break some 
> previously working builds.



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

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

2017-10-21 Thread Christian Schulte (JIRA) 

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

Christian Schulte commented on MNG-6141:


[~joehni] To not introduce any misunderstandings. This issue is about 
overriding dependency management locally within a module's {{}} 
section. Such overrides are only in effect locally during building the module 
and nowhere else - not even in the same reactor. See the attached example 
project. You could override the dependency management inside 
{{}} in a consistent way, though.

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



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

[jira] [Created] (MCLEAN-79) Partial Clean + Configurable Selectors

2017-10-21 Thread Matthew Ouyang (JIRA) 
Matthew Ouyang created MCLEAN-79:


 Summary: Partial Clean + Configurable Selectors
 Key: MCLEAN-79
 URL: https://issues.apache.org/jira/browse/MCLEAN-79
 Project: Maven Clean Plugin
  Issue Type: New Feature
Affects Versions: 3.0.0
Reporter: Matthew Ouyang
 Attachments: clean-partial.patch

Partial cleanup would be useful in situations where source files are deleted or 
changing between feature branches (which also can result in deleted source 
files).  This would eliminate the need to do a full clean.

Looking for feedback on provided patch.  To enable this, Selectors need to be 
configurable + some POC implementations (IdentitySelector, JavaSelector) have 
between provided.  The patch also includes a page that describes the new 
feature in more detail, and Selectors have been placed in a separate package 
(now that there is more than one implementation).



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

[jira] [Commented] (MCLEAN-78) Ability to retry longer if clean fails

2017-10-21 Thread Matthew Ouyang (JIRA) 

[ 
https://issues.apache.org/jira/browse/MCLEAN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214140#comment-16214140
 ] 

Matthew Ouyang commented on MCLEAN-78:
--

[~cowwoc] The ability to configure unlimited retries might be a better solution 
fit for your situation. What do you think? I also wonder what the project team 
thinks of this proposal.

> Ability to retry longer if clean fails
> --
>
> Key: MCLEAN-78
> URL: https://issues.apache.org/jira/browse/MCLEAN-78
> Project: Maven Clean Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
> Environment: Windows 10, 64-bit, build 10.0.14393
>Reporter: Gili
>
> Following up on MCLEAN-45, I am running into a problem where a build fails to 
> clean 100% of the time. The existing retry mechanism sleeps roughly 1 second, 
> which makes it impossible to investigate what is actually holding the lock. I 
> already went through the obvious culprits by disabling Windows Indexing and 
> anti-virus, to no avail. I can reproduce the problem on two separate machines 
> as well. I am afraid that Maven itself might be holding the lock.
> I order to aid troubleshooting of this scenario, can you please add or 
> enhance the existing configuration options so that the clean plugin can retry 
> longer (e.g. up to 30 seconds)?
> Worse-case scenario, the lock will eventually get released and my build will 
> work. Best-case scenario, the lock won't get released but I will finally have 
> enough time to run SysInternals ProcessMonitor to figure out who is holding 
> the lock. When I try doing this after the JVM shuts down, I don't find anyone 
> holding the lock so I strongly suspect the JVM itself is at fault.
> Proposal: let users specify a max retry time and generate the intermediate 
> sleep intervals on their behalf. I would happily use retry intervals of up to 
> a minute if it meant that my automated builds would be more stable.



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

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

2017-10-21 Thread Enrico Olivelli (JIRA) 

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

Enrico Olivelli commented on SUREFIRE-1424:
---

Ok let's wait, there is no hurry.
If you want me to start working on the patch just ping me.
I think that most of the work will be about changing it tests and then writing 
docs.

Anyway IMHO I think that we not in charge of answering with maven documentation 
to questions which are directed to JDK maintainers.


> 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-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1424:


No, this is not serious.
Serious would be to let Oracle answer 
https://issues.apache.org/jira/browse/SUREFIRE-1424?focusedCommentId=16213853=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16213853

> 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-21 Thread Enrico Olivelli (JIRA) 

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

Enrico Olivelli commented on SUREFIRE-1424:
---

IMO we can drop the trick and add the help as soon as possible, then we have 
time to give suggestions.
Every one, even non maven users, has the same issue, of finding the good set of 
dependency to replace legacy parts of the JRE.

Sure I can work on this

> 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-1262) Add modulepath support

2017-10-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1262:


I have several TODOs with unit tests. JaCoCo curve got worse suddenly.

On Sat, Oct 21, 2017 at 1:49 PM, Robert Scholte (JIRA) 



> Add modulepath support
> --
>
> Key: SUREFIRE-1262
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1262
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Tibor Digana
> Fix For: Backlog
>
>
> With the Jigsaw project Java9 is extended with a modulepath. This means that 
> surefire should be executed in a different way.
> When working with a modulepath, the Classpath in the MANIFEST of the 
> executable jar will be ignored, you need need to add everything on 
> commandline. 
> Just like javadoc, the java executable has an {{@}} option, where you 
> can add arguments per line. So this is the new preferred way to build the 
> module-path.
> IIUC for surefire it is important to add {{--patch-module 
> target/test-classes}} (was: -Xpatch) which makes it possible to use the same 
> packages as target/classes.



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

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

2017-10-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1424:


[~eolivelli]
We still do not have answer for [1] and clarity what to say in documentation 
regarding dependencies which will substitute removed API. The Oracle should 
answer this.
[1]:
https://issues.apache.org/jira/browse/SUREFIRE-1424?focusedCommentId=16213853=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16213853

> 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-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1424:


[~eolivelli]
Additionally, documentation {{java9.html}} and FAQ.
I am working on unit tests in the branch SUREFIRE-1262 and one more issue.
If we were two, the release would go out faster too.

> 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-21 Thread Enrico Olivelli (JIRA) 

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

Enrico Olivelli commented on SUREFIRE-1424:
---

[~tibor17] I will be happy to help.
Next week I will be very busy, but if there is no hurry I can do this.
Remove the hack, add the help msg and  change it tests.
I will need your help eventually for it tests.
Feel free to assign the issue to me if there is no rush

> 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-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1424:


Do you [~eolivelli] or anybody else wants to do it?
There is more work. As in my comment, but also to keep *Java9*IT integration 
tests working. Let them fail and the error message should be asserted with 
something like "Do you use deleted Java SE API? Please see 
http://maven.apache.org/surefire/maven-surefire-plugin/java9.html;.

> 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-21 Thread Enrico Olivelli (JIRA) 

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

Enrico Olivelli commented on SUREFIRE-1424:
---

+1 for dropping -add-modules java.ee.se

> 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-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana edited comment on SUREFIRE-1424 at 10/21/17 11:50 AM:
---

[~eolivelli]
Flag=config param means for me that this configuration would be obsolete in 
Java 10, and I do not want to maintain one more parameter, therefore I vote to 
drop the feature {{-add-modules java.ee.se}} of version 2.20.1 and commit the 
removal in 2.21.0.Jigsaw. Of course old documentation should stay and a new one 
should be added related to 2.21.0.
We already have too many configuration parameters, so better to drop this and 
throw exception on Build Error (if any test fails) with clear link to our 
documentation (if Java specification version >= 9).
The documentation in Surefire should mention on how to use Maven profiles, 
{{-add-modules java.ee.se}} in {{argLine}} for version 2.21.0 or higher, Maven 
dependencies substituting removed API and implementation, and a link to Jigsaw 
doc where Oracle must update it.
If somebody removes a feature, he should obviously take care of writing 
documentation which gives the user alternatives and contact the communities 
about consequencies.


was (Author: tibor17):
[~eolivelli]
Flag=config param means for me that this configuration would be obsolete in 
Java 10, and I do not want to maintain one more parameter, therefore I vote to 
drop the feature {{-add-modules java.ee.se}} of version 2.20.1 and commit the 
removal in 2.21.0.Jigsaw. Of course old documentation should stay and a new one 
should be added related to 2.21.0.
We already have too many configuration parameters, so better to drop this and 
throw exception on Build Error (if any test fails) with clear link to our 
documentation (if Java specification version >= 9).
The documentation in Surefire should mention on how to use Maven profiles, 
{{-add-modules java.ee.se}} in {{argLine}} for version 2.21.0 or higher, Maven 
dependencies substituting removed API and implementation, and a link to Jigsaw 
which Oracle must be update.
If somebody removes a feature, he should obviously take care of writing 
documentation which gives the user alternatives and contact the communities 
about consequencies.

> 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-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana edited comment on SUREFIRE-1424 at 10/21/17 11:49 AM:
---

[~eolivelli]
Flag=config param means for me that this configuration would be obsolete in 
Java 10, and I do not want to maintain one more parameter, therefore I vote to 
drop the feature {{-add-modules java.ee.se}} of version 2.20.1 and commit the 
removal in 2.21.0.Jigsaw. Of course old documentation should stay and a new one 
should be added related to 2.21.0.
We already have too many configuration parameters, so better to drop this and 
throw exception on Build Error (if any test fails) with clear link to our 
documentation (if Java specification version >= 9).
The documentation in Surefire should mention on how to use Maven profiles, 
{{-add-modules java.ee.se}} in {{argLine}} for version 2.21.0 or higher, Maven 
dependencies substituting removed API and implementation, and a link to Jigsaw 
which Oracle must be update.
If somebody removes a feature, he should obviously take care of writing 
documentation which gives the user alternatives and contact the communities 
about consequencies.


was (Author: tibor17):
[~eolivelli]
Flag=config param means for me that this configuration would be obsolete in 
Java 10, and I do not want to maintain one more parameter, therefore I vote to 
drop the feature {{-add-modules java.ee.se}} of version 2.20.1 and commit the 
removal in 2.21.0.Jigsaw. Of course old documentation should stay and a new one 
should be added related to 2.21.0.
We already have too many configuration parameters, so better to drop this and 
throw exception on Build Error (if any test fails) with clear link to our 
documentation (if Java specification version >= 9).
The documentation in Surefire should mention on how to use Maven profiles, 
{{-add-modules java.ee.se}} in {{argLine}} for version 2.21.0 or higher, Maven 
dependencies substituting removed API and implementation, and a link to Jigsaw 
which Oracle must be updated.
If somebody removes a feature, he should obviously take care of writing 
documentation which gives the user alternatives and contact the communities 
about consequencies.

> 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-1262) Add modulepath support

2017-10-21 Thread Robert Scholte (JIRA) 

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

Robert Scholte commented on SUREFIRE-1262:
--

[~tibor17], I think this is looking good and ready to be merged.

> Add modulepath support
> --
>
> Key: SUREFIRE-1262
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1262
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Tibor Digana
> Fix For: Backlog
>
>
> With the Jigsaw project Java9 is extended with a modulepath. This means that 
> surefire should be executed in a different way.
> When working with a modulepath, the Classpath in the MANIFEST of the 
> executable jar will be ignored, you need need to add everything on 
> commandline. 
> Just like javadoc, the java executable has an {{@}} option, where you 
> can add arguments per line. So this is the new preferred way to build the 
> module-path.
> IIUC for surefire it is important to add {{--patch-module 
> target/test-classes}} (was: -Xpatch) which makes it possible to use the same 
> packages as target/classes.



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

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

2017-10-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1424:


[~eolivelli]
Flag=config param means for me that this configuration would be obsolete in 
Java 10, and I do not want to maintain one more parameter, therefore I vote to 
drop the feature {{-add-modules java.ee.se}} of version 2.20.1 and commit the 
removal in 2.21.0.Jigsaw. Of course old documentation should stay and a new one 
should be added related to 2.21.0.
We already have too many configuration parameters, so better to drop this and 
throw exception on Build Error (if any test fails) with clear link to our 
documentation (if Java specification version >= 9).
The documentation in Surefire should mention on how to use Maven profiles, 
{{-add-modules java.ee.se}} in {{argLine}} for version 2.21.0 or higher, Maven 
dependencies substituting removed API and implementation, and a link to Jigsaw 
which Oracle must be updated.
If somebody removes a feature, he should obviously take care of writing 
documentation which gives the user alternatives and contact the communities 
about consequencies.

> 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-21 Thread Alan Bateman (JIRA) 

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

Alan Bateman commented on SUREFIRE-1424:


Dropping `--add-modules=java.se.ee`, which I think is what Enrico is proposing 
with #2, is the way to go. Anyone with a library or application that depend on 
the Maven artifact and it should just work. Ditto for module projects where 
they can deploy the java.transaction module on the module path and it should 
just work too.

> 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-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1424:


I want to update documentation and list all dependencies which must be added by 
the user instead of removed modules.
I did some research by myself but I am not sure if the substitutes of removed 
API is compliant with Java 9 and implementation.
Please help somebody!
Oracle should add Maven dependencies as substitutes of removed modules here: 
http://openjdk.java.net/jeps/261.

These are the removed modules:
java.corba
java.transaction
java.activation
java.xml.bind
java.xml.ws
java.xml.ws.annotation

These are the Maven artifacts as API (no implementation), which I am not sure 
if versions are compatible with API in Java 9:
javax.activation:javax.activation-api:1.2.0
javax.transaction:javax.transaction-api:1.2
javax.xml.bind:activation:1.0.2
javax.xml.bind:jaxb-api:2.3.0
javax.xml.ws:jaxws-api:2.3.0

This is the implementation of JAXB but I am missing version 2.3.0:
javax.xml:jaxb-impl:2.1

I am missing CORBA and implementation for the APIs.

> 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-21 Thread Enrico Olivelli (JIRA) 

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

Enrico Olivelli commented on SUREFIRE-1424:
---

IMHO we have two options:
1)  Add a flag to inject java.ee.se in case of java9
Or
2) Drop it and write a doc which explains how to use maven profiles and 
surefire arg line to add java.ee.se in case of java9

I can send a pr for 1) or help writing a blog post for 2)



> 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-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1424:


No it is not healthy but it is feature required from your group, Users. Just 
check it in Jira and you will see. I am now comparing the set of classes in 
modules for removal against Java 8. This is really bad situation and 
[~eolivelli] and [~mmusgrov] in {{SUREFIRE-1265}} required this feature so the 
users should say what to do now. But the worst is that I and we spent our 
private time to enter integration tests and code and I am really angry about 
what Oracle's consequences cause here!!!

> 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-21 Thread Krzysztof Krason (JIRA) 

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

Krzysztof Krason commented on SUREFIRE-1424:


I don't think there is a point in arguing what should be in JDK and what 
shouldn't, who is right and who is not.

Current situation is that surefire makes something that user doesn't expect 
(adding all modules under java.se.ee) and has to do workarounds to make 
surefire work with given application (make user choose which modules to load, 
don't do it for him). As of now when one encounters a problem similar to the 
one discussed here, "the net" recommends using older surefire/failsafe version. 
I think this is not a healthy situation.


> 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-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1424:


[~alanb]
[~AlanBateman]
Again, however I understand class loading issue, the Oracle did not do what 
they planned to initially to do. They wanted JDK/JRE to simply extend by adding 
jar modules. Current status in Java 9 is a precedence and anything can be 
changed so that you would not tell that it would be Java in few years. Java was 
built on fact that it was stable and not removed.
So Oracle should rely on initial idea that {{javax}} packages and 
{{java.transaction}} are extensions and should go to separate jar file files 
and User would download them from Oracle's {{downloads.html}} and/or 
installation on Windows will interactively download it in to JRE 9 and 
reconstruct what people rely on. The bad is that Oracle {{unplugged}} modules 
and {{removed}} classes without giving ability to get it back to previous 
status preventing from happened precedence.
Instead your arguments are {{because of EE classes}}, but it is not entirely 
truth because {{Java Activation}} and {{JAXB}} are pure static utilities and 
annotations which have nothing to do with container managed app. You can easily 
run the utilities in {{public static void main()}}.
Oracle could make it so dynamic that application without {{module-info}} would 
behave as before and all modules are on classpath as it was in Java 8, and 
opposite in modular app is recognized. {{Now Surefire substitutes this behavior 
and I think this is what Users want}}. But no, Oracle {{dictated}} something in 
the world and we have the problem, we have to do your job! This is the problem.

> 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] [Issue Comment Deleted] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

2017-10-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana updated SUREFIRE-1424:
---
Comment: was deleted

(was: [~alanb]
[~AlanBateman]
Again, however I understand class loading issue, the Oracle did what they 
planned to initially to do. They wanted JDK/JRE to simply extend by adding jar 
modules. Now it is a precedence and anything can be changed so that you would 
not tell that it would be Java in few years. Java was built on fact that it was 
stable and not removed.
So they should rely on initial idea that {{javax}} packages and 
{{java.transaction}} are extensions and should go to separate jar file files 
and User would download them from Oracle's {{downloads.html}} and/or 
installation on Windows will interactively download it in to JRE 9 and 
reconstruct what people rely on. The bad is that you {{unplugged}} modules and 
{{removed}} classes without giving ability to get it back to previous status 
and not to accomplish the precedence.
Instead your arguments are {{because of EE}}, but it is not truth because Java 
Activation and JAXB are pure static utilities and annotations which have 
nothing to do with container managed app. You can easily run the utilities in 
{{public static void main()}}. You could make it so dynamic that application 
without {{module-info}} would behave as before and all modules are on classpath 
as it was in Java 8,and opposite in modular app. {{Now Surefire substitutes 
this behavior and I think this is what Users want}}. But no, Oracle 
{{dictated}} something and we have the problem, we have to do your job! This is 
the problem.)

> 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-21 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1424:


[~alanb]
[~AlanBateman]
Again, however I understand class loading issue, the Oracle did what they 
planned to initially to do. They wanted JDK/JRE to simply extend by adding jar 
modules. Now it is a precedence and anything can be changed so that you would 
not tell that it would be Java in few years. Java was built on fact that it was 
stable and not removed.
So they should rely on initial idea that {{javax}} packages and 
{{java.transaction}} are extensions and should go to separate jar file files 
and User would download them from Oracle's {{downloads.html}} and/or 
installation on Windows will interactively download it in to JRE 9 and 
reconstruct what people rely on. The bad is that you {{unplugged}} modules and 
{{removed}} classes without giving ability to get it back to previous status 
and not to accomplish the precedence.
Instead your arguments are {{because of EE}}, but it is not truth because Java 
Activation and JAXB are pure static utilities and annotations which have 
nothing to do with container managed app. You can easily run the utilities in 
{{public static void main()}}. You could make it so dynamic that application 
without {{module-info}} would behave as before and all modules are on classpath 
as it was in Java 8,and opposite in modular app. {{Now Surefire substitutes 
this behavior and I think this is what Users want}}. But no, Oracle 
{{dictated}} something and we have the problem, we have to do your job! This is 
the problem.

> 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-21 Thread Alan Bateman (JIRA) 

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

Alan Bateman commented on SUREFIRE-1424:


Again, at issue here is that you cannot upgrade a module  by means of a JAR 
file on the class path. For class path applications, the JDK does not resolve 
the java.transaction module so you can put JTA on the class path and it should 
work like any library on the class path. However if you compile or run with 
`--add-modules java.transaction` (or "java.se.ee" or "ALL-SYSTEM") then 
java.transaction will be resolved so the class path will never be search for 
classes in the javax.transaction package.

Constrast that with JDK 8 where the only supported way to upgrade JTA with the 
version from Java EE was to use the endorsed standards override mechanism. 
Aside from app servers, few knew about that mechanism and instead deployed the 
JTA JAR file on the class path. If you probe closely then you'll see that the 
javax.transaction.xa classes were always loaded from the JDK. In the case of 
the javax.transaction package (where Java SE only defines a small subset), some 
of the classes were loaded from the JDK, some from the JAR file. It was only an 
accident that it ever worked.

> 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)