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.
/Mikhail
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
Mikhail,
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.
Pascal
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
Hi,
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