You can see it as a good thing ;) No, honestly, you are right. no sharing between deplPackages. Until now, with lack of a provisioning solutotion around it, obr+deploymentadmin has been not too attractive to me.
On 5/7/09, Guillaume Nodet <[email protected]> wrote: > 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] > > -- 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]
