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]
