Hard to say what the problem is without being able to see your project setup model. To what catalog does it belong? Does
it contain a WorkspaceTask?

>
> Hmm, I don't even know, what a WorkspaceTask is. Where and how can I add it?
You don't need to because the Github.com catalog already contains it for you.

> What can be achieved using it?
The only non-internal purpose of it is to be able to refer to its automatically computed attributes, e.g.,
${workspace.location}.

> See here for my current state of the project setup: https://gist.github.com/jbuchberger/f9a1fd9ac44d58d44333
I don't think you should decalre the variables "install.root" and "workspace.location". They're predefined and will be
prompted by the installer.

Cheers
/Eike

...
So we've investigated this a little more and it's generally possible to write an absolute path directly into the
"location" attribute of the InstallationTask. The remaining problem is that the product catalogs all contain such an
InstallationTask already and that InstallationTaskImpl currently doesn't support overriding. We can implement overriding
for both the InstallationTask and the WorkspaceTask if you want. Please submit an enhancement request.

...
> OK, I can do that. Before that, I'd like to better understand, though,
> what exactly is bad about putting an "install.root" variable into the setup.
> Because, so far, that seemed good enough for me.

The main problem is that the installer may create a VariableTask with the same name in your user.setup and that would
override the one in your (product?) setup.

...
> Does that mean, a variable in the user.setup will always override the ones from product or project setups?
Yes, always. This way a user can influence the results of the other setup models.

<?xml version="1.0" encoding="UTF-8"?>
<base:StringToStringMapEntry
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:base="http://www.eclipse.org/oomph/base/1.0"
    key="/instance/org.eclipse.wst.server.core/runtimes">
  <value>ignore</value>
</base:StringToStringMapEntry>

Eike Stepper wrote on Fri, 24 July 2015 09:22

...
> Does that mean, a variable in the user.setup will always override the ones from product or project setups?
Yes, always. This way a user can influence the results of the other setup models.

Hmm, is there a simple way for a user to reset a specific change he did in his preferences?

Let's say, I preconfigured some server runtimes in the project setup preferences.
Now, imagine one of my follow developers accidentally messing it up in his user preferences.
How could I help him restore the orginal setup quickly?

Or can I protect him to some extent using annotations in project setup UserPreferences, so he doesn't shoot his own foot as easily?

<?xml version="1.0" encoding="UTF-8"?>
<base:StringToStringMapEntry
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:base="http://www.eclipse.org/oomph/base/1.0"
    key="/instance/org.eclipse.wst.server.core/runtimes">
  <value>ignore</value>
</base:StringToStringMapEntry>

Would this help?

Cheers
Jörg