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
----- Ursprungligt meddelande -----
Från: "Pascal Rapicault" <[email protected]>
Till: "P2 developer discussions" <[email protected]>
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: [email protected] [mailto:[email protected]] 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
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
