Re: [Jigsaw] classpaths and modulepaths

Let me first make clear that I chose Maven as a reference application. I wanted a real life multimodule example, not as big as SCM and with enough classes. I wanted to test if I could package/compile this project if I added module-info.java files to it and confirm that all the other plugins

Re: [Jigsaw] classpaths and modulepaths

However, you could theoretically generate module-info.java based on dependencies, if you knew which dependencies were modules. Given that the "what is a module" metadata is not being captured today, you would be required to inspect the contents of the jars in your dependency graph and then add

Re: [Jigsaw] classpaths and modulepaths

You could specify the "requires" by reading the module-info when available in a jar or by converting the file name when not available. However, "requires" could also be "requires public"[1]. That's all up to the developer. All other sections must be handcrafted. For that reason I mentioned

Re: [Jigsaw] classpaths and modulepaths

Sure, no problem Op Tue, 05 Jan 2016 22:20:16 +0100 schreef Paul Benedict : No problem, Robert. I just wanted to collaborate (since both you and I are on Maven and OpenJDK lists) and offer alternative options. Personally, my interest is generating module-info.java

Re: [Jigsaw] classpaths and modulepaths

No problem, Robert. I just wanted to collaborate (since both you and I are on Maven and OpenJDK lists) and offer alternative options. Personally, my interest is generating module-info.java from dependencies; so if you ever get to that problem space, please reach out to me so I can discuss some

Re: [Jigsaw] classpaths and modulepaths

Op Mon, 04 Jan 2016 00:28:24 +0100 schreef Igor Fedorenko : Good you agreed we don't need to add modulepath to MavenProject :-) I see few ways forward with java 9 module system support in maven * Convince jep authors to provide a mechanism to specify modulepath in a way

Re: [Jigsaw] classpaths and modulepaths

Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana : Do you want to use modulepath for dependencies -modulepath ../child2/target/classes, ../child3/target/classes instead of aggregating -classpath in javac? it is not about willing or not willing, it is a

Re: [Jigsaw] classpaths and modulepaths

wait a moment. javac must be backwards compatible, so why this won't work in Java9 javac -d ... -classpath .:child1:child2 Isn't module info a duplicate to POM? Why we must "copy" some libs to target/libs/, which would slow down the build, and add dependency arifacts to modulepath if they could

Re: [Jigsaw] classpaths and modulepaths

javac is backwards compatible, it is extended with module support. Based on your questions I suggest to watch the videos of the sessions of JavaOne[1] This gave me a good picture of what jigsaw is and what it is not. Robert [1] http://openjdk.java.net/projects/jigsaw/j1/ Op Mon, 04 Jan

Re: [Jigsaw] classpaths and modulepaths

I was watching the videos but this migration leads to POM duplicates. That's what I am trying to tell you. I guess you are too in hurry with that. I don't see any reason why the Maven should even use modulepath and module-info. You should maybe write a simple page where and how the modulepath can

Re: [Jigsaw] classpaths and modulepaths

On Mon, Jan 4, 2016, at 03:18 PM, Robert Scholte wrote: > Op Mon, 04 Jan 2016 00:28:24 +0100 schreef Igor Fedorenko > : > > > Good you agreed we don't need to add modulepath to MavenProject :-) > > > > I see few ways forward with java 9 module system support in maven > >

Re: [Jigsaw] classpaths and modulepaths

Good you agreed we don't need to add modulepath to MavenProject :-) I see few ways forward with java 9 module system support in maven * Convince jep authors to provide a mechanism to specify modulepath in a way that does not require specific file/directory naming convention. I only had very

Re: [Jigsaw] classpaths and modulepaths

Do you want to use modulepath for dependencies -modulepath ../child2/target/classes, ../child3/target/classes instead of aggregating -classpath in javac? On Sun, Jan 3, 2016 at 5:55 PM, Robert Scholte wrote: > Hi, > > I've been able to locally *package* a subset of the

Re: [Jigsaw] classpaths and modulepaths

Ok, let me write out the complete story: maven-settings-builder has the following module-info.java module maven.settings.builder { exports org.apache.maven.settings.building; exports org.apache.maven.settings.crypto; exports org.apache.maven.settings.io; exports

Re: [Jigsaw] classpaths and modulepaths

What changes to MavenProject do you have in mind? -- Regards, Igor On Sun, Jan 3, 2016, at 11:55 AM, Robert Scholte wrote: > Hi, > > I've been able to locally *package* a subset of the MavenModules enriched > with module-info. > > mvn package -pl :maven-settings-builder -am

Re: [Jigsaw] classpaths and modulepaths

I agree that getCompileClasspathElements/getTestClasspathElements are flawed, but I don't think adding getCompileModulepathElements/getTestModulepathElements is a good idea. MavenProject is supposed to be generic, and modulepath is something very specific to java 9. At the same time, compile mojo

[Jigsaw] classpaths and modulepaths

Hi, I've been able to locally *package* a subset of the MavenModules enriched with module-info. mvn package -pl :maven-settings-builder -am -Denforcer.skip resulting in: [INFO] Reactor Summary: [INFO] [INFO] Apache Maven .. SUCCESS [57.217s]

Re: [Jigsaw] classpaths and modulepaths

getCompileModulepathElements() and getTestModulepathElements() Based on a modulePath you can (re)calculate the classPath, but not the other way around. Actually, I think there's a small design flaw when a MavenProject contains getCompileClasspathElements() and getTestClasspathElements().

Re: [Jigsaw] classpaths and modulepaths

I would really prefer a solution without changing Maven Project, especially since we're talking about non-generic or language-specific elements. However, in my example where maven-settings-builder depends on maven-settings, how would m-s-b know what the modulePath for m-s is? You shouldn't

Re: [Jigsaw] classpaths and modulepaths

Not sure I understand. Are you talking about compiling, and more specifically, invoking maven-compiler-plugin, on maven-settings-builder and maven-settings projects or something else? If you are talking about invoking maven-compiler-plugin on several interdependent projects, can you explain how