Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Virgo/Community/F2F/Journal November 2010
08:30 start
The day dawned dull and gloomy — it was very cold and there were portents of wintry weather. Nevertheless, around the table, Chris Krasimir, Steve (I), Georgi, Hristo, Borislav, Violeta, Dmitry and Glyn, sat and munched danish pastries and drank coffee. Outside the sun struggled to break through.
We waited for Flavian — rumour had it that he was just about to arrive, so we chatted and waited until nine. He didn't appear (we were later to learn that he was stranded at Frankfurt) so we began.
Glyn encouraged us to introduce ourselves, in the time-honoured manner, and we checked that the hotel was satisfactory (except Krasimir said that the Gym was too far from the hotel -- it is one minute's walk!) and that we were all interested in OSGi. We were — that's a relief.
Glyn's self-introduction turned into a brief history of Virgo (née dm Server) and compared the OSGi modularity experience of our users to the large systems restructure efforts that he (and I) experienced a few years ago. It is only when you have a robust system that enforces some sort of modularity that you begin to understand how un-modular your system really is.
09:20 first things first
Objectives and Agenda were the first things. The main objectives were simple: to meet each other, to discuss the immediate work, and to explore the committer rôle. The agenda was visited and agreed (with some mods) — Krasimir immediately asked for Use Cases to be discussed next — and we were off!
09:34 use cases
It is apparent that there are a number of use cases we bear in mind when we consider extensions or modifications to the Virgo Web Server. There are the base platforms for simple component re-use: the elemental sharing of modular application components; there are the syndicated, or distributed, collections of server engines monitored and managed centrally for balancing and isolating jobs (or work) with scalability; there are the development platforms where flexibility and refreshability are of primary benefit, as opposed to production environments where robustness and predictability are prevalent. These are not (asked by G, answered by K) restricted to web applications — there is also the (niche?) area of non-web (batch?) engines, possibly as part of a coordinated server collection. (Are these cloudily linked, I wonder?)
K mentioned that isolation and protection against system failures (malicious or otherwise) lead to a 'sandbox' concept, similar to the Google efforts: there is a list of things an app can do (what is not permitted is forbidden ! ).
Dmitry asks: What is an application? (This reminds me of a colleague I used to work with, who continually asked us "What is an activity?", when most of us were implementing it — until we took him seriously one day, and discovered we all meant different things by it. A pivotal point in our understanding.) G says there is an RFC in progress — we jolly well hope so — and hints we should be standards based; D says "If you build it, they will come," by which I think he means we should lead standards rather than following them (and I agree, I think).
D goes on to point out that artifacts (apps) that run on a 'standard' engine should work 'out of the box' on Virgo. A tall order, perhaps, but a good goal. We need to improve deployment times (long head-scratching by OSGi resolution followed by incomprehensible or irrelevant failure messages is not helpful). Oh, and What is an application?
G and K then had a conversation about ORM and runtimes, synthetic contexts and the Jira app used as a testcase. I do not pretend to understand all this, but nod sagely. The idea of using a largish app like Jira to do validation/system tests is quite appealing, although without extensive smaller testing programmes to eliminate the little problems these sorts of tests can often be swamped by trivial issues which lead to complex and obscure failure symptoms.
D mentioned that he decomposed his systems both horizontally and vertically. (Can you explain this a little here, please Dmitry?) His operating scenarios involve about 6-7 plans which are vertical towers that nevertheless share common application components: they are not distinct, isolated stovepipes.
G mentioned use cases from our perspective: WAR files (etc?) and Kernel extensions. There is RAP, for example, the Jetty work, and other extensions possible on top of the Kernel (like Spring Batch??). Extensibility is the design point of the Kernel, and is the key to rich exploitation. The right sort of extensibility, of course :-) The tooling support is also something we want to see enhanced.
I put my oar in at this time to say that I see the possibility of satisfying both the development and production requirements only by providing some sort of control over Resolver wiring (and re-wiring) to make it less disruptive in production, and more flexible in development. (I feel exhausted after saying this — we take a short break.)
10:34 Kernel overview (Glyn)
This turned into an outline of the things we would like to do (or are about to do) to the kernel. One thing which we spent a lot of time discussing was the impact of the change from nested frameworks to resolver and framework filter hooks (coming in Equinox 3.7). Glyn has been working on moving to Equinox 3.7 (from 3.6) in preparation for experimenting with this. (No tech details here. I hope G takes the time to outline it elsewhere.) We spent altogether too much time on this — though we did manage to highlight what might be show-stoppers for this spec alteration. Time will tell.
11:40 SAP (Borislav and Krasimir) file system structure
Here the basic directory layout of the kernel/server was outlined and a proposal was made to change it for a more Eclipse-friendly one. This is to allow a kernel/server to be installed and started by the Eclipse launcher process (also used by plugins) with a view to making the installation, starting, configuration and application deployment of a kernel/server managed as an Eclipse component. This is a tall order, and has some consequences. This is all bound up with the p2 repository support, from which, it is likely, we need to provision dependencies, deploy apps and source kernel component bundles. (We talk about p2 a lot today.)
As we spoke the soft snow began to fall outside.
12:30 dependencies
declarative services was mentioned as an alternative to Spring DM/Blueprint service. This eventually was deemed to be interesting, but perhaps not sufficiently compelling for us to make the change? In any case, a feasibility prototype might be produced as a proof-of-concept. A bugzilla (track?) to discuss and take through a change might be raised. There were some concerns that ds was too static and didn't allow for enough failure diagnosis.
LUNCH
13:45 deployer extensibility
K said deployment is an overloaded term. We discussed the EAR artifact problem and solution, as a Gedanken experiment to validate the extensibility of the deployer. Apparently, less of a G-E since Dmitry has tried it — but needing a kernel fragment bundle. Not extensible enough, then. A tentative proposal was mooted to encapsulate all the features of an artifact needed to augment the deployer, and refactor the deployer to make use of "artifact deployer models" instead of explicit artifact code being built-in to the kernel. (Artifact models could be offered as services, for example.)
G said that deployer extensions are not limited to new artifact types (scoping, for example), but this might be a way forward for some fairly standard extensions. We then discussed where the repository bridge code for an artifact could come from. Not from deployed bundles offering services, that's for sure, since these were deployed too late. Perhaps the artifact models need to be available to the repositories that can store them also! Do the models have to describe how to repose (to coin a verb) artifacts also?
14:17 Build and Release
Chris gave us a brief but beautifully formed overview of the build system (á la virgo-build), the s3 and eclipse build publications; ripplor and releaselor scripts (for doing semi-automatic ripples and releases); and a bit about maven/tycho possibilities. This rapidly broadened out into a discussion of the merits (or otherwise) of Maven.
15:15 hudson
I gave a brief outline of where we are with CI-builds on hudson.eclipse.org (and how we got there) with a few references to what we would like to see in the end. One suggestion was an automatic nightly ripple (when we start publishing to eclipse.org from the CI-server).
15:43 artifact-repository
A simple quick look at the artifact-repository source, with reference to the main interfaces exported and implemented; the repository types and the use of these exported interfaces by (for example) the hosted repository application. Discussion quickly led to...
16:10 grepcode.com
16:11 p2
Georgi gave a masterly overview of p2 (which at least Glyn and Chris understood, so I'll get the details from them). Suffice to say it looks as though making a p2 repository a repository type in the chain seems easy; making it synchronised with the kernel deployments (so that artifacts can be deployed either from p2 or by the kernel and p2 remains in synch with what is deployed) seems a lot harder. However, opinion seems to be that this might be doable, and I expressed the hope that this might be achieved without doing violence to the basic (non-p2, non-eclipse) operating environment of the kernel/server. In other words, I expect the p2 integration to be addable to a kernel without code modification of the kernel and adjustment only of the configuration. This might require careful refactoring of the kernel base to allow the appropriate hooks.
The general discussion about p2 terminated around 17:40, by which time I was pooped.
We determined to go for dinner at the Chilworth Arms.
The Chilworth Arms supplied us all with libation and vittles, and presently we were "well fed up and agreeably drunk". Good old SpringSource.