> On Apr 11, 2018, at 12:36 PM, Robert Scholte <rfscho...@apache.org> wrote: > > On Wed, 11 Apr 2018 14:25:37 +0200, Russell Gold <russell.g...@oracle.com> > 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
That’s good to know. In this case, there are two profiles which are mutually exclusive. he multi-jar profile is activated when building an MR jar, and the test-toolchains-bypass profiles is run when NOT building an MR jar. I can do that with a single property. Is there a way to do that with a single -P switch? > >> >> 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 > <https://issues.apache.org/jira/browse/MCOMPILER-308> That should be easy to fix. I just need to limit the configuration to the jar goal. > >> >> 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 <provides> > in the toolchain.xml and inside the <jdk> element of the > maven-toolchains-plugin configuration. Only version has a special meaning. > e.g. you can add <vendor>oracle</vendor> or <vendor>openjdk</vendor> 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 <provides> might have more elements, but these are > ignored. Thank you. There are some things I will experiment with, to see if I can handle more cases. BTW, I have posted a list of the other MR solutions that I know of at http://www.russgold.net/sw/2018/03/looking-for-mr-good-jar/ <http://www.russgold.net/sw/2018/03/looking-for-mr-good-jar/>, along with my comments. As far as I know, mine is the only one that allows unit testing of the code for each JDK version. > > thanks, > Robert > >> >> 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
