Skip to main content



      Home
Home » Eclipse Projects » Oomph » How to setup dialog_settings.xml via Oomph user.setup?(Package Explorer settings config using Oomph user setup)
How to setup dialog_settings.xml via Oomph user.setup? [message #1752503] Tue, 24 January 2017 09:39 Go to next message
Eclipse UserFriend
Hi all,

I am trying to setup Package Explorer settings using the Oomph user.setup.
I am editing the user.setup in Eclipse.

I know you can use profiles for this, but in our team everybody wants to have their own way of setting up the Package Explorer, so we decided to set things up in the user settings.

As I saw in examples it's possible to add a "Resource Creation" task to write the dialog_settings.xml into the workspace.

When I configure the Resource Creation entry with a file "my_dialog_settings.xml", the file is written successfully.
I imagine that the actual file dialog_settings.xml is also written - but invoking "Perform Setup Tasks..." has no effect in Eclipse.

My Question:
Is setting up the Package Explorer settings this way even possible?
The PE settings are stored via mementos in dialog_settings.xml. But apparently that file is read before Eclipse comes up and written when Eclipse shuts down (at least that's what appears to happen).
If that is true, maybe changing the dialog_settings file has no effect in Eclipse at all...

Is there a way to setup the Package Explorer's configuration via Oomph user settings?


Cheers,
Ingo
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1752551 is a reply to message #1752503] Wed, 25 January 2017 00:00 Go to previous messageGo to next message
Eclipse UserFriend
Yes, the problem is that most often dialog_settings.xml resources are read on startup, before Oomph performs any tasks. We use the early start extension point to trigger the startup of Oomph and that happens pretty much after everything as read there settings files. A restart would be needed (and hopefully nothing is storing the settings files again during shutdown).

We do have tasks to initialize the dialog_settings.xml in the standard project catalogs. But these tasks are triggered at bootstrap time when a project stream is included via the second page of the advanced wizard. So the workspace is initialized before the installation starts to use it. That works well. There are really no hooks to force the various technologies to re-read the settings files. They don't generally expect these files to be modified other than by the preference/settings dialogs, which know to apply the changed values. This is sometimes an issue with preference tasks as well, if the technology doesn't listen to preference changes.

Perhaps we could do something to force a restart, i.e., to allow you to specify that a restart is needed if some task is performed, much like the p2 task forces/requests a restart after it performs. Perhaps you'll want to open a Bugzilla enhancement request for such a feature.
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1752573 is a reply to message #1752551] Wed, 25 January 2017 04:03 Go to previous messageGo to next message
Eclipse UserFriend
Ed,

Thank you for the quick reply.
Yes, that sounds of a good idea. I'll do that (creating an enhancement request).
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1752576 is a reply to message #1752573] Wed, 25 January 2017 04:26 Go to previous messageGo to next message
Eclipse UserFriend
Well, a restart apparently doesn't fix the problem. In a manual test Eclipse replaced the entire dialog_settings.xml at shutdown. Thus, my user.setup based changes at dialog_settings.xml are being overwritten and have no effect.

Thus, a general option for a setup task to add a "requires restart" flag wouldn't help that much for now.
Thanks anyway for the information.
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1752591 is a reply to message #1752576] Wed, 25 January 2017 08:14 Go to previous messageGo to next message
Eclipse UserFriend
Yes, I had a feeling that dialog settings might get saved on shutdown. It does make you wonder though why that would be necessary. I.e., why not only save them when they've been changed...
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1752902 is a reply to message #1752591] Mon, 30 January 2017 07:50 Go to previous messageGo to next message
Eclipse UserFriend
I think the problem here is that some plugins use dialog settings for things which should actually go into the plugin preferences. Plugin preferences have the benefit that there is a way to provide defaults via plugin_customization.ini. IMHO we should create bugs for such cases (problems view, packages explorer, etc). WDYT?
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1752941 is a reply to message #1752902] Mon, 30 January 2017 22:12 Go to previous messageGo to next message
Eclipse UserFriend
Yes, that makes sense to me. I suppose some might argue that preferences should be used for things modifiable by Preferences... but your counter argument that storing these things as preferences enables external customization seems a good one.
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1753189 is a reply to message #1752941] Thu, 02 February 2017 10:27 Go to previous messageGo to next message
Eclipse UserFriend
I've created bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=511580 for package explorer.
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1753200 is a reply to message #1753189] Thu, 02 February 2017 11:19 Go to previous messageGo to next message
Eclipse UserFriend
Is this just about changing dialog_settings.xml after Eclipse has been installed? I'm asking because we have lots of setups that successfully switch to showing working sets in the package explorer.
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1753211 is a reply to message #1753200] Thu, 02 February 2017 12:39 Go to previous messageGo to next message
Eclipse UserFriend
No, changing the file is one of the problems. The way the view unitializes is another .
If we change the file after view was opened, it will ignore the changes.After shutdown the view own (wrong ) settings are persisted so we are at the beginnung.
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1753214 is a reply to message #1753211] Thu, 02 February 2017 12:46 Go to previous messageGo to next message
Eclipse UserFriend
Right, but when you configure dialog_settings.xml during installation, no view has been opened and all is well.
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1753220 is a reply to message #1753214] Thu, 02 February 2017 13:29 Go to previous messageGo to next message
Eclipse UserFriend
But if you have users who don't install Eclipse just because they want to create a new workspace, you are lost again.
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1753224 is a reply to message #1753220] Thu, 02 February 2017 13:42 Go to previous messageGo to next message
Eclipse UserFriend
First, I only wanted to understand why you have a problem where I don't Smile

Second, my experience is that with bundle pool and oomph it's getting a lot easier to convince developers to just "install a new workspace" which behind the scenes may include installing a new Eclipse. Much more attention, time and resources are invested in the workspace than in installing yet another Eclipse. YMMV, of course.
Re: How to setup dialog_settings.xml via Oomph user.setup? [message #1753225 is a reply to message #1753224] Thu, 02 February 2017 13:55 Go to previous message
Eclipse UserFriend
Most of us in our lab have multiple workspaces for different streams, different languages, different project sets. Having multiple installations would make the chaos perfect, additionally to the problem that the workspace selection dialog would show only one from them. I've just had a feedback meeting on our first Oomph-based installaton and few developers had questions how they can easily create multiple new workspaces for *the same* git branch. So 1:1 relationship between installation and workspace is not an option. BTW I guess you are coming from the JDT bug - I still need a +1, +2 and a merge Surprised)
Previous Topic:Problems satisfying version constraints when materializing
Next Topic:Git Clone & Project Import Won't Run Automatically
Goto Forum:
  


Current Time: Sun Jul 13 08:42:31 EDT 2025

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

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

Back to the top