Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Oomph » Update to remove a feature(Authoring Oomph to remove a feature)
Update to remove a feature [message #1821198] Fri, 07 February 2020 00:04 Go to next message
Chris Lake is currently offline Chris LakeFriend
Messages: 25
Registered: November 2015
Junior Member
I've recently tried to author an Oomph setup to automatically update my devs from 2018-12 to 2019-09, but I have a problem.

When updating old workspaces an error is shown regarding "o.e.epp.internal.logging.aeri.ide.notifications.MylynNotificationsSupport". I found this bug and decided that we could remove the *.aeri.* bundles as they are not used: https://bugs.eclipse.org/bugs/show_bug.cgi?id=558840

Investigations found that these bundles were installed as part of "EPP Common Package Feature (org.eclipse.epp.package.common.feature.feature.group)".

So I removed that feature from my .setup file and added in its place its requirements individually: o.e.oomph.setup.feature.group (1.14) and org.eclipse.epp.package.common (4.13).

Now when the update runs I have a problem shown by the following log:
ERROR: org.eclipse.equinox.p2.director code=10054 Cannot complete the install because of a conflicting dependency.
  at org.eclipse.oomph.util.OomphPlugin.coreException(OomphPlugin.java:280)
...
  ERROR: org.eclipse.equinox.p2.director code=0 Software being installed: artificial_root 1.0.0.v1581032449397
  ERROR: org.eclipse.equinox.p2.director code=1 Only one of the following can be installed at once: 
    ERROR: org.eclipse.equinox.p2.director code=0 Common EPP Bundle 4.13.0.20190917-0000 (org.eclipse.epp.package.common 4.13.0.20190917-0000)
    ERROR: org.eclipse.equinox.p2.director code=0 Common EPP Bundle 4.10.0.20181214-0600 (org.eclipse.epp.package.common 4.10.0.20181214-0600)
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: artificial_root 1.0.0.v1581032449397
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.eclipse.epp.package.common [4.13.0,4.13.1)
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: artificial_root 1.0.0.v1581032449397
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.eclipse.epp.package.common.feature.feature.group [4.10.0,4.11.0)
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: EPP Common Package Feature 4.10.0.20181214-0600 (org.eclipse.epp.package.common.feature.feature.group 4.10.0.20181214-0600)
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.eclipse.epp.package.common [4.10.0.20181214-0600,4.10.0.20181214-0600]


This is a problem as "EPP Common Package Feature 4.10.0.20181214-0600 (org.eclipse.epp.package.common.feature.feature.group 4.10.0.20181214-0600)" should no longer be installed.

Is there a way to tell Oomph to remove/ignore this old feature which is no longer in use and indeed no longer part of the setup?

Chris
Re: Update to remove a feature [message #1821201 is a reply to message #1821198] Fri, 07 February 2020 05:40 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
One question here though, what Product Version is in the Installation setup for these users? I ask because that will also contribute requirements and update sites to the merged p2 task. What kind of model are you updating? A Product model? Also note that each EPP product IU directly requires org.eclipse.epp.package.common.feature.feature.group so I don't see that it's possible to remove this because you need some product IU...

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Update to remove a feature [message #1821433 is a reply to message #1821201] Thu, 13 February 2020 01:52 Go to previous messageGo to next message
Chris Lake is currently offline Chris LakeFriend
Messages: 25
Registered: November 2015
Junior Member
So the product is based off the RCP/RAP Eclipse package. Essentially rebuilding it using the features I can see it comes with. Then we add several more features and plugins for our development purposes.

The current working Eclipse 2019-03 environment starts as:
  <product name="eclipse.development.ide"
      label="Development IDE">
    <version
        name="latest"
        label="Eclipse IDE for RCP Development"
        requiredJavaVersion="1.8">
      <setupTask
          xsi:type="setup.p2:P2Task"
          label="Development IDE (Latest)"
          licenseConfirmationDisabled="true">

        <!-- base -->
        <requirement
            name="org.eclipse.epp.package.rcp.feature.feature.group"
            versionRange="[4.11.0,4.11.1)"/>
        <requirement
            name="org.eclipse.epp.package.common.feature.feature.group"
            versionRange="[4.11.0,4.11.1)"/>
        <requirement
            name="org.eclipse.sdk.feature.group"
            versionRange="[4.11.0,4.11.1)"/>
        ...
        <!-- supplemental -->
        <requirement
            name="org.eclipse.cdt.launch.remote.feature.group"
            versionRange="[9.7.0,9.7.1)"/>
        ...
        and so on


So although "epp.package.rcp" requires "org.eclipse.epp.package.common.feature.feature.group", we don't use that top level "epp.package.rcp" IU. So now I am attempting the following for 2019-09:
  <product name="eclipse.development.ide"
      label="Development IDE">
    <version
        name="latest"
        label="Eclipse IDE for RCP Development"
        requiredJavaVersion="1.8">
      <setupTask
          xsi:type="setup.p2:P2Task"
          label="Development IDE (Latest)"
          licenseConfirmationDisabled="true">

        <!-- base -->
        <requirement
            name="org.eclipse.epp.package.rcp.feature.feature.group"
            versionRange="[4.13.0,4.13.1)"/>
        <!-- org.eclipse.epp.package.common.feature includes these 3 IUs
               * org.eclipse.epp.logging.aeri.feature.feature.group
               * org.eclipse.oomph.setup.feature.group
               * org.eclipse.epp.package.common
             They are installed individually because the 'aeri.feature' is not wanted
        -->
        <requirement
            name="org.eclipse.oomph.setup.feature.group"
            versionRange="[1.14.0,1.14.1)"/>
        <requirement
            name="org.eclipse.epp.package.common"
            versionRange="[4.13.0,4.13.1)"/>
        <requirement
            name="org.eclipse.sdk.feature.group"
            versionRange="[4.13.0,4.13.1)"/>
        ...
        <!-- supplemental -->
        <requirement
            name="org.eclipse.cdt.launch.remote.feature.group"
            versionRange="[9.9.0,9.9.1)"/>
        ...
        and so on


So now that the feature is gone, I want it removed from devs Eclipse instance.

Note that in testing, I manually removed that feature then performed the update and this worked perfectly.
Re: Update to remove a feature [message #1821436 is a reply to message #1821433] Thu, 13 February 2020 03:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
The issue is that when the p2 task performs as a profile change request (in org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.adjustProfileChangeRequest(IProfileChangeRequest, IProgressMonitor)), the current profile is considered, and any root IUs (user visible) in the current profile are included as requirements in the change request. So, in general, any root IUs that the user has installed (manually or otherwise via previous p2 tasks), will remain installed, regardless of what new things or updates will be installed to satisfy the p2 task's requirements. This is of course because if a user installs a product using the installer and then installs manually a bunch of additional things, they'd be pretty upset if later Help -> Perform Setup Tasks removed them all again because the Eclipse product they installed doesn't require those things.

So in general, a p2 task cannot and is not designed to uninstall root IUs. Two possibilities, if this were badly needed. One, the p2 task could include a boolean property that would set org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.setRemoveExistingInstallableUnits(boolean) to true; that seems like a sledge hammer. Or two, a Requirement is able to model a so-called negative requirement to explicitly remove something, i.e, to require it not to be installed.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Update to remove a feature [message #1821518 is a reply to message #1821436] Fri, 14 February 2020 00:54 Go to previous messageGo to next message
Chris Lake is currently offline Chris LakeFriend
Messages: 25
Registered: November 2015
Junior Member
Thanks for the info.

  • So what defines a "root IU"? I could (I presume), re-design the setup to not use them if that made things easier in future.

  • I see in the Git repo there are several setups for the downloadable Eclipse packages (in org.eclipse.products.setup). Is there an "official" oomph setup for the "Eclipse IDE for RCP and RAP Developers" package somewhere? If so, would it be better to use that as a base and build on top of that?

  • I have successfully used a "negative requirement" which will at least get me through this update, then at the next update, I can just remove it from the setup as everyone should have been already updated.



Re: Update to remove a feature [message #1821519 is a reply to message #1821518] Fri, 14 February 2020 04:47 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
We use the query org.eclipse.equinox.p2.engine.query.UserVisibleRootQuery which tests each IU whether it has this property:
	/**
	 * A property key (value <code>"org.eclipse.equinox.p2.type.root"</code>) for a
	 * boolean property indicating whether an installable unit should be considered
	 * a root of the install. Typically this means the unit will appear to the end user
	 * as a top-level installed item. The property should be obtained from a profile using 
	 * IProfile#getInstallableUnitProperty(IInstallableUnit, String).
	 * 
	 * @see #LOCK_UNINSTALL
	 * @see #LOCK_UPDATE
	 * @see #LOCK_NONE
	 */
	public static final String PROP_PROFILE_ROOT_IU = "org.eclipse.equinox.p2.type.root"; //$NON-NLS-1$
So you can't really avoid them. Note too that you can use Navigate -> Open Discovered Type to find Java source code for any Eclipse project, so if someone tells you the qualified name of a class or method, you can find it's source code via a web link.

You can see all the generated product definitions using Navigate -> Open Setup -> Parent Models -> Eclipse.org and in there you'll find products for all the EPP Packages. In fact, you can see this same resource in any Setup Editor if you toggle the "Show all Resources" toolbar button.

How did you use a negative requirement?


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Update to remove a feature [message #1821639 is a reply to message #1821519] Tue, 18 February 2020 05:40 Go to previous messageGo to next message
Chris Lake is currently offline Chris LakeFriend
Messages: 25
Registered: November 2015
Junior Member
Thanks, I'll look in to it.

For the negative requirement I used the following:

        <requirement
            name="org.eclipse.epp.package.common.feature.feature.group"
            filter="(nonexistent.property=true)"/>


This seems to have stopped considering any version of "org.eclipse.epp.package.common.feature.feature.group" being part of the setup, and so the installer could continue past the dependency conflict. This had the desired effect of "uninstalling" that feature from the Eclipse instance.
Re: Update to remove a feature [message #1821644 is a reply to message #1821639] Tue, 18 February 2020 07:31 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
That's clever! This indeed would replace/override the requirements gathered from the already-installed software and by then filtering out the requirement itself, no requirement is left to satisfy so the IU won't be installed by any requirement...

Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Version Management: Show differences
Next Topic:Accessing location of setup file during setup
Goto Forum:
  


Current Time: Fri Apr 26 06:01:31 GMT 2024

Powered by FUDForum. Page generated in 0.02945 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top