You could specify the "requires" by reading the module-info when available
in a jar or by converting the file name when not available.
However, "requires" could also be "requires public"[1]. That's all up to
the developer. All other sections must be handcrafted. For that reason I
mentioned that you can verify if they are in sync.
So you can't just write the complete java-file, unless you are thinking of
something like the templating-maven-plugin[2] to do some half manual/half
generated stuff.
Anyhow, for me it is out of scope. I'm just writing poms as usual and
write the module-info.java with my favorite texteditor and those are the
first things that should work.
thanks,
Robert
[1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html
[2] http://www.mojohaus.org/templating-maven-plugin/
Op Tue, 05 Jan 2016 21:58:42 +0100 schreef Paul Benedict
<pbened...@apache.org>:
However, you could theoretically generate module-info.java based on
dependencies, if you knew which dependencies were modules. Given that the
"what is a module" metadata is not being captured today, you would be
required to inspect the contents of the jars in your dependency graph and
then add that to the model at runtime.
Cheers,
Paul
On Tue, Jan 5, 2016 at 2:53 PM, Robert Scholte <rfscho...@apache.org>
wrote:
Let me first make clear that I chose Maven as a reference application. I
wanted a real life multimodule example, not as big as SCM and with
enough
classes. I wanted to test if I could package/compile this project if I
added module-info.java files to it and confirm that all the other
plugins
would still do their work.
This is where users are asking for now that the jdk9-ea versions are
available: IDE's and buildtools to support these new features.
Yes, there is some overlap between a dependencies and module-info, but
they have different purposes. In short: you cannot generate module-info
based on dependencies, nor generate the dependencies-section based on
module-info (although you can check if they are in sync). By the time
I'll
write a blogentry about it, because it is good to know the subtle
differences between the two.
thanks,
Robert
Op Mon, 04 Jan 2016 23:43:12 +0100 schreef Tibor Digana <
tibor.dig...@googlemail.com>:
I was watching the videos but this migration leads to POM duplicates.
That's what I am trying to tell you.
I guess you are too in hurry with that.
I don't see any reason why the Maven should even use modulepath and
module-info.
You should maybe write a simple page where and how the modulepath can
be
used in build lifecycle and why it is so important. The best would be
to
descrribe it in picture in very trivial way.
The JDK9 is far away and anything may still change. I understand that
Maven
should be compliant if really necessary but I am sure that you Robert
dig
into this problem more than anyone else and everything is clear to you
but
any detail you may miss may be important.
On Mon, Jan 4, 2016 at 11:31 PM, Robert Scholte <rfscho...@apache.org>
wrote:
javac is backwards compatible, it is extended with module support.
Based on your questions I suggest to watch the videos of the sessions
of
JavaOne[1]
This gave me a good picture of what jigsaw is and what it is not.
Robert
[1] http://openjdk.java.net/projects/jigsaw/j1/
Op Mon, 04 Jan 2016 23:25:54 +0100 schreef Tibor Digana <
tibor.dig...@googlemail.com>:
wait a moment. javac must be backwards compatible, so why this won't
work
in Java9
javac -d ... -classpath .:child1:child2
Isn't module info a duplicate to POM?
Why we must "copy" some libs to target/libs/, which would slow down
the
build, and add dependency arifacts to modulepath if they could be in
classpath as they are now?
Is this true?
modulepath = List(dependency artifacts)?
What benefit javac has if you just split the classpath?
Again, this seems to be a duplicate of dependency descriptions.
What resolution would be? To merge, to prioritize and order artifact
files?
On Mon, Jan 4, 2016 at 9:03 PM, Robert Scholte <rfscho...@apache.org>
wrote:
Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
tibor.dig...@googlemail.com>:
Do you want to use modulepath for dependencies
-modulepath ../child2/target/classes, ../child3/target/classes
instead of aggregating -classpath in javac?
it is not about willing or not willing, it is a must when compiling
(java)
modules.
On Sun, Jan 3, 2016 at 5:55 PM, Robert Scholte
<rfscho...@apache.org>
wrote:
Hi,
I've been able to locally *package* a subset of the MavenModules
enriched
with module-info.
mvn package -pl :maven-settings-builder -am
-Denforcer.skip
resulting in:
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven ...................................... SUCCESS
[57.217s]
[INFO] Maven Builder Support ............................. SUCCESS
[1:12.072s]
[INFO] Maven Settings .................................... SUCCESS
[10.900s]
[INFO] Maven Settings Builder ............................ SUCCESS
[29.223s]
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
Skipping enforcer is required because the bytecode signature for
java9
isn't recognized yet.
The reason I use 'package' is because it'll use the created jars
of
every
maven module. These jars I can copy to a specific folder ( e.g.
target/libs
), so I can use as compiler argument '-modulepath target/libs'.
And this works, including executing surefire without patching!
I haven't used the -modulesourcepath, because that would include
the
module-name in the outputdirectory, resulting in something like
target/classes/maven.setting.builder/org/apache/maven/setting/building/SettingsBuilder.class
Every plugin using classpath would fail.
However, to be able to run 'mvn compile', according to the
specs[1]
in
case of exploded directory, such directory must start with the
module
name,
hence I should start using -modulesourcepath
I was hoping that we only had to patch the plugins, but it seems
like
we
need to change MavenProject as well to separate classpath from
modulepath
since you need them both.
IMHO if we try to abuse classpath for modulepaths we'll have to
do a
lot
of tricks and magic to always get the right values, which is
doomed
for
failure.
Maybe now that we can specify the builder via commandline there
could
be
an easy way to extend MavenProject, I'm just not if that's
something
worth
trying.
I'm also wondering how IDEs think this should be solved.
So the question is: can this only be solved with a new version of
Maven
or
does somebody has a proposal to fix this on a plugin-level?
thanks,
Robert
[1] http://openjdk.java.net/jeps/261
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
