Well, deployment admin has the major drawback of not being able to share any bundle between deployments. Hence, your deployed applications are in complete isolation, which might be good, or bad, depending on your needs. Take a simple example where you have a shell installed and you want to deploy a new service along with its commands. The deployment admin would not really allow to do that afaik. I may be wrong, but that's my understanding of deployment admin.
On Thu, May 7, 2009 at 15:59, Toni Menzel <[email protected]> wrote: > On 5/7/09, Guillaume Nodet <[email protected]> wrote: >> On Thu, May 7, 2009 at 15:49, Toni Menzel <[email protected]> wrote: >>> Your are bringing in a good point, peter: >>> "I think you're confusing existing implementations for what OBR really is" >>> >>> This is either >>> - a call for: we need more/better obr implementations >> >> We need to discuss the use cases first. >> >>> or >>> - a sign of "obr specification too broad to be implemented by poor >>> humans". >> >> Well, I don't think OBR repositories are meant to be used by humans, >> given the size of the xml for any non simplistic bundle. Imho, only >> tools can leverage repositories. > > I was referring to peter's claim "I think you're confusing existing > implementations for what OBR really is" merged with my guess on: why > is that ? Why is OBR so much misunderstood ? > Thankfully with Ace we probably get a decent (working) mix of > OBR+deploymentadmin soon. > > >> >>> Toni >>> >>> On 5/7/09, Peter Kriens <[email protected]> wrote: >>>> The resolver API in OBR can handle the issues you mention. You can add >>>> resources by hand, these will always be included in the solution and >>>> have preference. The resolver also provides you with optional >>>> resources that could be used if you choose them. >>>> >>>> The "slow" parsing is only an issue during synchronization of >>>> repositories, you're free to store this information locally anyway you >>>> like. >>>> >>>> I think you're confusing existing implementations for what OBR really >>>> is. It is likely that you find more ready made components for other >>>> types of solutions but from an architecture point of view I believe >>>> OBR has quite a bit to offer. So it depends what you want ... >>>> >>>> Kind regards, >>>> >>>> Peter Kriens >>>> >>>> >>>> >>>> >>>> On 7 mei 2009, at 08:47, Guillaume Nodet wrote: >>>> >>>>> Right, but I don't have much problems with OBR the spec, but mostly >>>>> with how it can be used now. >>>>> Repositories are huge xml files, slow to parse. Currently, OBR >>>>> repositories usually point directly to a download location for the >>>>> bundle (as in http://felix.apache.org/obr/releases.xml). >>>>> Furthermore, you don't really have control over what is installed with >>>>> the current implementation: if multiple bundles can be used to fulfill >>>>> a given requirement, i don't think you have any control over which one >>>>> will be installed. Additionaly, any optional requirement that can be >>>>> satisfied will be (no control here too). >>>>> >>>>> I think OBR could be used at build time to create a list of bundles >>>>> that should be installed. Using it at runtime for provisioning is a >>>>> different thing. >>>>> >>>>> >>>>> On Thu, May 7, 2009 at 08:19, Peter Kriens <[email protected]> >>>>> wrote: >>>>>>> OBR is really verbose and leads to *very* big files. The existing >>>>>>> repositories don't use maven repositories, so you can't benefit from >>>>>>> any local cache (i.e. everything will be downloaded from the >>>>>>> internet). >>>>>> >>>>>> I do not think this is in any way part of OBR. Any OBR >>>>>> implementation can >>>>>> easily cache. The OBR file is only an index of the whole repo. >>>>>> There is also >>>>>> a query URL format specified that allows you to get the index >>>>>> partially and >>>>>> to even resolve. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Peter Kriens >>>>>> >>>>>> >>>>>> On 7 mei 2009, at 08:02, Guillaume Nodet wrote: >>>>>> >>>>>>> On Thu, May 7, 2009 at 00:29, Moloney, Tim M <[email protected] >>>>>>> > >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> What are the pros and cons of using feature repositories, Maven >>>>>>>> repositories, and OSGI bundle repositories in Karaf? >>>>>>>> >>>>>>>> Feature Pros >>>>>>>> - can include bundle configuration >>>>>>>> - can include other features >>>>>>>> - can group unrelated bundles/features >>>>>>>> - no required directory structure >>>>>>>> >>>>>>>> Feature Cons >>>>>>>> - manually created >>>>>>>> - no automatic dependency resolution >>>>>>> >>>>>>> We have a maven plugin that can be used to create a features >>>>>>> repository from a maven project, but there is still a bit of work >>>>>>> needed. >>>>>>> >>>>>>>> Maven Pros >>>>>>>> - no configuration required >>>>>>>> - convenient for development, can reuse local repository >>>>>>>> >>>>>>>> Maven Cons >>>>>>>> - no automatic dependency resolution >>>>>>>> - no bundle configuration >>>>>>>> - requires deep directory structure >>>>>>> >>>>>>> In theory, maven is more a protocol than a provisioning system. >>>>>>> Using >>>>>>> the maven pax url handler which is included in Karaf, >>>>>>> you could provision features or OBR using maven repositories (we >>>>>>> usually do that when using features). >>>>>>> This provide local caching and enable using a more abstract URI so >>>>>>> you >>>>>>> don't have to point to the real file using an http location. >>>>>>> THis can also be used from within a company to make everything point >>>>>>> to a single controlled repository, whereas plain http urls can not >>>>>>> be >>>>>>> easily moved around. >>>>>>> >>>>>>>> OBR Pros >>>>>>>> - automatic dependency resolution >>>>>>>> - no required directory structure >>>>>>>> >>>>>>>> OBR Cons >>>>>>>> - no bundle configuration >>>>>>>> - repository isn't as dynamic since bindex must be run to >>>>>>>> assimilate >>>>>>>> changes >>>>>>> >>>>>>> OBR is really verbose and leads to *very* big files. The existing >>>>>>> repositories don't use maven repositories, so you can't benefit from >>>>>>> any local cache (i.e. everything will be downloaded from the >>>>>>> internet). >>>>>>> >>>>>>>> >>>>>>>> Did I miss anything? It appears that a combination of these is >>>>>>>> probably >>>>>>>> best. How are people using these repositories when distributing >>>>>>>> their >>>>>>>> projects? >>>>>>> >>>>>>> I tend to advocate features + maven. >>>>>>> >>>>>>>> >>>>>>>> Tim Moloney The reasonable man adapts himself to >>>>>>>> MRSL the world; the unreasonable one >>>>>>>> persists >>>>>>>> 2015 Cattlemen Road in trying to adapt the world to >>>>>>>> himself. >>>>>>>> Sarasota, FL 34232 Therefore all progress depends on the >>>>>>>> (941) 377-6775 x208 unreasonable man. - George Bernard Shaw >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Cheers, >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> ------------------------ >>>>>>> Open Source SOA >>>>>>> http://fusesource.com >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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] >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Blog: http://gnodet.blogspot.com/ >>>>> ------------------------ >>>>> Open Source SOA >>>>> http://fusesource.com >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> >>> >>> >>> -- >>> Toni Menzel >>> Independent Software Developer - Looking for new projects! >>> Professional Profile: http://www.osgify.com >>> Blog: tonitcom.blogspot.com >>> [email protected] >>> http://www.ops4j.org - New Energy for OSS Communities - Open >>> Participation Software. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Toni Menzel > Independent Software Developer - Looking for new projects! > Professional Profile: http://www.osgify.com > Blog: tonitcom.blogspot.com > [email protected] > http://www.ops4j.org - New Energy for OSS Communities - Open > Participation Software. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
