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
<[email protected]>:
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 <[email protected]>
wrote:
Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
[email protected]>:
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 <[email protected]>
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
