Robert,
How do you compile these 2 modules with Maven ?
module foo {
exports foo to bar;
}
module bar {
requires foo;
}
when compiling 'foo' javac needs to see if 'bar' exists and when compiling
'bar', javac will ask to see 'foo'.
cheers,
Rémi
----- Mail original -----
> De: "Robert Scholte" <rfscho...@apache.org>
> À: fo...@univ-mlv.fr, "Nicolai Parlog" <n...@codefx.org>
> Cc: jigsaw-dev@openjdk.java.net
> Envoyé: Samedi 21 Janvier 2017 17:49:45
> Objet: Re: Reusing module name token `*` in -d
> On Sat, 21 Jan 2017 14:55:50 +0100, Nicolai Parlog <n...@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, 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
