I'm sorry but I'm not sure what you are reluctant to introduce as a result it is difficult for me to comment.
On 18 February 2010 21:24, Guillaume Nodet <[email protected]> wrote: > Fwiw, I'm a little reluctant to introduce such a mechanism given I > think it does not support all the use cases. > If you consider the application as a composite with external > dependencies, what we want to do is be able to draw the boundaries > between what should be inside the composite and what should be > outside, but also what needs to be imported and what's need to be > exported. Exporting is quite important since you may want to have > services and packages defined by the application being visible to > other applications. > > I think we need to support having applications being completely shared > (including the application content) or completely isolated (including > all the dependencies). But we should look for something both powerful > and easy to use for the common cases. > > What about using osgi headers such as Import-Package / Export-Package, > Import-Service / Export-Service for that. > If a package that is a dependency is in the Import-Package list, this > means it should come from outside the composite, else the bundle > should be installed inside the composite and isolated. Same for > services. > > On Tue, Feb 16, 2010 at 18:21, Alasdair Nottingham <[email protected]> wrote: >> I think perhaps this is where a subsystem is different from an >> application, but I'm a little out of my depth here having not been on >> the subsystem calls or having read the RFC/RFP. >> >> Alasdair >> >> On 16 February 2010 16:20, Guillaume Nodet <[email protected]> wrote: >>> IIRC, we had some discussions around that on a subsystems conference call. >>> I think the outcome was roughly that we may want to support three modes: >>> * all shared >>> * all private >>> * mixed content >>> >>> It should be quite simple using a global flag somehow which could be >>> overriden for some specific bundles. Shared would mean to install in the >>> main framework, while private would mean that the bundles would be >>> installed in a composite bundle. >>> >>> I also think we need the same kind of flags at package and service >>> level so that one >>> can control what services and packages will be visible from outside >>> the composite >>> bundle. >>> >>> The approach you propose has the limitation of not being able to >>> deploy an application >>> in an all-shared environment IIUC. >>> >>> >>> >>> On Tue, Feb 16, 2010 at 14:28, Alasdair Nottingham <[email protected]> wrote: >>>> I haven't been following the subsystem work in the alliance as closely >>>> as you (Graham Charters has, but is on vacation this week so it'll be >>>> interesting to see his thoughts when he gets back next week), but >>>> based on my understanding I also see applications as a specialisation >>>> of subsystems, and I do think that aries should support both >>>> applications, and the more general sub-system solution. I also see a >>>> strong affinity between an application and a composite bundle. >>>> >>>> On the subject of applications being self contained I have a slightly >>>> different view, in fact I was going to send an email today about >>>> contributing some improvements. I'll try to explain my thoughts here >>>> (let me know if it needs a different discussion thread). I'm going to >>>> talk about this in terms of composite bundles, because that best >>>> describes what I am trying to achieve. >>>> >>>> The Application-Content of an application describes the isolated, or >>>> core, content of the application. When an application is installed a >>>> composite bundle is created and the bundles in the Application-Content >>>> are installed into the composite. The application may need additional >>>> packages or services that are not provided by the core content. This >>>> is also possible and bundles that provide those packages are installed >>>> outside the application composite and can be shared with other >>>> applications. >>>> >>>> This is not reflected in our current implementation, but I was going >>>> to propose adding it in. I was not planning on changing the >>>> Application.MF, it would still have the application-content as it is >>>> today, but when you call createApplication on the >>>> AriesApplicationManager we generate a deployment.mf that is used when >>>> install is called (we call out to a resolver to do this). This >>>> deployment.mf currently contains a Deployed-Content header which >>>> contains all the bundles in Application-Content, but ties them down to >>>> a specific version. In addition to doing this I was going to add a >>>> header named "Provision-Bundle" which denotes bundles that are needed >>>> to support the application-content. These bundles would be installed >>>> into the host framework and be shared with other applications. >>>> >>>> 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 >>>> >>>> On 16 February 2010 11:21, David Bosschaert <[email protected]> >>>> wrote: >>>>> Yeah, maybe we need to tidy up the terminology a bit and come to >>>>> agreement on that, I think Guillaume's clarification helps. >>>>> >>>>> In my opinion it would be nice if Aries could provide both models. The >>>>> shared subsystem building block one as well as the more isolated >>>>> application one. Since I tend to think about Applications as a >>>>> specialization of a subsystem it should be possible to do this quite >>>>> naturally. >>>>> >>>>> Just my thoughts, >>>>> >>>>> David >>>>> >>>>> On 15 February 2010 22:21, Guillaume Nodet <[email protected]> wrote: >>>>>> Are you talking about nested framework instead of subsystems ? >>>>>> Subsystems are currently defined by RFC 152 and nested frameworks by RFC >>>>>> 138. >>>>>> >>>>>> My understanding is that applications as they stand are meant to be >>>>>> self-contained (or mostly) and isolated, >>>>>> whereas subsystems can be considered more as building blocks with >>>>>> sharing capabilities >>>>>> >>>>>> The way applications or subsystems can be isolated could be done using >>>>>> nested frameworks or manifest rewriting for example. >>>>>> >>>>>> On Mon, Feb 15, 2010 at 22:58, David Jencks <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> On Feb 15, 2010, at 1:34 PM, Guillaume Nodet wrote: >>>>>>> >>>>>>>> Aries applications model is quite similar to the subsytem model being >>>>>>>> discussed in the OSGi EEG. >>>>>>>> I'd like to think that subsytems are more generic than applications, >>>>>>>> or said another way, that applications >>>>>>>> are specialization of subsystems. Subsystems allow reference to other >>>>>>>> subsystems, scoping, etc... >>>>>>>> >>>>>>>> I'd like to see how we can make both fits together. I guess the first >>>>>>>> question to solve it whether we want >>>>>>>> to keep applications the way they are, without advanced features >>>>>>>> provided by subsystems such as >>>>>>>> sharing / scoping, dependencies on other subsytems, etc... >>>>>>>> >>>>>>>> Once we've answered that, we can think about the way we want to support >>>>>>>> both. >>>>>>>> >>>>>>>> Thoughts ? >>>>>>>> >>>>>>> >>>>>>> My point of view.... perhaps shared by no one else.... is that an >>>>>>> application would be deployed or installed into a particular subsystem, >>>>>>> but >>>>>>> that several apps and plain bundles can all be installed into a single >>>>>>> subsystem. I'm thinking of an application as a way to deploy a set of >>>>>>> bundles at once, where the "maven-like" dependencies aren't specified, >>>>>>> and >>>>>>> where the framework has a way to resolve the osgi dependencies into >>>>>>> maven-like dependencies. >>>>>>> >>>>>>> I don't think this idea is expressed in the current code in any way. >>>>>>> >>>>>>> thanks >>>>>>> david jencks >>>>>>> >>>>>>>> -- >>>>>>>> Cheers, >>>>>>>> Guillaume Nodet >>>>>>>> ------------------------ >>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>> ------------------------ >>>>>>>> Open Source SOA >>>>>>>> http://fusesource.com >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> Open Source SOA >>>>>> http://fusesource.com >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Alasdair Nottingham >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >> >> >> >> -- >> Alasdair Nottingham >> [email protected] >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Alasdair Nottingham [email protected]
