Reusing module name token `*` in -d

Sat Jan 21 16:49:45 UTC 2017

On Sat, 21 Jan 2017 14:55:50 +0100, Nicolai Parlog <nipa at codefx.org> wrote:

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

Maven is not using module-source-path, but remains using source-path so  
the current structure can stay as it is, both input and output folders.

And this works, because one pom represents one jar (=represents one module)

Robert

>
>
> On 21.01.2017 14:32, forax at univ-mlv.fr wrote:
>> ----- 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
>>