Hi Sandro, There are a couple of things you could do here.
1. The generic capabilities/requirements model is certainly the most elegant. This basically allows you to create any type of capability (not just an export package or bundle name). Then in the consumer you can depend on it. Generic capabilities are organized in namespaces, so for example you could use a namespace for all your JS library bundles (e.g. org.apache.sling.js) and then as value have jsNodeTypes for the bundle that contains that. So for example you an add in your bundle: Provide-Capability: org.apache.sling.js; org.apache.sling.js=jsNodeTypes;version:Version=1.0.0 Then on the requiring side you can require this dependency as follows: Require-Capability: org.apache.sling.js; filter:="(&(org.apache.sling.js=jsNodeTypes)(version>=1.0)(!(version>=2.0))) You can find more examples for this in the OSGi specs (http://www.osgi.org/Specifications) 2. An alternative approach, which is less elegant, but definitely also works is using a 'fake' package. For example you could have your bundle that contains jsNodeTypes export a package 'org.apache.sling.static.js.jsNodeTypes' and then import that as if it was a normal package. It's a bit of a hack, but it works and was often used before the Provide/Require-Capability model was part of OSGi.... Hope this helps, David On 24 October 2014 12:31, Sandro Boehme <[email protected]> wrote: > Yay that sounds like the right path! Thanks Felix for the hint! I'm looking > forward to David Bosschaerts pointers to use the Provide-/Require-Capability > model! > >> I am referring to the provider bundle at >> https://github.com/sandroboehme/jsNodeTypes. Is that correct ? > Yes, thats correct. > > Thanks, > > Sandro > > Am 24.10.14 12:45, schrieb Felix Meschberger: > >> Hi >> >> I am a bit confused, sorry. >> >> I am referring to the provider bundle at >> https://github.com/sandroboehme/jsNodeTypes. Is that correct ? >> >> Also having SLING-4001 in mind, I might come to the core of the >> problem: You want to deploy an application which depends on the >> functionality of the jsNodeTypes bundle. So you need a way to >> indicate to OBR that if you application bundle is deployed, the >> jsNodeTypes bundle must be installed as well. >> >> Correct, Require-Bundle used to be the only solution here, though >> cranky but feasible. >> >> Nowadays we do have a more flexible Provide-/Require-Capability >> model: The jsNodeTypes would Provide-Capability — the jsNodeTypes >> feature — and your application would Require-Capability this >> jsNodeTypes feature. >> >> I have copied David Bosschaert who can certainly share how this >> mechanism could be leveraged in this use case. Whether an existing >> capability can be reused or whether you might want to define a custom >> capability. >> >> >> Regards Felix >> >> [1] https://issues.apache.org/jira/browse/SLING-4001 >> >>> Am 24.10.2014 um 11:44 schrieb Sandro Boehme >>> <[email protected]>: >>> >>> Hello, >>> >>> in the Sling Resource-Editor I would like to integrate the >>> JavaScript JSNodeTypes library that doesn't have a public Java API. >>> But the user should still be able to use OSGi to easily install the >>> tool. >>> >>> The problem is, when using the maven-bundle-plugin the Bnd tool >>> won't automatically find the dependency to that library when >>> looking for Java import statements and I cannot manually add a >>> 'Import-Package' statement as there is no package I can use. >>> >>> There is one thing to note: The JSNodeTypes library is created by >>> myself. This means if there is a solution that needs changes in >>> that library I could do that. E.g. I could create an empty Java >>> package in JSNodeTypes that I can use in an 'Import-Package' >>> statement. >>> >>> But isn't there a better solution? >>> >>> Thanks, >>> >>> Sandro >> >> >
