On Apr 12, 2018, at 10:44 AM, Martin Gainty <mgai...@hotmail.com> wrote:
> 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> 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: > <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> 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. If you are actively working on adding MR capabilities to the compiler plugin, is there something I can do to help? > 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
