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]
