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
> ''modules'' you usually find in Java and features like restricted
> export or uses/provides also force several modules to be compiled
> together.
That's interesting. As far as I understood up to now a single POM (to
fall back on a known build tool) will by default correspond to a
single module. Isn't that so? Or in other words how would I use Maven
or Gradle to effortlessly create multiple artifacts?
so long ... Nicolai
On 21.01.2017 14:32, fo...@univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Nicolai Parlog" <n...@codefx.org> À: fo...@univ-mlv.fr Cc:
>> jigsaw-dev@openjdk.java.net Envoyé: Samedi 21 Janvier 2017
>> 13:08:24 Objet: Re: Reusing module name token `*` in -d
>
>> Hi Remi.
>
> Hi Nicolai,
>
>>
>>> My advice is to not try to fight the module layout, it's like
>>> trying to fight ocean waves, it's better to surf on it.
>>
>> My personal opinion is that the proposed layout with a src folder
>> at the top is not going to see a lot of adoption.
>>
>> The main reason for that is that I think each sub-project/module
>> should have a directory structure just to itself to store
>> sources, tests, resources, configuration, build scripts,
>> documentation, source control info, etc. The fact that most build
>> tool and IDEs understand this structure by default underlines
>> that thought. And not only does the proposed structure not add
>> any benefits (that I can see), it also comes at a considerable
>> costs because (a) all tools have to be taught "the new way" and
>> (b) a migration is a lot of work.
>>
>> So I believe the
>> `<module>/src/{main,test}/{java,resources,whatever}` structure is
>> here to stay.
>
> 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
> ''modules'' you usually find in Java and features like restricted
> export or uses/provides also force several modules to be compiled
> together.
>
>>
>>> And yes it means that if you want to modularize an already
>>> existing project, you have to change its layout to be jigsaw
>>> compatible
>>
>> I disagree.
>>
>> I'm not sure how essential it is for tools to have the compiled
>> classes land in `<module>/target/classes`. If it is important,
>> they could not have compiled several sub-projects at the same
>> time anyways (unless I'm missing something). If they already put
>> all compiled classes into the same folder, then multi-module
>> builds will work just fine for them.
>>
>> Not being able to do multi-module builds into
>> `<module>/target/classes` or similar is hence no new limitation
>> from Java 9 and compiling modules one by one can be done for
>> arbitrary directory structures.
>
> see my comment above about not being able to compile multiple
> modules in isolation.
>
> also Java has never supported an arbitrary layout, packages has to
> be organized in a certain way and now that jigsaw modules are part
> of the language. I think the problem is more that what you call a
> module may not be what Java calls a module.
>
>>
>> At the same time it looks to me that the concept of a module
>> name token opens up the possibility to create a feature that
>> didn't exist before and allows tools to compile many modules at
>> once where they couldn't before.
>>
>> so long ... Nicolai
>
> cheers, Rémi
>
>>
>>
>>
>> On 21.01.2017 11:37, Remi Forax wrote:
>>> Hi Nicolai, the runtime (ModuleFinder) is able to read
>>> exploded modules, .class in folders, not only modules in jars,
>>> so the layout on disk is more or less fixed.
>>>
>>> My advice is to not try to fight the module layout, it's like
>>> trying to fight ocean waves, it's better to surf on it. And yes
>>> it means that if you want to modularize an already existing
>>> project, you have to change its layout to be jigsaw compatible,
>>> this is exactly what was done for the jdk.
>>>
>>> regards, Rémi
>>>
>>> ----- Mail original -----
>>>> De: "Nicolai Parlog" <n...@codefx.org> À:
>>>> jigsaw-dev@openjdk.java.net Envoyé: Samedi 21 Janvier 2017
>>>> 11:00:35 Objet: Reusing module name token `*` in -d
>>>
>>>> Hi!
>>>>
>>>> Another feature request from the trenches regarding
>>>> multi-module compilation. (It is possible that there was a
>>>> similar thread a couple of days/weeks (?) back but I didn't
>>>> find it.)
>>>>
>>>> It would be nice to have the ability to specify module
>>>> specific target folders, so they do not automatically end up
>>>> in `<whatever-was-given-to-d>/<module-name>`.
>>>>
>>>> It seems obvious (which could very well make it stupid) to
>>>> reuse the asterisk here and allow something like
>>>>
>>>> javac --module-path mods --module-source-path
>>>> "./*/src/main/java" -d "./*/target/classes" -module
>>>> initial.module
>>>>
>>>> I have not thought through how this might or might not work
>>>> with multiple module source paths. It looks like the only
>>>> tractable approach would be to not allow more than one -d
>>>> element.
>>>>
>>>> so long ... Nicolai
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> PGP Key:
>>>> http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
>>>>
>>>>
>>>>
>>
>>>>
Web:
>>>> http://codefx.org a blog about software development
>>>> https://www.sitepoint.com/java high-quality Java/JVM content
>>>> http://do-foss.de Free and Open Source Software for the City
>>>> of Dortmund
>>>>
>>>> Twitter: https://twitter.com/nipafx
>>>
>>
>> --
>>
>> PGP Key:
>> http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
>>
>>
>>
Web:
>> http://codefx.org a blog about software development
>> https://www.sitepoint.com/java high-quality Java/JVM content
>> http://do-foss.de Free and Open Source Software for the City of
>> Dortmund
>>
>> Twitter: https://twitter.com/nipafx
>
--
PGP Key:
http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
Web:
http://codefx.org
a blog about software development
https://www.sitepoint.com/java
high-quality Java/JVM content
http://do-foss.de
Free and Open Source Software for the City of Dortmund
Twitter:
https://twitter.com/nipafx
