Community
Participate
Working Groups
Build Identifier: I20110613-1736 The class PlatformLogWriter has been moved from core.runtime to equinox.common. But the equinox.common plugin does not change the version number (only qualifier). Reproducible: Always Steps to Reproduce: 1. Update console application with eclipse plugins from 3.6 to 3.7 by hand. 2. Do not update equinox.common, but eclipse.core.runtime. 3. ClassNotFoundException PlatformLogWriter
It's strange that this didn't show up in version number tool. org.eclipse.equinox.common version number was 3.6 in Helios, and 3.6 in Indigo. It certainly had code changes (although no API changes). It should have been 3.6.100 in Indigo.
John is correct, this bundles version should have been incremented to 3.6.100 in Indigo. So what do we do now? - increment to 3.6.100 in Indigo SR2 and 3.6.200 in Juno (assuming we will have or had changes in juno to the equinox common bundle)?
I am going to wait until after M2, but I have a patch ready that does this: - equinox.common bumped up to 3.6.100 - core.runtime dependency on equinox.common changed to [3.6.100,4.0) This properly expresses the dependency on PlatformLogWriter which moved to common. Since this is not API it only involves changing the service segment. I didn't think about Indigo SR2 but it doesn't strike me as a pressing problem that has to be fixed in maintenance. If we did, your suggestion makes sense, so we have some "room" for future Helios maintenance that doesn't collide bundle versions with Indigo maintenance.
(In reply to comment #3) > I am going to wait until after M2, but I have a patch ready that does this: > > - equinox.common bumped up to 3.6.100 > - core.runtime dependency on equinox.common changed to [3.6.100,4.0) > > This properly expresses the dependency on PlatformLogWriter which moved to > common. Since this is not API it only involves changing the service segment. I agree, I did not catch that the runtime range for equinox.common should change, be sure to update the version of the core.runtime bundle. ;-) > > I didn't think about Indigo SR2 but it doesn't strike me as a pressing problem > that has to be fixed in maintenance. If we did, your suggestion makes sense, so > we have some "room" for future Helios maintenance that doesn't collide bundle > versions with Indigo maintenance. I agree, not a pressing issue for SR2.
http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=6dd4ea58c507cecd07ec34c47ac627adc1d50aef http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=c82f6b1ad91a7ddad6feb1bf12b096a6de8738f9
I'm still confused ... probably just "too early" yet? I tried starting off with eclipse-SDK for Juno M2, and then loading, from git, the 'master' of .../gitroot/platform/eclipse.platform.runtime.git. Error in org.eclipse.core.runtime, due to invalid constraints org.eclipse.equinox.common;bundle-version="[3.6.100,4.0.0)" So, fine, I thought, I'll just update to latest I builds ... but, no go. I guess 3.6.100 is not in an I build yet? So, I'd have to load the source for all of equinox? Seems to me, this "mismatch" wouldn't happen if the platform truly "built on top" of equinox ... then the change in version range would have to wait until that version was available in a build. As it is, rather than load equinox source, I'll just change 3.6.100 back to 3.6.0 in my workspace, for the moment ... after spending 90 minutes trying to figure it all out :) ... Just letting you know impacts ... hard to set up simplest dev env. (And, hoping you'll explain, if I'm seeing something all wrong).
(In reply to comment #6) > I'm still confused ... probably just "too early" yet? > > I tried starting off with eclipse-SDK for Juno M2, and then loading, from git, > the 'master' of .../gitroot/platform/eclipse.platform.runtime.git. > > Error in org.eclipse.core.runtime, due to invalid constraints > org.eclipse.equinox.common;bundle-version="[3.6.100,4.0.0)" > > So, fine, I thought, I'll just update to latest I builds ... but, no go. I > guess 3.6.100 is not in an I build yet? So, I'd have to load the source for all > of equinox? > > Seems to me, this "mismatch" wouldn't happen if the platform truly "built on > top" of equinox ... then the change in version range would have to wait until > that version was available in a build. As it is, rather than load equinox > source, I'll just change 3.6.100 back to 3.6.0 in my workspace, for the moment > ... after spending 90 minutes trying to figure it all out :) ... Just letting > you know impacts ... hard to set up simplest dev env. (And, hoping you'll > explain, if I'm seeing something all wrong). Sorry for the headaches this has caused you David! Both changes (to equinox.common and core.runtime) are not in the latest I-Build. It is true that if the platform truly built on top of equinox then this problem may have been lessened for you. But there are plenty of other inter bundle relationships in the platform that could result in similar failures if we need to change versions and ranges in this way. For example, a bundle in PDE may require something new in JDT which has not been included in an I-Build yet. The PDE and JDT teams must coordinate the version changes to get a successful N-Build, but I would not want to force PDE to wait upto a week before updating their ranges in order to start using the new functionality.
Sorry, I should have at least announced this on the core-dev mailing list. As Tom said, these kinds of co-dependent changes happen fairly frequently but we should at least warn people when they do. The root of the bug is that core.runtime rely does require the latest equinox.common, because it uses an internal class what was added in the newer version. So, although org.eclipse.core.runtime would allow you to use the Equinox from Eclipse 3.6, in practice that would result in errors at runtime (as described in comment #0). So, the version range change is enforcing a real underlying dependency in the code here.
Thanks for the explanations and sympathies :) It would be interesting to see what a notification to dev list would look like. In the good 'ol days of cvs, it's fairly straight forward "if you load x project from runtime from head, you need to also load y project from equinox from head". Now ... I guess ... it will be more like "if you have master of eclipse.platform.runtime in your workspace, you will have to also clone the ?equinox? git repo and load ?all? its projects from ?master?
(In reply to comment #9) > Thanks for the explanations and sympathies :) > > It would be interesting to see what a notification to dev list would look like. > In the good 'ol days of cvs, it's fairly straight forward "if you load x > project from runtime from head, you need to also load y project from equinox > from head". > > Now ... I guess ... it will be more like "if you have master of > eclipse.platform.runtime in your workspace, you will have to also clone the > ?equinox? git repo and load ?all? its projects from ?master? Well, it's the same thing in the end. If you have org.eclipse.core.runtime from master in your workspace, then you need org.eclipse.equinox.common from master in your workspace... The implementation detail of how that gets into your workspace does change though ;) I don't think you would need every project from the repo in your workspace. I typically have all the repositories that I use cloned, but only bring things into my workspace occasionally if I want to browse source or edit them.
