You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Aaron Coburn <ac...@apache.org> on 2018/03/05 14:53:48 UTC
Java 9 & 10
Hi,
I am a bit new to Tamaya, so apologies if this has already been discussed. It is clear that the codebase targets Java 8. It is also entirely _usable_ on newer (jdk9 & jdk10) platforms. However, it is not currently possible to build Tamaya on jdk9 or jdk10. My first question is: should it be possible to build Tamaya on the latest JDK?
In fact, the only impediment to building on jdk9 is the karaf-maven-plugin. In particular, some Java EE libraries are no longer on the classpath by default: javax.xml.bind and javax.activation. With jdk10, these libraries will no longer be included in the Java SE at all. Adding those dependencies directly to the plugin configuration or upgrading to the latest (milestone) Karaf release makes it possible to build on jdk9.
Building on jdk10 has the additional problem of the javadoc plugin not being able to parse the JVM version string with commons-lang 3.5 release. Forcing the use of commons-lang 3.7 for the plugin solves that.
Is this something you all would like to support? I can provide a pull request for that.
The other, related, issue has to do with the Java 9 module system (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there is a fairly simple thing that can be done to make the Tamaya codebase easier to use with the Java 9 module system. Basically, it involves adding a "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file. Practically, this means adjusting the various bnd.bnd files in the codebase. For instance, the tamaya-core JAR would likely have a module name of: org.apache.tamaya.core (typically, this would align with the existing OSGi Export-Package). The tamaya-api JAR currently exports two packages (o.a.t and o.a.t.spi), so perhaps the module name would simply be org.apache.tamaya? I suspect that the various extensions would make use of the current OSGi export naming convention for this, as with tamaya-core. If this is something you'd like to have for the 0.4 release, I can also supply a pull request for that.
Also, I am happy to open JIRA issues for either or both of these items, though I wasn't sure if you'd like to discuss either of these first.
Thanks,
Aaron Coburn
Re: Java 9 & 10
Posted by "P. Ottlinger" <po...@apache.org>.
Hi Aaron,
thanks for taking care and your contributions ....
Am 06.03.2018 um 21:30 schrieb Aaron Coburn:
> Just to be clear, I am not suggesting the addition of any Java 9 or 10 features to Tamaya. I suspect that it makes much more sense for the source code to continue to target Java 8. I am just interested in making the source code *buildable* on the newer JDKs.
and sorry for the delay.
I just merged all of your PRs,
let's see what the ASF infra/Jenkins thinks about it,
Phil
Re: Java 9 & 10
Posted by Anatole Tresch <at...@gmail.com>.
+1 also from my side: stick with 8, ensure it builds with later versions.
Am 06.03.2018 21:30 schrieb "Aaron Coburn" <ac...@amherst.edu>:
> Just to be clear, I am not suggesting the addition of any Java 9 or 10
> features to Tamaya. I suspect that it makes much more sense for the source
> code to continue to target Java 8. I am just interested in making the
> source code *buildable* on the newer JDKs.
>
> > On Mar 6, 2018, at 3:07 PM, Werner Keil <we...@gmail.com> wrote:
> >
> > Actually a Multi-Release JAR if we found that useful (with a new JDK
> every 6 months it seems tempting or even inevitable) is not built with Java
> 9 or 10, the plugin states it should be with Java 8, but thanks to the
> Multi-release feature and META-INF it’ll work with different versions.
> >
> > I am not sure, how it deals with e.g. a class that relies on entirely
> new language Features of Java 10 or 11 like „var“ etc. that someone has to
> find out. I tried to build JARs with a module-info under JDK9 and it would
> no longer run on a JVM before Java 9.
>
> Correct. If the source code itself targets Java 9 (e.g. with the
> module-info.java file), then it becomes runnable only on Java 9+, unless
> you make use of a Multi-Release JAR. And the Maven tooling for
> Multi-Release JARs is still catching up (at least it was when I last
> checked into this).
>
> > I don’t think we want to be trapped in a Java „Version-Hell“ so at least
> Java 8 should still work for some time as the Minimum Version.
>
> Yes, exactly. Quite a few Apache projects are staying on Java 8 at least
> until there is another LTS version available (i.e. Java 11), and from the
> perspective of making Tamaya easy to adopt in other projects, there are
> good arguments for remaining on Java 8 for now.
>
> Regards,
> Aaron
>
>
> >
> > From: Aaron Coburn
> > Sent: Tuesday, March 6, 2018 21:01
> > To: dev@tamaya.incubator.apache.org
> > Subject: Re: Java 9 & 10
> >
> > Hi,
> >
> > Travis-CI currently supports Java 9 builds, which would be simple to add
> to the current .travis.yml configuration. It is possible to test Java 10 on
> Travis but it requires some acrobatics (find the latest EA version by
> parsing some HTML, download the JDK artifact and then install it).
> Including CI support for JDK 10 is most likely not worth the effort in the
> context of Travis.
> >
> > For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are
> both available: https://cwiki.apache.org/confluence/display/INFRA/JDK+
> Installation+Matrix <https://cwiki.apache.org/
> confluence/display/INFRA/JDK+Installation+Matrix>
> >
> > Regards,
> > Aaron
> >
> >> On Mar 6, 2018, at 2:17 PM, Oliver B. Fischer <o....@swe-blog.net>
> wrote:
> >>
> >> Hi Aaron,
> >>
> >> as far I know we don't have any CI job for Java 9 or 10. So it would be
> difficult to maintain such changes without breaking it.
> >>
> >> I could check Apache's Jenkins if both JDK versions available on
> Jenkins.
> >>
> >> Best,
> >> Oliver
> >>
> >> Am 05.03.18 um 15:53 schrieb Aaron Coburn:
> >>> Hi,
> >>> I am a bit new to Tamaya, so apologies if this has already been
> discussed. It is clear that the codebase targets Java 8. It is also
> entirely _usable_ on newer (jdk9 & jdk10) platforms. However, it is not
> currently possible to build Tamaya on jdk9 or jdk10. My first question is:
> should it be possible to build Tamaya on the latest JDK?
> >>> In fact, the only impediment to building on jdk9 is the
> karaf-maven-plugin. In particular, some Java EE libraries are no longer on
> the classpath by default: javax.xml.bind and javax.activation. With jdk10,
> these libraries will no longer be included in the Java SE at all. Adding
> those dependencies directly to the plugin configuration or upgrading to the
> latest (milestone) Karaf release makes it possible to build on jdk9.
> >>> Building on jdk10 has the additional problem of the javadoc plugin not
> being able to parse the JVM version string with commons-lang 3.5 release.
> Forcing the use of commons-lang 3.7 for the plugin solves that.
> >>> Is this something you all would like to support? I can provide a pull
> request for that.
> >>> The other, related, issue has to do with the Java 9 module system
> (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there is a
> fairly simple thing that can be done to make the Tamaya codebase easier to
> use with the Java 9 module system. Basically, it involves adding a
> "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file.
> Practically, this means adjusting the various bnd.bnd files in the
> codebase. For instance, the tamaya-core JAR would likely have a module name
> of: org.apache.tamaya.core (typically, this would align with the existing
> OSGi Export-Package). The tamaya-api JAR currently exports two packages
> (o.a.t and o.a.t.spi), so perhaps the module name would simply be
> org.apache.tamaya? I suspect that the various extensions would make use of
> the current OSGi export naming convention for this, as with tamaya-core. If
> this is something you'd like to have for the 0.4 release, I can also supply
> a pull request for that.
> >>> Also, I am happy to open JIRA issues for either or both of these
> items, though I wasn't sure if you'd like to discuss either of these first.
> >>> Thanks,
> >>> Aaron Coburn
> >
> >
>
>
Re: Java 9 & 10
Posted by Aaron Coburn <ac...@amherst.edu>.
Just to be clear, I am not suggesting the addition of any Java 9 or 10 features to Tamaya. I suspect that it makes much more sense for the source code to continue to target Java 8. I am just interested in making the source code *buildable* on the newer JDKs.
> On Mar 6, 2018, at 3:07 PM, Werner Keil <we...@gmail.com> wrote:
>
> Actually a Multi-Release JAR if we found that useful (with a new JDK every 6 months it seems tempting or even inevitable) is not built with Java 9 or 10, the plugin states it should be with Java 8, but thanks to the Multi-release feature and META-INF it’ll work with different versions.
>
> I am not sure, how it deals with e.g. a class that relies on entirely new language Features of Java 10 or 11 like „var“ etc. that someone has to find out. I tried to build JARs with a module-info under JDK9 and it would no longer run on a JVM before Java 9.
Correct. If the source code itself targets Java 9 (e.g. with the module-info.java file), then it becomes runnable only on Java 9+, unless you make use of a Multi-Release JAR. And the Maven tooling for Multi-Release JARs is still catching up (at least it was when I last checked into this).
> I don’t think we want to be trapped in a Java „Version-Hell“ so at least Java 8 should still work for some time as the Minimum Version.
Yes, exactly. Quite a few Apache projects are staying on Java 8 at least until there is another LTS version available (i.e. Java 11), and from the perspective of making Tamaya easy to adopt in other projects, there are good arguments for remaining on Java 8 for now.
Regards,
Aaron
>
> From: Aaron Coburn
> Sent: Tuesday, March 6, 2018 21:01
> To: dev@tamaya.incubator.apache.org
> Subject: Re: Java 9 & 10
>
> Hi,
>
> Travis-CI currently supports Java 9 builds, which would be simple to add to the current .travis.yml configuration. It is possible to test Java 10 on Travis but it requires some acrobatics (find the latest EA version by parsing some HTML, download the JDK artifact and then install it). Including CI support for JDK 10 is most likely not worth the effort in the context of Travis.
>
> For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are both available: https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix <https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix>
>
> Regards,
> Aaron
>
>> On Mar 6, 2018, at 2:17 PM, Oliver B. Fischer <o....@swe-blog.net> wrote:
>>
>> Hi Aaron,
>>
>> as far I know we don't have any CI job for Java 9 or 10. So it would be difficult to maintain such changes without breaking it.
>>
>> I could check Apache's Jenkins if both JDK versions available on Jenkins.
>>
>> Best,
>> Oliver
>>
>> Am 05.03.18 um 15:53 schrieb Aaron Coburn:
>>> Hi,
>>> I am a bit new to Tamaya, so apologies if this has already been discussed. It is clear that the codebase targets Java 8. It is also entirely _usable_ on newer (jdk9 & jdk10) platforms. However, it is not currently possible to build Tamaya on jdk9 or jdk10. My first question is: should it be possible to build Tamaya on the latest JDK?
>>> In fact, the only impediment to building on jdk9 is the karaf-maven-plugin. In particular, some Java EE libraries are no longer on the classpath by default: javax.xml.bind and javax.activation. With jdk10, these libraries will no longer be included in the Java SE at all. Adding those dependencies directly to the plugin configuration or upgrading to the latest (milestone) Karaf release makes it possible to build on jdk9.
>>> Building on jdk10 has the additional problem of the javadoc plugin not being able to parse the JVM version string with commons-lang 3.5 release. Forcing the use of commons-lang 3.7 for the plugin solves that.
>>> Is this something you all would like to support? I can provide a pull request for that.
>>> The other, related, issue has to do with the Java 9 module system (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there is a fairly simple thing that can be done to make the Tamaya codebase easier to use with the Java 9 module system. Basically, it involves adding a "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file. Practically, this means adjusting the various bnd.bnd files in the codebase. For instance, the tamaya-core JAR would likely have a module name of: org.apache.tamaya.core (typically, this would align with the existing OSGi Export-Package). The tamaya-api JAR currently exports two packages (o.a.t and o.a.t.spi), so perhaps the module name would simply be org.apache.tamaya? I suspect that the various extensions would make use of the current OSGi export naming convention for this, as with tamaya-core. If this is something you'd like to have for the 0.4 release, I can also supply a pull request for that.
>>> Also, I am happy to open JIRA issues for either or both of these items, though I wasn't sure if you'd like to discuss either of these first.
>>> Thanks,
>>> Aaron Coburn
>
>
RE: Java 9 & 10
Posted by Werner Keil <we...@gmail.com>.
Actually a Multi-Release JAR if we found that useful (with a new JDK every 6 months it seems tempting or even inevitable) is not built with Java 9 or 10, the plugin states it should be with Java 8, but thanks to the Multi-release feature and META-INF it’ll work with different versions.
I am not sure, how it deals with e.g. a class that relies on entirely new language Features of Java 10 or 11 like „var“ etc. that someone has to find out. I tried to build JARs with a module-info under JDK9 and it would no longer run on a JVM before Java 9.
I don’t think we want to be trapped in a Java „Version-Hell“ so at least Java 8 should still work for some time as the Minimum Version.
Werner
From: Aaron Coburn
Sent: Tuesday, March 6, 2018 21:01
To: dev@tamaya.incubator.apache.org
Subject: Re: Java 9 & 10
Hi,
Travis-CI currently supports Java 9 builds, which would be simple to add to the current .travis.yml configuration. It is possible to test Java 10 on Travis but it requires some acrobatics (find the latest EA version by parsing some HTML, download the JDK artifact and then install it). Including CI support for JDK 10 is most likely not worth the effort in the context of Travis.
For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are both available: https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix <https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix>
Regards,
Aaron
> On Mar 6, 2018, at 2:17 PM, Oliver B. Fischer <o....@swe-blog.net> wrote:
>
> Hi Aaron,
>
> as far I know we don't have any CI job for Java 9 or 10. So it would be difficult to maintain such changes without breaking it.
>
> I could check Apache's Jenkins if both JDK versions available on Jenkins.
>
> Best,
> Oliver
>
> Am 05.03.18 um 15:53 schrieb Aaron Coburn:
>> Hi,
>> I am a bit new to Tamaya, so apologies if this has already been discussed. It is clear that the codebase targets Java 8. It is also entirely _usable_ on newer (jdk9 & jdk10) platforms. However, it is not currently possible to build Tamaya on jdk9 or jdk10. My first question is: should it be possible to build Tamaya on the latest JDK?
>> In fact, the only impediment to building on jdk9 is the karaf-maven-plugin. In particular, some Java EE libraries are no longer on the classpath by default: javax.xml.bind and javax.activation. With jdk10, these libraries will no longer be included in the Java SE at all. Adding those dependencies directly to the plugin configuration or upgrading to the latest (milestone) Karaf release makes it possible to build on jdk9.
>> Building on jdk10 has the additional problem of the javadoc plugin not being able to parse the JVM version string with commons-lang 3.5 release. Forcing the use of commons-lang 3.7 for the plugin solves that.
>> Is this something you all would like to support? I can provide a pull request for that.
>> The other, related, issue has to do with the Java 9 module system (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there is a fairly simple thing that can be done to make the Tamaya codebase easier to use with the Java 9 module system. Basically, it involves adding a "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file. Practically, this means adjusting the various bnd.bnd files in the codebase. For instance, the tamaya-core JAR would likely have a module name of: org.apache.tamaya.core (typically, this would align with the existing OSGi Export-Package). The tamaya-api JAR currently exports two packages (o.a.t and o.a.t.spi), so perhaps the module name would simply be org.apache.tamaya? I suspect that the various extensions would make use of the current OSGi export naming convention for this, as with tamaya-core. If this is something you'd like to have for the 0.4 release, I can also supply a pull request for that.
>> Also, I am happy to open JIRA issues for either or both of these items, though I wasn't sure if you'd like to discuss either of these first.
>> Thanks,
>> Aaron Coburn
Re: Java 9 & 10
Posted by Aaron Coburn <ac...@amherst.edu>.
Hi,
> On Mar 19, 2018, at 4:50 PM, P. Ottlinger <po...@apache.org> wrote:
>
> Am 06.03.2018 um 21:01 schrieb Aaron Coburn:
>> Travis-CI currently supports Java 9 builds, which would be simple to add to the current .travis.yml configuration. It is possible to test Java 10 on Travis but it requires some acrobatics (find the latest EA version by parsing some HTML, download the JDK artifact and then install it). Including CI support for JDK 10 is most likely not worth the effort in the context of Travis.
>>
>> For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are both available: https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix <https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix>
>
>
> +1
>
> I've added JDK9 to the travis matrix and builds seem to be fine.
It appears that I neglected to send a pull request to the tamaya-extensions repository to add JDK 9+ build support. I have just done so, and it appears that Travis-CI is satisfied with the change.
https://travis-ci.org/apache/incubator-tamaya-extensions/builds/356025813
Locally, I have also verified that the code builds with the jdk10 GA release.
> We can stick with the old JDK8 on ASF.
This makes sense.
Cheers,
Aaron
Re: Java 9 & 10
Posted by "P. Ottlinger" <po...@apache.org>.
Hi,
Am 06.03.2018 um 21:01 schrieb Aaron Coburn:
> Travis-CI currently supports Java 9 builds, which would be simple to add to the current .travis.yml configuration. It is possible to test Java 10 on Travis but it requires some acrobatics (find the latest EA version by parsing some HTML, download the JDK artifact and then install it). Including CI support for JDK 10 is most likely not worth the effort in the context of Travis.
>
> For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are both available: https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix <https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix>
+1
I've added JDK9 to the travis matrix and builds seem to be fine.
We can stick with the old JDK8 on ASF.
Cheers,
Phil
Re: Java 9 & 10
Posted by Aaron Coburn <ac...@apache.org>.
Hi,
Travis-CI currently supports Java 9 builds, which would be simple to add to the current .travis.yml configuration. It is possible to test Java 10 on Travis but it requires some acrobatics (find the latest EA version by parsing some HTML, download the JDK artifact and then install it). Including CI support for JDK 10 is most likely not worth the effort in the context of Travis.
For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are both available: https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix <https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix>
Regards,
Aaron
> On Mar 6, 2018, at 2:17 PM, Oliver B. Fischer <o....@swe-blog.net> wrote:
>
> Hi Aaron,
>
> as far I know we don't have any CI job for Java 9 or 10. So it would be difficult to maintain such changes without breaking it.
>
> I could check Apache's Jenkins if both JDK versions available on Jenkins.
>
> Best,
> Oliver
>
> Am 05.03.18 um 15:53 schrieb Aaron Coburn:
>> Hi,
>> I am a bit new to Tamaya, so apologies if this has already been discussed. It is clear that the codebase targets Java 8. It is also entirely _usable_ on newer (jdk9 & jdk10) platforms. However, it is not currently possible to build Tamaya on jdk9 or jdk10. My first question is: should it be possible to build Tamaya on the latest JDK?
>> In fact, the only impediment to building on jdk9 is the karaf-maven-plugin. In particular, some Java EE libraries are no longer on the classpath by default: javax.xml.bind and javax.activation. With jdk10, these libraries will no longer be included in the Java SE at all. Adding those dependencies directly to the plugin configuration or upgrading to the latest (milestone) Karaf release makes it possible to build on jdk9.
>> Building on jdk10 has the additional problem of the javadoc plugin not being able to parse the JVM version string with commons-lang 3.5 release. Forcing the use of commons-lang 3.7 for the plugin solves that.
>> Is this something you all would like to support? I can provide a pull request for that.
>> The other, related, issue has to do with the Java 9 module system (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there is a fairly simple thing that can be done to make the Tamaya codebase easier to use with the Java 9 module system. Basically, it involves adding a "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file. Practically, this means adjusting the various bnd.bnd files in the codebase. For instance, the tamaya-core JAR would likely have a module name of: org.apache.tamaya.core (typically, this would align with the existing OSGi Export-Package). The tamaya-api JAR currently exports two packages (o.a.t and o.a.t.spi), so perhaps the module name would simply be org.apache.tamaya? I suspect that the various extensions would make use of the current OSGi export naming convention for this, as with tamaya-core. If this is something you'd like to have for the 0.4 release, I can also supply a pull request for that.
>> Also, I am happy to open JIRA issues for either or both of these items, though I wasn't sure if you'd like to discuss either of these first.
>> Thanks,
>> Aaron Coburn
Re: Java 9 & 10
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi Aaron,
as far I know we don't have any CI job for Java 9 or 10. So it would be
difficult to maintain such changes without breaking it.
I could check Apache's Jenkins if both JDK versions available on Jenkins.
Best,
Oliver
Am 05.03.18 um 15:53 schrieb Aaron Coburn:
> Hi,
>
> I am a bit new to Tamaya, so apologies if this has already been discussed. It is clear that the codebase targets Java 8. It is also entirely _usable_ on newer (jdk9 & jdk10) platforms. However, it is not currently possible to build Tamaya on jdk9 or jdk10. My first question is: should it be possible to build Tamaya on the latest JDK?
>
> In fact, the only impediment to building on jdk9 is the karaf-maven-plugin. In particular, some Java EE libraries are no longer on the classpath by default: javax.xml.bind and javax.activation. With jdk10, these libraries will no longer be included in the Java SE at all. Adding those dependencies directly to the plugin configuration or upgrading to the latest (milestone) Karaf release makes it possible to build on jdk9.
>
> Building on jdk10 has the additional problem of the javadoc plugin not being able to parse the JVM version string with commons-lang 3.5 release. Forcing the use of commons-lang 3.7 for the plugin solves that.
>
> Is this something you all would like to support? I can provide a pull request for that.
>
>
> The other, related, issue has to do with the Java 9 module system (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there is a fairly simple thing that can be done to make the Tamaya codebase easier to use with the Java 9 module system. Basically, it involves adding a "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file. Practically, this means adjusting the various bnd.bnd files in the codebase. For instance, the tamaya-core JAR would likely have a module name of: org.apache.tamaya.core (typically, this would align with the existing OSGi Export-Package). The tamaya-api JAR currently exports two packages (o.a.t and o.a.t.spi), so perhaps the module name would simply be org.apache.tamaya? I suspect that the various extensions would make use of the current OSGi export naming convention for this, as with tamaya-core. If this is something you'd like to have for the 0.4 release, I can also supply a pull request for that.
>
> Also, I am happy to open JIRA issues for either or both of these items, though I wasn't sure if you'd like to discuss either of these first.
>
> Thanks,
> Aaron Coburn
>
Re: Java 9 & 10
Posted by Werner Keil <we...@gmail.com>.
Hi,
I raised this for the RI of JSR 385, the upcoming new Units of Measurement
standard 2.0: https://github.com/unitsofmeasurement/indriya/issues/25
If this Maven plugin was acceptable by Apache projects it could be used not
only by Tamaya.
And utilizing the Multi-Release JAR feature of Java 9 would even allow to
include support for Java 7 if we still care or 8 and beyond.
Gunnar is also at JavaLand, so those who are there or at the community
Unconference may get a chance to talk to him about it.
Regards,
Werner
On Mon, Mar 5, 2018 at 4:59 PM, Anatole Tresch <at...@gmail.com> wrote:
> Hi Aaron
>
> thank you very much for your mail. Both, opening jira, as well as
> providing patches are very welcome, as well ad any other feedback!
>
> Best
> Anatole
>
> Am 05.03.2018 15:53 schrieb "Aaron Coburn" <ac...@apache.org>:
>
> > Hi,
> >
> > I am a bit new to Tamaya, so apologies if this has already been
> discussed.
> > It is clear that the codebase targets Java 8. It is also entirely
> _usable_
> > on newer (jdk9 & jdk10) platforms. However, it is not currently possible
> to
> > build Tamaya on jdk9 or jdk10. My first question is: should it be
> possible
> > to build Tamaya on the latest JDK?
> >
> > In fact, the only impediment to building on jdk9 is the
> > karaf-maven-plugin. In particular, some Java EE libraries are no longer
> on
> > the classpath by default: javax.xml.bind and javax.activation. With
> jdk10,
> > these libraries will no longer be included in the Java SE at all. Adding
> > those dependencies directly to the plugin configuration or upgrading to
> the
> > latest (milestone) Karaf release makes it possible to build on jdk9.
> >
> > Building on jdk10 has the additional problem of the javadoc plugin not
> > being able to parse the JVM version string with commons-lang 3.5 release.
> > Forcing the use of commons-lang 3.7 for the plugin solves that.
> >
> > Is this something you all would like to support? I can provide a pull
> > request for that.
> >
> >
> > The other, related, issue has to do with the Java 9 module system
> > (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there
> is a
> > fairly simple thing that can be done to make the Tamaya codebase easier
> to
> > use with the Java 9 module system. Basically, it involves adding a
> > "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file.
> > Practically, this means adjusting the various bnd.bnd files in the
> > codebase. For instance, the tamaya-core JAR would likely have a module
> name
> > of: org.apache.tamaya.core (typically, this would align with the existing
> > OSGi Export-Package). The tamaya-api JAR currently exports two packages
> > (o.a.t and o.a.t.spi), so perhaps the module name would simply be
> > org.apache.tamaya? I suspect that the various extensions would make use
> of
> > the current OSGi export naming convention for this, as with tamaya-core.
> If
> > this is something you'd like to have for the 0.4 release, I can also
> supply
> > a pull request for that.
> >
> > Also, I am happy to open JIRA issues for either or both of these items,
> > though I wasn't sure if you'd like to discuss either of these first.
> >
> > Thanks,
> > Aaron Coburn
>
Re: Java 9 & 10
Posted by Anatole Tresch <at...@gmail.com>.
Hi Aaron
thank you very much for your mail. Both, opening jira, as well as
providing patches are very welcome, as well ad any other feedback!
Best
Anatole
Am 05.03.2018 15:53 schrieb "Aaron Coburn" <ac...@apache.org>:
> Hi,
>
> I am a bit new to Tamaya, so apologies if this has already been discussed.
> It is clear that the codebase targets Java 8. It is also entirely _usable_
> on newer (jdk9 & jdk10) platforms. However, it is not currently possible to
> build Tamaya on jdk9 or jdk10. My first question is: should it be possible
> to build Tamaya on the latest JDK?
>
> In fact, the only impediment to building on jdk9 is the
> karaf-maven-plugin. In particular, some Java EE libraries are no longer on
> the classpath by default: javax.xml.bind and javax.activation. With jdk10,
> these libraries will no longer be included in the Java SE at all. Adding
> those dependencies directly to the plugin configuration or upgrading to the
> latest (milestone) Karaf release makes it possible to build on jdk9.
>
> Building on jdk10 has the additional problem of the javadoc plugin not
> being able to parse the JVM version string with commons-lang 3.5 release.
> Forcing the use of commons-lang 3.7 for the plugin solves that.
>
> Is this something you all would like to support? I can provide a pull
> request for that.
>
>
> The other, related, issue has to do with the Java 9 module system
> (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there is a
> fairly simple thing that can be done to make the Tamaya codebase easier to
> use with the Java 9 module system. Basically, it involves adding a
> "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file.
> Practically, this means adjusting the various bnd.bnd files in the
> codebase. For instance, the tamaya-core JAR would likely have a module name
> of: org.apache.tamaya.core (typically, this would align with the existing
> OSGi Export-Package). The tamaya-api JAR currently exports two packages
> (o.a.t and o.a.t.spi), so perhaps the module name would simply be
> org.apache.tamaya? I suspect that the various extensions would make use of
> the current OSGi export naming convention for this, as with tamaya-core. If
> this is something you'd like to have for the 0.4 release, I can also supply
> a pull request for that.
>
> Also, I am happy to open JIRA issues for either or both of these items,
> though I wasn't sure if you'd like to discuss either of these first.
>
> Thanks,
> Aaron Coburn