Reusing module name token `*` in -d

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Nicolai Parlog" <nipa at codefx.org>
> À: forax at univ-mlv.fr
> Cc: jigsaw-dev at 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" <nipa at codefx.org> À:
>>> jigsaw-dev at 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