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.


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 
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.

Aaron Coburn

Reply via email to