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


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 <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.

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

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

Reply via email to