Re: Building and unit-testing MR Jars, easily

[Robert Scholte]

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

is it possible to use maven flatten plugin with maven shade plugin?

[Richard Sand]

Hi all,

Has anyone tried using the MojoHaus flatten plugin in conjunction with 
Maven shade plugin? The trick is to get the flatten plugin to flatten 
the DRP after shading, instead of the original pom.


My goal is for the uber-jar to include a standalone POM that does not 
reference any parent POM, but still includes any original dependencies 
that were *not* shaded. So if the project has dependencies D1, D2, and 
D3, and the shade plugin is configured to put D2 and D3 into the 
uber-jar, then the DRP will contain only a dependency for D1. I then 
want the flatten plugin to remove the parent information (and some of 
the other stuff it removes) from the DRP, put the updated POM into the 
uber-jar, and then we proceed to mvn install/deploy with the uber-jar 
and flattened DRP.


I'm guessing doing this will require code changes in the flatten plugin, 
but if there's a pure configuration way of achieving that would be 
terrific.


Thanks for any input!

-Richard