Konrad Windszus wrote > Some more investigations on that: > > The BREE header is deprecated since OSGi 4.3 > (https://www.infoq.com/news/2011/03/osgi-43). I don't think we should > generate it any longer. Instead we should only rely on the Require-Capability > which is being generated by bnd automatically based on the class version > (compare with http://bnd.bndtools.org/instructions/noee.html and > https://github.com/bndtools/bnd/blob/41056e2507e9781d17aeaf66a00b35370a63043d/biz.aQute.bndlib/src/aQute/bnd/osgi/Analyzer.java#L772)
Good point, in fact the OSGi spec states that a bundle should not use both at the same time - which we actually do. So removing the BREE header simplifies everything Regards Carsten > > Regarding the animal-sniffer-plugin: > 1) There is not yet a Java 9 signature (i.e. requiring java9 for Sling > Modules does not work yet) > 2) Javac 9 comes with bootclasspaths for Java 6, Java 7 and Java 8 (see > https://stackoverflow.com/a/43103038/5155923 and > http://openjdk.java.net/jeps/247) which makes using animal-sniffer-plugin > obsolete with JDK9. > > I would therefore recommend to configure javac via the "release" parameter > (supported since m-c-p 3.6.0, see > https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release). > Maybe we should do that in a profile only activated for Java9 and above. > The animal-sniffer-plugin should only be used for Java < 9. > > I think with those conclusions we can again get rid of your custom plugin and > only use the buildhelper-plugin to determine the right animal sniffer > signature version when running in Java < 9. > WDYT? > >> On 4. Sep 2017, at 14:01, Robert Munteanu <romb...@apache.org> wrote: >> >> On Mon, 2017-09-04 at 13:06 +0200, Konrad Windszus wrote: >>>> Am 04.09.2017 um 11:30 schrieb Robert Munteanu <romb...@apache.org> >>>> : >>>> >>>>> On Mon, 2017-09-04 at 08:55 +0200, Konrad Windszus wrote: >>>>> If I understand correctly we only need to extract the relevant >>>>> version from the sling java property and use that then in the >>>>> configuration of other plugins (like animal sniffer or m-c-p). >>>>> That >>>>> is totally possible with the mentioned buildhelper plugin. >>>> >>>> Agreed. >>>> >>>>> There is no need for a dedicated plugin. The BREE header is >>>>> mostly >>>>> static and must be set in the m-b-p configuration. The dynamic >>>>> part >>>>> can also be retrieved via the buildhelper plugin. I hope this >>>>> makes >>>>> things clearer. >>>> >>>> The BREE header is set following the sling.java.version property. >>>> Yes, >>>> it is mostly static but does not directly follow the Java version ( >>>> see >>>> [1] for more details). Here is a mapping of sling.java.version to >>>> BREE >>>> headers: >>>> >>>> 5 - J2SE-1.5 >>>> 6 - JavaSE-1.6 >>>> 7 - JavaSE-1.7 >>>> 8 - JavaSE-1.8 >>>> 9 - JavaSE-9 >>>> >>>> This is something that we mapped with the antrun plugin stuff. Now >>>> I >>>> propose switching to a custom plugin due to Java 9 issues. >>>> >>>> I still don't see how the BREE header can be configured using the >>>> buildhelper plugin. Can you add a small config snippet or link to >>>> an >>>> example? >>>> >>> >>> Supporting Java5 is probably not necessary and even for Java 9 >>> JavaSE-1.9 seems valid. >> >> Seems, but it is not :-) >> >> I started the Sling launchpad with Java 9 and the system bundle >> provides the following capabilities: >> >> osgi.ee; osgi.ee="OSGi/Minimum"; version:List="1.0, 1.1, 1.2", osgi.ee; >> osgi.ee="JavaSE"; version:List="1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, >> 1.8, 9", >> osgi.ee; osgi.ee="JavaSE/compact1"; version:List="1.8, 9", >> osgi.ee; osgi.ee="JavaSE/compact2"; version:List="1.8, 9", >> osgi.ee; osgi.ee="JavaSE/compact3"; version:List="1.8, 9" >> >> Note the 9 everywhere, following the version change in Java: >> >> $ /opt/jdk-9/bin/java -version >> java version "9" >> (snip) >> >>> I think you can generate the header then with the following bnd >>> instruction: http://bnd.bndtools.org/instructions/runee.html >> >> The way I read it, this instruction parses a string argument into an EE >> enum. That does not help us as we are using a 'plain' java version >> string, not a legal execution environment value. >> >> ----- >> >> I understand the desire to not reinvent the wheel, especially with >> infrastructure code. However, releasing this plugin unblocks us with >> testing for Java 9, which has further issues once we run the ITs. >> >> Releasing a version of this plugin does not mean we'll never revisit >> the solution. If there is something better, I'm happy to remove the >> plugin from our parent pom. But given that the code is there, it's >> small and self-contained I'm inclined just to use it for now, and when >> we have a better solution retire it. >> >> Thanks, >> >> Robert >> >>> >>>> Thanks, >>>> >>>> Robert >>>> >>>> >>>> [1]: https://www.osgi.org/developer/specifications/reference/ >>>>> >>>>> Von meinem iPhone gesendet >>>>> >>>>>> Am 03.09.2017 um 23:01 schrieb Robert Munteanu <rombert@apache. >>>>>> org> >>>>>> : >>>>>> >>>>>> Hi Konrad, >>>>>> >>>>>>> On Sat, 2017-09-02 at 10:38 +0200, Konrad Windszus wrote: >>>>>>> Sorry for answering late, but wouldn't the buildhelper plugin >>>>>>> with >>>>>>> its parse-version fulfill our needs: http://www.mojohaus.org/ >>>>>>> buil >>>>>>> d-he >>>>>>> lper-maven-plugin/parse-version-mojo.html >>>>>>> >>>>>>> That should be able to generate all version strings in the >>>>>>> required >>>>>>> formats from one source property. >>>>>> >>>>>> The functionality is not about setting the project's version, >>>>>> but >>>>>> about >>>>>> generating the 'minimum supported java' version for various >>>>>> plugins. >>>>>> For javac and animal-sniffer it's usually the Java version >>>>>> number. >>>>>> For >>>>>> the maven-bundle-plugin it's the Bundle- >>>>>> RequiredExecutionEnvironment >>>>>> header. >>>>>> >>>>>> I don't see how the build helper plugin can generate the >>>>>> Bundle- >>>>>> RequiredExecutionEnvironment header. Is there such an option? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Robert >>>>>> >>>>>>> >>>>>>> Von meinem iPhone gesendet >>>>>>> >>>>>>>> Am 01.09.2017 um 10:10 schrieb Karl Pauls <karlpauls@gmail. >>>>>>>> com> >>>>>>>> : >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> regards, >>>>>>>> >>>>>>>> Karl >>>>>>>> >>>>>>>>> On Fri, Sep 1, 2017 at 8:35 AM, Carsten Ziegeler <cziegel >>>>>>>>> er@a >>>>>>>>> pach >>>>>>>>> e.org> wrote: >>>>>>>>> Sounds good to me, thanks Robert >>>>>>>>> >>>>>>>>> Carsten >>>>>>>>> >>>>>>>>> Robert Munteanu wrote >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> As you might know, running the Sling ITs with Java 9 is >>>>>>>>>> blocked >>>>>>>>>> by an >>>>>>>>>> incompatibility of the maven-antrun-plugin with Java 9 >>>>>>>>>> ([1], >>>>>>>>>> [2]). >>>>>>>>>> >>>>>>>>>> It seems that a solution is not yet agreed on and I'd >>>>>>>>>> like >>>>>>>>>> to >>>>>>>>>> start >>>>>>>>>> running the ITs on Java 9 sooner rather than later. >>>>>>>>>> >>>>>>>>>> To that end, I've written a tiny Maven plugin which >>>>>>>>>> does >>>>>>>>>> exactly what >>>>>>>>>> the maven-antrun-plugin snippet did [3]. TBH, I never >>>>>>>>>> really >>>>>>>>>> liked >>>>>>>>>> scripting in the pom but that's another issue :-) >>>>>>>>>> >>>>>>>>>> Anyway, my proposal is to drop the maven-antrun-plugin >>>>>>>>>> _only_ >>>>>>>>>> for >>>>>>>>>> setting the project properties in the parent pom. >>>>>>>>>> Bertrand >>>>>>>>>> rightly >>>>>>>>>> mentioned that we have other usages all over Sling, but >>>>>>>>>> those >>>>>>>>>> do not >>>>>>>>>> affect running the ITs and I won't touch them. >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>>> >>>>>>>>>> Robert >>>>>>>>>> >>>>>>>>>> [1]: https://issues.apache.org/jira/browse/SLING-7072 >>>>>>>>>> [2]: https://issues.apache.org/jira/browse/MNG-6275 >>>>>>>>>> [3]: http://svn.apache.org/viewvc?rev=1806875&view=rev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Carsten Ziegeler >>>>>>>>> Adobe Research Switzerland >>>>>>>>> cziege...@apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Karl Pauls >>>>>>>> karlpa...@gmail.com > > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
