Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Oomph » Lock workspace to installation(I would like to know how to each eclipse binary to a specific workspace)
Lock workspace to installation [message #1732282] Sat, 14 May 2016 14:47 Go to next message
Luke deGruchy is currently offline Luke deGruchyFriend
Messages: 4
Registered: May 2016
Junior Member
First of all, apologies if this question has already been asked and answered. I tried googling for the answer but the vocabulary I used might be wrong.

I would like to know how to lock a specific eclipse installation to a specific workspace.

Before Oomph, I set up several different Eclipse binaries each pointing to their own workspace and launch them as needed. The reason for this is needing to install different versions of a specific plugin, specifically, production and dev versions of that plugin. So, I would launch eclipse1 linked to workspace 1 then launch eclipse2 and it would load workspace2.

Now with Ooomph, I would launch eclipse1 with workspace1, close it, then launch eclipse2 and workspace1 would come up.

Is there a way for me to tell Oomph to link the binaries I want to the workspaces I want?

Ideally I'd like to keep the preferences the same among the binaries/workspaces but if I have to keep them in sync manually that's acceptable.
Re: Lock workspace to installation [message #1732369 is a reply to message #1732282] Mon, 16 May 2016 15:46 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31032
Registered: July 2009
Senior Member
Luke,

Comments below.

On 16.05.2016 15:45, Luke deGruchy wrote:
> First of all, apologies if this question has already been asked and
> answered. I tried googling for the answer but the vocabulary I used
> might be wrong.
>
> I would like to know how to lock a specific eclipse installation to a
> specific workspace.
> Before Oomph, I set up several different Eclipse binaries each
> pointing to their own workspace and launch them as needed.
How did you do that? Why doesn't that work with an installation created
with Oomph?
> The reason for this is needing to install different versions of a
> specific plugin, specifically, production and dev versions of that
> plugin. So, I would launch eclipse1 linked to workspace 1 then
> launch eclipse2 and it would load workspace2.
What's in each workspace? If you wrote an project setup for what's in
the workspace, and created an installation for each project setup, it
would create a workspace that's associated with the installation as the
default, and you could click the check box so that you won't be prompted
again...
>
> Now with Ooomph, I would launch eclipse1 with workspace1, close it,
> then launch eclipse2 and workspace1 would come up.
Why? I don't see that an Oomph-created installation (unless provisioned
for a given project setup) behaves any differently from what you had before.
>
> Is there a way for me to tell Oomph to link the binaries I want to the
> workspaces I want?
Project setups generally produce that behavior.
>
> Ideally I'd like to keep the preferences the same among the
> binaries/workspaces but if I have to keep them in sync manually that's
> acceptable.
Re: Lock workspace to installation [message #1732405 is a reply to message #1732369] Mon, 16 May 2016 23:16 Go to previous messageGo to next message
Luke deGruchy is currently offline Luke deGruchyFriend
Messages: 4
Registered: May 2016
Junior Member
I actually managed to resolve this (after posting this topic) by doing the following:

Navigate > Open Setup > Installation

Then adding this preference:

    <annotation
        source="http://www.eclipse.org/oomph/setup/UserPreferences">
      <detail
          key="/instance/org.eclipse.ui.ide/WORKSPACE_NAME">
        <value>record</value>
      </detail>
    </annotation>


Replies to your replies below:

>> Before Oomph, I set up several different Eclipse binaries each
>> pointing to their own workspace and launch them as needed.
> How did you do that? Why doesn't that work with an installation created
with Oomph?

I did not create the installs with Oomph. I created them from tarballs as I normally do. When I pulled the latest Mars updates I started noticing this behaviour. I should have been clearer in my original post clarifying that I meant Oomph the preference syncing feature as opposed to the installer.

>> The reason for this is needing to install different versions of a
>> specific plugin, specifically, production and dev versions of that
>> plugin. So, I would launch eclipse1 linked to workspace 1 then
>> launch eclipse2 and it would load workspace2.
> What's in each workspace? If you wrote an project setup for what's in
the workspace, and created an installation for each project setup, it
would create a workspace that's associated with the installation as the
default, and you could click the check box so that you won't be prompted
again...

I'm wondering if this is due to the fact that my installation and workspace were not created through Oomph but through a binary that I installed a while ago. IIRC, it was the first very version of Mars.

Re: Lock workspace to installation [message #1732610 is a reply to message #1732405] Wed, 18 May 2016 13:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31032
Registered: July 2009
Senior Member
Luke,

Sorry, I don't really understand the nature of the problem. The
workspace name preference is not normally recorded because of course you
want each workspace to have a different name. Eclipse should properly
remember the most recently used workspace when you run it; I don't think
any recording is involved in that because it's not something you change
in the preferences dialog.

On 17.05.2016 01:16, Luke deGruchy wrote:
> I actually managed to resolve this (after posting this topic) by doing
> the following:
>
> Navigate > Open Setup > Installation
>
> Then adding this preference:
>
>
> <annotation
> source="http://www.eclipse.org/oomph/setup/UserPreferences">
> <detail
> key="/instance/org.eclipse.ui.ide/WORKSPACE_NAME">
> <value>record</value>
> </detail>
> </annotation>
>
>
> Replies to your replies below:
>
>>> Before Oomph, I set up several different Eclipse binaries each
>>> pointing to their own workspace and launch them as needed.
>> How did you do that? Why doesn't that work with an installation created
> with Oomph?
>
> I did not create the installs with Oomph. I created them from
> tarballs as I normally do. When I pulled the latest Mars updates I
> started noticing this behaviour. I should have been clearer in my
> original post clarifying that I meant Oomph the preference syncing
> feature as opposed to the installer.
>
>>> The reason for this is needing to install different versions of a
>>> specific plugin, specifically, production and dev versions of that
>>> plugin. So, I would launch eclipse1 linked to workspace 1 then
>>> launch eclipse2 and it would load workspace2.
>> What's in each workspace? If you wrote an project setup for what's in
> the workspace, and created an installation for each project setup, it
> would create a workspace that's associated with the installation as
> the default, and you could click the check box so that you won't be
> prompted again...
>
> I'm wondering if this is due to the fact that my installation and
> workspace were not created through Oomph but through a binary that I
> installed a while ago. IIRC, it was the first very version of Mars.
>
>
Re: Lock workspace to installation [message #1732754 is a reply to message #1732610] Fri, 20 May 2016 00:22 Go to previous messageGo to next message
Luke deGruchy is currently offline Luke deGruchyFriend
Messages: 4
Registered: May 2016
Junior Member
Am I correct in assuming the following, absent any modifications such as the one I made above?

* The old behaviour is each Eclipse installation remembers its own latest workspace due to the lack of cloud-based preferences.
* The new behaviour is each Eclipse installation uses the same cloud-based preferences therefore both installations share the same latest workspace.

If so, IMHO, there should be an easier way to either restore the old behaviour or more easily (perhaps I'm missing something obvious) opting out of cloud-based preferences altogether.

I don't mean to sound critical as I think this new approach solves a lot of problems with Eclipse-based preferences that have been irritants for so long. Much of my workflow has involved adapting to the old situations, such as exporting and importing preferences. I just got used to the old ways and am trying to adapt to the new ways.

> Sorry, I don't really understand the nature of the problem. The
workspace name preference is not normally recorded because of course you
want each workspace to have a different name. Eclipse should properly
remember the most recently used workspace when you run it; I don't think
any recording is involved in that because it's not something you change
in the preferences dialog.
Re: Lock workspace to installation [message #1732768 is a reply to message #1732754] Fri, 20 May 2016 06:30 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31032
Registered: July 2009
Senior Member
Luke,

Comments below.

On 20.05.2016 02:22, Luke deGruchy wrote:
> Am I correct in assuming the following, absent any modifications such
> as the one I made above?
>
> * The old behaviour is each Eclipse installation remembers its own
> latest workspace due to the lack of cloud-based preferences.
Yes, the installation has configuration-scoped preference in which these
are stored. They're stored in

<installation-folder>/configuration/.settings/org.eclipse.ui.ide.prefs

> * The new behaviour is each Eclipse installation uses the same
> cloud-based preferences therefore both installations share the same
> latest workspace.
That shouldn't be the case. It's been a year sense Mars released, but
I believe in older versions of Oomph we listened to changes in the
entire preference, but now we only listen to the workspace node of the
preference tree. So we should not be recording any configuration-scoped
preferences (which should be different for each installation).
>
> If so, IMHO, there should be an easier way to either restore the old
> behaviour or more easily (perhaps I'm missing something obvious)
> opting out of cloud-based preferences altogether.
Well, preference recording records into a file on the local file system
which you can can opt-in to store with your Eclipse account so you can
share them between machines. But the basic mechanism isn't cloud based.
>
> I don't mean to sound critical as I think this new approach solves a
> lot of problems with Eclipse-based preferences that have been
> irritants for so long.
Indeed.
> Much of my workflow has involved adapting to the old situations, such
> as exporting and importing preferences. I just got used to the old
> ways and am trying to adapt to the new ways.
Yes, many people did that, and then you end up having to edit that giant
blob of XML because it has things in it you really really don't want
applied to each workspace.

So with the new approach, you can use Navigate -> Open Setup -> Open
User. Here you can see what's all recorded (under the "User
Preferences" node) You can delete this not to forget about all recorded
preferences and you can disable recording and never use it again. Or
you can use the "Import Preferences" toobar button, point at the file
you've been importing manually, select which of those you want always
applied in every workspace. After that you don't need to do anything
manually ever again. Each new installation and each new workspace you
open with any installation will set those preferences as you wish them
to be.
>
>> Sorry, I don't really understand the nature of the problem. The
> workspace name preference is not normally recorded because of course
> you want each workspace to have a different name. Eclipse should
> properly remember the most recently used workspace when you run it; I
> don't think any recording is involved in that because it's not
> something you change in the preferences dialog.
>
Previous Topic:How to copy file to workspace
Next Topic:Code Style XML Documentation
Goto Forum:
  


Current Time: Sun Apr 05 06:22:02 GMT 2020

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

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

Back to the top