It is a fundamental principal of modularity that the consumer (of a package) defines its depenencies i.e. it is not wired automatically to everything else.
Another option could possibly be jboss-deployment-structure.xml
[tdiesler@tdvaio jboss-as]$ find . -name jboss-deployment-structure.xml ./testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/deployment/structure/war/jboss-deployment-structure.xml ./testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/deployment/structure/jar/jboss-deployment-structure.xml ./testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/deployment/structure/ear/jboss-deployment-structure.xml
The standard option would be to stick to OSGi bundle deployments only. What would be preventing you to do that?
Starting from 7.1.2 (07-May-2012) non OSGi deployments are automatically registered with resolver environment. So you could put your APIs in a jar and import them from your bundle.
Thanks for replying Thomas.
Yes, I have an additional constraint for not deploying my OSGI bundle in the deployments folder. One of its components is JPL, a Java library using JNI to interact with a Prolog engine.
If I deploy the bundle in the deployments folder, after any modifications in the applications clients of my bundle, I get a:
"... java.lang.UnsatisfiedLinkError: Native Library /usr/local/lib/Yap/libjpl.dylib already loaded in another classloader"
And the only thing I can do is to restart the server.
As far as I understood, the solution to this problem is to somehow deploy the bundle "globally", so it will be loaded only once and the UnsatisfiedLinkError error will not occur.
Trying to do this, I followed the procedure to deploy a global module, but using my OSGI bundle jar as the only jar in the module, just to see what would happen. To my surprise, this kind of work, I was able to access classes inside my bundle (without having to declare the dependency in the MANIFEST.MF file of the client applications).
Unfortunately, I observed that in these two cases (both when deploying the bundle locating it in the "deployments" folder, or when deploying it as a global JBoss module), I sill had the problem of the UnsatisfiedLinkError error when modifying classes in clients of the OSGI bundle.
In both cases I also observed an additional problem: the "Export-Package" directive in the bundle manifest file is ignored, and the client applications are able to see all the classes in the bundle, not only classes in the exported packages as expected. As far as I understand this could lead to conflicts if the client applications are using different versions of a library that is also present in the bundle, is this correct ?.
The only partial solution I have found to my problem is to separate the JPL library from the rest of my OSGI bundle and then publishing only this library as a global JBoss module. For some reason, if only this library is deployed alone as a global module (instead of my entire OSGI bundle), then I do not have anymore the UnsatisfiedLinkError error. I am not happy with this solution since the installation of my application starts to get complex. I think it should be a way to deploy an OSGI bundle such that I know its classes will be loaded only once by the application server (avoiding in this way issues with JNI), and that its non exported packages are not accessible to client aplications.
Thanks for any help on this!