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] > > -- Cheers Tibor
