Community
Participate
Working Groups
Bug 421571 ('Add Eclipse Workspace Mechanic') contains a long discussion about moving Workspace Mechanic to Eclipse and integrating it into the EPP packages, all of this did never happen for one reason or another. But since some time we've got a project at Eclipse.org that does the same (and even more). As an additional plus it is available as a 1.0 release (i.e. not in Incubation Phase) and is under active development. I'm talking about Oomph [1]. I'm using it myself, mainly for synchronising my preference settings between many workspaces, and I'm very happy with it. I propose to make Oomph part of all Mars EPP packages like we did with the MPC some years ago. Oomph is part of Mars (beginning with Mars M4), and they will contribute version 1.1.0 according to their project plan. Size? A full installation of Oomph would add probably less than 10 MB to every package, but I expect that we do not need 'everything' - this is something that I'd like to discuss in this bug and where we need input from the Oomph developers. [1] https://projects.eclipse.org/projects/tools.oomph
+1 is an understatement Oomph will resolve a number of issues new Eclipse users face, making Eclipse much more palatable to them. Oomph can also help existing Eclipse users and Power Users with the workspace sync features. Finally, Oomph also opens the door to future possibilities, such as minimal and customized installs, sharing preferences with others, or even storing Eclipse preferences and settings on your Eclipse.org account (which could help us all determine better defaults).
The Oomph project provides a number of tools that wouldn't need to be in the packages. I suspect that it's mostly the Core and UI of our "Setup" engine, including the required lower-level frameworks, such as "p2 Management" and "Preference Management". Oomph has a modular and extensible SetupTask concept and supports automatic discovery for not-yet-installed SetupTasks. That means that we could ship just a handful of the core SetupTasks, in particular the ones needed to automate the setting and distribution of user preferences. All other SetupTasks would still show up in the "New Child" menus when people edit their setup models, but be installed on demand. I'll assemble a concrete list of plugins required to support this minimum use case of (management of user preferences) tomorrow and report here...
I haven't tried it yet. But if Markus *and* Denis say is that great, I'll add it to the Committers package immediately. :) (In reply to Eike Stepper from comment #2) > I'll assemble a concrete list of plugins required to support this minimum > use case of (management of user preferences) tomorrow and report here... Eike, can you compose a "runtime" feature? AFAIK that's easier to consume/maintain from a packages perspective than a list of plug-ins.
(In reply to Gunnar Wagenknecht from comment #3) > I haven't tried it yet. But if Markus *and* Denis say is that great, I'll > add it to the Committers package immediately. :) Instead of adding it to all packages manually, I'd prefer to add it as a requirement to the 'EPP Common Package Feature' (org.eclipse.epp.package.common.feature) that is part of all packages and contains the MPC. > (In reply to Eike Stepper from comment #2) > > I'll assemble a concrete list of plugins required to support this minimum > > use case of (management of user preferences) tomorrow and report here... > > Eike, can you compose a "runtime" feature? AFAIK that's easier to > consume/maintain from a packages perspective than a list of plug-ins. Yep, one, or two, or maybe three "main" features would be appreciated and much better than a list of many features or many bundles. When I've been looking into the Simultaneous Release repository and into the categorization there, I found a lot of Oomph related features and to be honest, it wasn't fully clear to me which ones are important and which are not so important for the packages.
Yes, a single feature for the packages is definitely going to make it easier for us, too. With "list of plugins" I just meant something that helps to estimate the total payload addition ;-)
Since Mars M4 EPP was today I assume thta we talk about joining the packages at M5, right? That would allow us to create and test a special EPP feature with the concrete list of plugins. Such a special feature would make it easier for us to maintain our normal features without accidentally "polluting" the packages in the future.
(In reply to Eike Stepper from comment #6) > Since Mars M4 EPP was today I assume thta we talk about joining the packages > at M5, right? Yes, that's correct. Today I played with the thought about adding it for M4 but it seemed to be too much in a hurry.
(In reply to Markus Knauer from comment #4) > (In reply to Gunnar Wagenknecht from comment #3) > > I haven't tried it yet. But if Markus *and* Denis say is that great, I'll > > add it to the Committers package immediately. :) > > Instead of adding it to all packages manually, I'd prefer to add it as a > requirement to the 'EPP Common Package Feature' > (org.eclipse.epp.package.common.feature) that is part of all packages and > contains the MPC. Maybe we should try it out with the Committers package first to test how it behaves, at least for one milestone before we add it to all packages?
(In reply to Eike Stepper from comment #6) > That would allow us to create and test a special EPP feature with the > concrete list of plugins. Such a special feature would make it easier for us > to maintain our normal features without accidentally "polluting" the > packages in the future. I stand corrected: We already have exactly the needed feature because our Oomph Installer uses exactly that feature to install Oomph's runtime plugins into the Oomph-installed IDEs. This feature currently leads to the addition of these 28 plugins: org.eclipse.oomph.base org.eclipse.oomph.base.edit org.eclipse.oomph.p2 org.eclipse.oomph.p2.core org.eclipse.oomph.p2.doc org.eclipse.oomph.p2.edit org.eclipse.oomph.p2.ui org.eclipse.oomph.predicates org.eclipse.oomph.predicates.edit org.eclipse.oomph.preferences org.eclipse.oomph.resources org.eclipse.oomph.resources.edit org.eclipse.oomph.setup org.eclipse.oomph.setup.core org.eclipse.oomph.setup.doc org.eclipse.oomph.setup.edit org.eclipse.oomph.setup.editor org.eclipse.oomph.setup.p2 org.eclipse.oomph.setup.p2.edit org.eclipse.oomph.setup.ui org.eclipse.oomph.setup.ui.questionnaire org.eclipse.oomph.setup.workbench org.eclipse.oomph.setup.workbench.edit org.eclipse.oomph.ui org.eclipse.oomph.util org.eclipse.oomph.workingsets org.eclipse.oomph.workingsets.edit org.eclipse.oomph.workingsets.editor Their sizes currently add up to 5.91 MB. Of course that might grow a little bit over time, for example when we add more documentation.
When we get to having a package for Andmore, this will be very useful. +1
(In reply to Eike Stepper from comment #9) > ... the needed feature ... > ... that feature to install Oomph's runtime plugins > This feature currently leads to the addition of ... Which one is 'this feature'? ;-) It's not the org.eclipse.oomph.all feature because this contains too much.
(In reply to Markus Knauer from comment #11) > Which one is 'this feature'? ;-) > It's not the org.eclipse.oomph.all feature because this contains too much. Sorry, I forgot to say that it's the org.eclipse.oomph.setup feature.
(In reply to Dennis Huebner from comment #8) > Maybe we should try it out with the Committers package first to test how it > behaves, at least for one milestone before we add it to all packages? I'd like to push this a bit in order to get as much feedback as possible before our release in June. And by integrating it now we've got plenty of time before we need to deliver M5 in February. I've created a change in Gerrit that enables Oomph in the packages: 38613: Add main Oomph feature to EPP Common Package Feature [Ib017fd9b] https://git.eclipse.org/r/#/c/38613/
Created attachment 249566 [details] package size comparison with/without Oomph Comparing the build results against our M3 build without Oomph (1) The size of most packages increased by about 5.2 - only the required Oomph bundles (less than the numbers given in comment #9, maybe worth double checking). (2) Some packages (e.g. cpp and committers) are 5.8 MB bigger caused by the following additional bundles: > org.eclipse.emf.common.ui_2.9.0.v20141215-0350.jar > org.eclipse.emf.edit_2.11.0.v20141215-0350.jar > org.eclipse.emf.edit.ui_2.11.0.v20141215-0350.jar (3) Three packages have an increased size of 7.3-7.9 MB (automotive, reporting, testing) which can be explained by these bundles that were added by p2: > javaewah_0.7.9.v201401101600.jar > org.eclipse.egit.core_3.6.0.201411121045-m1.jar > org.eclipse.jgit_3.6.0.201411121045-m1.jar @Eike: I don't think the first two categories are critical, but the 3rd one is or has the potential to be. Would it be possible to remove the dependency that is responsible for the addition of these three bundles?
Is that epp common feature used in the "standard package"? IMHO, nothing more should be added to it, the "standard package" since it is my view is it should always remain a fairly minimal set of "sdk + git". But, just my advise. I've no "official role" in the decision.
(In reply to Markus Knauer from comment #14) In bug 455933 I've removed the dependencies on org.eclipse.egit.ui and org.eclipse.egit plugins from two of our Setup plugins. That leaves us with dependencies on org.eclipse.egit.core from two of our Setup plugins: (a) org.eclipse.oomph.setup.git --> org.eclipse.egit.core;bundle-version="[3.0.0,4.0.0)" (b) org.eclipse.oomph.predicates --> org.eclipse.egit.core;bundle-version="[3.0.0,5.0.0)";resolution:=optional;x-installation:=greedy I'd like to discuss with Ed if/how we can move the (b) dependency or whether we could just make it non-greedy. The (a) dependency is altready a factored-out dependency, so in this case the only chance to get rid of it is to either move the org.eclipse.oomph.setup.git dependency out of our main Setup feature, or create an additional feature without that dependency, or find some p2 trickery to make our main Setup feature not include that dependency in these specific packages.
(In reply to Eike Stepper from comment #16) > (b) org.eclipse.oomph.predicates --> > org.eclipse.egit.core;bundle-version="[3.0.0,5.0.0)";resolution:=optional;x- > installation:=greedy We've made this dependency non-greedy now.
(In reply to Markus Knauer from comment #14) > (3) Three packages have an increased size of 7.3-7.9 MB (automotive, > reporting, testing) which can be explained by these bundles that were added > by p2: > > javaewah_0.7.9.v201401101600.jar > > org.eclipse.egit.core_3.6.0.201411121045-m1.jar > > org.eclipse.jgit_3.6.0.201411121045-m1.jar I think with all my recent changes no EGit plugins should be pulled in anymore. From where did you pull our setup feature to test this? In case you want to retest quickly I kicked a new nightly build, which is now available for p2 via http://download.eclipse.org/oomph/updates/latest .
Created attachment 249591 [details] package size comparison with/without Oomph, build #91 + #92 Great. I tested a build of all packages with the latest version from http://download.eclipse.org/oomph/updates/latest ... https://hudson.eclipse.org/packaging/job/epp-tycho-build.gerrit/92/ ... and can confirm that all packages, including automotive, reporting, and testing, are only 5.2 - 5.8 MB larger than before.
Excellent. Thank you for trying it out so quickly.
I pushed https://git.eclipse.org/r/#/c/38613/ to master. A new test-build with now available at https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/119/.
Included in all packages as part of the EPP Commons feature since Mars M4. Closing as fixed.
FWIW, with bug 570350 , it seems like not all package want to full same subset of Oomph. I'll submit a patch for bug 570350 which removes the requirement on Oomph from the common feature and move it instead to each package .product definition so package maintainers can select subsets as it better fits their target audience.
