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

Reply via email to