Saxon

Is it a known issue that sometimes the jar file can't find the license file even through it's in the same directory?

Answer: yes. The logic Saxon uses is this:

            CodeSource codeSource = getClass().getProtectionDomain().getCodeSource();
            if (codeSource != null) {
                URL sourceLoc = codeSource.getLocation();
                if (sourceLoc != null) {
                    URL licenseLoc = new URL(sourceLoc, LICENSE_FILE_NAME);

and to be honest, it works in some environments and not in others, and I don't really understand enough about protection domains and the like to know the details. I know that it's related to code signing, so it wouldn't surprise me if changing the manifest headers upsets things too.

Let us know how you get on with OSGi. It's been on our "TODO" list for years, but I've never seen a clear explanation of what we need to do to enable it, what exactly we can achieve once it's done, and how we test that we have got it right when we have done so.

I did manage to get it running as an OSGi bundle in Karaf. (Karaf by the way is a standalone OSGi container but is used in both ServiceMix and JBoss Fuse, so applies there as well.) Normally Karaf will genereate OSGi metadata when you drop a jar file in, but in this case the metadata for Saxon-EE needed guidance, so we used the bnd tool. This properties file when fed to bnd.jar at least works even if it's not entirely locked down:

version=9.6.0.4
Bundle-Name: Saxon-EE
Bundle-SymbolicName: saxon-ee
Bundle-Version: ${version}
Import-Package: com.ibm.icu.*;resolution:=optional,org.dom4j.*;resolution:=optional,nu.xom;resolution:=optional,org.apache.axiom.*;resolution:=optional,org.apache.xml.resolver.*;resolution:=optional,org.jdom.*;resolution:=optional,org.jdom2.*;resolution:=optional,*
Export-Package: *;version=${version}
DynamicImport-Package: *

With the headers this adds in the Saxon-EE jar manifest, Karaf happily lists it as an active OSGi package "Saxon-EE (9.6.0.4)" when dropped into the deploy directory.

It still requires the use of FeatureKeys.LICENSE_FILE_LOCATION and FeatureKeys.GENERATE_BYTE_CODE set to false otherwise it will complain. Again, I'm not sure why.

That aside, Saxon needs an OSGi-friendly dynamic class loading strategy because it's impossible to generate manifest entries for classes only known at runtime.

Lacking this I had to set the Dynamic Import Package to "*" because without it I'd get class not found errors when reading in my XSLT files that were calling Java methods via reflection in my own code and a few other third-party libraries. This sort of defeats the purpose of OSGi and is usually a method of last resort to get things to work. However I did a little digging and came up with this page:

http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html

which might have some recommendations useful for making Saxon more OSGi-friendly after looking at your dynamic class loading strategy described here:

https://saxonica.plan.io/issues/18