| Re: [cdt-dev] [tm-dev] [cross-project-issues-dev] TM Terminal and RSE releases for Photon (was: Correct repo for CDT to be referring to) |
+1 for Tycho-1.2 after Photon from my POV._______________________________________________Whoever needs Java-1.7 support would use Terminal-Photon or older.If any consumers disagree please speak up now.Many thanks, Nick, for driving this!Cheers,MartinOn 13 Jun 2018, at 21:36, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:> b) building with the latest build deps (Tycho 1.2, jgit timestamps), but which loses support for JDK 7+1I was not happy making this change for Photon in the last week before RC4, but I am more than happy changing it going forward.Pydev has a nice bit on its install page that makes it clear which release is the last one you can use if you don't want to keep up with the platform -- a stretch goal could be to have this somewhere -- perhaps in an updated https://www.eclipse.org/tm/downloads.php which sort of has this info already but is quite out of date.Need to use older Eclipse/Java/Python
If you need to use an older version of Eclipse/Java/Python, below is the latest PyDev version to be used based on your requisites.
- Eclipse 4.5, Java 8: PyDev 5.2.0
- Eclipse 3.8, Java 7: PyDev 4.5.5
- Eclipse 3.x, Java 6: PyDev 2.8.2
- Python 2.5 or older: PyDev 5.5.0
_______________________________________________On Wed, 13 Jun 2018 at 18:59, Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:_______________________________________________On Wed, Jun 13, 2018 at 8:08 PM, Nick Boldt <nboldt@xxxxxxxxxx> wrote:It's minimal effort at the moment to maintain both tm.rse and tm.terminal as separate jobs. My new publisher and composite-site-generator jobs make it ever easier. So... I'm happy for now to keep the terminal building & publishing against Ye Olde Version, at least until something breaks.That said, Java 7 is EOL, and Tycho 0.23 isn't really supported any more, and I'd prefer to use jgit timestamps so we know 100% when a plugin was last built, based on which commit in git... so I'll let you guys decide which is worse:a) building with old stuff which could cause hidden issues, but is more backward compatible for JDK 7 support, orb) building with the latest build deps (Tycho 1.2, jgit timestamps), but which loses support for JDK 7I would strongly encourage using Tycho 1.2 for the fact that it publishes/resolves capabilities and there have been multiple issues we caught on platform side thanks to that. It also generates the newer more secure sha256 checksums and it's time to move away of the insecure md5.If we move to the latest, as Doug prefers (but Martin does not) then the first release of the post-Photon Simrel in 2018-09 could include this change... right in time for JDK 11's release. Seems a good time to drop JDK 7, no?So... CDT and TM users/adopters, or product builders who depend on CDT or TM... please speak up and break the tie here.NickOn Tue, Jun 12, 2018 at 2:23 PM, Doug Schaefer <dschaefer@xxxxxxxxxxxxxx> wrote:Thanks Martin, that helps explain how we got here.
But, given this is a meritocracy, downstream consumers who haven’t contributed upstream to help Nick with the effort don’t really have a say. Do what you think is best Nick.
I’ll speak up as the maintainer of the Eclipse C/C++ IDE as a consumer and I’d feel much safer if the Terminal was built with the latest Platform to ensure 100% the binary compatibility.
Doug.
From: tm-dev-bounces@xxxxxxxxxxx [mailto:tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Martin Oberhuber
Sent: Tuesday, June 12, 2018 1:57 PM
To: TM project developer discussions <tm-dev@xxxxxxxxxxx>
Cc: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: Re: [tm-dev] [cdt-dev] [cross-project-issues-dev] TM Terminal and RSE releases for Photon (was: Correct repo for CDT to be referring to)
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
On 12 Jun 2018, at 11:18, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Answers inline.
On Mon, 11 Jun 2018 at 23:51, Nick Boldt <nboldt@xxxxxxxxxx> wrote:
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?
[2] http://download.eclipse.org/tm/terminal/builds/development/nightly/
[3] http://git.eclipse.org/c/tm/org.eclipse.tm.terminal.git/tree/admin/pom-config.xml#n73
But, if we want to use the Photon-built bits in the TM or CDT contribution to the Simrel, I've added a new deployment step to the 4.8-based job [4], which will push bits here [5].
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.
[7] http://git.ec. At leastlipse.org/c/tm/org.eclipse.tm.terminal.git/tree/admin/pom-config.xml#n249
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
On Mon, Jun 11, 2018 at 11:39 AM, Doug Schaefer <dschaefer@xxxxxxxxxxxxxx> wrote:
+1. I trust you there. I don’t know the Terminal well enough to know whether the API changes in the deps would matter.
(BTW, removed cross-project as we’re getting a bit specific to TM).
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Nick Boldt
Sent: Monday, June 11, 2018 11:13 AM
To: TM project developer discussions <tm-dev@xxxxxxxxxxx>
Cc: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>; CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cross-project-issues-dev] [tm-dev] [cdt-dev] TM Terminal and RSE releases for Photon (was: Correct repo for CDT to be referring to)
Doug,
Do you agree we should respin TM against the latest Orbit and Photon deps? I'll assume so and try to find time today to get that built and pushed to the milestone site.
Nick
On Mon, Jun 11, 2018 at 10:16 AM, Doug Schaefer <dschaefer@xxxxxxxxxxxxxx> wrote:
CDT users use TM regularly, especially for Arduino and other embedded targets. Haven’t seen anything drastically broken so we haven’t done anything to it. I am a committer as well if a patch comes in. Other than that it’s in deep maintenance mode.
Doug.
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Nick Boldt
Sent: Monday, June 11, 2018 9:25 AM
To: TM project developer discussions <tm-dev@xxxxxxxxxxx>
Cc: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>; CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] [tm-dev] TM Terminal and RSE releases for Photon (was: Correct repo for CDT to be referring to)
I stepped in recently to do releng for tm.rse & update it to build against Photon (because JBoss Tools requires it) but as yet I haven't done anything for tm.terminal, as I believe CDT Doug's been running the show there (because CDT requires it).
If he's OK with me stepping in to help there too, I can find time this week to make sure there are new tm.terminal and tm.rse builds based on Photon.0.RC4. Can anyone on this list commit to smoke testing the builds? Other than "the tests pass in Jenkins" and "I can install everything from the update sites" I don't know how to verify the builds' contents are working as expected.
Nick
On Mon, Jun 11, 2018 at 9:06 AM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Ni Nick,
Thanks for looking into this. I (on behalf of CDT) am not publishing the TM builds, simply consuming them when I noticed the discrepancy. Are you running releng for TM at the moment, or is this a continuing case of TM lacking the devs it needs?
AFAICT, the correct TM is being published, but from an unstable URL, so end users are getting the right version.
Jonah
On Mon, 11 Jun 2018 at 13:49, Nick Boldt <nboldt@xxxxxxxxxx> wrote:
The nightly site contains something newer (2018/03/14) that the last milestone site (2018/03/12).
You can use p2 browser [1] to explore the sites [2] and pick an IU to investigate versions:
Given we're at RC4, it would probably be wise to release the 03/14 build to the milestone site.
I can cobble a job together to do the publishing, unless you already have something you're using to publish updates.
I notice the last tm.terminal build [3] was based on Photon.0.M6 so we should probably update that & rebuild it too to make sure it still works against Photon.RC4.
I suppose I should also do a TM.RSE release [4] this week too as the last build was back in March, also based on earlier Photon deps.
On Sat, Jun 9, 2018 at 6:13 PM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Hi TM folk,
I am doing a review of CDT's target platform for the 9.5 branch (in preparation for Photon release) and I came across a minor anomaly I wanted to resolve.
At the moment CDT uses a build from 2 days before what TM is contributing in the simrel.
I don't really want to have CDT point at a development/nightly build on the 9.5 branch. Is there any difference between the two. Does TM plan to publish a URL suitable for building against Photon?
Thanks,
Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
--
Nick Boldt
Principal Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
--
Nick Boldt
Principal Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
--
Nick Boldt
Principal Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
--
Nick Boldt
Principal Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
_______________________________________________
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 list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
_______________________________________________
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--Nick BoldtPrincipal Software Engineer, RHCSAProductization Lead :: JBoss Tools & Dev StudioIM: @nickboldt / @nboldt / http://nick.divbyzero.com
_______________________________________________
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
--Alexander KurtakovRed Hat Eclipse Team
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 list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
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
Nick Boldt
Principal Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com