Community
Participate
Working Groups
I had been using the 32-bit Windows version of Java EE packaged version "Eclipse IDE for Java EE Developers, 206 MB" (Build id: 20100917-0705) from http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/helios/SR1/eclipse-jee-helios-SR1-win32.zip. Am not able to uninstall the RSE plugins; the button is disabled. How do I uninstall it from the distribution ?
I think probably this need be considered as a duplicate to bug 265948. @Pascal: Even though from a p2 point of view this is the expected behavior as you state, the way I use these pre-built packages is to get the necessary set of plugins catered to a distribution and then should be able to add/delete/modify the ones I intend to. This would save me from downloading the minimal distribution and keep adding intended plugins.
Currently all EPP packages are defined by a single "root feature" (see bug 329973) and the RSE bundles are just children of of this feature. Therefore it is not possible to uninstall a few bundles in this dependency chain.
*** Bug 455363 has been marked as a duplicate of this bug. ***
I did experiments with Tycho 0.20 in April, moving dependency features from the "EPP package" feature as root features into the product, but at that time it was too late in the release cycle for such a large change. After all the packages always used to be structured like this and this change would have been an unexpected and unpredictable surprise for many. Some of my thoughts at that time were... - When we change the current structure we (i.e. package maintainers) don't have control about the timing of updates and the version of the new features that are installed in a product. There are some products out there who rely on a relationship between product version and the installed feature versions. - Many people want a combination of packages, i.e. the RCP package *and* the Modeling package. All those people are downloading one package, e.g. the RCP package, and can easily install the "Modeling Feature" into the RCP package. This use case wouldn't be supported any more. - And then there are probably others who built something based on the assumption that the packages are like they are... use cases that we are not aware of. - What would be the ideal structure? Move everything from the single EPP root feature that currently defines the content of a package one level up and install the package content as root features? Or just some of them? Would be interesting to find a better solution for Eclipse Mars and now would be a good time to start this discussion again.
Bug 345503 "Reconsider patch/update policy for EPP Packages" contains more background information about this topic.
> - When we change the current structure we (i.e. package maintainers) don't > have control about the timing of updates and the version of the new features > that are installed in a product. There are some products out there who rely > on a relationship between product version and the installed feature versions. The assumption that a given product include a specific version of a feature is unfortunately flawed because anything can be patched and changed breaking this assumption. That said, if the product wanted to have some kind of control over which versions of its pieces are applicable, then it could express dependencies on features that are not yet installed in order to avoid issues mixing and matching features of different stream. This is what a non-greedy and optional dependency allows. > > - What would be the ideal structure? Move everything from the single EPP > root feature that currently defines the content of a package one level up > and install the package content as root features? Or just some of them? > > Would be interesting to find a better solution for Eclipse Mars and now > would be a good time to start this discussion again. IMO, we need to step back and look at the purpose of a given package. To me being a Modeling developer means having every plug-in to do modeling, not having support for git, cvs, mylyn, etc... To resolve this, I propose that we think of a package as 3 complementary pieces: 1 - The must have parts - These are really the parts that you can't avoid no matter what you are doing. At this point I think of this as the platform and the bug reporter. 2 - The package parts - These represent the features and plug-ins that constitute set of tools that are really core to the mission of the package (e.g. JDT + WTP for JEE package) 3 - The useful parts - Whereas 1 and 2 focus on bringing all the tools required to perform a certain set of tasks (e.g. writing an HTML document, writing java code), w/o making any assumption on the environment (which SCM, build tool, etc.), these parts are here to create a more ready to consume environment and give a way to promote cool eclipse technology w/o forcing those on to our users. Concretely, what does this mean: - Have a feature that includes the features that are core to the mission of the package and locks dependencies on the platform. This would be a trimmed down version of the <packageName>.feature we have today. - Have the product definition of a given package include the feature previously described and introduce as root all the items identified in #3. This is key to have a package that include all the bells and whistles and yet let the user pick and chose which one they like or need. With this I think we cover the majority of the cases (or after so much writing I'd like to think so :)) 1 - the packages are focused and yet filled with tools to make the user more productive 2 - the pieces not core to the package are removable (e.g. mylyn or RSE) 3 - users willing to lay multiple packages over each others would be able to do so, and would only get the core functionalities which is probably what they wanted anyway. Of course I recognize that the case where someone starts from a modeling package and adds the JEE core feature would not have a way to get RSE or Mylyn but with the mechanisms we have at hand today it is all we can do. A more elaborate solution would be, on the first start, to take the user through a wizard that proposes interesting pieces to install like I proposed in EasyEclipse. For example which SCM do you use, which build tool do you use, etc. HTH
Can such a restructuring also address the wish to inherit products, i.e. make the committers package an extension of the Java package so that includes all features of the Java package by default?
(In reply to Gunnar Wagenknecht from comment #7) > Can such a restructuring also address the wish to inherit products, i.e. > make the committers package an extension of the Java package so that > includes all features of the Java package by default? If the desire is to reuse "The package parts" as described in comment 6, then yes. This can be done by including or requiring the other package feature. If the desire is to reuse more than this, then more work is needed (e.g. use a templating a approach to generate the product, change the metadata generated, etc.)
*** Bug 456951 has been marked as a duplicate of this bug. ***
My intention with https://bugs.eclipse.org/bugs/show_bug.cgi?id=456951 was targeted towards what Pascal proposes as the purpose of an eclipse product. If I am using my preferred non-eclipse tools to do some of my development tasks I don't want my eclipse IDE blaoted with plugins that I don't need/use. For me this becomes more critical when some of these plugins consume resources or spwan tasks in the background to do stuff that I don't need. I know that for most casual/general users all this automation is thought as to benefit them and provide an easier developing experience. I would add to the re-thining on why version control tools are part of the core. Are they required by eclipse to download and install new plugins? Why is git part of the core and not svn? Perhaps the modeling product groups decides that git is part of the modeling process and thus must be bundeled in their distribution. That is fine. But I would like to: i) Unistall things I dont want/use ii) Be able to start with a minimal eclipse sdk and add just the plugins and features I like. If I lack a dependency... well, isn't that the purpose of dependencies? I know I would have to install it (them).
(In reply to Horacio Hoyos from comment #10) > ii) Be able to start with a minimal eclipse sdk and add just the plugins and > features I like. If I lack a dependency... well, isn't that the purpose of > dependencies? I know I would have to install it (them). In EPP we try to create packages that bundle a set of functionality into specific downloads for a group of users. In your case it could help you to look into the downloads of the Eclipse platform team at http://download.eclipse.org/eclipse/downloads/. Maybe one of their downloads (e.g. the SDK download) is a good starting point.
@Markus It seems I didn't made my point. For me, the smallest eclipse product (Eclipse SDK) is still to bloated, in my particular case with EGit. My initial request was that EGit could be unisntalled. Since it is a core component, this could never be achieved. I think the intent of this bug is to design a new eclipse packaging method or such that would allow thiner eclipse products, with the burden of fulfilling dependencies left to the user, as stated by Pascal. Perhaps I should open a specif bug enhancement request to have Egit removed form the core pacakges.
Again, please take a look at the link from my comment #11 first. If you open a specific version on that page you'll find an SDK download that does *not* contain EGit, and an even smaller eclipse-platform-* download.
(In reply to Horacio Hoyos from comment #12) > @Markus It seems I didn't made my point. For me, the smallest eclipse > product (Eclipse SDK) is still to bloated, in my particular case with EGit. > My initial request was that EGit could be unisntalled. Since it is a core > component, this could never be achieved. I think the intent of this bug is > to design a new eclipse packaging method or such that would allow thiner > eclipse products, with the burden of fulfilling dependencies left to the > user, as stated by Pascal. > > Perhaps I should open a specif bug enhancement request to have Egit removed > form the core pacakges. -1. I want Egit in the CPP package so, no you can't remove it. And that's the point. The packages contents are decided by the maintainers to address certain user's needs. Not all users, but a large number of them. What you're looking for is a way to make you're own package and that's out side the scope of EPP.
> -1. I want Egit in the CPP package so, no you can't remove it. > > And that's the point. The packages contents are decided by the maintainers > to address certain user's needs. Not all users, but a large number of them. Doug, I think you are missing the point. The fact that you as a package maintainer want to add all sorts of stuffs in the package just because you think is cool and make sense to use it together is not a reason to prevent your users from uninstalling it. For example you want to force Git because you think it is cool, but I'm using Mercurial or SVN on my project, so I would rather not have the plugin there at all. Since you like analogies with Linux, when you install a distro like Ubuntu, it comes with a bunch of packages pre-installed because they think it will be those that you will need. However they still let you uninstall some if you chose to.
I'm not disagreeing with the requirement. Being able to create a custom package with only the things you want in it is great and something we really need to do. I'm hoping with Wayne's work on improving the install experience we can make something like that. I also agree with the original request here, to be able to uninstall a feature from a package. Thought I feel the need for that is more a design issue with those features. You should never know a feature is installed unless you're using it, or you run through a workflow that you may decide to start using it. And we do have a lot of bad plug-ins that violate that, e.g. every plug-in that implements an early startup, RSE included.
*** Bug 480756 has been marked as a duplicate of this bug. ***
There are now 14 changes in Gerrit, each for one of the package, and for each one I'm asking a package maintainer to give at least a +1 vote in Gerrit - a mail to epp-dev mailing list will follow. The changes itself are just a restructuring, i.e. a simple move of the dependencies from the package feature up to the product itself, and in the product they are now 'root' features which can have their own lifecycle, i.e. they can be updated independently and/or removed. Planning Council discussion about updates/upgrades: https://wiki.eclipse.org/Planning_Council/February_03_2016#Neon_Planning_.28and_beyond.29 Finally, a list with all changes in Gerrit: Android: Move package content definition from feature to product https://git.eclipse.org/r/#/c/66993/ Automotive: Move package content definition from feature to product https://git.eclipse.org/r/#/c/66997/ Committers: Move package content definition from feature to product https://git.eclipse.org/r/#/c/66998/ CPP: Move package content definition from feature to product https://git.eclipse.org/r/#/c/66999/ DSL: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67000/ 67002: Java: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67002/ 67004: JavaEE: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67004/ 67005: Modeling: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67005/ 67006: Parallel: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67006/ 67007: PHP: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67007/ 67008: RCP/RAP: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67008/ 67010: Reporting: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67010/ 67012: Testing: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67012/ 67011: Scout: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67011/
There are now 14 changes in Gerrit, each for one of the package, and for each one I'm asking a package maintainer to give at least a +1 vote in Gerrit - a mail to epp-dev mailing list will follow. The changes itself are just a restructuring, i.e. a simple move of the dependencies from the package feature up to the product itself, and in the product they are now 'root' features which can have their own lifecycle, i.e. they can be updated independently and/or removed. Planning Council discussion about updates/upgrades: https://wiki.eclipse.org/Planning_Council/February_03_2016#Neon_Planning_.28and_beyond.29 Finally, a list with all changes in Gerrit: Android: Move package content definition from feature to product https://git.eclipse.org/r/#/c/66993/ Automotive: Move package content definition from feature to product https://git.eclipse.org/r/#/c/66997/ Committers: Move package content definition from feature to product https://git.eclipse.org/r/#/c/66998/ CPP: Move package content definition from feature to product https://git.eclipse.org/r/#/c/66999/ DSL: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67000/ Java: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67002/ JavaEE: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67004/ Modeling: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67005/ Parallel: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67006/ PHP: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67007/ RCP/RAP: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67008/ Reporting: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67010/ Testing: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67012/ Scout: Move package content definition from feature to product https://git.eclipse.org/r/#/c/67011/
New Gerrit change created: https://git.eclipse.org/r/69154
JavaScript: Move package content definition from feature to product https://git.eclipse.org/r/#/c/69154/
Gerrit change https://git.eclipse.org/r/69154 was merged to [master]. Commit: http://git.eclipse.org/c/epp/org.eclipse.epp.packages.git/commit/?id=2e8fda72d87146ed1082ca478d625c8973068eb9
Current status as of Neon M6 (4.6.0M6): Automotive: package removed Committers: merged CPP: merged DSL: merged JavaEE: merged JavaScript: merged Modeling: merged Parallel: merged RCP/RAP: merged Testing: merged Scout: merged Android: open (not yet approved) Java: open (not yet approved) PHP: open (not yet approved) Reporting: open (not yet approved)
With 4.6 M7 (Neon) all packages were updated to the new structure. Closing as fixed.
I am trying to uninstall EGit from Eclipse RCP RAP 4.7.2. See also here: https://stackoverflow.com/questions/48724529/how-to-uninstall-egit
Please do not open closed bugs but create a new one if you believe you are running into a bug with Eclipse.
(In reply to Gunnar Wagenknecht from comment #26) > Please do not open closed bugs but create a new one if you believe you are > running into a bug with Eclipse. Can you please explain why? How is this another problem? Or is it generally not allowed to reopen bugs that were fixed once?
(In reply to Holger Voormann from comment #27) > Can you please explain why? How is this another problem? Or is it generally > not allowed to reopen bugs that were fixed once? Holger, it's my understanding that re-opening bugs which have been closed/resolved for at least a full release cycle should be considered unwanted practice. Just because of the time that has passed since then it's unclear whether an issue exist because of an incomplete implementation back then or some unrelated changes happened meanwhile. Thus, it's better to create a new bug and allow this one to be triaged properly. Of course, this is just my opinion. Some projects don't care. Besides, there are a ton of users described to this bug. I apologize for taking away part of their time with this noise.
