[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[ 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
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.
[ 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.
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.
[ 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.
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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)