On Thu, May 7, 2009 at 7:47 AM, Guillaume Nodet <[email protected]> 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).
We discussed this kind of requirement at the developer tooling summit
- my feeling is there seems to be a need to expand the resolver api to
allow "meta criteria" to be specified in the search - i.e. not just
api level requirements but other requirements like (smallest, signed,
author, namespace, etc) feels a little bit like WS-Policy for
resolution - but ideally with less XML ;)
I started (but by no means finished) some work in this area in Sigil
in that the resolver api looks like...
public interface IBundleResolver {
IResolution resolve(IModelElement element, ResolutionConfig config,
IResolutionMonitor monitor) throws ResolutionException;
}
Where:
* element is the thing you want to resolve (bundle, package, bean, etc)
* config is a place to specify meta info to "tune" the resolver
* monitor allows you to cancel and receive info about the resolve as
it's happening
>
> 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.
Just to say we use the OBR index in sigil to figure out the list of
bundles that should be used for compiling against too.
I find OBR is a useful format in that it allows you to figure out
information about a bundle without having to open the stream to the
bundle - whilst in theory the Manifest.MF file should be the first
entry in a jar - a significant number of jars don't do this and this
leads to a lot of unnecessary network traffic to figure out if the
bundle is of interest.
I agree about the large files problem - and I'm not sure that simply
splitting them up helps unless you can make some intelligent guess
about how the split was done. One of the problems in resolving is that
you often need to see the whole space in order to make intelligent
decisions - the problem is that the space of every bundle and version
ever created is pretty large...(don't get me started on trying to
solve "uses" in this too)
The approach I've take in the sigil resolver (to apply some sort of
order to this) is to allow the user to specify a list of repositories.
If you ask for a bundle to be resolved it searches for solutions in
the first repository - if this fails it cascades up the hierarchy of
repositories till it finds a solution.
Possibly another way of doing this would be a good federation scheme
in OBR itself - so it's not just user configuration but provider
config too? i.e. repository A points to repository B for some stuff
and repository C for others - kinda BTree like algorithm?
>
>
> 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]
>
>
--
-------------------------------------------------------------------------------------
Paremus Limited. Registered in England. Registration No. 4181472
Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
Postal Address: 107-111 Fleet Street, London, EC4A 2AB
The information transmitted is intended only for the person(s) or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited.
If you received this in error, please contact the sender and delete
the material from any computer.
-------------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
