Good you agreed we don't need to add modulepath to MavenProject :-)
I see few ways forward with java 9 module system support in maven
* Convince jep authors to provide a mechanism to specify modulepath in a
way that does not require specific file/directory naming convention. I
only had very cursory look at the jsr, so can't suggest anything more
specific at this point, but I think this approach will be the best fit
for maven and m2e/eclipse usecases.
* use symbolic and/or hard links to "assemble" per-project modulepath
directory structure. This should have virtually zero cpu and i/o
overhead, and unless I misunderstand jsr proposal, should work with the
current proposed apis and tools. Much more expensive variation of this
approach is to use filesystem copy to create per-project modulepath
directory structure.
* require project build output and testOutput directories follow
modulepath naming convention. this is my least favourite approach
because I think it makes module system support too invasive. we can
probably make it almost invisible to the enduser with some clever
super-pom profile, so it may be not so bad.
--
Regards,
Igor
On Sun, Jan 3, 2016, at 04:00 PM, Robert Scholte wrote:
> Ok, let me write out the complete story:
>
> maven-settings-builder has the following module-info.java
>
> module maven.settings.builder
> {
> exports org.apache.maven.settings.building;
> exports org.apache.maven.settings.crypto;
> exports org.apache.maven.settings.io;
> exports org.apache.maven.settings.merge;
> exports org.apache.maven.settings.validation;
>
> requires maven.builder.support;
> requires maven.settings;
> requires plexus.cipher;
> requires plexus.interpolation;
> requires plexus.component.annotations;
> requires plexus.sec.dispatcher;
> requires plexus.utils;
> }
>
>
> during "mvn package" all the both maven.builder.support and
> maven.settings
> are available as jar in the reactor.
> According to the current specs of jep-261 I can't refer to the jars
> directly, but need to refer to the directory containing this jar, so what
> currently happens is that every jar is copied to target/libs and this is
> used as value for modulepath.
>
> during "mvn compile" there are no jars yet for maven.builder.support and
> maven.settings. Instead the compiled classes are available in
> target/classes, which is used as classpath entry.
> If I want to compile maven-settings-builder, it'll fail because it is
> missing the maven.builder.support and maven.settings modules. jep-261
> specifies that modulepath can also refer to a directory with the classes,
> but the first directory must match the module name.
> So when I compile maven-settings and maven-builder-support I must use
> -modulesourcepath src/main/java -d target/mods which will create the
> classes under target/mods/maven.settings/
>
> I've looked at how the classpath entries are actually calculated and
> here's the key code:
>
> private void addArtifactPath( Artifact artifact, List<String>
> classpath )
> {
> File file = artifact.getFile();
> if ( file != null )
> {
> classpath.add( file.getPath() );
> }
> }
>
> Good part: adding getCompileModulepathElements() to MavenProject doesn't
> help. artifact.getFile() either points to target/classes or the jar. But
> I
> also need something which points to target/mods.
>
> Options I can think of:
> - there's one interesting method still available: artifact.addMetadata().
> Maybe I can store data here
> - purely based on convention (no configuration): if file points to
> target/mods/some.module.name (classic classpath element), use its parent
> as the modulepath.
>
> Hopefully this explained the problem a bit better.
>
> Robert
>
> Op Sun, 03 Jan 2016 21:08:14 +0100 schreef Igor Fedorenko
> <i...@ifedorenko.com>:
>
> > Not sure I understand. Are you talking about compiling, and more
> > specifically, invoking maven-compiler-plugin, on maven-settings-builder
> > and maven-settings projects or something else? If you are talking about
> > invoking maven-compiler-plugin on several interdependent projects, can
> > you explain how adding modulepath info to MavenProject is going to help?
>
> ---------------------------------------------------------------------
> 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
