> 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 

>> 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/>, 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

Reply via email to