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. > 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]
