EclipseCon has been an energetic event, with early mornings and late nights (and quite often, a large amount of beer). This is starting to affect people and it feels like the conference has started to wind towards the close later today. Of course, there's no exhibitors today so that may have an affect on the number of attendees.
The other BoF was an open discussion of the update manager. It provoked a lot of interesting comments; we didn't end up leaving until 23:15 (and it started at 21:30; one of the reasons why I am a bit behind this morning!) The original goal of the BoF -- an open source repository for bundles and changes to the update manager -- was extended to also deal with issues regarding deployment and management of Eclipse installations in an enterprise situation. There were some good ideas that came out, but given the time available we ended up really understanding the problems that people would like an update system to do rather than necessarily proposing ways of fixing them. The kind of issues raised involved:
- Can there be a delta distribution for bundles? Using Pack200 is good for compression, but can this be applied with older versions of the same bundle as well?
- How can many repositories co-exist at the same time? There may be desires to have a global federated set of plugin repositories, such as developer-level, project-level, department-level, corporate-level or even global-level. [I'm not sure whether this meant repositories for installation, or for mandates on Eclipse installations managed at those levels - Al]
- How internally-developed plugins can be distributed/deployed
- How applications can be co-hosted to maximise bundle re-use
- Multi-threading the download implementation
- Being able to resume downloads of incomplete plugins using restartable HTTP instead of starting download again
- User profiles for managing which plugins are allowed to be used (i.e. selective authorization of internal plugins)
- Management of preferences as well as plugins at a developer/project/departmental/corporate/global level
This caused a good debate about the current implementation of Update Manager, and how it doesn't address these needs above. Some out-of-the-box thinking led us in directions of:
- Using a protocol like RSync or similar to send diffs of updatable components (though a JarDiff tool would have better results). This presupposes that the previous version is available for comparison in order to generate the diff. Binary diffs of Jar-like structures may not be sufficient since the binary versions often change over the file even when the change is small and localised.
- Could the PDE suggest or provide tooling to increment minor/major changes of version numbers of bundles
- Can the update manager be parameterised to allow arbitrary information (such as licence keys or authentication information) to be passed for dynamic update sites?
- What about using Atom as a standard container for notification of updates?
- What's the level of overlap with Maven and its repository structure? Could the dependency information from either OSGi manifest or Maven's pom.xml be used to derive dependency for any kind of update?
- Apart from how bundles are updated, how are they discovered in the first place? Would there be central registry services that provide indexing (ala Google) whilst still farming out the location of the individual Jars to other sites? (This can be done to a certain extent now; the location of the
site.xmland the location of the Jar don't need to be located on the same server.)
One interesting point mentioned by Jeff was that there's already plans for a centralised bundle repository called the OBR (OSGi Bundle Repository), available at bundles.osgi.org which aims to provide centralised searching of bundles and associated information. There are some bundles provided there, but the search could use some work and a couple of the bundles I clicked on received 404s. Maybe as Eclipse grows, particularly for public releases, versioned bundles will get registered there as a matter of course.
The conclusion was to take the rest of the conversation on to the Eclipse mailing list for
platform-update-dev and to explore other ways of being able to improve the updates. The good news is that there does seem to be both community interest in these problems, and hopefully we'll be able to make some progress in the post 3.2 timeframe.