|
|
|
|
|
Re: switching target platform version [message #1782222 is a reply to message #1782221] |
Tue, 20 February 2018 15:38 |
|
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:
<?xml version="1.0" encoding="UTF-8"?>
<setup:VariableTask
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"
name="eclipse.target.platform"
value="Photon"
storageURI="scope://Workspace">
<restriction
xsi:type="setup:Stream"
href="index:/org.eclipse.setup#//@projectCatalogs[name='org.eclipse']/@projects[name='platform']/@projects[name='runtime']/@streams[name='master']"/>
</setup:VariableTask>
You can copy this XML snippet directly to your Setup editor. Note that the variable override is restricted to the Master stream of the Platform Runtime project.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Re: switching target platform version [message #1782228 is a reply to message #1782223] |
Tue, 20 February 2018 18:54 |
|
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?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Re: switching target platform version [message #1782243 is a reply to message #1782239] |
Tue, 20 February 2018 20:02 |
Mario Jauvin Messages: 94 Registered: October 2015 |
Member |
|
|
Maybe the pertinent questions are:
- 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.
[Updated on: Tue, 20 February 2018 20:12] Report message to a moderator
|
|
|
Re: switching target platform version [message #1782261 is a reply to message #1782243] |
Wed, 21 February 2018 04:43 |
Ed Merks Messages: 33139 Registered: July 2009 |
Senior Member |
|
|
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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.05639 seconds