[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:

- 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