Re: maven-compiler-plugin JPMS module resolution

[Martin Desruisseaux]

Hello Robert

Le 11/04/2018 à 18:45, Robert Scholte a écrit :

> I am not aware of such problem. Did you create a Jira[1] issue for it?
>
> There should be no reason to have a workaround, all the information is
> there so Maven is capable to divide jars properly over both paths. If
> you can add a project so I can reproduce the issue, I can have a look
> at it.
>
I have not yet created a JIRA issue. I tried last week to create a
minimal test case reproducing the issue, without success. The issue
happen with the real project; I have not yet isolated all the conditions
that make the issue happen.

The issue happen with GeoAPI [1]. The following works fine (assuming a
JSR 385 2.0-SNAPSHOT is available on the local repository):

mvn clean install -Pjdk9

But running the following immediately after:

mvn install -Pjdk9

cause the following error message:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) 
on project geoapi: Compilation failure
[ERROR] module not found: java.measure

Executing in debug mode, we can see that the java.measure (JSR-385)
dependency is correctly put in modulepath when maven-compiler-plugin
compiles everything (e.g. when the "clean" phase is present), but not
when the plugin compiles only the classes that have been modified and
that set of classes do not include module-info.java. For example the
following work

touch geoapi/src/main/java9/module-info.java
mvn install -Pjdk9

But maven-compiler-plugin then fails on the next module, unless I touch
the module-info.java of that next module too, /etc./

I will see if I can do a new attempt at creating a minimal test case
later this week.

    Martin

[1] https://github.com/opengeospatial/geoapi

Re: maven-compiler-plugin JPMS module resolution

[Robert Scholte]

Hi Martin,

I am not aware of such problem. Did you create a Jira[1] issue for it?
There should be no reason to have a workaround, all the information is  
there so Maven is capable to divide jars properly over both paths. If you  
can add a project so I can reproduce the issue, I can have a look at it.


thanks,
Robert

[1] https://issues.apache.org/jira/projects/MCOMPILER

On Wed, 11 Apr 2018 14:24:36 +0200, Martin Desruisseaux  
 wrote:



I also have the case where maven-compiler-plugin puts a dependency in
classpath while it should be in modulepath. Strangely, the plugin does
the correct thing when executed with "mvn _clean_ install" but not when
executing "mvn install" without clean. This issue happen only when the
useIncrementalCompilation option is set to false. In addition the
javadoc plugin also seems to sometime put dependencies in unexpected
classpath/modulepath option. A Maven option for specifying whether a
dependency should be in the classpath or modulepath would be convenient
as a workaround…

Martin


Le 11/04/2018 à 13:14, Roman Grigoriadi a écrit :


Thanks Robert,

I tried to add requires for name which is resolved by JPMS for my
non-modularised jar, and it *somehow* made compiler-plugin to put this  
jar

on module-path.

However if I don't want to reference this jar in my module descriptor,  
so I

let decision up to user if to put this dependency on CP or MP for app
runtime, would it make sense to add configuration parameter for
compiler-plugin which will force CP/MP for some of the dependencies  
during

compilation?

The best solution I have found so far is to copy such dependencies
somewhere before compilation and pass --module-path, --add-modules and
--add-reads to javac.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-compiler-plugin JPMS module resolution

[Robert Scholte]

Hi Roman,

seems like you want to mark your dependency as true  
and define the depending module as requires static some.module;


thanks,
Robert

On Wed, 11 Apr 2018 13:14:24 +0200, Roman Grigoriadi  
 wrote:



Thanks Robert,

I tried to add requires for name which is resolved by JPMS for my
non-modularised jar, and it *somehow* made compiler-plugin to put this  
jar

on module-path.

However if I don't want to reference this jar in my module descriptor,  
so I

let decision up to user if to put this dependency on CP or MP for app
runtime, would it make sense to add configuration parameter for
compiler-plugin which will force CP/MP for some of the dependencies  
during

compilation?

The best solution I have found so far is to copy such dependencies
somewhere before compilation and pass --module-path, --add-modules and
--add-reads to javac.


Thank you,
Roman

On Tue, Apr 10, 2018 at 8:55 PM, Robert Scholte 
wrote:


Hi

every jar that matches a "requires"-entry of your projects module
descriptor and all jars that matches the indirect requirements will be
added to the module-path. The rest will stay on the classpath.
If you want to do more, you need to verify the JPMS options available  
for

java/javac[1]

thanks
Robert

[1] https://docs.oracle.com/javase/9/tools/javac.htm#JSWOR627


On Tue, 10 Apr 2018 16:23:10 +0200, Roman Grigoriadi <
roman.grigori...@gmail.com> wrote:

Hi,


I would like to place some of the project dependencies to  
--module-path to
make them automatic "derived name" modules during project compilation.  
I
can see that maven-compiler-plugin:3.7.0 tries to find  
module-info.class
and Automatic-Module-Name entry in MANIFEST. If found it uses those  
jars

as
modules.

Is there any way I can force placement non-modularized dependencies on
module path?


Thank you,
Roman



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Building and unit-testing MR Jars, easily

[Robert Scholte]

On Wed, 11 Apr 2018 14:25:37 +0200, Russell Gold   
wrote:



Hi Robert,

I used properties because I need to trigger multiple profiles, depending  
on whether we’re building the MR jar, and what JDK versions will be  
needed - and I can use them to turn profiles off, which I could not do  
by simply turning on a profile, as far as I know.


Yes, you can turn off profiles by prefixing it with !,e.g. -P!someprofile



I didn’t consider test jars, and am not familiar with how they are used.  
Can you tell me more about them?


https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html
The issue was exposed with  
https://issues.apache.org/jira/browse/MCOMPILER-308




At present, the parent POM supports only up to JDK11, and doesn’t handle  
well cases where the main jar would be, say, JDK11. To some extent I see  
this as a stop gap. It is not clear to me if a better approach would  
start with an extension, or if there is any real long-term alternative  
to putting the changes into the compiler, surefire, and jar plugins.


Unit testing is the default behavior. Toolchains are used to compile  
each version of the code with the correct compiler (since the  
source/target and release flags don’t quite duplicate doing so), and  
then surefire runs the tests with the jdk used to run Maven itself.  
Clearly, the documentation is lacking. But yes, you do need to run the  
build multiple times, since the code actually run can vary. If you are  
using Travis CI, that means that you need to configure the toolchains  
explicitly. I have not yet figured out how to do this with both oracle  
and open jdk options, since the toolchains seem to require you to make  
that choice in the pom, not just the JDK.


Not sure if I understand. But you can add as much entries to both  
 in the toolchain.xml and inside the  element of the  
maven-toolchains-plugin configuration. Only version has a special meaning.
e.g. you can add oracle or openjdk to  
the toolchain.xml and the plugin configuration. By adding it to the plugin  
you say that at least version+vendor must be specified in the  
toolchain.xml with matching values. The  might have more  
elements, but these are ignored.


thanks,
Robert



Thanks,
Russ


On Apr 4, 2018, at 3:11 PM, Robert Scholte  wrote:

Hi Russell, interesting approach.

The difference between library developers and application developers  
becomes more and more clear and this concept might be useful for  
library builders.
We should probably have a separate page for all the available solutions  
and menion the pro's and cons.


Just a few remarks: why are you using property enabled profiles instead  
of -Pmulti-release?
Be aware that you can also create test-jars, which should NOT have the  
multi-release flag set in the MANIFEST.


It will mean that you should provide a new version every every half  
year, unless you already add all those versions right now ;)


What I'm missing is a clear explanation how unit testing works. IIUC  
you build the whole project with a specific JDK version and that's how  
the matching unittests are executed. So you should run the build X  
times, once for every multirelease version.


thanks,
Robert


On Tue, 03 Apr 2018 21:42:39 +0200, Russell Gold  
 wrote:


I have just developed a new and easier way for building MR Jars  
, while waiting for  
the capability to be built into Maven.


This approach is not only simple to set up (just use the designated  
parent POM, if you can), it lets you unit test for any supported JDK.  
For example:


jdk7 && mvn -Dmulti_release clean test
jdk10 && mvn -Dmulti_release clean test

where jdk7 and jdk10 set the appropriate versions for maven to use.  
Either will run against the appropriate additional code.


To build an MR JAR you set a property on the command line

mvn -Dmulti_release clean install

which happens automatically when doing a release.

I have also explained how it works at Easier Than It Looks  






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Building and unit-testing MR Jars, easily

[Russell Gold]

Hi Robert,

I used properties because I need to trigger multiple profiles, depending on 
whether we’re building the MR jar, and what JDK versions will be needed - and I 
can use them to turn profiles off, which I could not do by simply turning on a 
profile, as far as I know.

I didn’t consider test jars, and am not familiar with how they are used. Can 
you tell me more about them?

At present, the parent POM supports only up to JDK11, and doesn’t handle well 
cases where the main jar would be, say, JDK11. To some extent I see this as a 
stop gap. It is not clear to me if a better approach would start with an 
extension, or if there is any real long-term alternative to putting the changes 
into the compiler, surefire, and jar plugins.

Unit testing is the default behavior. Toolchains are used to compile each 
version of the code with the correct compiler (since the source/target and 
release flags don’t quite duplicate doing so), and then surefire runs the tests 
with the jdk used to run Maven itself. Clearly, the documentation is lacking. 
But yes, you do need to run the build multiple times, since the code actually 
run can vary. If you are using Travis CI, that means that you need to configure 
the toolchains explicitly. I have not yet figured out how to do this with both 
oracle and open jdk options, since the toolchains seem to require you to make 
that choice in the pom, not just the JDK.

Thanks,
Russ

> On Apr 4, 2018, at 3:11 PM, Robert Scholte  wrote:
> 
> Hi Russell, interesting approach.
> 
> The difference between library developers and application developers becomes 
> more and more clear and this concept might be useful for library builders.
> We should probably have a separate page for all the available solutions and 
> menion the pro's and cons.
> 
> Just a few remarks: why are you using property enabled profiles instead of 
> -Pmulti-release?
> Be aware that you can also create test-jars, which should NOT have the 
> multi-release flag set in the MANIFEST.
> 
> It will mean that you should provide a new version every every half year, 
> unless you already add all those versions right now ;)
> 
> What I'm missing is a clear explanation how unit testing works. IIUC you 
> build the whole project with a specific JDK version and that's how the 
> matching unittests are executed. So you should run the build X times, once 
> for every multirelease version.
> 
> thanks,
> Robert
> 
> 
> On Tue, 03 Apr 2018 21:42:39 +0200, Russell Gold  
> wrote:
> 
>> I have just developed a new and easier way for building MR Jars 
>> , while waiting for the 
>> capability to be built into Maven.
>> 
>> This approach is not only simple to set up (just use the designated parent 
>> POM, if you can), it lets you unit test for any supported JDK. For example:
>> 
>> jdk7 && mvn -Dmulti_release clean test
>> jdk10 && mvn -Dmulti_release clean test
>> 
>> where jdk7 and jdk10 set the appropriate versions for maven to use. Either 
>> will run against the appropriate additional code.
>> 
>> To build an MR JAR you set a property on the command line
>> 
>> mvn -Dmulti_release clean install
>> 
>> which happens automatically when doing a release.
>> 
>> I have also explained how it works at Easier Than It Looks 
>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-compiler-plugin JPMS module resolution

[Martin Desruisseaux]

I also have the case where maven-compiler-plugin puts a dependency in
classpath while it should be in modulepath. Strangely, the plugin does
the correct thing when executed with "mvn _clean_ install" but not when
executing "mvn install" without clean. This issue happen only when the
useIncrementalCompilation option is set to false. In addition the
javadoc plugin also seems to sometime put dependencies in unexpected
classpath/modulepath option. A Maven option for specifying whether a
dependency should be in the classpath or modulepath would be convenient
as a workaround…

    Martin


Le 11/04/2018 à 13:14, Roman Grigoriadi a écrit :

> Thanks Robert,
>
> I tried to add requires for name which is resolved by JPMS for my
> non-modularised jar, and it *somehow* made compiler-plugin to put this jar
> on module-path.
>
> However if I don't want to reference this jar in my module descriptor, so I
> let decision up to user if to put this dependency on CP or MP for app
> runtime, would it make sense to add configuration parameter for
> compiler-plugin which will force CP/MP for some of the dependencies during
> compilation?
>
> The best solution I have found so far is to copy such dependencies
> somewhere before compilation and pass --module-path, --add-modules and
> --add-reads to javac.

Re: maven-compiler-plugin JPMS module resolution

[Roman Grigoriadi]

Thanks Robert,

I tried to add requires for name which is resolved by JPMS for my
non-modularised jar, and it *somehow* made compiler-plugin to put this jar
on module-path.

However if I don't want to reference this jar in my module descriptor, so I
let decision up to user if to put this dependency on CP or MP for app
runtime, would it make sense to add configuration parameter for
compiler-plugin which will force CP/MP for some of the dependencies during
compilation?

The best solution I have found so far is to copy such dependencies
somewhere before compilation and pass --module-path, --add-modules and
--add-reads to javac.


Thank you,
Roman

On Tue, Apr 10, 2018 at 8:55 PM, Robert Scholte 
wrote:

> Hi
>
> every jar that matches a "requires"-entry of your projects module
> descriptor and all jars that matches the indirect requirements will be
> added to the module-path. The rest will stay on the classpath.
> If you want to do more, you need to verify the JPMS options available for
> java/javac[1]
>
> thanks
> Robert
>
> [1] https://docs.oracle.com/javase/9/tools/javac.htm#JSWOR627
>
>
> On Tue, 10 Apr 2018 16:23:10 +0200, Roman Grigoriadi <
> roman.grigori...@gmail.com> wrote:
>
> Hi,
>>
>> I would like to place some of the project dependencies to --module-path to
>> make them automatic "derived name" modules during project compilation. I
>> can see that maven-compiler-plugin:3.7.0 tries to find module-info.class
>> and Automatic-Module-Name entry in MANIFEST. If found it uses those jars
>> as
>> modules.
>>
>> Is there any way I can force placement non-modularized dependencies on
>> module path?
>>
>>
>> Thank you,
>> Roman
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: How can I prevent SLF4J's infamous “multiple bindings” warning at build time for maven build?

[Nick Stolwijk]

You can ban duplicate classes with the enforcer plugin [1].

[1] http://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html

Hth,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Wed, Apr 11, 2018 at 10:39 AM Debraj Manna 
wrote:

> I have seen a similar question being answered in stackoverflow
>
>
> https://stackoverflow.com/questions/25335497/how-can-i-prevent-slf4js-infamous-multiple-bindings-warning-at-build-time
>
> Is it possible achieve something like this via maven build also ?
>

How can I prevent SLF4J's infamous “multiple bindings” warning at build time for maven build?

[Debraj Manna]

I have seen a similar question being answered in stackoverflow

https://stackoverflow.com/questions/25335497/how-can-i-prevent-slf4js-infamous-multiple-bindings-warning-at-build-time

Is it possible achieve something like this via maven build also ?