[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Bundle directories
|
Great! It would be fantastic if we could standardize this in the near
future. I think I agree with most of your discussion except the
following (argued further on):
- Grouping versus requirements/capabilties
- Install versus download
Requirements from the OSGi point of view: (open for discussion)
Federated - We do not want to physically host the bundles and cause
some bottleneck in updating. From the OSGi web site it should be
possible to detect any authorized repository. Then again, we want a
single access point for convenience, though many repositories can
exist.
Licenses - There is a need to see a license, and documentation, before
downloading.
Authentication - I think it will be necessary that the repository
gets a chance to authenticate the caller. We discussed to put
commercial bundles in there that probably will have a restricted
license. It would be nice if this was based on PKI, but I guess passwd
authentication should suffice and is easier. Authentication should be
optional.
Distributions - Should be possible to get the source of a bundle, if
provided.
Dependencies - A general capability-requirement model is necessary. My
preference is that this general model handles grouping, package and
bundle dependencies. I am hesitant for a grouping model like Features
because in my experience it is often not necessary and requires the
author to make all possible combinations. I'd prefer to keep the model
flat (just bundles) with relations (capability/requirements) that can
be used to find out what is necessary and what is optional. For
example fragments with translations should have optional requirement
while an XML parser can be a mandatory requirement.
Discovery - It should be possible to search the repository for
bundles with certain capabilities. Short descriptions should be
provided to the user to select the appropriate bundles.
Scalability - The repository must be able to scale to thousands of
bundles. I think this allows a client based selection approach and is
easier to implement. However, if we want to do it right, we should
support a server based approach.
Integrity - The repository must support signed bundles
Update facility - It must be possible from the client side to detect
any necessary updates to the installed/cached bundles.
Client agnostic - The server should allow for many different clients.
Clients should not be restricted. E.g. a client should be able to keep
a cache or local repository.
Cool to have:
Key management - Bundles can only run when they have the right key
(which must be time based).
Alternate formats - Support for features and OSGi Deployment Packages
Direct Install - Clicking on a web site directly installs that bundle
with its prerequisites.
---------------
Further comments inlined:
JM> As part of the Equinox transition we want to put together a
JM> directory of bundles that people can get and use. It turns out
JM> that many of the Eclipse bundles, upon closer inspection and after
JM> a bit of reorganization in the lower reaches of the Eclipse
JM> runtime, are really quite independent of Eclipse and should be
JM> able to run in many different situations. Things like the
JM> extension registry, jobs, preferences, help, swt, ... are all
JM> generally useful. To help promote the use of OSGi (and Eclipse of
JM> course :-) we want to ensure that it is easy for people to
JM> discover and use these bundles.
JM> The obvious approach is to enhance the update technology to
JM> make it easier to manage individual plugins and to separate the
JM> payload from the metadata. Add to that some additional PDE
JM> function for adding plugins from the update site to the target and
JM> it starts getting pretty attractive.
JM> As part of the due diligence for this we looked around and
JM> found a couple of related technologies that may be interesting to
JM> explore instead or in addition. Maven 2 repos (and Wagon) and the
JM> Oscar Bundle Repository (OBR). Below is a capsule summary of the
JM> technlogy and some of the issues.
JM> Coincidentally it turns out that OSGi itself is looking to
JM> setup a directory on osgi.org. This makes perfect sense.
JM> Persumably we should try to coordinate and use similar/compatible
JM> technology, use the same directory, ....
JM> There are two main use scenarios.
JM> Populating a running instance
JM> =============
JM> The user is running an OSGi framework and invokes some
JM> operation (e.g., browses a repo) that triggers the download and
JM> installation of a bundle. Ideally all of the prerequisite bundles
JM> are also downloaded and installed. This is very interesting.
JM> However, forcing people to be connected to install is
JM> problematic. Connectivity, firewalls, etc all get in the way.
JM> There needs to be a way of simply acquiring the bundles and
JM> installing them later. Perhaps multiple times.
I think this should be a client choice. It could also implement a
local repo that is replenished from the connected repository. It does
at least double the storage requirements and creates all kinds of
potential error cases. An installed bundles is completely, and in a
standard way, available to other bundles.
JM> Aquisition of function
JM> =============
JM> Here the user is looking to simply discover and acquire
JM> desired function. They want to browse available bundles, check
JM> licenses, and then aquire the bundles (and optionally the related
JM> source) and perhaps the prerequiste bundles as well. The
JM> downloaded bundles can then be installed, added to targets, traded
JM> with friends, ...
That is an ok client, but I am not sure that that should be the
primary use case. For example, I tried to install AJDT (and failed
somewhere :-( ) which I think is now to much work. I have to find the
url, find the update window, add the url etc. etc. It would be much
nicer if I could just type in AJDT in the update window and it showed
me a list of possible bundles. I really do not want to download it
first and then do something more with it, that is not the typical use
case I think.
JM> In both cases the user should be able to talk about groups of
JM> bundles (this scales better and allows people to capture logical
JM> groupings of otherwise unrelated bundles)
I am not impressed with features and Deployment Packages. I think most
of the problems are possible to address with bundles, which makes the
overall model simpler. A flat structure with relations usually works
better because you do not have to think upfront about the composition.
I really like the requirements capability model. This definitely works
better when the requirements not only depend on the deliverable, but
also on the capabilities of the client. I think a flat model has a
better chance of supporting a diversity of clients than a grouped
model. Designers have a tendency to only support a single
configuration then because it is too complex to make all the required
groups. With separate bundles that are related, third parties can add
the necessary capabilities.
JM> and MUST be able to
JM> preview and filter by license. In this day and age this is
JM> critical. The IBM Eclipse team members, for example, are not
JM> allowed to download anything without knowing the license first.
JM> All it takes is a few bytes of GPL to ruin your day.
Agree.
JM> In any event, it seems that the ideal is for some combination
JM> of OBR and Update capabilities with the option to back onto a
JM> Maven repo. Why not do it all :-)
JM> Jeff
JM> Maven 2 repos:
JM> =============
JM> - The repo itself is just a particular disk layout where
JM> paths are group-id/artifact/version/<stuff>. so for example,
JM> eclipse/org.eclipse.osgi/3.1.0/org.eclipse.osgi_3.1.0.jar
JM> - No surprises. Quite simple.
JM> - It is not listable and there is no index
JM> - It follows a strict containment model so the same content
JM> in multiple groups would be duplicated
JM> - "Wagon" appears to be some technlogy/API for accessing the
JM> repo locally and remotely but I'll be darned if I can find any doc
JM> or other info on it. There isn't even a download or indication of
JM> what to check out of the repo. I'm not sure of the status of this
JM> work and thus how you would access the repo from Java code is
JM> unclear. Perhaps it is only intended to be accessed from Maven
JM> during a build?
JM> - There appear to be some number of people setting up Maven
JM> repos and if one had a maven build going on, you could point it at
JM> the bundle directory (assuming it was Maven format). Unclear if
JM> you can run a build with multiple remote repos and search them...
JM> - There is no notion of searching, grouping or
JM> categorization. Additional organizational structure would be
JM> needed to enable discovery
JM> - There does not appear to be a standard way for repo entries
JM> to expose a license either to humans or as search criteria
JM> OBR
JM> ====
JM> - I have not had a chance to try this myself. I've just read
JM> the doc, talked to a couple people and guessed the rest :-)
It should be quite easy to try it out and I do not think it is GPLed :-)
JM> - Repo is just disk, remote or local.
I think it works with URLs
JM> - Disk structure unknown but the general architecture is one
JM> where metadata is added to the repo but content is hosted
JM> elsewhere. so in effect you don't care
JM> - Eclipes Plugins exist or populating an OBR's metadata. I
JM> have not tried this but heard about it from Mikael Desertot. He
JM> is talking about it at OSGi World Congress in Oct. I hope to find
JM> out more before then.
JM> - OBR client talks to the repo (protocol unknown) and fetches
JM> all available metadata. User selects some bundles to install.
JM> OBR figures out what other bundles are needed and
JM> downloads/installs them into the current instance
As far as I know it works with an XML file that can point to other
repositories; it also contanis the metadata for a number of bundles.
JM> - Unclear if one can just download the bundles and stash them
JM> for later/alternate use (e.g., as part of a target)
I think it currently installs but that is a client issue.
JM> - Unclear if the resolution/picking accomodates R4 things like Require-Bundle
To support R4, I know that Richard started to work on a general
requirements capability model.
JM> - So far I have not seen a standard way of exposing a license
JM> to users or filtering download/install candidates based on license
JM> type
Nope, do not think that is supported. Mere mortals are not that
panicked by GPL :-)
JM> - There is a rumor that ORB supports a characteristic
JM> matching facility that sounds promising in terms of selection of
JM> bundles
Yes, probably needs work but Richard and I discussed this extensively
and I think he implemented it in a beta. See JSR 124 for more ideas.
JM> - the client already appears to support some level of search over the metadata
JM> - downside is that it downloads all the metadata. This may
JM> not scale as the repo grows to hold many versions of many bundles.
This is true. For me it is not that important at the moment but it
needs attention for the future.
JM> - no facilities for managing groups of bundles. Sometimes
JM> individual bundle dependencies are not enough. For example some
JM> bundles connect together via loose couplings like extensions.
Which I think is the right way to go! As I argued before, these
concerns should be addressed by relations.
JM> - client (command line) appears to be reasonably functional
JM> Update (for completeness)
JM> =======================
JM> - Disk layout based repo.
JM> - http access
JM> - site list/index in site.xml. Metadata embedded in artifacts (features, plugins).
JM> - standard practice todate has not filtered up the dependency
JM> metadata into features so it can be hard to get the complete
JM> picture without actually downloading the plugins. This is not a
JM> technological problem but rather a convention/practice that would
JM> have be overcome
JM> - supports license exposure
JM> - supports groupings of bundles (e.g., features)
JM> - would need utility helpers to ease the addition of
JM> individula (or groups) of bundles by generating a feature for
JM> them. The update site builder technology can be leveraged here.
JM> - No "smarts" on the client in that it only downloads what
JM> you told it. There is some very modest search capability that
JM> helps find required features.
JM> - rudimentary command line client capabilities but
JM> non-trivial API in the background.
JM> - Categorization on the site.xml Only one level?
JM> - Update site is expected to physically contain all bundles
JM> and features. Curently no facilities for serving content separate
JM> from metadata. One tractible change would be to have the plugin
JM> jars on a separate site but the feature.jars contain the
JM> interesting metadata so either we have to extract the feature.xml
JM> or the whole feature has to stay with the site/directory.
--
Peter Kriens Mob +33633746480
9C, Avenue St. Drézéry Tel +33467542167
34160 Beaulieu, France Tel +15123514821
Tel +33870447986
AOL,Yahoo, Skype pkriens ICQ 255570717
