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 <rfscho...@apache.org> 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 <russell.g...@oracle.com> > wrote: > >> I have just developed a new and easier way for building MR Jars >> <https://github.com/meterware/multirelease-parent>, 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 >> <http://www.russgold.net/sw/2018/04/easier-than-it-looks/> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
