How does maven handle Java module dependencies?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

How does maven handle Java module dependencies?

Russell Gold-3
I’m sure this must have been described somewhere; is there an overall direction document for supporting the java platform module system?

case 1)

I want to compile against another project on the module path rather than the class path. I do this in order to ensure compile-time checking for attempts to compile against non-exported packages.

case 2)

I want to test against another project on the module path. This would allow me to catch reflective access attempts against that module’s internals

case 3)

I want to use the module dependencies to create an installer, with the dependent modules on the module path. In theory, if Maven understands the above 2 cases, it would also be able to verify the requires clauses in my project’s module-info.

So how will we be doing this in maven? Is it already supported? My first thought was that we need two new scopes: module (case 1) and module-test (case 2), but has this already been planned?

Thanks,
Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How does maven handle Java module dependencies?

Russell Gold-3
A bit more research turned up this page https://www.sitepoint.com/maven-cannot-generate-module-declaration/ in which Robert explains why my “first thought” below is a non-starter, unless the pom spec is upgraded. So it sounds now as though we are waiting on ASM to read module-info files…? Is there really nothing to be done in the meantime?

> On Aug 27, 2017, at 7:50 AM, Russell Gold <[hidden email]> wrote:
>
> I’m sure this must have been described somewhere; is there an overall direction document for supporting the java platform module system?
>
> case 1)
>
> I want to compile against another project on the module path rather than the class path. I do this in order to ensure compile-time checking for attempts to compile against non-exported packages.
>
> case 2)
>
> I want to test against another project on the module path. This would allow me to catch reflective access attempts against that module’s internals
>
> case 3)
>
> I want to use the module dependencies to create an installer, with the dependent modules on the module path. In theory, if Maven understands the above 2 cases, it would also be able to verify the requires clauses in my project’s module-info.
>
> So how will we be doing this in maven? Is it already supported? My first thought was that we need two new scopes: module (case 1) and module-test (case 2), but has this already been planned?
>
> Thanks,
> Russ
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How does maven handle Java module dependencies?

Robert Scholte-6
In reply to this post by Russell Gold-3
Hi Russ,

this is how it works:
in case there's a module descriptor, the module-path with be used. With  
the help of plexus-java it is possible to divide all jars over the  
module-path and classpath. This mechanism is implemented in the  
maven-compiler-plugin (will do an official release soon with the latest  
improvements), other plugins can/should use this too.

This means that you actually don't need to change anything in your  
pom.xml. With the module descriptor and all the dependencies there's  
enough information to decide which jars belong on the modulepath and which  
on the classpath. So in the end there's no need for new scopes anymore,  
although that was my first thought as well.

To create an installer, I think you're referring to JLink. Karl Heinz is  
preparing the maven-jlink-plugin.

thanks,
Robert

On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold <[hidden email]>  
wrote:

> I’m sure this must have been described somewhere; is there an overall  
> direction document for supporting the java platform module system?
>
> case 1)
>
> I want to compile against another project on the module path rather than  
> the class path. I do this in order to ensure compile-time checking for  
> attempts to compile against non-exported packages.
>
> case 2)
>
> I want to test against another project on the module path. This would  
> allow me to catch reflective access attempts against that module’s  
> internals
>
> case 3)
>
> I want to use the module dependencies to create an installer, with the  
> dependent modules on the module path. In theory, if Maven understands  
> the above 2 cases, it would also be able to verify the requires clauses  
> in my project’s module-info.
>
> So how will we be doing this in maven? Is it already supported? My first  
> thought was that we need two new scopes: module (case 1) and module-test  
> (case 2), but has this already been planned?
>
> Thanks,
> Russ
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How does maven handle Java module dependencies?

Karl Heinz Marbaise-3
Hi,

On 27/08/17 14:38, Robert Scholte wrote:

> Hi Russ,
>
> this is how it works:
> in case there's a module descriptor, the module-path with be used. With
> the help of plexus-java it is possible to divide all jars over the
> module-path and classpath. This mechanism is implemented in the
> maven-compiler-plugin (will do an official release soon with the latest
> improvements), other plugins can/should use this too.
>
> This means that you actually don't need to change anything in your
> pom.xml. With the module descriptor and all the dependencies there's
> enough information to decide which jars belong on the modulepath and
> which on the classpath. So in the end there's no need for new scopes
> anymore, although that was my first thought as well.
>
> To create an installer, I think you're referring to JLink. Karl Heinz is
> preparing the maven-jlink-plugin.

This is not an installer it is a Java Run-Time Image which uses JLink
(maven-jlink-plugin, maven-jmod-plugin)...

An example how it looks like at the moment can be seen[1] and in [2] how
the most recent code works...

The first alpha release of maven-jlink-plugin and maven-jmod-plugin is
planned within a few weeks...

Kind regards
Karl Heinz Marbaise

[1]:
http://blog.soebes.de/blog/2017/06/06/howto-create-a-java-run-time-image-with-maven/
[2]:
https://github.com/khmarbaise/jdk9-jlink-jmod-example/tree/master/maven-example


>
> thanks,
> Robert
>
> On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold
> <[hidden email]> wrote:
>
>> I’m sure this must have been described somewhere; is there an overall
>> direction document for supporting the java platform module system?
>>
>> case 1)
>>
>> I want to compile against another project on the module path rather
>> than the class path. I do this in order to ensure compile-time
>> checking for attempts to compile against non-exported packages.
>>
>> case 2)
>>
>> I want to test against another project on the module path. This would
>> allow me to catch reflective access attempts against that module’s
>> internals
>>
>> case 3)
>>
>> I want to use the module dependencies to create an installer, with the
>> dependent modules on the module path. In theory, if Maven understands
>> the above 2 cases, it would also be able to verify the requires
>> clauses in my project’s module-info.
>>
>> So how will we be doing this in maven? Is it already supported? My
>> first thought was that we need two new scopes: module (case 1) and
>> module-test (case 2), but has this already been planned?
>>
>> Thanks,
>> Russ
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise        USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen                           http://www.soebes.de

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How does maven handle Java module dependencies?

Russell Gold-3
In reply to this post by Robert Scholte-6
Hi Robert,

That sounds great. Any idea on timing of the release? What about the surefire plugin? Is there something I can do to help?  I am actively working on Java 9 issues in a few projects, including both the module system and multi-release jars, so I am very motivated to do what I can to help maven get there.

Thanks,
Russ

> On Aug 27, 2017, at 8:38 AM, Robert Scholte <[hidden email]> wrote:
>
> Hi Russ,
>
> this is how it works:
> in case there's a module descriptor, the module-path with be used. With the help of plexus-java it is possible to divide all jars over the module-path and classpath. This mechanism is implemented in the maven-compiler-plugin (will do an official release soon with the latest improvements), other plugins can/should use this too.
>
> This means that you actually don't need to change anything in your pom.xml. With the module descriptor and all the dependencies there's enough information to decide which jars belong on the modulepath and which on the classpath. So in the end there's no need for new scopes anymore, although that was my first thought as well.
>
> To create an installer, I think you're referring to JLink. Karl Heinz is preparing the maven-jlink-plugin.
>
> thanks,
> Robert
>
> On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold <[hidden email]> wrote:
>
>> I’m sure this must have been described somewhere; is there an overall direction document for supporting the java platform module system?
>>
>> case 1)
>>
>> I want to compile against another project on the module path rather than the class path. I do this in order to ensure compile-time checking for attempts to compile against non-exported packages.
>>
>> case 2)
>>
>> I want to test against another project on the module path. This would allow me to catch reflective access attempts against that module’s internals
>>
>> case 3)
>>
>> I want to use the module dependencies to create an installer, with the dependent modules on the module path. In theory, if Maven understands the above 2 cases, it would also be able to verify the requires clauses in my project’s module-info.
>>
>> So how will we be doing this in maven? Is it already supported? My first thought was that we need two new scopes: module (case 1) and module-test (case 2), but has this already been planned?
>>
>> Thanks,
>> Russ
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How does maven handle Java module dependencies?

Robert Scholte-6
Hi Russ,

All maven-compiler-plugin 3.6.x are already based on this idea. So if you  
use maven-compiler-plugin 3.6.2 (current) it'll work as explained.

And yes, surefire needs some help on this, but I like to leave Tibor in  
the lead for this. JUnit5 and Java9 both have impact, but the focus has  
been mainly on JUnit 5 for now.

The main missing feature it to run surefire with the modulepath[1].
Tibor can explain it better, but this is my understanding:
surefire creates an executable jar with a manifest file containing the  
classpath to ensure it all fits on the cmdline.
With Java 9 this has to be transformed an @args file, so the way to call  
this jar will change as well.

I got some feedback from Alan Bateman as well (and he's willing to help as  
well):
"I assumed the challenge for test execute would be getting the CLI options  
right. I would expect it will end up like this:

-p  
<target-classes>:<target-test-classes>:<dependences>:<test-scope-dependences>
--add-modules <project-module>
--patch-module <project-module>=<target-test-classes>
--add-reads <project-module>=junit
--add-exports <project-module>/<package>=junit
-m junit/org.junit.runner.JUnitCore <test-class>

which is complicated. The `--add-reads` option will depend on which test  
framework is used. The `--add-exports` options will be repeated for each  
package contains tests invoked by the test framework."

So there's enough to improve to make it all work.
I would say "any help is appreciated", but I'll leave it up to Tibor.

thanks
Robert

[1] https://issues.apache.org/jira/browse/SUREFIRE-1262

On Mon, 28 Aug 2017 04:16:21 +0200, Russell Gold <[hidden email]>  
wrote:

> Hi Robert,
>
> That sounds great. Any idea on timing of the release? What about the  
> surefire plugin? Is there something I can do to help?  I am actively  
> working on Java 9 issues in a few projects, including both the module  
> system and multi-release jars, so I am very motivated to do what I can  
> to help maven get there.
>
> Thanks,
> Russ
>
>> On Aug 27, 2017, at 8:38 AM, Robert Scholte <[hidden email]>  
>> wrote:
>>
>> Hi Russ,
>>
>> this is how it works:
>> in case there's a module descriptor, the module-path with be used. With  
>> the help of plexus-java it is possible to divide all jars over the  
>> module-path and classpath. This mechanism is implemented in the  
>> maven-compiler-plugin (will do an official release soon with the latest  
>> improvements), other plugins can/should use this too.
>>
>> This means that you actually don't need to change anything in your  
>> pom.xml. With the module descriptor and all the dependencies there's  
>> enough information to decide which jars belong on the modulepath and  
>> which on the classpath. So in the end there's no need for new scopes  
>> anymore, although that was my first thought as well.
>>
>> To create an installer, I think you're referring to JLink. Karl Heinz  
>> is preparing the maven-jlink-plugin.
>>
>> thanks,
>> Robert
>>
>> On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold  
>> <[hidden email]> wrote:
>>
>>> I’m sure this must have been described somewhere; is there an overall  
>>> direction document for supporting the java platform module system?
>>>
>>> case 1)
>>>
>>> I want to compile against another project on the module path rather  
>>> than the class path. I do this in order to ensure compile-time  
>>> checking for attempts to compile against non-exported packages.
>>>
>>> case 2)
>>>
>>> I want to test against another project on the module path. This would  
>>> allow me to catch reflective access attempts against that module’s  
>>> internals
>>>
>>> case 3)
>>>
>>> I want to use the module dependencies to create an installer, with the  
>>> dependent modules on the module path. In theory, if Maven understands  
>>> the above 2 cases, it would also be able to verify the requires  
>>> clauses in my project’s module-info.
>>>
>>> So how will we be doing this in maven? Is it already supported? My  
>>> first thought was that we need two new scopes: module (case 1) and  
>>> module-test (case 2), but has this already been planned?
>>>
>>> Thanks,
>>> Russ
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How does maven handle Java module dependencies?

Russell Gold-3
Hi Tibor,

My offer to help stands; I sincerely hope that the suggested command line is not the way things go; in my regular projects, we have been working very hard to avoid the use of various —add-* switches, as they are stopgaps. Of course, one of my real hopes is to have all of this work with multi-release jars, with such builds rerunning tests with both the old and new versions :)

Regards,
Russ


> On Aug 28, 2017, at 6:24 AM, Robert Scholte <[hidden email]> wrote:
>
> Hi Russ,
>
> All maven-compiler-plugin 3.6.x are already based on this idea. So if you use maven-compiler-plugin 3.6.2 (current) it'll work as explained.
>
> And yes, surefire needs some help on this, but I like to leave Tibor in the lead for this. JUnit5 and Java9 both have impact, but the focus has been mainly on JUnit 5 for now.
>
> The main missing feature it to run surefire with the modulepath[1].
> Tibor can explain it better, but this is my understanding:
> surefire creates an executable jar with a manifest file containing the classpath to ensure it all fits on the cmdline.
> With Java 9 this has to be transformed an @args file, so the way to call this jar will change as well.
>
> I got some feedback from Alan Bateman as well (and he's willing to help as well):
> "I assumed the challenge for test execute would be getting the CLI options right. I would expect it will end up like this:
>
> -p <target-classes>:<target-test-classes>:<dependences>:<test-scope-dependences>
> --add-modules <project-module>
> --patch-module <project-module>=<target-test-classes>
> --add-reads <project-module>=junit
> --add-exports <project-module>/<package>=junit
> -m junit/org.junit.runner.JUnitCore <test-class>
>
> which is complicated. The `--add-reads` option will depend on which test framework is used. The `--add-exports` options will be repeated for each package contains tests invoked by the test framework."
>
> So there's enough to improve to make it all work.
> I would say "any help is appreciated", but I'll leave it up to Tibor.
>
> thanks
> Robert
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1262
>
> On Mon, 28 Aug 2017 04:16:21 +0200, Russell Gold <[hidden email]> wrote:
>
>> Hi Robert,
>>
>> That sounds great. Any idea on timing of the release? What about the surefire plugin? Is there something I can do to help?  I am actively working on Java 9 issues in a few projects, including both the module system and multi-release jars, so I am very motivated to do what I can to help maven get there.
>>
>> Thanks,
>> Russ
>>
>>> On Aug 27, 2017, at 8:38 AM, Robert Scholte <[hidden email]> wrote:
>>>
>>> Hi Russ,
>>>
>>> this is how it works:
>>> in case there's a module descriptor, the module-path with be used. With the help of plexus-java it is possible to divide all jars over the module-path and classpath. This mechanism is implemented in the maven-compiler-plugin (will do an official release soon with the latest improvements), other plugins can/should use this too.
>>>
>>> This means that you actually don't need to change anything in your pom.xml. With the module descriptor and all the dependencies there's enough information to decide which jars belong on the modulepath and which on the classpath. So in the end there's no need for new scopes anymore, although that was my first thought as well.
>>>
>>> To create an installer, I think you're referring to JLink. Karl Heinz is preparing the maven-jlink-plugin.
>>>
>>> thanks,
>>> Robert
>>>
>>> On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold <[hidden email]> wrote:
>>>
>>>> I’m sure this must have been described somewhere; is there an overall direction document for supporting the java platform module system?
>>>>
>>>> case 1)
>>>>
>>>> I want to compile against another project on the module path rather than the class path. I do this in order to ensure compile-time checking for attempts to compile against non-exported packages.
>>>>
>>>> case 2)
>>>>
>>>> I want to test against another project on the module path. This would allow me to catch reflective access attempts against that module’s internals
>>>>
>>>> case 3)
>>>>
>>>> I want to use the module dependencies to create an installer, with the dependent modules on the module path. In theory, if Maven understands the above 2 cases, it would also be able to verify the requires clauses in my project’s module-info.
>>>>
>>>> So how will we be doing this in maven? Is it already supported? My first thought was that we need two new scopes: module (case 1) and module-test (case 2), but has this already been planned?
>>>>
>>>> Thanks,
>>>> Russ
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]