Hello Jan, On Dec 1, 2011, at 0:05 AM, <janze...@email.cz> <janze...@email.cz> wrote:
> as a member of a research group in Pilsen, that strives to create > a tool for semantic version of OSGi bundles (http://osgi.kiv.zcu.cz/obvs/), > I have some questions to ask: > > I don't think OBR from projects ace-obr-servlet and ace-obr-storage > is accessed via the Vaadin UI interface. Instead of it, as deep > as I've dug, it looks like it uses the ArtifactRepository from > ace-client-repository-* projects. Does this mean, the projects ace-obr > projects are obsolete? Or is the ace-obr-servlet really mapped to > http://localhost:8080/obr only without the web interface? How can one > then manage this OBR, e.g. put the bundles there? To start with your first question: no, the OBR bundles are not obsolete at all. To explain how and where they're used, I should perhaps first explain a bit more about the ACE server and which major subsystems it includes. In this context, there are three subsystems which are relevant: 1) the OBR bundles 2) the client bundles 3) the (other) server bundles These three subsystems can actually be deployed on different nodes, even though by default we all ship them as part of the ACE server. The OBR bundles, when deployed with an HTTP server, form a stand-alone OBR which publishes (as per OBR spec) the contents of its repository via the (automatically generated and updated) repository.xml and extends the normal spec a bit because we also implemented an HTTP POST call to add new artifacts to the OBR. For convenience, if you have physical access to the filesystem that OBR runs on, you can even directly copy artifacts into the "store" folder and they will be detected as well (even though we don't actively encourage that, the official way is via the POST method as that allows us to properly check the contents of the artifact). The client bundles, together with the Vaadin web UI and an HTTP server, can also be deployed on a different node. Actually, the client bundles form an API that can be used in all kinds of clients. Before donating the codebase to Apache, for example, we had a Swing based "rich client" that could run on a different machine and that communicated with both the ACE server and the OBR. This is also why you see that artifacts "enter the system" via the client API. If you dig deeper, you will see that from the client, an artifact will be "uploaded" to the OBR as well, via a POST call. Finally, the other server bundles form the heart of the ACE server and contain the major repositories that hold all historic metadata for the store repository (which keeps track of the relations between artifacts, features and distributions), the license repository (which keeps track of the relations between distributions and targets) and the deployment repository (which is really the sum of the first two, and maps targets to artifacts in a format that is suited for fast deployment). During deployment, when a management agent contacts the server and asks for a deployment package, this package is actually created on the fly by the server. During that process, it will fetch artifacts from the OBR (so that's another place where the OBR is used). > Some time ago, our leader Premek Brada proposed adding our semantic > versioning to the OBR of ACE. We would like to go on with this goal. Some > changes were made and I'd like to present it to the you and ask for your > opinion : > > 1. PUT > Our vision is that by putting a new resource to the OBR, there > would be a decision, whether it is or it isn't a bundle. If it is another > file, > store it only in the OBR. If it is a bundle, perform the versioning according > the last version of the bundle in the OBR first, then store it. This should > happen all the time and thus, we could have the consistent list of all the > versions of the bundle, that were uploaded in time. Naturally, if there is no > another version, no versioning is performed. If you look at the definition of a REST API then the semantics for PUT are to always store (and replace) the exact resource that you specified, so I would not want to deviate from that unless we have a really good reason. We are however free to add a POST command that uses semantic versioning. > The problem is, that only the method put(String fileName, InputStream > data) is present so far, the client decides the filename. If there is a file > with > this name in the OBR (which is the case by different bundle versions) it > would > be overwritten. We are free to extend our API. > To let the OBR API backward compatible and still take advance > from the versioning, the client have to manually add the the version suffix > to the > filename, but it doesn't know, whether the version in the manifest is really > correct, since no semantic versioning was performed yet. Right now we assume the client has correctly done semantic versioning. Most of the time, he will have to do that by hand, but there are other tools surfacing that help (BndTools now allows this). > We propose to add another method to the OBR servlet like > dryRun(InputStream data), that perform the versioning on the uploaded bundle > but doesn't store it to the OBR, only returns in the HTTP header the info, > whether > there is another version and if so, also the corrected version of the > uploaded > bundle. Then the client constructs the filename and calls the common put > method. Let me make a counter-proposal here to add a POST method that will do the upload, then modify the bundle (if there are existing versions in the OBR of this same bundle) and finally either redirect or return the proper URL of the versioned bundle. > 2. GET > Typically I like to get the latest version of the bundle, that is in the > repository. > We can use the present get(filename) method, but we have to know the filename. > listBundles(String symbolicName) would do the work, possibly by inspecting > the repository.xml. The current OBR spec indeed assumes that you first GET the repository.xml, parse that and based on the information inside that file, make up your mind about what exact bundle (or artifact) you want. On top of that, I could live with an optional query mechanism that allows you to do things like: GET /obr/?bsn=org.apache.felix.cm - to return the highest version of a bundle with the specified symbolic name GET /obr/?vsn=org.apache.felix.cm&v=[1.0,2.0) - same, but highest version within the given range GET /obr/?vsn=org.apache.felix.cm&v=[1.0,2.0)&lowest - same, but lowest version within the given range or even, some kind of query that will return a list or subset (in which case it might actually make sense to either return just URLs or a filtered repository.xml) Greetings, Marcel
