Re: missing resources when using --patch-module

Thanks for the explanation, it makes sense: Patch acts more like an override than an append. best, Robert On 3-4-2020 12:56:10, Alan Bateman wrote: On 03/04/2020 10:17, Robert Scholte wrote: > This issue was registered as SUREFIRE-1768[1] > It contains a very small Maven project to demon

missing resources when using --patch-module

This issue was registered as SUREFIRE-1768[1] It contains a very small Maven project to demonstrate the issue. That project contains one method executing the following: Demo.class.getClassLoader().getResources("demo").asIterator().forEachRemaining(url -> {   System.out.println(url.getFile());

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

Since my request is only about required modules, I'll solely focus on that. The responsibility of a build tool is to provide the right set of modules as described in the module descriptor. But this module descriptor doesn't specify where these modules are coming from, so the build tool should

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

. thanks, Robert On 13-2-2020 00:12:02, Alex Buckley wrote: On 2/12/2020 1:08 PM, Robert Scholte wrote: > To prevent these workarounds and to provide an easier way to patch a > module via a dedicated descriptor will help keeping the module > system cleaner. It will lead to "

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

It is kind of unfortunate that this topic has been hijacked for something I don't see as an issue. I've been able to build up the right set of commandline arguments for this case for both javac and java With *just* the dependencies(respecting compile + test scope) from the pom, and the module

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

the packager shouldn't allow to add it, nor other tools to use it. But these are details open for discussion. Robert On 5-2-2020 08:57:53, Simone Bordet wrote: Hi Robert, On Wed, Feb 5, 2020 at 8:38 AM Robert Scholte wrote: > > Hi Simone, > > I understand your concern, but the pa

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

Hi Simone, I understand your concern, but the patched module descriptor doesn't have to (or should not) replace the --patch-module option. This proposal is about the additional options you now need to put on the commandline, but which already fit in the module descriptor. thanks, Robert On

Re: ServiceLoader.load(Class, ClassLoader) does not load services exposed in modules and loaded by parent CL

+0200, Alan Bateman <alan.bate...@oracle.com> wrote: On 23/05/2018 21:28, Peter Levart wrote: : It's not an official plugin. And it seems that the Maven container is to blame, not the plugin. Robert Scholte is on this mailing list and may be able to comment on this. The nonst

Re: Explicit file names in module-info - #AutomaticModuleNames

On Fri, 05 May 2017 12:36:38 +0200, Stephen Colebourne wrote: I think this design addresses some of Roberts's concern too. With this plan, Maven Central would contain modules depending on automatic modules, but the dependency names would be sufficiently stable for this

Re: Can automatic modules be made to work?

Yes, this option has been mentioned in some form. The good thing about this part is that exports and requires use the same structure, i.e. the package is the unit shared between 2 modules. However, this will probably lead to a long list of requirements, so I understand the choice the name of

Re: Revised proposal for #AutomaticModuleNames

he refer to automodule, because he doesn't control the combinations of jars used by the application developer. thanks, Robert On Thu, 04 May 2017 19:39:06 +0200, <mark.reinh...@oracle.com> wrote: Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and Robert Scholte, for the ex

Re: Can automatic modules be made to work?

The returning question is: how can I as a *library builder* participate in adopting Jigsaw? The first thing you need to ensure is that there are no split package issues. The next steps can be conflicting: - I want to name my module, so my customers can refer to it - I do not want to refer

Re: Automatic module names

On Tue, 07 Feb 2017 14:20:07 +0100, Brian Fox wrote: On Fri, Feb 3, 2017 at 10:40 AM, Alan Bateman wrote: As regards the example naming clash then these two projects might already get complaints over their poor choice of artifacts, esp. when

Re: Automatic module names

On Fri, 27 Jan 2017 16:54:59 +0100, Robert Scholte <rfscho...@apache.org> wrote: On Fri, 27 Jan 2017 15:11:14 +0100, Stephen Colebourne <scolebou...@joda.org> wrote: Back in October, I raised the issue of modules names generally and for automatic modules specifically [1]. The

Re: Automatic module names

Hi Nicolai, let's consider that my project depends on the following dependencies: com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. I somehow want to have them both as requirements: module M.N { requires static library; // com.foo.bar:library requires library; //

Re: Reusing module name token `*` in -d

On Sat, 21 Jan 2017 19:35:28 +0100, Stephan Herrmann wrote: On 01/21/2017 06:52 PM, fo...@univ-mlv.fr wrote: Robert, How do you compile these 2 modules with Maven ? module foo { exports foo to bar; } module bar { requires foo; } when compiling 'foo' javac

Re: Reusing module name token `*` in -d

On Sat, 21 Jan 2017 14:55:50 +0100, Nicolai Parlog wrote: Hi! Ah, i see why you have a problem, a jigsaw module != a sub project A sub project with your layout will contain several modules if you prefer. A jigsaw module is more lightweight that the other kind of

[ANN] Apache Maven Compiler Plugin 3.6.1 Released

The Apache Maven team is pleased to announce the release of the Apache Maven Compiler Plugin, version 3.6.1 Most important change is the support for test-compile when using JDK 9 build b148+ https://maven.apache.org/plugins/maven-compiler-plugin/ You should specify the version in your

Re: modules and tests

On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax wrote: setting command line arguments or using a build tool to fiddle them for you is exactly what we do not want here! We want fidelity between the compile time configuration and the runtime configuration. Having to play

Re: onejars under Jigsaw

Hi, The following topics have been created for this issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleJARs Once resolved we should improve the maven-shade-plugin according the new

Re: module-info hygiene

On Mon, 17 Oct 2016 12:59:25 +0200, Alan Bateman wrote: 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.

Re: module-info hygiene

2016 10:45:26 AM GMT+02:00, Andrew Haley <a...@redhat.com> wrote: On 16/10/16 19:52, Robert Scholte wrote: To enforce the discipline, the java compiler should IMHO at least check if all required modules are indeed required and if the transitive required modules are indeed transitive.

module-info hygiene

Hi, with the introduction of the module-info something interesting is happening. Up until now the scope of a Java project was limited to the compilation of the classes. In case of Maven the end-user was in full control regarding the classpath and the order of entries. With the order of

Re: Module names - related to #ModuleNameSyntax

One thing that is missing here is that you can only control the direct dependencies, you cannot control the transitive dependencies. To complete the example: module com.mycompany:foo-utils { requires guava; // automodule from google } but we also have module com.acme:bar-utils { requires

Review Request: Apache Maven Recipe for module-info and older projects

Hi, I've written a page[1] about the problem related to projects which need to be compatible with pre Java9 versions, but also want to provide a module-info file in case it is used in a Java 9 project. This is mainly an issue for library builders, end-application builders can simply push

Re: [MRJAR] Entry order matters?

Confirmed there's an issue; jar should have been recognized as a multirelease jar. https://bugs.openjdk.java.net/browse/JDK-8165723 thanks, Robert On Mon, 05 Sep 2016 09:10:56 +0200, Alan Bateman <alan.bate...@oracle.com> wrote: On 04/09/2016 21:56, Robert Scholte wrote: :

Re: [MRJAR] Entry order matters?

On Sun, 04 Sep 2016 22:50:00 +0200, Alan Bateman <alan.bate...@oracle.com> wrote: On 04/09/2016 18:01, Robert Scholte wrote: Hi, we have this demo application[1] to show how you can generate a multirelease JAR right now with Maven. However, in my case the result for Java9 i

[MRJAR] Entry order matters?

INF/maven/multirelease/multirelease-base/pom.xml mr/A.class META-INF/maven/multirelease/multirelease-base/ META-INF/maven/ AFAIK the JEP238 doesn't mention something about order. This is an issue on both Windows and Mac. Anyone who has an explanation? regards, Robert Scholte [1] https://github.

Re: Building jar targeting multiple Java versions, including 9

I've been working on the implementation of this in the maven-compiler-plugin, but I'm not really pleased with the result. The problem is that in the worst case scenario we have to work with 3 different versions of Java: - The Maven Runtime (set as JAVA_HOME) - JDK for the module-info.java -

Re: Building jar targeting multiple Java versions, including 9

On Fri, 26 Aug 2016 13:31:47 +0200, Alan Bateman <alan.bate...@oracle.com> wrote: On 26/08/2016 11:49, Robert Scholte wrote: Hi, I'm struggling with this issue too. I would have liked to see all the files under src/main/java, but since module-info cannot be compiled at the sam

Re: Building jar targeting multiple Java versions, including 9

Hi, I'm struggling with this issue too. I would have liked to see all the files under src/main/java, but since module-info cannot be compiled at the same time as the other files we need to do some extra things: Possible solutions: - Keep them all in the same folder but let Maven do 2 javac

Re: Discover modulename

maven.core etc. this way users have a relative simple way to get a complete overview of all the modules used. I might tweak the output, but the info is there. Robert On Thu, 25 Aug 2016 12:26:48 +0200, Robert Scholte <rfscho...@apache.org> wrote: Hi, In an old thread I asked this

Discover modulename

Hi, In an old thread I asked this before and got the following answer: "One way is `jar --file foo.jar -p`. That will print the module descriptor when the JAR file is a modular JAR. There is API support for reading the binary form of the module declaration too." With the renaming of the

Paths in Mutli Release Jar

I noticed that the path is still META-INF/*versions*/ even though the JEP has been renamed from Multi Version jar to Multi Release jar. Is that intended or should/will that be changed as well? thanks, Robert

Javadoc custom Taglets

Hi, in preparation of the DevoxxFr talk about Maven and Java9 by Hervé Boutemy and Arnaud Héritier I noticed some issues with custom taglets when generation Javadoc reports. For the developers of Maven plugins we have a set of Annotations or DocletTags[1] to generate the plugin

Re: modulepath and classpath mixture

On Thu, 17 Mar 2016 21:23:25 +0100, Alan Bateman <alan.bate...@oracle.com> wrote: On 17/03/2016 19:51, Robert Scholte wrote: : To me it seems like the need for knowing the module name keeps returning. This increases the need for a proper implementation of the maven-compiler-

Re: modulepath and classpath mixture

On Mon, 07 Mar 2016 14:53:28 +0100, Sander Mak wrote: I don't think I understand the issue here. Using -Xpatch doesn't change the module declaration or export. It can be used to override or augment the module content, it just can't override the module declaration.

Re: modulepath and classpath mixture

On Mon, 07 Mar 2016 13:13:38 +0100, Alan Bateman <alan.bate...@oracle.com> wrote: On 06/03/2016 14:01, Robert Scholte wrote: Hi, I've asked for some feedback and there seems to be concerns with split packages when there are two or more modules on the module path that export th

Re: modulepath and classpath mixture

On 02/22/2016 12:44 PM, Robert Scholte wrote: Hi, first of all I'd like to say that I'm very pleased with the new -mp options, these matches better with the way Apache Maven would like to work with jars and class-folders. Here's my use case: I noticed that if I add a module-info to src/mai

Re: modulepath and classpath mixture

On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman <alan.bate...@oracle.com> wrote: On 23/02/2016 21:10, Robert Scholte wrote: : If I understand this correctly I need to know the module name. Has there been any discussion around having the module name in the POM? From the

Re: modulepath and classpath mixture

On Wed, 24 Feb 2016 00:15:26 +0100, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote: On 02/23/2016 01:22 PM, Robert Scholte wrote: On Tue, 23 Feb 2016 22:14:32 +0100, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote: On 02/23/2016 01:06 PM, Jonathan Gibbons wro

Re: modulepath and classpath mixture

On Tue, 23 Feb 2016 22:14:32 +0100, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote: On 02/23/2016 01:06 PM, Jonathan Gibbons wrote: On 02/23/2016 12:48 PM, Robert Scholte wrote: On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote

Re: modulepath and classpath mixture

On Tue, 23 Feb 2016 01:30:16 +0100, Alex Buckley <alex.buck...@oracle.com> wrote: Hi Robert, On 2/22/2016 12:44 PM, Robert Scholte wrote: Here's my use case: I noticed that if I add a module-info to src/main/java and put all compile-scoped dependencies to the module path, all compiles

Re: modulepath and classpath mixture

On Tue, 23 Feb 2016 13:59:13 +0100, Alan Bateman <alan.bate...@oracle.com> wrote: On 22/02/2016 20:44, Robert Scholte wrote: Hi, first of all I'd like to say that I'm very pleased with the new -mp options, these matches better with the way Apache Maven would like to work wit

Re: modulepath and classpath mixture

On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote: On 02/22/2016 12:44 PM, Robert Scholte wrote: Hi, first of all I'd like to say that I'm very pleased with the new -mp options, these matches better with the way Apache Maven would like to

modulepath and classpath mixture

Hi, first of all I'd like to say that I'm very pleased with the new -mp options, these matches better with the way Apache Maven would like to work with jars and class-folders. Here's my use case: I noticed that if I add a module-info to src/main/java and put all compile-scoped

Re: hg: jigsaw/jake/langtools: support module files directly on file manager module paths

should now have been addressed by http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/719a1da641c7 -- Jon On 02/03/2016 09:38 AM, Robert Scholte wrote: Hi Jonathan, it seems like this change is not enough, see: Locations.ModulePathLocationHandler::setPaths 910 @Override 911

Re: hg: jigsaw/jake/langtools: support module files directly on file manager module paths

Hi Jonathan, it seems like this change is not enough, see: Locations.ModulePathLocationHandler::setPaths 910 @Override 911 void setPaths(Iterable paths) { 912 if (paths != null) { 913 for (Path p: paths) { 914 if

Re: Specifying module paths

schreef Paul Benedict <pbened...@apache.org>: Robert, in the SOTM document, it explicitly calls out that Module systems are not required to support multiple versions of a module. Correct me if wrong, but I think you're hinting at that? Cheers, Paul On Fri, Jan 15, 2016 at 3:06 AM, Robert S

Re: Specifying module paths

Op Thu, 14 Jan 2016 23:45:32 +0100 schreef Jonathan Gibbons : On 01/14/2016 12:25 PM, e...@zusammenkunft.net wrote: Hello, If I understood it correctly the modules on the MP must be unique and are not merged, thats why the order inside the directory does not

Re: Specifying module paths

mmandline, the can still refer to module folders. As for Maven (I cannot speak for other tools), we use the CompilerAPI, so commandline-length is not the issue. thanks, Robert Scholte [1] https://docs.oracle.com/javase/7/docs/api/java/io/File.html#list()

Re: [Jigsaw] Apache Maven status update

Op Tue, 05 Jan 2016 22:55:03 +0100 schreef Jochen Wiedmann <jochen.wiedm...@gmail.com>: On Thu, Dec 31, 2015 at 1:01 PM, Robert Scholte <rfscho...@apache.org> wrote: The next blocking issue requires some work by the Apache Maven team and/or at the QDox project[2]. QDox is a

Re: Draft of The Java Language Specification Java SE 9 Edition

Op Wed, 30 Dec 2015 23:30:30 +0100 schreef Remi Forax <fo...@univ-mlv.fr>: - Mail original - De: "Robert Scholte" <rfscho...@apache.org> À: jigsaw-dev@openjdk.java.net Envoyé: Mercredi 30 Décembre 2015 23:11:52 Objet: Draft of The Java Language Specification Java

Draft of The Java Language Specification Java SE 9 Edition

. It would be great if the missing parts could be added before releasing the official documents for Java 9. Thanks, Robert Scholte

Re: RFE support jar as modulepath argument

Hi Mark, I wasn't aware of this request, simply because I assumed that classpath and modulepath would allow similar arguments. Main difference: in case of a modulepath the module-info is used if available otherwise it is considered a auto module. When using classpath arguments, the

RFE support jar as modulepath argument

that exactly the dependencies as specified in the pom.xml are used (not more or less) without the need to copy files it would be my wish to have -mp also support (jar)-files. thanks, Robert Scholte [1] https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea [2] https://repo1.maven.org

JDeps: detecting offending packages

-> sun.misc So why this change? And is there another way to detect the usage of non-accessible classes? The maven-plugin has a parameter called failOnWarning (default:true) which should break the build in order to help developers to change their code when they rely on internal classes. regards, Robert Scholte

Re: JavaxToolsCompiler

Op Fri, 18 Sep 2015 10:26:46 +0200 schreef Alan Bateman <alan.bate...@oracle.com>: 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

JavaxToolsCompiler

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? regards, Robert Scholte [1] https://github.com/codehaus-plexus/plexus-compiler

Re: JavaxToolsCompiler

Op Mon, 14 Sep 2015 20:27:39 +0200 schreef Alan Bateman <alan.bate...@oracle.com>: 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

Re: Apache Maven JDeps Plugin

. dependenciesToAnalyzeExcludes excludeorg.foo.test:*/exclude /dependenciesToAnalyzeExcludes This should match your requirements. Regards, Robert Scholte Op Wed, 18 Feb 2015 05:46:37 +0100 schreef Mandy Chung mandy.ch...@oracle.com: Hi Robert, Indeed this looks very useful. On 2/16/2015 10:45 AM

Re: Apache Maven JDeps Plugin

/execution /executions /plugin This should match your requirements. Robert Op Mon, 16 Feb 2015 19:45:16 +0100 schreef Alan Bateman alan.bate...@oracle.com: On 16/02/2015 18:28, Robert Scholte wrote: Hi Alan, if you are referring to the -R / -recursive option