[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Bundle directories
|
With OBR, there are no "smarts" on the server side...the only thing on
the server side is a repository XML file containing bundle metadata
which is downloaded locally.
The repository XML file may also contain URLs to other repository XML files.
The "OBR" bundle provides a service for installing/updating bundles from
the repository. All "smarts" are inside this bundle.
The OBR bundle implements an algorithm for deploying bundles, which
includes transitive closure of dependencies as well as determining when
to install versus update.
OBR does download all metadata, but this decision was made for
simplicity purposes. It allows anyone to easily "host" an OBR
repository, since they only have to put an XML file on some server
somewhere, as opposed to having to run some sort of process. I have
contemplated implementing some sort of caching scheme, but haven't got
around to it yet.
The latest betas of OBR do support a generic provide/require model, but
this isn't quite fully baked yet.
The latest beta also takes into account the fact that R4 allows multiple
versions of the same package, but does not yet have any explicit support
for require-bundle or fragments; however, it should at least be possible
to model these dependencies in the generic provide/require model.
No licensing support was included, other than stuffing a URL into the
bundle metadata.
OBR was intended to be simple and for the most part still is, although
it has become more complicated than when it started. Personally, I think
it would be a mistake to make it too complicated, since its purpose is
to simplify dissemination and access to bundles, not to be an entire
management system.
-> richard
Jeff McAffer wrote:
OBR
====
- I have not had a chance to try this myself. I've just read the doc,
talked to a couple people and guessed the rest :-)
- Repo is just disk, remote or local.
- Disk structure unknown but the general architecture is one where
metadata is added to the repo but content is hosted elsewhere. so in
effect you don't care
- Eclipes Plugins exist or populating an OBR's metadata. I have not
tried this but heard about it from Mikael Desertot. He is talking
about it at OSGi World Congress in Oct. I hope to find out more
before then.
- OBR client talks to the repo (protocol unknown) and fetches all
available metadata. User selects some bundles to install. OBR
figures out what other bundles are needed and downloads/installs them
into the current instance
- Unclear if one can just download the bundles and stash them for
later/alternate use (e.g., as part of a target)
- Unclear if the resolution/picking accomodates R4 things like
Require-Bundle
- So far I have not seen a standard way of exposing a license to users
or filtering download/install candidates based on license type
- There is a rumor that ORB supports a characteristic matching
facility that sounds promising in terms of selection of bundles
- the client already appears to support some level of search over the
metadata
- downside is that it downloads all the metadata. This may not scale
as the repo grows to hold many versions of many bundles.
- no facilities for managing groups of bundles. Sometimes individual
bundle dependencies are not enough. For example some bundles connect
together via loose couplings like extensions.
- client (command line) appears to be reasonably functional
