Guillaume, Apache Ace (watch for https://issues.apache.org/jira/browse/ACE-16) might be the thing you want for the missing runtime portion.
On 5/7/09, Guillaume Nodet <[email protected]> wrote: > I agree, I was really talking about the bundlerepository > implementation in felix (the only one I know about), not the OBR > specification. > I don't have much problems with the OBR spec itself, but with the > existing repositories (that have absolute urls to the bundles) and > implementations. > > At runtime, using OBR requires to make a lot of choices, so either you > have no control and you don't really known which bundles will be > installed, or you need to ask the user a lot of questions. There is > also the fact that it will *download* the bundles, unless you modify > the repository to replace the urls with alternate urls you can > control. > So I'm not really confident in using OBR for runtime provisioning, > though it would perfectly map an offline tool which would create a > more simple list of required bundles to deploy at runtime. > > > > On Thu, May 7, 2009 at 15:28, 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] >>> >> >> > > > > -- > 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]
