Hi, Am Dienstag, den 08.01.2008, 14:25 -0500 schrieb Richard S. Hall: > It sounds like what you want is some way to install "applications". OBR > was not intended to support applications...I figured this would be a > layer above OBR.
Such a layer above OBR could be an extension supporting the distribution of Deployment Packages ? >From the API point of view (not digging deep right now), a deployment package is a distributable resource with a name, a version and requirements and capabilities just like any bundle. So this should work. The implementation of course is different, as the current bundlerepository implementation just works on bundles. What do you think ? Regards Felix > > I think that some people have experimented with approaches for deploying > sets of bundles, perhaps they can respond. > > As a simple solution to your situation mentioned below, you could have > your client bundle require a B2 service, since B2Impl should provide a > B2 service, then OBR should correctly deploy it. > > In other words, your B1 metadata is incomplete, since it only states > that it requires the packages, not a service. OBR capabilities also > allow you to specify that you require and/or provide a service, which > will then be included in the resolve process. > > I think the bindex tool correctly converts Import-Service and > Export-Service manifest entries into requirements and capabilities... > > -> richard > > Pierre De Rop wrote: > > Hello everyone; > > > > We are using the felix OBR (1.0.0) for deploying bundles into our > > application server. > > So, we store all our bundles into an OBR http server, and we uses a > > GUI obr browser which allows to install some bundles from the OBR into > > the application server. > > > > Now, assuming that the following bundles are stored in the OBR > > repository: > > > > * B1.jar (which imports package from B2.jar. The ServiceTracker will > > be used to get B2 instance) > > * B2.jar (only contains an API interface) > > * B2Impl.jar (contains an activator which registers into the service > > registry an implementation for B2.jar) > > > > So; using a GUI, I deploy B1.jar from the OBR into my cluster --> the > > OBR will install both B1.jar and B2.jar because > > B1.jar imports packages from B2.jar ... But what about B2Impl.jar ? > > > > B2Impl.jar won't be installed because there is not direct dependencies > > between B1.jar/B2.jar and B2Impl.jar. > > I could use the "Require-Bundle: B2Impl" header in B2.jar, but this is > > not a good practice (see Peter Kriens remarks about that, and also the > > specification, which details many problems about using Require-Bundle > > header) ... > > > > You could just tell me that the only solution consists in clicking on > > B2Impl.jar in order to install it too ... But the point is : we have > > potentially many bundles to deploy and the administrator does not > > necessarily always have knowledge about all bundles to be installed ... > > > > So the question is: how to simplify the deployment of a complex > > application from the OBR ? Is there any other headers than > > "Require-Bundle" that could ease deployment of bundles from the OBR ? > > > > /Pierre. > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
