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
