Hi Daniel, 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? 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. 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. 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. 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 _______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
