Reusing module name token `*` in -d

[Nicolai Parlog]

 Hi Remi.

> 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.

> 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.

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



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