[ANN] Apache Maven Shared Component: Maven Shared Utils Version 3.2.0 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the 
Apache Maven Shared Component: Maven Shared Utils Version 3.2.0
 
https://maven.apache.org/shared/maven-shared-utils/

You should specify the version in your project:
 

  org.apache.maven.shared
  maven-shared-utils
  3.2.0


You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/shared/maven-shared-utils/download.cgi
 
Release Notes Maven Shared Utils 3.2.0

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12338026

Bugs:

 * [MSHARED-574] - UT failure on Windows: utils.io.Java7SupportTest 
createAndReadSymlink
 * [MSHARED-610] - PrettyPrintXMLWriter internally uses java.io.PrintWriter 
without checking for any errors.
 * [MSHARED-617] - StreamFeeder should flush OutputStream
 * [MSHARED-618] - CommandLineCallable does not always call the 
'runAfterProcessTermination' runnable.
 * [MSHARED-619] - StreamFeeder silently ignores exceptions.
 * [MSHARED-622] - CommandLineCallable silently ignores exceptions thrown from 
the stdin processor (StreemFeeder).
 * [MSHARED-630] - Javadoc of several classes still references Maven 3.4.0 for 
color support

Improvements:

 * [MSHARED-587] - remove logger level API from MessageBuilder
 * [MSHARED-620] - CommandLineCallable should defer starting threads until 
called.
 * [MSHARED-621] - CommandLineCallable should calculate process timeouts using 
'System.nanoTime' instead of 'System.currentTimeMillis'.
 * [MSHARED-639] - Removed prerequisites cause it is not a plugin

Task:

 * [MSHARED-623] - Deprecation of methods 'close' and 'flush' of class 
'StreamPumper'.

Enjos,
 
-The Apache Maven team

Karl Heinz Marbaise

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

Re: Follow up: Building projects for multiple platforms

[Christofer Dutz]

Hi,

Ok … turns out it was a combination of things I had to do.

In the end this configuration worked:


org.apache.maven.plugins
maven-surefire-plugin
2.20

  
**/*Test.class
  
  
${project.build.testOutputDirectory}

  

It seems that testClassesDirectory is used for generated test classes, to I 
just used my retrolambda processed classes as generated classes.
Second thing was to change the directory scanning pattern to look for “class” 
files instead of “java” files. Couldn’t find this documented anyware … again 
the code was the best documentation ;-)

Now I have to get the toolchain thingy to work …

Chris



Am 17.06.17, 18:20 schrieb "Christofer Dutz" :

Hi Karl Heinz,

I’m already working on this. Now I’m simply setting up a set of “pure-pom” 
modules. I got the dependency plugin to unpack the jar to “target/classes” and 
test-jar to “target/test-classes” and retrolambda is correctly transforming 
them there. Even the animalsniffer is now happy with the 1.7 signatures (It 
fails, if I disable the retrolambda plugin). So right now, all is looking good.

… Except I can’t seem to get surefire to detect any tests.

I also saw the config option to run the tests, unfortunately the unit-test 
jar is created after the unit test phase, using the java8 version shouldn’t 
work. Also I don’t feel that comfortable with reconfiguring the plugins to work 
in different phases just to trick surefire into running my tests … think I’ll 
just grab the sources of the surefire plug in and see if I can find a way to 
make it do what I want :-)

But anyway … I have gotten really far with this approach … thank you for 
that … and I think this will cause far less problems when releasing.

Chris


Am 17.06.17, 16:48 schrieb "Karl Heinz Marbaise" :

Hi,

On 17/06/17 16:23, Christofer Dutz wrote:
> I Karl Heinz,
> 
> I think that’s a really good idea … unfortunately I can’t seem to be 
able to run the retrolambda plugin on jars, so I might setup little projects, 
that use the dependency-plugin to unpack the jars and test-jars first and run 
the retrolambda on them and then package them back. Eventually this might also 
help running the testsuite a second time, but with Java7. Is there a way to 
have maven execute tests with a different java version (Run maven with Java 8 
and execute the tests with Java 7)?  Right now I’m relying on the animalsniffer 
plugin  to verify my java8 and java7 jars, but the others would feel more 
comfortable if we really ran the tests with a different java version.

That's example for using toolchains...

Running Maven with Java 8 and running Tests with Java 7 ...which should 
be a separate module (otherwise the configuration would be a 
nightmare)...

If I correctly understand that scenario you have a jar build with Java 
8 
in a module call it "xyz-jdk8" also having tests for that ...

Now you need another module (defining toolchains using JDK 7) running 
your tests with surefire (I can remember there is an option to scan 
existing jars which contain tests found it: dependenciesToScan )...and 
run the tests and repackage after retolambda...But you have to be sure 
that the tests don't use JDK 8 specific parts cause they will run on 
JDK 
7 ...

Should working I didn't even test it...

Kidn regards
Karl Heinz Marbaise


> 
> Chris
> 
> Am 16.06.17, 14:36 schrieb "Karl Heinz Marbaise" :
> 
>  Hi,
>  
>  I would make a separate module for java8 and run there the 
retrolambda-
>  maven-plugin and another separate module for java7 and run there 
the
>  retrolambda-
>  maven-plugin as well...than you can make a separate jar file for 
each ...
>  
>  No need for different executions of the compiler plugins etc. and
>  separte output folders configurations etc.
>  
>  This needs to use toolchains and then you can run with a single
>  run...all of them...
>  
>  Just coming into my mind...
>  
>  
>  
>  If i correctly understand you are developing in JDK 8 and than 
you would
>  like to offer a package which supports JDK 7 ..
>  
>  So making a module with JDK 8 code in it pluse unit tests...
>  
>  A separate module which uses the JDK 8 code as dependency and 
using the
>  retrolambda plugin and maybe some supplemental tests on 
it...using JDK 7
> 

Re: Follow up: Building projects for multiple platforms

[Christofer Dutz]

Hi Karl Heinz,

I’m already working on this. Now I’m simply setting up a set of “pure-pom” 
modules. I got the dependency plugin to unpack the jar to “target/classes” and 
test-jar to “target/test-classes” and retrolambda is correctly transforming 
them there. Even the animalsniffer is now happy with the 1.7 signatures (It 
fails, if I disable the retrolambda plugin). So right now, all is looking good.

… Except I can’t seem to get surefire to detect any tests.

I also saw the config option to run the tests, unfortunately the unit-test jar 
is created after the unit test phase, using the java8 version shouldn’t work. 
Also I don’t feel that comfortable with reconfiguring the plugins to work in 
different phases just to trick surefire into running my tests … think I’ll just 
grab the sources of the surefire plug in and see if I can find a way to make it 
do what I want :-)

But anyway … I have gotten really far with this approach … thank you for that … 
and I think this will cause far less problems when releasing.

Chris


Am 17.06.17, 16:48 schrieb "Karl Heinz Marbaise" :

Hi,

On 17/06/17 16:23, Christofer Dutz wrote:
> I Karl Heinz,
> 
> I think that’s a really good idea … unfortunately I can’t seem to be able 
to run the retrolambda plugin on jars, so I might setup little projects, that 
use the dependency-plugin to unpack the jars and test-jars first and run the 
retrolambda on them and then package them back. Eventually this might also help 
running the testsuite a second time, but with Java7. Is there a way to have 
maven execute tests with a different java version (Run maven with Java 8 and 
execute the tests with Java 7)?  Right now I’m relying on the animalsniffer 
plugin  to verify my java8 and java7 jars, but the others would feel more 
comfortable if we really ran the tests with a different java version.

That's example for using toolchains...

Running Maven with Java 8 and running Tests with Java 7 ...which should 
be a separate module (otherwise the configuration would be a nightmare)...

If I correctly understand that scenario you have a jar build with Java 8 
in a module call it "xyz-jdk8" also having tests for that ...

Now you need another module (defining toolchains using JDK 7) running 
your tests with surefire (I can remember there is an option to scan 
existing jars which contain tests found it: dependenciesToScan )...and 
run the tests and repackage after retolambda...But you have to be sure 
that the tests don't use JDK 8 specific parts cause they will run on JDK 
7 ...

Should working I didn't even test it...

Kidn regards
Karl Heinz Marbaise


> 
> Chris
> 
> Am 16.06.17, 14:36 schrieb "Karl Heinz Marbaise" :
> 
>  Hi,
>  
>  I would make a separate module for java8 and run there the 
retrolambda-
>  maven-plugin and another separate module for java7 and run there the
>  retrolambda-
>  maven-plugin as well...than you can make a separate jar file for 
each ...
>  
>  No need for different executions of the compiler plugins etc. and
>  separte output folders configurations etc.
>  
>  This needs to use toolchains and then you can run with a single
>  run...all of them...
>  
>  Just coming into my mind...
>  
>  
>  
>  If i correctly understand you are developing in JDK 8 and than you 
would
>  like to offer a package which supports JDK 7 ..
>  
>  So making a module with JDK 8 code in it pluse unit tests...
>  
>  A separate module which uses the JDK 8 code as dependency and using 
the
>  retrolambda plugin and maybe some supplemental tests on it...using 
JDK 7
>  which can be handled with Toolchain...
>  
>  
>  Kind regards
>  Karl Heinz Marbaise
>  
>  On 16/06/17 14:25, Justin Georgeson wrote:
>  > Instead of tweaking the version, I would configure an executions 
of the compiler plugins compile and testcompile goals to a separate output 
folders, like ${build.directory}${file.separator}classes-java7 and 
${build.directory}${file.separator}test-classes-java7 and then an execution of 
the jar plugin to create/attach a jar with classifier set to 'java7'.
>  >
>  > 
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
>  >
>  > That way you can have both versions build/deploy together in one 
pipeline with the same version.
>  >
>  > You can use properties in the version if you use Maven 3.5 with 
some other tricks, there was a recent thread on the list about it
>  >
>  > http://www.mail-archive.com/users@maven.apache.org/msg139475.html
>  >
>  >
>  

Re: Follow up: Building projects for multiple platforms

[Karl Heinz Marbaise]

Hi,

On 17/06/17 16:23, Christofer Dutz wrote:

I Karl Heinz,

I think that’s a really good idea … unfortunately I can’t seem to be able to 
run the retrolambda plugin on jars, so I might setup little projects, that use 
the dependency-plugin to unpack the jars and test-jars first and run the 
retrolambda on them and then package them back. Eventually this might also help 
running the testsuite a second time, but with Java7. Is there a way to have 
maven execute tests with a different java version (Run maven with Java 8 and 
execute the tests with Java 7)?  Right now I’m relying on the animalsniffer 
plugin  to verify my java8 and java7 jars, but the others would feel more 
comfortable if we really ran the tests with a different java version.


That's example for using toolchains...

Running Maven with Java 8 and running Tests with Java 7 ...which should 
be a separate module (otherwise the configuration would be a nightmare)...


If I correctly understand that scenario you have a jar build with Java 8 
in a module call it "xyz-jdk8" also having tests for that ...


Now you need another module (defining toolchains using JDK 7) running 
your tests with surefire (I can remember there is an option to scan 
existing jars which contain tests found it: dependenciesToScan )...and 
run the tests and repackage after retolambda...But you have to be sure 
that the tests don't use JDK 8 specific parts cause they will run on JDK 
7 ...


Should working I didn't even test it...

Kidn regards
Karl Heinz Marbaise




Chris

Am 16.06.17, 14:36 schrieb "Karl Heinz Marbaise" :

 Hi,
 
 I would make a separate module for java8 and run there the retrolambda-

 maven-plugin and another separate module for java7 and run there the
 retrolambda-
 maven-plugin as well...than you can make a separate jar file for each ...
 
 No need for different executions of the compiler plugins etc. and

 separte output folders configurations etc.
 
 This needs to use toolchains and then you can run with a single

 run...all of them...
 
 Just coming into my mind...
 
 
 
 If i correctly understand you are developing in JDK 8 and than you would

 like to offer a package which supports JDK 7 ..
 
 So making a module with JDK 8 code in it pluse unit tests...
 
 A separate module which uses the JDK 8 code as dependency and using the

 retrolambda plugin and maybe some supplemental tests on it...using JDK 7
 which can be handled with Toolchain...
 
 
 Kind regards

 Karl Heinz Marbaise
 
 On 16/06/17 14:25, Justin Georgeson wrote:

 > Instead of tweaking the version, I would configure an executions of the 
compiler plugins compile and testcompile goals to a separate output folders, like 
${build.directory}${file.separator}classes-java7 and 
${build.directory}${file.separator}test-classes-java7 and then an execution of the 
jar plugin to create/attach a jar with classifier set to 'java7'.
 >
 > 
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
 >
 > That way you can have both versions build/deploy together in one 
pipeline with the same version.
 >
 > You can use properties in the version if you use Maven 3.5 with some 
other tricks, there was a recent thread on the list about it
 >
 > http://www.mail-archive.com/users@maven.apache.org/msg139475.html
 >
 >
 >> -Original Message-
 >> From: Christofer Dutz [mailto:christofer.d...@c-ware.de]
 >> Sent: Friday, June 16, 2017 3:54 AM
 >> To: Maven List 
 >> Subject: [EXTERNAL] Follow up: Building projects for multiple platforms
 >>
 >> External Sender: Use caution with links/attachments.
 >>
 >>
 >>
 >> Hi,
 >>
 >> A short follow up question regarding my last one.
 >> In the Edgent maven build, which I am working on, we need to produce 
java8,
 >> java7 and android versions of jars. This is done by running the 
retrolambda-
 >> maven-plugin on the classes when building the java7 version. To make the
 >> dependency resolution work correctly with all variants we decided to 
use the
 >> normal version number for the java8 output and add a suffix of “–java7” 
to the
 >> version in case of a java7 build (for SNAPSHOT versions the “-java7” is 
included
 >> between the version and the “SNAPSHOT”). In order to be able to switch 
the
 >> versions by selecting profiles, I used variables for the artifact 
versions.
 >> As I know variables for versions of parent poms is a really bad idea 
(Don’t even
 >> know if it works), I setup the project to have constant versions in the 
parent
 >> poms and only use these for configuring the reactor and the plugins – no
 >> dependencies are handled here. The build is working nicey, 
unfortunately the
 >> build is outputting hundreds of 

Re: Follow up: Building projects for multiple platforms

[Christofer Dutz]

I Karl Heinz,

I think that’s a really good idea … unfortunately I can’t seem to be able to 
run the retrolambda plugin on jars, so I might setup little projects, that use 
the dependency-plugin to unpack the jars and test-jars first and run the 
retrolambda on them and then package them back. Eventually this might also help 
running the testsuite a second time, but with Java7. Is there a way to have 
maven execute tests with a different java version (Run maven with Java 8 and 
execute the tests with Java 7)?  Right now I’m relying on the animalsniffer 
plugin  to verify my java8 and java7 jars, but the others would feel more 
comfortable if we really ran the tests with a different java version.

Chris

Am 16.06.17, 14:36 schrieb "Karl Heinz Marbaise" :

Hi,

I would make a separate module for java8 and run there the retrolambda-
maven-plugin and another separate module for java7 and run there the 
retrolambda-
maven-plugin as well...than you can make a separate jar file for each ...

No need for different executions of the compiler plugins etc. and 
separte output folders configurations etc.

This needs to use toolchains and then you can run with a single 
run...all of them...

Just coming into my mind...



If i correctly understand you are developing in JDK 8 and than you would 
like to offer a package which supports JDK 7 ..

So making a module with JDK 8 code in it pluse unit tests...

A separate module which uses the JDK 8 code as dependency and using the 
retrolambda plugin and maybe some supplemental tests on it...using JDK 7 
which can be handled with Toolchain...


Kind regards
Karl Heinz Marbaise

On 16/06/17 14:25, Justin Georgeson wrote:
> Instead of tweaking the version, I would configure an executions of the 
compiler plugins compile and testcompile goals to a separate output folders, 
like ${build.directory}${file.separator}classes-java7 and 
${build.directory}${file.separator}test-classes-java7 and then an execution of 
the jar plugin to create/attach a jar with classifier set to 'java7'.
> 
> 
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
> 
> That way you can have both versions build/deploy together in one pipeline 
with the same version.
> 
> You can use properties in the version if you use Maven 3.5 with some 
other tricks, there was a recent thread on the list about it
> 
> http://www.mail-archive.com/users@maven.apache.org/msg139475.html
> 
> 
>> -Original Message-
>> From: Christofer Dutz [mailto:christofer.d...@c-ware.de]
>> Sent: Friday, June 16, 2017 3:54 AM
>> To: Maven List 
>> Subject: [EXTERNAL] Follow up: Building projects for multiple platforms
>>
>> External Sender: Use caution with links/attachments.
>>
>>
>>
>> Hi,
>>
>> A short follow up question regarding my last one.
>> In the Edgent maven build, which I am working on, we need to produce 
java8,
>> java7 and android versions of jars. This is done by running the 
retrolambda-
>> maven-plugin on the classes when building the java7 version. To make the
>> dependency resolution work correctly with all variants we decided to use 
the
>> normal version number for the java8 output and add a suffix of “–java7” 
to the
>> version in case of a java7 build (for SNAPSHOT versions the “-java7” is 
included
>> between the version and the “SNAPSHOT”). In order to be able to switch 
the
>> versions by selecting profiles, I used variables for the artifact 
versions.
>> As I know variables for versions of parent poms is a really bad idea 
(Don’t even
>> know if it works), I setup the project to have constant versions in the 
parent
>> poms and only use these for configuring the reactor and the plugins – no
>> dependencies are handled here. The build is working nicey, unfortunately 
the
>> build is outputting hundreds of warnings like this:
>>
>> [WARNING] Some problems were encountered while building the effective 
model
>> for 
org.apache.edgent.analytics:edgent-analytics-sensors:jar:1.2.0-SNAPSHOT
>> [WARNING] 'version' contains an expression but should be a constant. @
>> org.apache.edgent.analytics:edgent-analytics-sensors:${edgent.version},
>> /Users/christoferdutz/Projects/Apache/Edgent/incubator-
>> edgent/analytics/sensors/pom.xml, line 31, column 12
>>
>> Is there a “maven way” (TM) to achieve this sort of thing without the 
warnings?
>>
>> Chris
> 
> --
> This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is 

Re: ClassNotFoundException: org.sonatype.aether.collection.DependencyCollectionException

[Robert Scholte]

Hi,

it looks like the plugin is pretty old ;)
They should try to have an implementation based on  
maven-artifact-transfer[1], which supports both Aether implementations.


thanks,
Robert

[1] https://maven.apache.org/shared/maven-artifact-transfer/

On Fri, 16 Jun 2017 16:19:52 +0200, Sergio Fernández   
wrote:



Hi,

I'm suffering this issue, reported at
https://issues.apache.org/jira/browse/MARMOTTA-668

I found some details at
https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound

But the information looks prety old. Does anybody has any hint how to  
some

this build issue?

Thanks in advance!

Cheers,


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