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.
Am 05.03.18 um 15:53 schrieb Aaron Coburn:
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
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
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.