We Keep Coding

Add a ResourceBundle service provider directive in a Java 13 module through moditect maven plugin

I got a Java project that I'm migrating from Java 8 to Java 13. This project uses ResourceBundles to enable language localisation.
In Java 8, I provided a custom ResourceBundle.Control to ResourceBundle.getBundle(baseName, control) but this doesn't work anymore in Java 9+. As I understand it, I must instead provide a custom ResourceBundleProvider interface, which I called UiProvider, and an implementation of this interface, UiProviderImpl, which must be used as a service.
To generate module descriptors, I'm using the moditect maven plugin. But it doesn't look like I can add a provides directive anywhere, only exports, opens and uses directives. Or am I missing anything? Here's an excerpt of my pom.xml with what I tried to configure. Can this be fixed?
<module>
<moduleInfo>
<name>net.babelsoft.negatron</name>
<opens>net.babelsoft.negatron;</opens>
<uses>theme.language.spi.UiProvider</uses>
<provides>theme.language.spi.UiProvider with theme.language.spi.UiProviderImpl</provides>
</moduleInfo>
</module>

At the time I wrote my question, Moditect didn't support the provides directive within the moduleInfo tag.
The only way was to use a moduleInfoSource tag, which forces the developper to directly write the actual content of module-info.java, not very satisfactory.
After discussing with the author of Moditect, I submitted a pull request to add the support of the provides directive within the moduleInfo tag. It hasn't been merged to Moditect source code yet...

Is apache-camel source code buildable in open-jdk-11?

When building apache-camel with openJDK-11. There are a lot of missing dependencies like
* jaxb
* annotation
* ...
How to build apache-camel source code with openJDK?
Officially there is no documentation on how to build using openJDK; Is there is any way to force build it?
I have tried adding jaxb implementation for server like "org.eclipse.persistence.moxy" but the same wasn't picked up properly :(
I have restricted the build env to be only open source; hence using openJDK as the base for development.

According to this article https://blog.codefx.org/java/java-11-migration-guide/ several packages have been removed from JDK 11.
In particular the section called Migrating From Java 8 To Java 11 shed some light on how to deal with this.
In short the following packages were removed:
The JavaBeans Activation Framework (JAF) in javax.activation CORBA in the packages javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.*
The Java Transaction API (JTA) in the package javax.transaction
JAXB in the packages javax.xml.bind.*
JAX-WS in the packages javax.jws, javax.jws.soap, javax.xml.soap, and javax.xml.ws.*
Commons Annotation in the package javax.annotation
To fix this:
Add third-party dependencies that contain the classes you need. The easiest way to do that is to stick to the reference implementations (given as Maven coordinates without version – use the most current ones):
JAF: with com.sun.activation:javax.activation
CORBA: there is currently no artifact for this
JTA: javax.transaction:javax.transaction-api
JAXB: com.sun.xml.bind:jaxb-impl
JAX-WS: com.sun.xml.ws:jaxws-ri
Commons Annotation: javax.annotation:javax.annotation-api
You can also view some more information using this Stackoverflow answer

Can/should I depend on WebLogic's bundled modules

My target platform is a WebLogic 12c application server.
I have an ear-project, which on startup requires e.g. org.apache.commons.logging.LogFactory.
I know that this class - an related classes - can be found in <WL_HOME>/modules/com.bea.core.apache.commons.logging.api_1.1.1.jar, but it is not by default available on the classspath.
In such cases - am I supposed to somehow make the jar file in <WL_HOME>/modulesavailable on the classpath - or should I provide whatever jar file I find suitable - either bundled in the application, or placed in <WL_HOME>/user_projects/domains/<mydomain>/lib?
If I am to use the one in the <WL_HOME>/modules folder - how do I configure my domain to make it available?
To me it seems reasonable that the jar files in the modules folder should be considered provided dependencies, but so far I have been unable to find the right way to enable them as such - I have been browsing for an answer for hours:-)
UPDATE:
I know I can simply add them to the CLASSPATH variable in the server startup script - my question is more like - should I? Is there a better way - or should I completely forget about <WL_HOME>/modules?

That's a short-sighted approach.
you need to reboot the server to upgrade libraries
every app on the server must be okay with those libraries in their claspath
Weblogic has the concept of Shared JEE Libraries (example). In short, you add extra lines to MANIFEST.MF and configure the jar differently, then you can reference it in other apps using weblogic-application.xml or whatever.
The point is that you can upgrade the library without restarting the server (provided you gave it a version like 1.1 (there were bugs last time I named it 1.1.1 - it needed to be able to cast it to a floating-point number to seamlessly upgrade)).
If you just want to include some libraries but not share them outside the app, then just specify the correct <prefer-application-packages> or < prefer-web-inf-classes> element, depending on whether you have an EAR or a WAR.

How to use Apache POI in OSGi

I want to use Apache POI in OSGi to write an Excel workbook with the streaming, OOXML API (SXSSF). The streaming API is available since POI 3.9.
As the latest Apache POI 3.11 jars are not bundles: What's the best way to get POI working in OSGi?
I tried two approaches:
embed the jars directly in the only bundle which will be using them
use POI jars prewrapped as bundles
I am despairing in getting all dependencies together.
First about embedding the POI jar in my bundle: my bndtools file contains
-buildpath: \
...
libs/dom4j-1.6.1.jar;version=file,\
libs/poi-3.11.jar;version=file,\
libs/poi-ooxml-3.11.jar;version=file,\
libs/poi-ooxml-schemas-3.11.jar;version=file
Private-Package: \
...
org.openxmlformats.schemas.*,\
org.apache.poi.*,\
org.dom4j.*,\
com.microsoft.schemas.office.x2006.*,\
schemaorg_apache_xmlbeans.*,\
schemasMicrosoftComOfficeExcel.*,\
schemasMicrosoftComOfficeOffice.*,\
schemasMicrosoftComVml.*
This results in a bundle which imports many, many things like for example org.bouncycastle.asn1.x509 and org.junit. I don't plan to encrypt or test in my application - so these two are probably somehow "optional". How can I specify this? Is there a good way of collecting all these dependencies?
Note: at least org.apache.commons.codec and com.sun.msv.datatype.xsd.lib are additionally required, but they are already bundles.
Using prewrapped jars, I tried using org.apache.servicemix.bundles.poi 3.9_2. This also requires dom4j so I used the prewrapped org.apache.servicemix.bundles.dom4j but that requires at least version 1.0 of javax.xml.stream which my JVM/Felix OSGi advertises as "only" version 0.0.0.1_007_JavaSE. I fixed this by hand (ugly), but then got stuck on another dependency.
What's the good way?

We use Gradle with bnd-platform to build OSGi bundles for our applications based on Maven dependencies.
No sure if this is "the good way", but this is how we build the target platform for our OSGi based applications, Apache POI being part of that. It's especially useful in cases where you have to do adaptions to bundles (e.g. make JUnit optional) or merge JARs (e.g. due to classloading issues in OSGi) to make them work.
I set up an example build with an Apache POI bundle (and implicitly, its POM-defined dependencies) on GitHub. You can clone it (sample-poi branch) and try it running ./gradlew clean bundles. Created bundles will be in build/plugins.
Please note that any optional Maven dependencies will not be included by default and have to be added manually to the build, if you need them (due to limitations in Gradle).

I don't have a working example of this work around but this bit of documentation may be helpful to you.
Can POI be used with OSGI?
Starting with POI 3.16 there's a workaround for OSGIs context
classloader handling, i.e. it replaces the threads current context
classloader with an implementation of limited class view. This will
lead to IllegalStateExceptions, as xmlbeans can't find the xml schema
definitions in this reduced view. The workaround is to initialize the
classloader delegate of POIXMLTypeLoader , which defaults to the
current thread context classloader. The initialization should take
place before any other OOXML related calls. The class in the example
could be any class, which is part of the poi-ooxml-schema or
ooxml-schema:
POIXMLTypeLoader.setClassLoader(CTTable.class.getClassLoader());

What is the difference between javax.faces-2.1.14.jar from jsf-api-2.2.0-m05.jar and jsf-impl-2.2.0-m05.jar

I am confused between the difference of javax.faces-2.1.14.jar from jsf-api-2.2.0-m05.jar and jsf-impl-2.2.0-m05.jar
I am trying to make a jsf project without using maven and while searching for examples I saw different jar dependencies on different tutorials. The tutorial from coreservlets uses javax.faces-2.1.14.jar and the other tutorial I saw from a different site uses 2 jar files jsf-api-2.2.0-m05.jar and jsf-impl-2.2.0-m05.jar
Id like to know the difference of these two set of dependencies.
Thanks in advance guys.

The jsf-api-xxx.jar contains classes that are under packages java package javax.faces. The classes in this jar are implementation of standard API defined by JSF specification. The jsf-impl-xxx.jar contains classes that are under java package com.sun.faces, which as the java package indicates, is Sun's own class for JSF implementation.
The javax.faces-xxx.jar actually merges the previous two jar files together. In the Maven repository, it is under org.glassfish groupId. You will find both javax.faces and com.sun.faces java package inside.
So what should you use for your development? Actually you can use both. But the recommended way is to include jsf-api-xxx.jar only in the compilation classpath. Thus your own application does not depend on any classes under com.sun.faces package to achieve the portability to other JSF implementations. If you are using an application such as GlassFish, the container should already provide the JSF implementation at runtime. You should not package the above JSF jar files with your war or ear file, as server will provide all of them. If you use a container that does not come with a JSF implementation by default such as Tomcat, you need to package javax.faces-xxx.jar or (jsf-api-xxx.jar + jsf-impl-xxx.jar) in the WEB-INF/lib.

They are different versions.
javax.faces-2.1.14.jar is a combined JAR file for 2.1.14
jsf-api-2.2.0-m05.jar and jsf-impl-2.2.0-m05.jar are separate JARs for 2.2.0-m05.
The differences between the versions can be found in the release notes, but 2.2 and 2.1 are non-trivially different.