Eclipse Community Forums: Oomph » 'Perform Setup Tasks..' P2 task doing more than I'd expect

Help

Home

Home » Eclipse Projects » Oomph » 'Perform Setup Tasks..' P2 task doing more than I'd expect

Show: Today's Messages :: Show Polls :: Message Navigator

'Perform Setup Tasks..' P2 task doing more than I'd expect [message #1857706]

Tue, 21 February 2023 23:59

Mark Lawrence

Messages: 28
Registered: February 2023

Junior Member

A large number of requirements are installed from a range of different repositories for an Oomph product & project combination I've been working on. This is an old product based on Photon.

My intention was for everything to be installed at BOOTSTRAP. Then after BOOTSTRAP it is only a few requirements I would like to ever be considered for update. So most of my P2 repos are only set up to trigger on BOOTSTRAP only, then I have a select few set to BOOTSTRAP STARTUP MANUAL.

This doesn't appear to be honoured though. If I run 'Perform Setup Tasks' I will see the P2 task with only the P2 Repos I'm expecting, but in nested elements I can see its trying to get a brand new eGit, Mylyn, & oomph, which I believed I had set to only install at BOOTSTRAP. To add to that, if I run the Tasks, I will get 'missing requirement' errors for features that are part of other P2 repos I've set for BOOTSTRAP only.

To combat some of this, I've put redirections on the eGit/Mylyn/Oomph update site URLs its using so its not using latest but rather a fixed version URL site (the version of the one installed), so updates aren't found, and I've also tried making all my previously BOOTSTRAP only repos to BOOTSTRAP STARTUP MANUAL, however that then seems to take ages fetching every single requirement that is already installed and eventually fails with a 'Error reading signed content' error.

Does the behaviour I'm seeing make sense? Is there any way to just get it to update just a small selection of plugins? If not, is there anyway to disable the P2 task in 'perform setup tasks...' because at the moment, I cannot get a successful 'Perform Setup Tasks...' run, it always fails for any of the reasons above.

Report message to a moderator

Re: 'Perform Setup Tasks..' P2 task doing more than I'd expect [message #1857712 is a reply to message #1857706]

Wed, 22 February 2023 07:37

Ed Merks

Messages: 33145
Registered: July 2009

Senior Member

The p2 task running in the IDE will always include requirements also from what's already installed in the IDE so that they remain installed. You will see those (additional root installable units) in the p2 task in the preview. In the end, the overall set of installed things must remain statisfiable so one cannot just "update" a smaller set of things, completely ignoring the other already installed things. But I suppose it would be nice if such requirements could also be satisfied by what's already installed in the IDE, but I expect that the implementation can only try to resolve those additional requirements against the repositories specified in the p2 task. I would try to solve that problem with redirections.

One way to completely disable the p2 task is to specify no p2 tasks with START or MANUAL trigger. I suppose using filters is possible as well, but that seems more complex...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: 'Perform Setup Tasks..' P2 task doing more than I'd expect [message #1857723 is a reply to message #1857712]

Wed, 22 February 2023 23:27

Mark Lawrence

Messages: 28
Registered: February 2023

Junior Member

I don't seem to be able to stop the P2 step completely on a MANUAL run, so instead I've made all P2 repos trigger on BOOTSTRAP STARTUP MANUAL.

However, I get this error when it tries to fetch the devstyle features by genuitec on a MANUAL (& if requirements are found to be incorrect on startup): https://bugs.eclipse.org/bugs/show_bug.cgi?id=572034

Is there any way to combat that issue on Photon?

Report message to a moderator

Re: 'Perform Setup Tasks..' P2 task doing more than I'd expect [message #1857728 is a reply to message #1857723]

Thu, 23 February 2023 06:36

Ed Merks

Messages: 33145
Registered: July 2009

Senior Member

In older runtimes, Equinox does its own signature checking. In the newer ones, it just uses what the JDK provides, so simply using a newer JDK would help. I don't see any way that you can get this older runtime to recognize newer signatures...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: 'Perform Setup Tasks..' P2 task doing more than I'd expect [message #1857750 is a reply to message #1857728]

Fri, 24 February 2023 00:05

Mark Lawrence

Messages: 28
Registered: February 2023

Junior Member

Thanks for replying Ed. I don't really have much movement on the JDK. I have to use Photon, & it must point to an IBM Java 8 due to certain plugins we use.

Though I have made some progress. I had a resource creation task modifying the list of available update sites so most were disabled (for the same reason as above, so only a few plugins would get updated when running 'Check for Updates', I was also getting 'No Remedy Found' errors when running it), as soon as I took out this Resource Creation task and I made all my P2 repos trigger on all events, the 'Perform Setup Tasks' P2 tasks runs to completion! Looking good....

....but not quite. After restart, I found that the install had been broken. Lots of errors & missing requirements. Turns out that the 'Perform setup tasks' process isn't installing the requirements in the correct place (as if it forgets installation.location), rather than installing to:

/Users/<my user name>/eclipse/<product name>/Eclipse.app/Contents/Eclipse

it's choosing to install missing requirements to:

/Users/Eclipse.app/Contents/Eclipse

This is down to something I mentioned I was going to do in another post. I need the 'configuration' folder to be outside the Eclipse.app bundle so that I can sign the Eclipse.app bundle and the signature not be broken soon after loading Eclipse with a changing internal 'configuration' folder (this is so secure storage plays nicely on Mac with other Eclipse instances). I got that working by adding osgi.configuration.area=${installation.location/}configuration to the config.ini. However, Oomph doesn't do this straight away during install. A few things get written in the 'configuration' folder within the Eclipse.app bundle before the line gets added. One of those folders is 'org.eclipse.oomph.setup'. Anyway, as soon as I disable my config.ini modification task and re-install, everything works great.

Is what I'm doing regarding the move of the configuration folder ok to do? It seems Oomph might expect it in a certain place? Can I change the [b]configuration:[\b] value used in Oomph?

Is there a way I can correct this path being used? How is it calculated? Looks like it might decide where to install requirements based on relative path to the 'configuration' folder, maybe?
index.php/fa/42978/0/

Attachment: Screenshot 2023-02-24 at 00.01.46.png
(Size: 445.57KB, Downloaded 268 times)

[Updated on: Fri, 24 February 2023 00:07]

Report message to a moderator

Re: 'Perform Setup Tasks..' P2 task doing more than I'd expect [message #1857768 is a reply to message #1857750]

Fri, 24 February 2023 10:56

Ed Merks

Messages: 33145
Registered: July 2009

Senior Member

These are very low level details, complicated further by the fact that I work on Windows where this isn't this rather complicated layout. Where Oomph wants to put things and find things like the Installation.setup is answered differently if your asking where does the installer put things versus where does a running application look for things. Certainly in the installer, Oomph expects a standard layout and will know nothing about you changing the configuration location. In the running application I would assume it looks in the configuration folder as specified by the osgi property. From what you describe, these sound like two different locations. If you search the source for Installation.setup you'll find related things. Also org.eclipse.oomph.setup.internal.core.SetupContext.getStaticConfigurationLocation() and org.eclipse.oomph.setup.internal.core.SetupContext.INSTALLATION_SETUP_URI are how the application finds things. But in the installer it does things like this:

      File configurationLocation = composedPerformer.getProductConfigurationLocation();
      if (configurationLocation != null)
      {
        File installationLocation = new File(configurationLocation, "org.eclipse.oomph.setup/installation.setup"); //$NON-NLS-1$

which expects a standard layout...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: 'Perform Setup Tasks..' P2 task doing more than I'd expect [message #1857778 is a reply to message #1857768]

Sat, 25 February 2023 01:02

Mark Lawrence

Messages: 28
Registered: February 2023

Junior Member

Thanks for info Ed. I had a look around at the code you suggested. I couldn't find any way of tricking the installer or the 'Eclipse Updater' to go the correct place. What I've been experiencing is the same as what's reported here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=391455
I think the only way around it would require changes to oomph to allow the configuration folder to live outside the Eclipse.app bundle. The Mac notarisation process seems to be stricter even more in Ventura and plays havoc on blocking unsigned apps from accessing the OS keychain. Mac app bundles have to be immutable nowadays. From what I've seen, signed apps can access any entry in the keychain following admin approval, but unsigned apps can only access a keychain entry they've created. So having multiple unsigned Eclipses on a Mac is bad news.

I've readjusted my expectations a bit, a feature I'm installing comes with a password provider, so I'm planning on using that. The snag I have now is, its only available after BOOTSTRAP, so any password variables in my setups are always asked for at install time and the Eclipse Installer can't save those passwords using my new password provider, as it hasn't been installed yet.
Is there a way of getting oomph to ask for password variable entry at STARTUP?

I saw it would do this if the variable was undeclared, but that doesn't work with passwords because anything that uses them after entry errors because they're not encrypted and in base64.

Report message to a moderator

Re: 'Perform Setup Tasks..' P2 task doing more than I'd expect [message #1857784 is a reply to message #1857778]

Sat, 25 February 2023 17:08

Ed Merks

Messages: 33145
Registered: July 2009

Senior Member

Perhaps a filter on the task that uses the password such that it is filtered out in the installer but not filtered out in the installation.

https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Conditional_Tasks

You could use an Eclipse Ini task set the value of the filter uses in the installation.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: 'Perform Setup Tasks..' P2 task doing more than I'd expect [message #1858070 is a reply to message #1857706]

Tue, 14 March 2023 16:45

Mark Lawrence

Messages: 28
Registered: February 2023

Junior Member

Thanks for your help previously on this Ed.

In the end I stopped using Oomph to manage the passwords. Instead, users just need to enter them manually when Eclipse asks for them. I also use a secure storage in the workspace of each install, the master password of which is managed by a passwordProvider that comes bundled in a feature we install, so we're not completely avoiding all the OS password provider issues.

Report message to a moderator

Previous Topic:	Gitlab checkout Oomph template (InducedChoices)
Next Topic:	Testing changes in project setup files

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue May 07 15:14:40 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter