Hi Jonah, Nick, all -
Some historical notes on why things are as they are with the terminal:
- The master build which we release is built on the oldest possible JDK and Eclipse. This is to guarantee it can run on anything from that oldest JDK / Eclipse. Especially the Eclipse 3.8 compatibility was important for some downstream consumers for a long time. I don't know if that is still the case ; but, as long as we don't need any API / Features from newer Platform or JDK, there was never a need to build against newer Platform / JDK. Thanks to binary compatibility it is expected to run. And we do basic validation that it runs with the validation jobs.
- In addition to that, we do want to be source compatible as well (which is a different thing than binary compatibility). Therefore we also have one build job building against Photon / latest Orbit. This job helped us about 1-2 times per year remove some old API usage that was removed in newer Eclipse. So far, we always found an API alternative that worked in both old and new Eclipse.
- Regarding the RSE cyclic dependeny: Terminal is designed to have minimal dependencies, so it should build first. I don't quite remember why Terminal would depend on RSE, perhaps it's an obsolete component that could be removed. But even if it's not removed: Terminal only needs RSE APIs and certainly no recent RSE code changes. So even if we build against a released RSE from 5 years ago it should work. There is no need whatsoever for Terminal to build against newest RSE, so that's where the dependency should be broken IMO.
Nick, when you say you don't think the current mode of operation is wise, I'm sure you have your reasons. And if Terminal were under active development and would use newer Platform features, I'd agree we need to move the master build to Photon. I just never saw any reason for changing things from the way they are today - I found it a good thing to support older versions as long as it doesn't hurt active development.
If you (or somebody else in the Community) finds the current mode of operation hurting your development more than you see benefit in supporting old versions, feel free to discuss here and change things. I don't know who the current consumers are, but I guess they'd speak up if they find themselves broken. I'd just recommend making such a change at the beginning of a new release cycle, and not in the release candidate phase.
HTH, Martin
Answers inline. After more digging it seems that the TM.terminal bits built from master [1], published to the dev/nightly site [2], are built against Eclipse Mars [3], not Photon.
I don't think this is wise, but I bet there's a technical reason (like guaranteeing backward compatibility for JDK 7?) so I'm not quite ready to just change this blindly. WDYT?
Should we use the Photon-stack based build bits instead?
Martin Oberhuber has recently requested that this remains built with Mars/JDK 7, so no, we should not change at the moment. The terminal-master-4.8 is supposed to be a validation only job.
Also worthy of note:
tm.terminal depends on CDT. The default master build uses 8.8.1 [6]; the Photon profile uses 9.4 [7].
Is it bad to be shipping something destined to run with 9.x when we're building it against 8.x? Feels bad to me, but again, perhaps there's a reason for this ?
IIRC while CDT as a whole had a major version change, the individual plug-ins in question here, cdt native, did not. The o.e.cdt.native.serial bundle was 1.0.0 in CDT 8.8.1, and it is now 1.1.0 in CDT 9.5. So it is ok.
Finally, I discovered that the tm.terminal build also depends on tm.rse [8], whose build in turn also depends on tm.terminal [9]. This circular build-time dependency is worrisome... and should be broken. I honestly don't know which project to build first in order.
We could merge the builds, move stuff around, etc. Again, WDYT?
Yes, that is a good idea. This is what Doug was considering doing, but because you stepped in a few months ago and got the TM builds working again, and because of a general lack of contributions, the idea was abandoned. Doug can probably comment more.
[8] org.eclipse.tm.terminal.view.ui.rse depends on org.eclipse.rse.core, org.eclipse.rse.subsystems.files.core, org.eclipse.rse.ui
[9] org.eclipse.rse.terminals.ui depends on org.eclipse.tm.terminal.control
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________tm-dev mailing listtm-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/tm-dev
|