I’m afraid I don’t understand what you are asking. That solution 
<http://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/> 
doesn’t use a build.xml. It uses the ant-plugin in its pom.xml:
[https://www.gravatar.com/avatar/8e25c0ca4bf25113bd9c0ccc5d118164?s=65]<http://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/>

Building Multi-Release JARs with Maven - In Relation 
To<http://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/>
in.relation.to
Java 9 comes with a new feature very useful to library authors: multi-release 
JARs (JEP 238). A multi-release JAR (MR JAR) may contain multiple variants of 
one and the same class, each targeting a specific Java version. At runtime, the 
right variant of the class will be loaded automatically ...




>         <plugin>
>             <groupId>org.apache.maven.plugins</groupId>
>             <artifactId>maven-antrun-plugin</artifactId>
>             <executions>
>                 <execution>
>                     <id>compile-java9</id>
>                     <phase>compile</phase>
>                     <configuration>
>                         <tasks>
>                             <mkdir dir="${java9.build.outputDirectory}" />
>                             <javac srcdir="${java9.sourceDirectory}" 
> destdir="${java9.build.outputDirectory}"
>                                 classpath="${project.build.outputDirectory}" 
> includeantruntime="false" />
>                         </tasks>
>                     </configuration>
>                     <goals>
>                         <goal>run</goal>
>                     </goals>
>                 </execution>
>             </executions>
>         </plugin>
MG>looks similar to maven-compiler-plugin with srcdir / destdir /classpath 
attrs..a bit more intuitive than maven-compiler-plugin
<artifactId>maven-compiler-plugin</artifactId>
<executions>
 <execution>
  <id>default-compile</id>
  <configuration>
   <compilerArgs>
    <srcdir>"${java9.sourceDirectory}</srcdir>
    <destdir>"${java9.build.outputDirectory}"</destdir>
    <classpath>${project.build.outputDirectory}</classpath>
   </compilerArgs>
....
MG>

which doesn’t do anything that is missing from the compiler plugin. It was 
actually my realization that I could do the exact thing with a separate 
execution that led me to the approach I have described.
MG>yes but your maven-antrun-plugin is more intuitive than preceding 
maven-compiler-plugin

If you are actively working on adding MR capabilities to the compiler plugin, 
is there something I can do to help?

MG>initial evaluation would include what are advantages/disadvantages of MR

> On Apr 12, 2018, at 10:44 AM, Martin Gainty <mgai...@hotmail.com> wrote:
>
> MG>one-off request with ant only approach to compiling MR jars
>
> ________________________________
> From: Russell Gold <russell.g...@oracle.com <mailto:russell.g...@oracle.com>>
> Sent: Thursday, April 12, 2018 7:00 AM
> To: Robert Scholte
> Cc: Maven Users List
> Subject: Re: Building and unit-testing MR Jars, easily
>
>
>
>> 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
> How to create a jar containing test classes - Apache 
> Maven<https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html
>  
> <https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html>>
> maven.apache.org <http://maven.apache.org/>
> When you want to create a jar containing test-classes, you would probably 
> want to reuse those classes. There are two ways to solve this: Create an 
> attached jar with the test-classes from the current project and loose its 
> transitive test-scoped dependencies. Create a separate project with the test 
> ...
>
>
>
>> The issue was exposed with 
>> https://issues.apache.org/jira/browse/MCOMPILER-308 
>> <https://issues.apache.org/jira/browse/MCOMPILER-308> 
>> <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/> 
> <http://www.russgold.net/sw/2018/03/looking-for-mr-good-jar/ 
> <http://www.russgold.net/sw/2018/03/looking-for-mr-good-jar/>>,
> MG>With regards to "Use of the ant-plugin to compile the JDK 9 code"
> MG>do you have a build.xml target we can use to backport features and 
> functions of this target into maven-compiler-plugin
> MG>possible trigger could be maven-compiler-plugin configuration of
> MG><source>1.9</source> and/or
> MG><target>1.9</target>
>
> 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