On 16 February 2010 16:12, David Bosschaert <[email protected]> wrote: > On 16 February 2010 13:28, Alasdair Nottingham <[email protected]> wrote: >> So the Application-Content in the Application.mf is isolated content, >> but the Deployment.mf contains additional shared bundles that are >> required to support the application. >> >> What do you think? >> Alasdair > > So this allows one to describe the transitive closure of all the > dependencies without forcing them all into the application. Maybe some > of the shareable dependencies are already there in your framework, in > which case they're ignored from the Deployment.mf file, right?
That would be the plan, I wouldn't describe it as ignored, but installing the bundle would be a no op :) > This sounds like a very useful approach to me, especially if you put > everything in a single .zip file - like the .eba. Just download the > .eba, install and your done. I agree > > Although I also think that in some deployments the Deployment.mf file > may not be required as all the transitive dependencies could be > resolved from OBR (I know - OBR doesn't really exist yet, but > hopefully it will soon). A Guillaume notes if the .eba has a the deployment.mf we don't go to OBR. This is so we can get some level of consistency between JVM/Frameworks. The idea would be you resolved once, save the file to disk and use the "resolved" file. > If your system is hooked up to an OBR, the > dependencies from your application could be resolved from there. > I guess it depends on how dynamic you want your deployment to be, but > to me these are both valid scenarios... > Right now we don't have a Resolver implementation that uses OBR, but that is definitely possible, and was the intent. When Mark committed the code we were thinking OBR, but wanted to get the AriesApplication interfaces available even if the Resolver wasn't done. If you want dynamic you get an OBR implementation of Resolver and use an EBA without a deployment.mf. We generate the deployment.mf which is held in memory. > Best regards, > > David > -- Alasdair Nottingham [email protected]
