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 or - a sign of "obr specification too broad to be implemented by poor humans". 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]
