Community
Participate
Working Groups
Build Identifier: emf-xsd-SDK-M201109050916 I downloaded emf-xsd-SDK-M201109050916.zip It has the following plugins: org.eclipse.emf.cheatsheets_2.5.0.v20100521-1846.jar org.eclipse.emf.ecore.change.edit_2.5.0.v20100521-1846.jar org.eclipse.emf.exporter_2.6.0.v20100521-1846.jar org.eclipse.emf.importer.ecore_2.6.0.v20100521-1846.jar org.eclipse.emf.importer.java_2.6.0.v20100521-1846.jar org.eclipse.emf.importer.rose_2.6.0.v20100521-1846.jar org.eclipse.emf.importer_2.6.0.v20100521-1846.jar It appears that at some point in time these plugins were updated to use eclipse require eclipse 3.7.0 but the plugin versions of these plugins were not updated. This caused a very hard to find but that only occurred in some environments. Because the plugin versions were the same but the dependencies were different it was difficult to troubleshoot. Please look at your change history and see when the manifest versions were updated to 3.7.0 and update the dependencies. I am using WTP 3.3.1 on eclipse 3.7.1. According to: http://download.eclipse.org/webtools/downloads/drops/R3.3.1/R-3.3.1-20110915193224/ emf-xsd-SDK-M201109050916.zip is the version I should be using. Reproducible: Always
Sorry, this is a side effect of our build generating the version ranges based on what it's built against. It's simply beyond our team's capacity to start maintain the version ranges manually (which leads to other problems where you depend on something new but don't change the range). It's not clear what problems this issue causes. After all, these bundles all depend on other EMF bundles that are incremented along with their version range increasing. And of course the build identifier does increase the version of these bundles themselves with each build. I'll mark this as won't fix because I just don't see how we could manage this differently and I don't see what significant problem it causes others.
These plugins even had the same timestamp (just different versions). Do you have any idea how that could happen?
(In reply to comment #2) > These plugins even had the same timestamp (just different versions). Do you > have any idea how that could happen? Let me fix that. These plugins have the same versions (down to the timestamp), but have different manifest file contents (different version dependencies). Do you have any idea how that could happen?
The basic Eclipse premise that two plugins with the same id and version are identical is broken in this case and is serious. In this case, we are not able to set up Eclipse 3.6 based target platforms for PDE using a development environment that is Eclipse 3.7.1 IDE with emf-xsd-SDK-M201109050916.
I'm still confused. EMF 2.7 won't work with Eclipse 3.6, you'd need EMF 2.6 for that. Kenn, should the build version change at some point? I.e., when we build against an incremented platform?
Let me explain a bit more. We are developing on eclipse so we have a host and target eclipse. My host is eclipse 3.7.1 but my target is eclipse 3.6. Now here is they key. I define my target platform using an eclipse update site. One of the plugins required by the target is org.eclipse.emf.importer.ecore_2.6.0.v20100521-1846.jar. Now what happens is that eclipse PDE knows I need org.eclipse.emf.importer.ecore_2.6.0.v20100521-1846.jar. It finds org.eclipse.emf.importer.ecore_2.6.0.v20100521-1846.jar in my HOST PDE so it doesn't bother to download it from the UPDATE SITE. Both the update site and the host have the EXACT same version (org.eclipse.emf.importer.ecore_2.6.0.v20100521-1846.jar), BUT the update site has a manifest with dependencies on eclipse 3.6.0 and the my host has the version with the manifest depending on eclipse 3.7.0. Eclipse PDE thinks they are the same plugin (because the names and versions are exactly the same), but they have different manifest plugin versions. This doesn't happen anywhere in eclipse but in the plugins listed above. So my question is, how could this happen? The plugin content changed but the version remained the same.
(In reply to comment #5) > I'm still confused. EMF 2.7 won't work with Eclipse 3.6, you'd need EMF 2.6 > for that. > > Kenn, should the build version change at some point? I.e., when we build > against an incremented platform? The qualifier portion of the version (i.e., the "fourth part") should be different with each build.
Its exactly the same. I know it should be different, but the files names are 100% identical.
Note, I got this zip from eclipse download (not some personal site). As I mentioned it came from the link on the WTP page --> http://download.eclipse.org/webtools/downloads/drops/R3.3.1/R-3.3.1-20110915193224/
Plus, why would a zip with this timestamp emf-xsd-SDK-M201109050916.zip have plugins from 2010?
(In reply to comment #10) > Plus, why would a zip with this timestamp emf-xsd-SDK-M201109050916.zip have > plugins from 2010? The reason is that one of two version qualifiers is chosen for a given bundle - either the commit timestamp (i.e., last time something was changed in the bundle) or the build timestamp (in cases where there is a delta in the dependencies). For some reason, these bundles ended up with the commit timestamp instead of the build timestamp; I'll need to investigate why. In the meantime, I wonder whether it's possible to install the bundles if you disable the option to look for dependencies in other repositories?
I am not sure there is that option on the target platform UI. I think they came from the host eclipse. Either way, would you say this is a bug and should be reopened? Not changing eclipse versions is pretty damaging to eclipse products.
I've touched all the MANIFEST.MF and feature.xml to change their timestamps for both 2.8 and 2.7 maintenance. That should produce updated build qualifiers for both streams with the next build.
It turns out that I was mistaken - Buckminster does not automatically use the build timestamp in cases where dependency versions have changed. I will post builds with updated version qualifiers on Monday.
Thanks for the help!
The changes are available in builds.
Should this fix have made it into the last Juno milestone? Because I still see org.eclipse.emf.ecore.change.edit_2.5.0.v20100521-1846.jar there, just this time around with a minimum EMF version of 2.8.0. Additionally, judging by the sources, it seems like you didn't actually increment the version of those plugins as http://wiki.eclipse.org/Version_Numbering suggests for a manifest change. Wouldn't it be much simpler and cleaner to update all bundle versions consistenty on a minor version change? Factually, without dependency ranges in the manifests, they're only compatible within that release anyway...
