You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2016/01/03 17:55:04 UTC

[Jigsaw] classpaths and modulepaths

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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

On Mon, Jan 4, 2016, at 03:18 PM, Robert Scholte wrote:
> Op Mon, 04 Jan 2016 00:28:24 +0100 schreef Igor Fedorenko  
> <ig...@ifedorenko.com>:
> 
> > 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.
> 
> That would be nice, but I think it has to do with source mixtures. They  
> probably don't want to force a module-info , but need a way to decide the 
> name of the module. This way it becomes an auto-module which exports  
> everything and requires all available modules.
> If this is indeed the reason, I think they've been too sweet. IMHO if you 
> have source AND want it to be a module, just add that module-info.
> 

Actually, for the compiler, you should be able to provide custom
JavaFileManager#getModuleLocation [1] implementation with maven-specific
module lookup logic. Not sure if there is similar extension point to do
the same for the runtime.

[1]
http://cr.openjdk.java.net/~mr/jigsaw/spec/api/javax/tools/JavaFileManager.html#getModuleLocation-javax.tools.JavaFileManager.Location-java.lang.String-

-- 
Regards,
Igor

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Robert Scholte <rf...@apache.org>.
Op Mon, 04 Jan 2016 00:28:24 +0100 schreef Igor Fedorenko  
<ig...@ifedorenko.com>:

> 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.

That would be nice, but I think it has to do with source mixtures. They  
probably don't want to force a module-info , but need a way to decide the  
name of the module. This way it becomes an auto-module which exports  
everything and requires all available modules.
If this is indeed the reason, I think they've been too sweet. IMHO if you  
have source AND want it to be a module, just add that module-info.

>
> * 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.

I had this idea as well. I know this has always been tricky with Windows,  
but let's see if this has been improved.

>
> * 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.
>
>

Even though I agree, this is probably the easiest to implement. For that  
reason I'll add it just to get the experience with the whole module system.
Just like the copying of the jars, which is by now the most solid  
solution, but I will remove it once the modulepath allows explicit  
references to jars.

thanks for these helpful comments!
Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Igor Fedorenko <ig...@ifedorenko.com>.
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  
> <ig...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Robert Scholte <rf...@apache.org>.
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  
<ig...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Igor Fedorenko <ig...@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?

-- 
Regards,
Igor

On Sun, Jan 3, 2016, at 02:30 PM, Robert Scholte wrote:
> I would really prefer a solution without changing Maven Project,  
> especially since we're talking about non-generic or language-specific  
> elements.
> However, in my example where maven-settings-builder depends on  
> maven-settings, how would m-s-b know what the modulePath for m-s is? You  
> shouldn't ask this information on the compiler-plugin of m-s, since there 
> should be no logic between plugins. There should be some sort of shared  
> context and the only reasonable object I can think of is the
> MavenProject.
> 
> Assuming I compiled with -modulesourcepath, should the compiler-plugin  
> copy all those files to the target/classes directory too, so other
> plugins  
> can use it as a pre-java9 project? I hope not, but it would be a simple  
> solution to keep the classpath in tact, but it doesn't solve the  
> modulepath problem required by other modules of the multimodule project.
> 
> Robert
> 
> Op Sun, 03 Jan 2016 18:59:25 +0100 schreef Igor Fedorenko  
> <ig...@ifedorenko.com>:
> 
> > I agree that getCompileClasspathElements/getTestClasspathElements are
> > flawed, but I don't think adding
> > getCompileModulepathElements/getTestModulepathElements is a good idea.
> > MavenProject is supposed to be generic, and  modulepath is something
> > very specific to java 9. At the same time, compile mojo and surefire can
> > already derive all they need from project dependency artifacts, so these
> > two new methods appear to be redundant.
> >
> > I am also not sure if
> > getCompileModulepathElements/getTestModulepathElements will be generally
> > useful for other java-related plugins. For example, I couldn't use
> > existing getCompileClasspathElements/getTestClasspathElements in takari
> > lifecycle and I suspect I will not be able to use
> > getCompileModulepathElements/getTestModulepathElements either.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Robert Scholte <rf...@apache.org>.
I would really prefer a solution without changing Maven Project,  
especially since we're talking about non-generic or language-specific  
elements.
However, in my example where maven-settings-builder depends on  
maven-settings, how would m-s-b know what the modulePath for m-s is? You  
shouldn't ask this information on the compiler-plugin of m-s, since there  
should be no logic between plugins. There should be some sort of shared  
context and the only reasonable object I can think of is the MavenProject.

Assuming I compiled with -modulesourcepath, should the compiler-plugin  
copy all those files to the target/classes directory too, so other plugins  
can use it as a pre-java9 project? I hope not, but it would be a simple  
solution to keep the classpath in tact, but it doesn't solve the  
modulepath problem required by other modules of the multimodule project.

Robert

Op Sun, 03 Jan 2016 18:59:25 +0100 schreef Igor Fedorenko  
<ig...@ifedorenko.com>:

> I agree that getCompileClasspathElements/getTestClasspathElements are
> flawed, but I don't think adding
> getCompileModulepathElements/getTestModulepathElements is a good idea.
> MavenProject is supposed to be generic, and  modulepath is something
> very specific to java 9. At the same time, compile mojo and surefire can
> already derive all they need from project dependency artifacts, so these
> two new methods appear to be redundant.
>
> I am also not sure if
> getCompileModulepathElements/getTestModulepathElements will be generally
> useful for other java-related plugins. For example, I couldn't use
> existing getCompileClasspathElements/getTestClasspathElements in takari
> lifecycle and I suspect I will not be able to use
> getCompileModulepathElements/getTestModulepathElements either.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Igor Fedorenko <ig...@ifedorenko.com>.
I agree that getCompileClasspathElements/getTestClasspathElements are
flawed, but I don't think adding
getCompileModulepathElements/getTestModulepathElements is a good idea.
MavenProject is supposed to be generic, and  modulepath is something
very specific to java 9. At the same time, compile mojo and surefire can
already derive all they need from project dependency artifacts, so these
two new methods appear to be redundant.

I am also not sure if
getCompileModulepathElements/getTestModulepathElements will be generally
useful for other java-related plugins. For example, I couldn't use
existing getCompileClasspathElements/getTestClasspathElements in takari
lifecycle and I suspect I will not be able to use
getCompileModulepathElements/getTestModulepathElements either.

-- 
Regards,
Igor

On Sun, Jan 3, 2016, at 12:35 PM, Robert Scholte wrote:
> getCompileModulepathElements() and getTestModulepathElements()
> 
> Based on a modulePath you can (re)calculate the classPath, but not the  
> other way around.
> 
> Actually, I think there's a small design flaw when a MavenProject
> contains  
> getCompileClasspathElements() and getTestClasspathElements(). These are  
> only interesting for java projects. This exposes the problem that a
> change  
> of the JDK behavior would probably need a new version of Maven.
> Assuming this isn't required with every new major version of a JDK,
> adding  
> these methods to MavenProject would be fine.
> 
> Robert
> 
> Op Sun, 03 Jan 2016 18:09:52 +0100 schreef Igor Fedorenko  
> <ig...@ifedorenko.com>:
> 
> > What changes to MavenProject do you have in mind?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Robert Scholte <rf...@apache.org>.
getCompileModulepathElements() and getTestModulepathElements()

Based on a modulePath you can (re)calculate the classPath, but not the  
other way around.

Actually, I think there's a small design flaw when a MavenProject contains  
getCompileClasspathElements() and getTestClasspathElements(). These are  
only interesting for java projects. This exposes the problem that a change  
of the JDK behavior would probably need a new version of Maven.
Assuming this isn't required with every new major version of a JDK, adding  
these methods to MavenProject would be fine.

Robert

Op Sun, 03 Jan 2016 18:09:52 +0100 schreef Igor Fedorenko  
<ig...@ifedorenko.com>:

> What changes to MavenProject do you have in mind?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Igor Fedorenko <ig...@ifedorenko.com>.
What changes to MavenProject do you have in mind?

-- 
Regards,
Igor

On Sun, Jan 3, 2016, at 11:55 AM, Robert Scholte 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Robert Scholte <rf...@apache.org>.
Sure, no problem

Op Tue, 05 Jan 2016 22:20:16 +0100 schreef Paul Benedict  
<pb...@apache.org>:

> No problem, Robert. I just wanted to collaborate (since both you and I  
> are
> on Maven and OpenJDK lists) and offer alternative options. Personally, my
> interest is generating module-info.java from dependencies; so if you ever
> get to that problem space, please reach out to me so I can discuss some
> ideas with you.
>
> Cheers,
> Paul
>
> On Tue, Jan 5, 2016 at 3:14 PM, Robert Scholte <rf...@apache.org>  
> wrote:
>
>> 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 <
>> pbenedict@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 <rf...@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.digana@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  
>>>>> <rf...@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.digana@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  
>>>>>>> <rf...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
>>>>>>>
>>>>>>> tibor.digana@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  
>>>>>>>> <rfscholte@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-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Paul Benedict <pb...@apache.org>.
No problem, Robert. I just wanted to collaborate (since both you and I are
on Maven and OpenJDK lists) and offer alternative options. Personally, my
interest is generating module-info.java from dependencies; so if you ever
get to that problem space, please reach out to me so I can discuss some
ideas with you.

Cheers,
Paul

On Tue, Jan 5, 2016 at 3:14 PM, Robert Scholte <rf...@apache.org> wrote:

> 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 <
> pbenedict@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 <rf...@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.digana@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 <rf...@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.digana@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 <rf...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
>>>>>>
>>>>>> tibor.digana@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 <rfscholte@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-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Jigsaw] classpaths and modulepaths

Posted by Robert Scholte <rf...@apache.org>.
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  
<pb...@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 <rf...@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.digana@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 <rf...@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.digana@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 <rf...@apache.org>
>>>>> wrote:
>>>>>
>>>>> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
>>>>>
>>>>>> tibor.digana@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  
>>>>>> <rf...@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Paul Benedict <pb...@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 <rf...@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.digana@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 <rf...@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.digana@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 <rf...@apache.org>
>>>> wrote:
>>>>
>>>> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
>>>>
>>>>> tibor.digana@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 <rf...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Jigsaw] classpaths and modulepaths

Posted by Robert Scholte <rf...@apache.org>.
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  
<ti...@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 <rf...@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.digana@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 <rf...@apache.org>
>>> wrote:
>>>
>>> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
>>>> tibor.digana@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 <rf...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Tibor Digana <ti...@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 <rf...@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.digana@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 <rf...@apache.org>
>> wrote:
>>
>> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
>>> tibor.digana@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 <rf...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: [Jigsaw] classpaths and modulepaths

Posted by Robert Scholte <rf...@apache.org>.
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  
<ti...@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 <rf...@apache.org>  
> wrote:
>
>> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
>> tibor.digana@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 <rf...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Tibor Digana <ti...@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 <rf...@apache.org> wrote:

> Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <
> tibor.digana@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 <rf...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: [Jigsaw] classpaths and modulepaths

Posted by Robert Scholte <rf...@apache.org>.
Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana  
<ti...@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 <rf...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Jigsaw] classpaths and modulepaths

Posted by Tibor Digana <ti...@googlemail.com>.
Do you want to use modulepath for dependencies
-modulepath ../child2/target/classes, ../child3/target/classes

instead of aggregating -classpath in javac?

On Sun, Jan 3, 2016 at 5:55 PM, Robert Scholte <rf...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Cheers
Tibor