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 ideas with you.
Cheers, Paul On Tue, Jan 5, 2016 at 3:14 PM, Robert Scholte <[email protected]> wrote: > 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 that you can verify if they are in sync. > So you can't just write the complete java-file, unless you are thinking of > something like the templating-maven-plugin[2] to do some half manual/half > generated stuff. > Anyhow, for me it is out of scope. I'm just writing poms as usual and > write the module-info.java with my favorite texteditor and those are the > first things that should work. > > thanks, > Robert > > [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html > [2] http://www.mojohaus.org/templating-maven-plugin/ > > > Op Tue, 05 Jan 2016 21:58:42 +0100 schreef Paul Benedict < > [email protected]>: > > > 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 that to the model at runtime. >> >> Cheers, >> Paul >> >> On Tue, Jan 5, 2016 at 2:53 PM, Robert Scholte <[email protected]> >> wrote: >> >> 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 >>> would still do their work. >>> This is where users are asking for now that the jdk9-ea versions are >>> available: IDE's and buildtools to support these new features. >>> >>> Yes, there is some overlap between a dependencies and module-info, but >>> they have different purposes. In short: you cannot generate module-info >>> based on dependencies, nor generate the dependencies-section based on >>> module-info (although you can check if they are in sync). By the time >>> I'll >>> write a blogentry about it, because it is good to know the subtle >>> differences between the two. >>> >>> thanks, >>> Robert >>> >>> Op Mon, 04 Jan 2016 23:43:12 +0100 schreef Tibor Digana < >>> [email protected]>: >>> >>> 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 be >>>> used in build lifecycle and why it is so important. The best would be to >>>> descrribe it in picture in very trivial way. >>>> The JDK9 is far away and anything may still change. I understand that >>>> Maven >>>> should be compliant if really necessary but I am sure that you Robert >>>> dig >>>> into this problem more than anyone else and everything is clear to you >>>> but >>>> any detail you may miss may be important. >>>> >>>> On Mon, Jan 4, 2016 at 11:31 PM, Robert Scholte <[email protected]> >>>> wrote: >>>> >>>> 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 2016 23:25:54 +0100 schreef Tibor Digana < >>>>> [email protected]>: >>>>> >>>>> >>>>> 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 be in >>>>>> classpath as they are now? >>>>>> >>>>>> Is this true? >>>>>> modulepath = List(dependency artifacts)? >>>>>> >>>>>> What benefit javac has if you just split the classpath? >>>>>> >>>>>> Again, this seems to be a duplicate of dependency descriptions. >>>>>> What resolution would be? To merge, to prioritize and order artifact >>>>>> files? >>>>>> >>>>>> >>>>>> On Mon, Jan 4, 2016 at 9:03 PM, Robert Scholte <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana < >>>>>> >>>>>> [email protected]>: >>>>>>> >>>>>>> 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 must when compiling >>>>>>>> >>>>>>> (java) >>>>>>> modules. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Jan 3, 2016 at 5:55 PM, Robert Scholte <[email protected] >>>>>>> > >>>>>>> >>>>>>> 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 -Denforcer.skip >>>>>>>>> >>>>>>>>> resulting in: >>>>>>>>> >>>>>>>>> [INFO] Reactor Summary: >>>>>>>>> [INFO] >>>>>>>>> [INFO] Apache Maven ...................................... SUCCESS >>>>>>>>> [57.217s] >>>>>>>>> [INFO] Maven Builder Support ............................. SUCCESS >>>>>>>>> [1:12.072s] >>>>>>>>> [INFO] Maven Settings .................................... SUCCESS >>>>>>>>> [10.900s] >>>>>>>>> [INFO] Maven Settings Builder ............................ SUCCESS >>>>>>>>> [29.223s] >>>>>>>>> [INFO] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> [INFO] BUILD SUCCESS >>>>>>>>> [INFO] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> Skipping enforcer is required because the bytecode signature for >>>>>>>>> java9 >>>>>>>>> isn't recognized yet. >>>>>>>>> >>>>>>>>> The reason I use 'package' is because it'll use the created jars of >>>>>>>>> every >>>>>>>>> maven module. These jars I can copy to a specific folder ( e.g. >>>>>>>>> target/libs >>>>>>>>> ), so I can use as compiler argument '-modulepath target/libs'. >>>>>>>>> And this works, including executing surefire without patching! >>>>>>>>> >>>>>>>>> I haven't used the -modulesourcepath, because that would include >>>>>>>>> the >>>>>>>>> module-name in the outputdirectory, resulting in something like >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> target/classes/maven.setting.builder/org/apache/maven/setting/building/SettingsBuilder.class >>>>>>>>> Every plugin using classpath would fail. >>>>>>>>> >>>>>>>>> However, to be able to run 'mvn compile', according to the specs[1] >>>>>>>>> in >>>>>>>>> case of exploded directory, such directory must start with the >>>>>>>>> module >>>>>>>>> name, >>>>>>>>> hence I should start using -modulesourcepath >>>>>>>>> >>>>>>>>> I was hoping that we only had to patch the plugins, but it seems >>>>>>>>> like >>>>>>>>> we >>>>>>>>> need to change MavenProject as well to separate classpath from >>>>>>>>> modulepath >>>>>>>>> since you need them both. >>>>>>>>> >>>>>>>>> IMHO if we try to abuse classpath for modulepaths we'll have to do >>>>>>>>> a >>>>>>>>> lot >>>>>>>>> of tricks and magic to always get the right values, which is doomed >>>>>>>>> for >>>>>>>>> failure. >>>>>>>>> >>>>>>>>> Maybe now that we can specify the builder via commandline there >>>>>>>>> could >>>>>>>>> be >>>>>>>>> an easy way to extend MavenProject, I'm just not if that's >>>>>>>>> something >>>>>>>>> worth >>>>>>>>> trying. >>>>>>>>> >>>>>>>>> I'm also wondering how IDEs think this should be solved. >>>>>>>>> >>>>>>>>> So the question is: can this only be solved with a new version of >>>>>>>>> Maven >>>>>>>>> or >>>>>>>>> does somebody has a proposal to fix this on a plugin-level? >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> [1] http://openjdk.java.net/jeps/261 >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>> >>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>> >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
