maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: [Jigsaw] classpaths and modulepaths
Date Tue, 05 Jan 2016 21:14:16 GMT
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  
<pbenedict@apache.org>:

> 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 <rfscholte@apache.org>  
> 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 <
>> tibor.digana@googlemail.com>:
>>
>> 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 <rfscholte@apache.org>
>>> 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 <
>>>> tibor.digana@googlemail.com>:
>>>>
>>>>
>>>> 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 <rfscholte@apache.org>
>>>>> wrote:
>>>>>
>>>>> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
>>>>>
>>>>>> tibor.digana@googlemail.com>:
>>>>>>
>>>>>> 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  
>>>>>> <rfscholte@apache.org>
>>>>>>
>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message