[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[p2-dev] A use case for droplets

Hi Pascal,

The organization I'm talking about has a policy of version-controlling all tools used for software development. This means that a new version of each tool is checked into an SCM system. The same rule goes for tool configuration. For example, a compiler suite gets configuration from Make files, so only its binaries get checked in. On the other hand, Jenkins contains both binaries and configuration, both of which are checked in independently from each other. All tools are maintained by few dedicated people.

The production code is split into modules, and each module has an associated "tools label", which can be either fixed or latest. When the tools team makes a new release, a new "tools label" is published. All modules, which have latest label get the new release automatically. Modules with a fixed label have to be updated manually by respective team leads. So, it is quite normal that several versions of tools are used simultaneously in production, and new versions get released at least once in couple weeks. Furthermore, individual developers may override specific tool versions if they need it.

In order to integrate Eclipse into this environment, my team has written several plug-ins. They provide an easy way to start a build, to run tests, to run static and dynamic code analysis, and feed the results of these operations back into Eclipse problems view or into several custom views. At the same time another team has written couple more plug-ins, which implement specific model-based code generation patterns. Both our and their plug-ins are considered tools, and have to be checked into SCM.

Now my team is also responsible for managing a shared Eclipse installation, and we need to make it possible for our users to check out a different tools label, and get a new set of plug-ins installed into Eclipse. So far we have two options: either use dropins, or re-implement a dropins-like mechanism ourselves. Either way, p2 installs our plug-ins into user configuration area on startup. Furthermore, some users install additional plug-ins into their user configuration areas.

Because of the mentioned "shared install changed" problem we so far had to create a new user configuration area for each new tools label, and try to manually migrate settings from the old configuration area. Unfortunately, the user plug-ins got lost in this case. The work you did for Ericsson should address this issue, and we may start re-using the same configuration area as soon as we have migrated to Kepler. This will simplify life for us and make users happier, thanks for this!

As for remaining problems, ideally, we would like to replace dropins with a better solution in order (1) to a little bit decrease Eclipse startup time, (2) to improve robustness and get better error reporting, and (3) to be able to split the shared Eclipse installation into smaller chunks and check in them too. The third goal is motivated by the fact we have three different Eclipse installations right now, and each of them gets 3-4 new versions per year. If instead of installing everything, we'll be able to install Eclipse Platform and provide other features as "droplets", the droplets can be updated independently from each other. The reason we cannot split a whole Eclipse installation into smaller parts now is because updating one part would affect other parts, so they are not completely independent from each other. This last desire overlaps surprisingly well with Krzysztof's desire to provide parts of Eclipse installation as individual Linux packages.


FrÃn: "Pascal Rapicault" <pascal.rapicault@xxxxxxxxxxxx>
Till: "P2 developer discussions" <p2-dev@xxxxxxxxxxx>
Skickat: onsdag, 31 jul 2013 14:32:10
Ãmne: Re: [p2-dev] 3rd party installers, droplets, etc



Stepping back from how you have implemented your solution, could you please describe what is the problem you are trying to solve and what are the issues with what p2 is currently able to do?


Iâm asking because in Kepler, Ericsson funded significant improvements to p2 to make sure that changes to the base (what is read only) are not causing the loss of the plugins installed by the user (see

âdetection of shared install changedâ http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/news/eclipse-news-part1.html ) and Iâm curious to see if that help solve the problems you are encountering.



From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Kalkov
Sent: July-31-13 8:15 AM
To: P2 developer discussions
Subject: Re: [p2-dev] 3rd party installers, droplets, etc



I'll refrain from technical comments since I'm not that good in p2 internals, but will comment on the problem description.

I think Pascal is right that ability to replace a part of base installation without affecting other parts would benefit Linux package managers. However, I think the actual user group for this feature is wider, and includes anybody willing to version-control parts of Eclipse. This is pretty much the case for any centrally managed installation, even on Windows.

Right now it is only possible to version control Eclipse installation as a whole (i.e., "single package"), so one has to create a new installation for each new bundle version. However this approach does not scale because each complete installation is quite large, and due to a large number of bundles, new installations have to be created too often. Therefore, one is forced to fallback to using dropins (i.e., one "base package" + several "bundle packages"), which are very fragile and the use of which is discouraged.

Kind regards,
Mikhail Kalkov