is there a way to perform setup tasks again to switch the target
platform version? For example, say that I chose "Luna" and now I want
to switch to "Mars" for the targlets; should I recreate the whole
workspace from scratch?

Am 28.08.2015 um 09:21 schrieb Lorenzo Bettini:
> Hi
>
> is there a way to perform setup tasks again to switch the target
> platform version? For example, say that I chose "Luna" and now I want
> to switch to "Mars" for the targlets; should I recreate the whole
> workspace from scratch?
No, you can do a normal manual perform and click "Show all variables". Then the TP variable should be shown and can be
changed.

On 28/08/2015 09:44, Eike Stepper wrote:
> Am 28.08.2015 um 09:21 schrieb Lorenzo Bettini:
>> Hi
>>
>> is there a way to perform setup tasks again to switch the target
>> platform version? For example, say that I chose "Luna" and now I want
>> to switch to "Mars" for the targlets; should I recreate the whole
>> workspace from scratch?
> No, you can do a normal manual perform and click "Show all variables".
> Then the TP variable should be shown and can be changed.

Hi

by "Manual perform" do you mean start the installer, not run perform
tasks from the workspace right? Because I don't see "show all
variables" when manually running perform tasks from the workspace.

I just ran oomph for the platform runtime. Now I click on the Help/Perform Setup Task, click back, select show all variables and I do not see a target platform variable. I also do not see the target platform variable when I tried to run for the platform UI and it fails (see Bugzilla 531358) and I click back on perform setup tasks command. Am I doing something wrong?

The Master streams in all Platform subprojects (except SWT) contains a VariableTask, which defines the value of the eclipse.target.platform variable to be either Photon or Oxygen (approx. 50/50). That means this variable already has got a value and is, hence, not prompted at all. I assume that's on purpose, but only the Platform.setup maintainer can confirm. I further guess that this predefined value should be Photon for the Master streams of all subprojects, but again, only the Platform.setup maintainer can confirm.

In the meantime you could work around the problem by adding the following setup task to your user setup:

This is extremely useful. On a related question, if I wish to debug an Oxygen Platform UI issue, would providing an override XML snippet with the correct XPath in the restriction element be sufficient to create a workspace with that configuration? What about the GIT branch that should be used for the Oxygen Platform UI source, would that be corrected with the eclipse.target.platform variable override? This is especially true since there are no tags in the oomph GIT repository, just a hidden property file (see Bugzilla 517228)?

It would clearly be better if the Platform.setup maintainer providedseparate Oomph streams for their Git branches, not just Master. Then you could just select the Oxygen stream and start working.

Not all setup tasks support overriding, just the ones that implement the SetupTask.getOverrideToken() in a meaningful way. VariableTask and GitCloneTask are among those. The override snippet that I provided just overrides the value of the "eclipse.target.platform" variable, and that usually just impacts TargletTasks, not GitCloneTasks. But you can try to copy their GitCloneTask to your user.setup and then adjust it to your needs. I imagine there might be other tasks in their setup that would need adjustment, e.g., their API Baseline configuration (which is apparently controlled through the "eclipse.api.baseline.target.platform" variable).

Regarding your last sentence, I don't get that at all. It ends with a question mark, but I see no question. How is Oomph's own Git repo, or the lack of tags therein, related to the Platform setup?

My last sentence is a poor attempt at asking/commenting that maybe the lack of tags in oomph repo makes it hard to support older platform once oomph has been updated to target Photon.

In most tools setups I have used, if a new version (say V2) is created, usually a tag in all repo that supported the previous version (say V1) is defined so as to enable the tool to be reset to the way it was when it last supported version V1.

How can I invoke oomph (eclipse installer) to create working workspaces for any of its projects targeted at Oxygen?

Are there commands that can create successfully the appropriate Oxygen workspace that was used by the various Eclipse projects during their development and maintenance of Oxygen?

Are there some conventions that must be adhered to by any projects in terms of tags, target platform specification/overriding?

I apologise if my questions appear weird. They do so because I do not know how things work internally. What I am looking for is a way to open any projects targeted at Oxygen regardless of what version is currently being developed. I am assuming this exists because it is necessary so as to permit the various project teams to support previous versions and because this is usually not difficult to do with some simple conventions.

As was noted in another Topic you said that some photon support was necessary in the platform UI setup (failing on a org.apache.batik.i18n requirement). Since the platform.ui setup was configured for Oxygen I assumed that the dependency on the Photon requirements introduced by something in oomph and not in the platform.ui setup. Again my apologies if my assumptions are incorrect.

The projects themselves must support a setup description for older versions of their code. And there are of course two issues involved. Which versions of which tools are actually installed in the IDE and which versions of which features and bundles are in the target platform. Most tools can work with older versions in the target platform so it's not necessary to develop against Oxygen with an Oxygen IDE. To support such a thing a project generally creates a maintenance branch in their Git clone, and defines a Stream in the Project Setup with a name that corresponds to that named branch in their clone. In that stream they would define the variables necessary, for example, to select Oxygen as the eclipse.target. platform, and the would need to ensure that all their targlet tasks properly support a named repository list for resolving their requirements against Oxygen repositories containing Oxygen versions of those requirements.

The problem with the platform's setups is that their code in the master branch must have Photon repos listed to resolve all their requirements, but they've left their setup description so that it only tries to resolve Oxygen which is no longer correct/sufficient for how the master branch has evolved. If they maintained this properly they'd have a Stream corresponding to their Oxygen maintenance stream, and that would use the Oxygen eclipse.target.platform value, while the master branch would use Photon and they'd have named Repository lists that properly referred to Photon repositories. Nothing need be done in Oomph itself to fix this and nothing can be done in Oomph to address this. It must be the Project setup authors who do this; they have the commit rights to their own setups and I do not.