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
