| Re: [cdt-dev] CDT Helios SR1 available |
|
Hi Doug, As I tried to update to SR1, I encounter major problems on updating (actually not CDT but the rest of all eclipse and plugins). So, after trying over almost the whole weekend now with not much success, I'm ready for a rant on Eclipse, P2, quality of top projects and the versioning. I just don't know, where to do it, that it reaches the right persons. Partly, this involves also CDT, as you also use the versioning scheme using <major>.<minor>.<patchlevel>.v<datetimestamp>. Currently, after donwloading the Eclipse SR1 classic (because updating did not work), I'm still facing Modeling Tools. As a longterm Eclipse/CDT user (since about 2002), I was actually impressed by the features it got over the time. But the worst thing that I ever encountered was the introduction of P2. Before that, it was easy to pick up a zip file, and extract it into the eclipse folder. Now, most only provide update sites to download, or just links to update sites to use P2. But as you can see from the log below, it is just a mess, and can not even pick the latest version to install. Even worse, there are three versions to choose from, with different versions. What is so hard for P2 to choose the latest. What is the reason to have a download zip file of an update site, which is 1.1.1v201009150234 and then provide a 1.1.1.v201009150438 over the UpdateManager, and P2 can not decide to use the latest? Do the Eclipse Developers, the teams of like CDT or Platform or MDT or ... actually try out such scenarios? Do they never encounter such strange things? Why is it just the user getting these problems? Well, when we make SW releases, we just use a <major>.<minor>.<bugfix> version, and while in integration phase, we only use a fourth number to indicate our intergation phase. But the final result will be a number like 1.2.0. And that is _the_ release, there is no timestamp except internally, but it is not part of the release version, nor is it used for installation to distinguish a different version. And what we also never do is, to rely on a feature that is not very well tested out, and P2 looks very much like such a feature. What is going on in Eclipse? Why is it that complicated? What is up with the quality of Eclipse releases? Doug, you as the CDT project lead maybe have good contacts to the Eclipse teams, and maybe can forward that to the right persons. But, when I think about this lost weekend, and if I think about my colleagues that would encounter that, we probably would very soon look for something else to work with. For this weekend, I'm pretty much pissed of, since I got nothing done with a Helios SR1 release! Here is a log from the Install Dialog: Your original request has been modified.
"EMF Compare" is already installed, so an update will be performed instead.
Cannot complete the install because of a conflicting dependency.
Software being installed: EMF Compare 1.1.1.v201009150438 (org.eclipse.emf.compare.feature.group 1.1.1.v201009150438)
Software currently installed: EMF Compare All plugins 1.1.1.v201009150234 (org.eclipse.emf.compare.all.feature.group 1.1.1.v201009150234)
Only one of the following can be installed at once:
EMF Compare UI 1.1.0.v201006150400 (org.eclipse.emf.compare.ui 1.1.0.v201006150400)
EMF Compare UI 1.1.1.v201009150438 (org.eclipse.emf.compare.ui 1.1.1.v201009150438)
EMF Compare UI 1.1.1.v201009150234 (org.eclipse.emf.compare.ui 1.1.1.v201009150234)
Cannot satisfy dependency:
From: EMF Compare All plugins 1.1.1.v201009150234 (org.eclipse.emf.compare.all.feature.group 1.1.1.v201009150234)
To: org.eclipse.emf.compare.sdk.feature.group [1.1.1.v201009150234]
Cannot satisfy dependency:
From: EMF Compare 1.1.1.v201009150234 (org.eclipse.emf.compare.feature.group 1.1.1.v201009150234)
To: org.eclipse.emf.compare.ui [1.1.1.v201009150234]
Cannot satisfy dependency:
From: EMF Compare 1.1.1.v201009150438 (org.eclipse.emf.compare.feature.group 1.1.1.v201009150438)
To: org.eclipse.emf.compare.ui [1.1.1.v201009150438]
Cannot satisfy dependency:
From: EMF Compare SDK 1.1.1.v201009150234 (org.eclipse.emf.compare.sdk.feature.group 1.1.1.v201009150234)
To: org.eclipse.emf.compare.feature.group [1.1.1.v201009150234]
Regards, Henning Am 25/09/2010 02:49, schrieb Doug Schaefer: BTW, Huge thanks to Vivian for getting this release out! On Fri, Sep 24, 2010 at 8:46 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:Thanks Vivian, do we need to push this build up to the CDT update site? On Fri, Sep 24, 2010 at 2:01 PM, Vivian Kong <vivkong@xxxxxxxxxx> wrote:CDT Helios SR1 is now available on http://download.eclipse.org/tools/cdt/releases/helios However, there is a problem installing GDB Hardware Debugging (org.eclipse.cdt.debug.gdbjtag) feature in the SR1 build (Bug 326176). This does not affect the CPP EPP package or Helios update site as GDB Hardware Debugging is not included by them. The problem has been fix. To install GDB Hardware Debugging feature, please use the latest build available here: http://download.eclipse.org/tools/cdt/builds/7.0.1/I.I201009241320/index.html Regards, Vivian Kong IBM Eclipse CDT IBM Canada Toronto Lab _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev |