On Wed, 2013-06-26 at 17:28 +0200, Mikhail Kalkov wrote: > Hi Daniel, First of all, thanks for your response!
> I am responsible for maintaining couple Eclipse installations in my > organization, and this organization wants me to make it possible to > version-control Eclipse configuration so that depending on the currently > checked out label a different set of bundles is loaded. Right now this is > solved by installing several base Eclipse instances onto a read-only network > drive, and supplying often-updated bundles via the dropins mechanism. So, > depending on the checked out label, the correct paths to a base installation > as well as to a set of dropins and to user configuration area are selected. > The immediate drawbacks are the need to create a new base installation if any > bundle in it has to be updated, the need to script migration of settings > between user configareas, and the need to deploy 40+ bundles via dropins. > > From your description it sounds like droplets may take place somewhere > between p2 bundles installed into the shared area and dropins installed into > the user area. If I understand correctly, they will be packaged already in > runnable form, installed by administrator and respond to changes when run by > user. There are some things I didn't get though. > - What exactly should and should not be packaged into a droplet? For > example, will bundles in runnable form be accompanied by configuration files? > - Would there be mechanism to check if installed droplet is p2-compatible > with target Eclipse installation or do you think it's responsibility of > packager to ensure compatibility? > - What exactly should happen during droplet (un-)installation? Assume that I > have Eclipse Classic installed and would like to install PlantUML, which is > packaged as a separate droplet (RPM). How would Eclipse Classic know that it > has got a new droplet? Would there be a droplets directory that is checked > upon startup? Can a droplet be installed solely by copying files around > without updating them? > - What exactly should happen at start up time apart from p2 remediation of > the new base+droplets platform against user-installed plugin? Are any droplet > configuration files going to be merged into user config? My intention was to have a group of plugins/features installed together as one unit (all or none go in). I have not yet considered configuration files. Regarding overall droplets management I'd expect following things: * during startup droplets are merged with the base installation. Users see them as a part of the master installation. * unresolved droplets report an error (they are supposed to work, it's not a best-can-do approach like in dropins). * uninstalled droplet is seen as a base installation change. user configuration area is dropped and then reinstallation dialog kicks in, which restored things that user had installed. * from an administrator point of view - it would be all about copying/deleting files into appropriate directories. > Overall, I think your idea sounds interesting because it may let me > a). minimize the base Eclipse installation and check it into a version > control system (it's too big and thus changes too often). This is similar to > your packaging plans. Agree. > b). speed up the first Eclipse start up by skipping the p2 installation step > required for dropins to work. I guess you'd benefit from it too. You may be disappointed here. I don't see a way to install anything without using p2, so it is quite possible the first startup will be equally long. > c). separate packaged bundles from user-installed ones. You've mentioned > that as one of the goals too. > In this light, leaving out touchpoints and even possibly configuration files > sounds like an acceptable sacrifice. What are your usecases for touchpoints and configuration files? > Kind regards, > Mikhail Kalkov > > Purple Scout AB > Software Developer > > > ----- Original Message ----- > From: "Krzysztof Daniel" <[email protected]> > To: "p2-dev" <[email protected]> > Sent: Wednesday, June 26, 2013 2:07:46 PM > Subject: [p2-dev] support for 3rd party installers > > Hello P2 masters, > > Eclipse installation in Fedora (managed by RPM, shipping in 7 days) was > broken every time after Eclipse was built. Heavy work happening in the > shared and remediation areas made my patches highly unstable, and I'm > tired of it - maintaining my own set of patches is *very* time consuming > (not to mention that fixing one problem reveals others). > > So I'd like to have support for 3rd party installers in Luna. > > The rationale is quite trivial: in the devops times centralized > deployment is something that completes common build infrastructure. One > has to have the possibility to quickly build and deploy Eclipse and > Eclipse components to developers. It's just too expensive to let them > download each new version :-). > > I've put my requirements in a wiki page [1], and opened a bug [2]. I'm > willing to do the work. If someone else is interested in the solution - > please speak up - I want this solution to be generally usable, not just > a niche Fedora solution. > > > [1] http://wiki.eclipse.org/Equinox/p2/Plan/3rd_party_installers > [2] 378329: Support 3rd party installers > https://bugs.eclipse.org/bugs/show_bug.cgi?id=378329 > -- Krzysztof Daniel <[email protected]> Red Hat _______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
