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

How to specify dependent features of custom liberty feature

I am developing a custom feature with WAB and ServiceBundles. I want to specify the dependent features as well in my feature manifest file.
Subsystem-Content: ServiceProvider;version=1.0.0,
ServiceProviderWeb;version=1.0.0,
com.ibm.websphere.appserver.adminCenter-1.0; type="osgi.subsystem.feature",
com.ibm.wsspi.appserver.webBundle-1.0; type="osgi.subsystem.feature"
Is it correct way to do it ? Eclipse Dev tools not giving option to select dependent features (built-in).

The syntax for including the adminCenter-1.0 and webBundle-1.0 features are correct, since you have listed them as type="osgi.subsystem.feature".
You can inspect other Liberty features for some examples by looking in wlp/lib/features/*.mf. For example, this is what the webBundle-1.0 feature has currently for Subsystem-Content:
Subsystem-Content: com.ibm.websphere.appserver.spi.wab.configure_1.0-javadoc.zip; type=file; location:="dev/spi/ibm/javadoc/com.ibm.websphere.appserver.spi.wab.configure_1.0-javadoc.zip",
com.ibm.websphere.appserver.servlet-3.0; ibm.tolerates:="3.1"; type="osgi.subsystem.feature",
com.ibm.websphere.appserver.spi.wab.configure; location:="dev/spi/ibm/,lib/"; type=jar; version="[1.0.0,1.0.200)",
com.ibm.ws.app.manager.wab; start-phase:=CONTAINER_LATE; version="[1.0.0,1.0.200)",
com.ibm.ws.eba.wab.integrator; version="[1.0.0,1.0.200)"
To break this down line by line:
includes a javadoc zip from wlp/dev/spi/ibm/javadoc
includes the serlet-3.0 feature, but also tolerates servlet-3.1
includes an wab configuration SPI jar at either wlp/dev/spi/ibm/ or wlp/lib/
includes two other bundles in a similar fashion
You can find official documentation on developing Liberty features here:
Developing a Liberty feature manually

Hibernate and Jersey dependency conflict (javassist) - can anyone explain how this works?

I'm currently using hibernate-4.1.4 and jersey-2.22. These have javassist-3.15 and javassist-3.18 respectively.
I included both hibernate and jersey in my project and to my surprise, there were no dependency conflicts between the said javassists.
I was wondering how Java tells hibernate to use 3.15 and how it tell jersey to use 3.18 since both are in the build path. Is one javassist not being used?
Follow up question: Let's say that javassist-3.15 and javassist-3.18 have a conflict with each other. How do I resolve this? Do I disable both javassists and include one externally?
EDIT: My app is a web app that runs on Tomcat 7. We don't use Maven/Gradle. We just configure the dependencies by putting the jars in the build path using Eclipse.

JAVA loads classes through ClassLoaders ... Many applications servers, as Tomcat or Wildfly, implement and use their own class loaders (not the regular ones of the common JDK) ... So you must check the Tomcat documentation to read about its classloading behaviour...
After saying that, is very likely that Tomcat is loading libraries in alphabetical order. I Explain...
Suppose that you use a class named: Dummy, and this class is contained at the libraries: dummy-1.0.jar and dummy-1.1.jar ... when the class Dummy is requested, the Tomcat ClassLoader search for that class definition, looking first at dummy-1.0.jar and later at dummy-1.1.jar ... given that dummy-1.0.jar contains that class, Tomcat stops looking a returns that class version ... If dummy-1.0.jar would not have the target class, the dummy-1.1.jar class version would be returned instead...
(I suggest to try this to validate the container behaivour, it's not so hard to implement)...
And yes, if javassist-3.15 and javassist-3.18 conflicts with each other, you should remove them and pick the javassist JAR more
suitable for both libraries (jersey and hibernate).
As thumb rule, I tend to pick the newest library (the one with greater version), but this scheme not always work...

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.