Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9
On 29/09/2017 08:57, Enrico Olivelli wrote: : 2) dealing with modules like java.sql which as not in java.base (http://download.java.net/java/jdk9/docs/api/java.base-summary.html) Currently I have no solution as there is no official maven dependency for java.sql package You shouldn't need to be concerned with the java.sql module. The only modules that you need to be concerned about are: java.corba java.transaction java.activation java.xml.bind java.xml.ws java.xml.ws.annotation and the java.se.ee aggregator. These modules are deprecated in Java SE and are proposed to be removed in a future release. Aside from java.corba, the 5 modules shared with Java EE are standalone technologies, each with one or more JSRs and its own download. Each of these projects used to be on java.net but moved to the Java EE github project recently. I don't know if the move to Eclipse will change anything there. In any case, each of the standalone versions can be deployed on the class path with JDK 9. In time they will be deployable as modules too and this will allow them to be deployed on the upgrade module path (--upgrade-module-path) to upgrade/override the module in the run-time image with the standalone or Java EE module. This will actually work with all except for the transaction API as there are a couple of issues to sort out there before it can be deployed as a module. As I understand it, the Spring folks in the JIRA issue are deploying the JTA JAR file on the class path. That should just work but is complicated by `--add-module=java.se.ee` as that will cause the java.transaction module to be resolved. You can't split the javax.transaction package between a module and the class path. For the surefire plugin then dropping the --add-modules should be looked at. You'll need to do that anyway once java.se.ee goes away. If the plugin relies on JAXB then adding a dependency on the standalone version should work. -Alan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: module-info hygiene
On 17/10/2016 08:32, Peter Levart wrote: : Do we need an --exclude-modules (in addition to --add-modules) option on javac, java and jlink commands? --exclude-modules would be different to --limit-modules. If some module requires module M and there is no module M on the module path or it is not observable because it was not mentioned in the --limit-modules option, then an exception is raised. OTOH if some module X requires module M and module M is mentioned in the --exclude-modules option, then such requires is silently ignored in hope that module X will not actually need types from module M. The module declaration is intended to be authoritative and so we have to trust module author when they declare that the module `requires M`. So my view is that options such as --exclude-modules that would have the effect of dropping requires puts us on the road to anarchy. That said, I do see Robert's concern that there might be orphaned `requires` clauses in some modules. My module started using the preferences API but later the implementation changed to use something else. I neglected to remove the `requires java.prefs` from the module declaration and the result is that my module cannot compile against or run on a run-time image that doesn't include this module. Static analysis tools might help here, as might the IDE. We are used to IDEs highlighting unused `import` statements and in time then I expect they will do the same for apparently unused `requires` clauses in module-info.java. If the usage is purely reflective then the module author might need to put a comment on the `requires` clause to avoid other maintainers from removing it (a bit like "// used by javadoc" in comments today when an import is for an unqualified reference in the javadoc). Another part to Robert's mail is the case where something is making use of types in modules that it doesn't depend on. Assuming these are static references then they will be caught at compile-time. This is big improvement compared to today's class path. A more general comment is that module authors will need to learn a few new things about compatibility and refactoring. One example is changing `requires transitive M` to `requires M` is an incompatible change. Another is splitting a module (several sub-cases) where the module author will need to add `requires transitive` to avoid breaking consumers. There are lots of opportunities here for authoritative books and documentation to help module authors do this right. -Alan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Specifying module paths
On 15/01/2016 09:06, Robert Scholte wrote: Suppose there's a logging module and a fat module, which also contains the classes of the logging module, but older. In my module-info I have requires logging; requires fat; These modules are in the same directory. Which class is loaded first and why? If it is the order in the module-info, then I would also like to see an example of the strategy with "requires public". The module names seems to be unique here so it doesn't matter if these two (packaged) modules are in the same directory or different directories that you specify to -modulepath in random order. The issue of modules with different names but overlapping packages is a different topic but a topic where there is much to say. Let's suppose that both module logging and module fat export the same package. Now suppose you have a module m1 that requires logging and requires fat. In that case you will get a compilation error as m1 is reading two modules exporting the same package to m1. If there is subterfuge used to compile this then it will fail at startup/runtime for the same reason. Now suppose that the logging API is exported by module logging but not exported by module fat. This may be the example you have in mind. I assume the owner of fat has decided to create this uber JAR with an old version of logging and without re-packaging it. We'll assume m1 requires logging and m1 requires fat as before. In that case, then m1 should compile as the logging.* types are only coming from one module. At run-time then it will fail at startup when logging and fat on the application module path. The error is that module logging and module fat cannot be defined to the same class loader because they have types in the same package. This is not an inherit issue in the module system, it's just a implementation limitation with modules on the application module path. A more sophisticated launcher would use the Layer API to put define modules with overlapping packages to different class loaders. It's somewhat tricky for the this to be done automatically when there is both an application module path and an application class path. The reason is that components on the class path require visibility of modules on the application module path. Conversely, automatic modules on the application module path need types on the class path to be visible. This is something that will need to be sorted out. I realize this may be more than you were looking for but the point is that there isn't any ambiguity as to where the logging classes are loaded from. A module is making use of types in package p then those types can only come from one module. The use of `requires public doesn't change this, instead it just increases the set of modules that are read. -Alan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RFE support jar as modulepath argument
On 03/12/2015 19:49, Robert Scholte wrote: After reading the specs it seems like I can only refer to a directory containing modules. For a dependency specified in the pom.xml I could refer to the directory (within the local repository) containing that specific artifact. However, such directory contains more files, so I can't be certain the correct file is picked up (e.g. cooomons-lang3-3.4[2]. Both commons-lang3-3.4.jar and commons-lang3-3.4-tests.jar might contain a module-info.class, but it is uncertain if this was the file specified as dependency). As Mark said, this has come up a few times and good to support this (it's easy, the only question might be whether it should allow exploded modules too). Just on the example, then I assume that commons-lang3-3.4-sources.jar and commons-lang3-3.4-javadoc.jar won't have a module declaration and so would be treated as automatic modules. This isn't going to work of course because the module name derived for both will be "commons-lang3" and we can't have 2+ modules with the same name in the same directory. I think *-tests.jar brings many discussion points and maybe something for another thread. In brief, if the tests are in their own package hierarchy, not overlapping with the packages in the library that they test, then the tests could be another module with their own module declaration. If the tests are in the same packages as the APIs that they are testing (this is typical, also necessary when testing package private types or methods) then they won't be their own module but will instead need to be grafted onto the module that they are testing. We've worked through several examples and I think we have all the options in place, we'll just need to make sure that it is easy to use and having Maven plugins supporting those options would be a great help. -Alan. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RFE support jar as modulepath argument
On 04/12/2015 12:27, Ali Ebrahimi wrote: Just as I said in another thread post: If we have module group concept and modules belong to same module group loaded by same classloader then we can support splited packages. This way each module group maps to each classloader. This will support test modules. We've been down this road in the distant past with "requires local" and I don't think we want to go there again :-) We've worked through many testing examples with the current design and prototype and haven't run into any major issues. The main thing to say is that TestNG, JUnit and other testing frameworks don't know about modules yet but we can get existing versions to work okay, it just needs command-line options that will look complicated at first, esp. when compiling or injecting test classes into existing modules. I think we should be confident that the tools and plugins will make this much easier in time. Just another reason why it's so critical to have tools and eco system working with us as the module system design (and implementation) moves forward. -Alan
Re: JavaxToolsCompiler
On 17/09/2015 22:07, Robert Scholte wrote: I can confirm the fix. thanks! Robert Thanks for the confirmation. Just to double check, this is with the ToolProvider fix rather than the patch to the compiler plugin that one of Stuart's mails referenced, right? As we're exchanging mail, I'm curious as to which plugins are exercised by your testing, just in case there are other plugins where we might still run into issues. -Alan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavaxToolsCompiler
On 14/09/2015 20:21, Stuart McCulloch wrote: Yes, the issue is that ToolProvider.getSystemJavaCompiler() is returning null when using the Jigsaw EA with Maven. AFAICT this is because it’s now using the service loader mechanism which is influenced by the Thread’s context ClassLoader The following patch to make sure Maven uses the system context when looking up the compiler appears to solve the issue: Just to follow-up on this one, the bug in ToolProvider has been fixed in the jigsaw/jake forest. We should have an updated EA build in the next day or two that will pick up this fix. Thanks again for the mails on this, it's good to have found this one early. -Alan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavaxToolsCompiler
On 14/09/2015 17:40, Robert Scholte wrote: Hi, On behalf of the Apache Maven team I'd like to ask for advice for changing the JavaxToolsCompiler[1] This implementation is used when java code is being compiled with Maven *by default*, so right now when pointing JAVA_HOME to the latest JDK9 version builds will fail. There are other ways to compile, e.g. use the fork-parameter[2] or with toolchains[3], but what I'd like to know is whether it is still possible/valid to use javax.tools.JavaCompiler and is so: how should we rewrite this code? Thanks for bringing this up as a few people have reported issues with Maven not finding the compiler. Just to be clear, are you seeing this issue with the regular JDK 9 EA builds or just the Jigsaw EA builds? Did this start when tools.jar went away? I just did a quick test to check that ToolProvider.getSystemJavaCompiler() is returning the system JavaCompiler is returned for both builds (and it is). Is the issue that you are seeing that getSystemJavaCompiler() is returning null? -Alan. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavaxToolsCompiler
On 14/09/2015 20:21, Stuart McCulloch wrote: Yes, the issue is that ToolProvider.getSystemJavaCompiler() is returning null when using the Jigsaw EA with Maven. AFAICT this is because it’s now using the service loader mechanism which is influenced by the Thread’s context ClassLoader That may be a bug as I wouldn't expect the ToolProvider.getSystemXXX methods to locate the these tools via the TCCL. -Alan. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven JDeps Plugin
On 13/04/2015 03:46, Hervé BOUTEMY wrote: last week, during DevoxxFR, Arnaud and I showed maven-jdeps-plugin: as expected, a lot of users didn't know about this tool So for sure, having this plugin and a report would help Then there is the question of: what should the report look like? Should it be a simple stdout dump of command line result? ugly... During DevoxxFR, I saw a graph of Java modules dependencies: having a report putting info on this graph could really be more expressive than console. Is there an html report available for jdeps? Should we parse text output to work on a graphic report? (seems hard...) jdeps can produce .dot files when you use -dotoutput. You can then you use Graphviz layout or other tools to draw graphs. Would that help? -Alan. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
