Bugzilla – Full Text Bug Listing
| Summary: | some surprising differences between RC4 and RC5 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | David Williams <david_williams> | ||||
| Component: | Packager | Assignee: | Project Inbox <epp.packager-inbox> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | john.arthorne, mknauer, tjwatson | ||||
| Version: | 1.4.0 | ||||||
| Target Milestone: | 1.4.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
So, here's a longer explanation ... anyone else seeing things like this? Anyone else concerned? :) There's basically 4 types of unexpected changes (buried in comments below). 1. I haven't looked yet how these "differ" ... but that's not right, for same version to ever have different "content" ... maybe just a space or tab, some how? Files indigoRC4/eclipseJEE/plugins/javax.transaction_1.1.1.v201105210645.jar and indigoRC5/eclipseJEE/plugins/javax.transaction_1.1.1.v201105210645.jar differ 2. These seemed to be _in_ RC4, but _not in_ RC5? Only in indigoRC4/eclipseJEE/plugins: org.apache.lucene.highlighter_2.9.1.v20100421-0704.jar Only in indigoRC4/eclipseJEE/plugins: org.apache.lucene.memory_2.9.1.v20100421-0704.jar Only in indigoRC4/eclipseJEE/plugins: org.apache.lucene.misc_2.9.1.v20100421-0704.jar Only in indigoRC4/eclipseJEE/plugins: org.apache.lucene.queries_2.9.1.v20100421-0704.jar Only in indigoRC4/eclipseJEE/plugins: org.apache.lucene.snowball_2.9.1.v20100421-0704.jar Only in indigoRC4/eclipseJEE/plugins: org.apache.lucene.spellchecker_2.9.1.v20100421-0704.jar 3. I've surprised some of these bundles changed ... maybe as a result of changing org.eclipse.osgi? But was unexpected. Only in indigoRC4/eclipseJEE/plugins: org.eclipse.cvs_1.1.100.v201106030909.jar Only in indigoRC5/eclipseJEE/plugins: org.eclipse.cvs_1.1.100.v201106131736.jar Only in indigoRC4/eclipseJEE/plugins: org.eclipse.help.base_3.6.0.v201106030909.jar Only in indigoRC5/eclipseJEE/plugins: org.eclipse.help.base_3.6.0.v201106131736.jar Only in indigoRC4/eclipseJEE/plugins: org.eclipse.jdt_3.7.0.v201106030909.jar Only in indigoRC5/eclipseJEE/plugins: org.eclipse.jdt_3.7.0.v201106131736.jar [The expected one to change] Only in indigoRC4/eclipseJEE/plugins: org.eclipse.osgi_3.7.0.v20110524.jar Only in indigoRC5/eclipseJEE/plugins: org.eclipse.osgi_3.7.0.v20110613.jar Only in indigoRC4/eclipseJEE/plugins: org.eclipse.pde_3.6.100.v201106030909.jar Only in indigoRC5/eclipseJEE/plugins: org.eclipse.pde_3.6.100.v201106131736.jar Only in indigoRC4/eclipseJEE/plugins: org.eclipse.platform_3.7.0.v201106030909 Only in indigoRC5/eclipseJEE/plugins: org.eclipse.platform_3.7.0.v201106131736 Only in indigoRC4/eclipseJEE/plugins: org.eclipse.rcp_3.7.0.v201106030909.jar Only in indigoRC5/eclipseJEE/plugins: org.eclipse.rcp_3.7.0.v201106131736.jar 4. Odd, these changed from directory? to jar file? Only in indigoRC4/eclipseJEE/plugins: org.eclipse.wtp.epp.package.capabilities_1.3.0.v201005102000 Only in indigoRC5/eclipseJEE/plugins: org.eclipse.wtp.epp.package.capabilities_1.3.0.v201005102000.jar Only in indigoRC4/eclipseJEE/plugins: org.eclipse.wtp.epp.package.jee.intro_1.3.0.v201006142040 Only in indigoRC5/eclipseJEE/plugins: org.eclipse.wtp.epp.package.jee.intro_1.3.0.v201006142040.jar
>
> 1. I haven't looked yet how these "differ" ... but that's not right, for
> same version to ever have different "content" ... maybe just a space or tab,
> some how?
>
> Files indigoRC4/eclipseJEE/plugins/javax.transaction_1.1.1.v201105210645.jar
> and indigoRC5/eclipseJEE/plugins/javax.transaction_1.1.1.v201105210645.jar
> differ
>
I can confirm this is inconsequential. They differ only in their signature file:
Binary files rc4javaxt//META-INF/ECLIPSEF.RSA and rc5javaxt//META-INF/ECLIPSEF.RSA differ
Not sure why that would be .... but, wouldn't matter, as long as valid signature (which, it is, as far as I can see).
3 items to go :)
>
> 3. I've surprised some of these bundles changed ... maybe as a result of
> changing org.eclipse.osgi? But was unexpected.
>
> Only in indigoRC4/eclipseJEE/plugins: org.eclipse.cvs_1.1.100.v201106030909.jar
> Only in indigoRC5/eclipseJEE/plugins: org.eclipse.cvs_1.1.100.v201106131736.jar
>
Kim has said these are just the "branding plugins" for these components, and by design, they change qualifier value every build.
2 items to go. :)
>
> 2. These seemed to be _in_ RC4, but _not in_ RC5?
>
> Only in indigoRC4/eclipseJEE/plugins:
> org.apache.lucene.highlighter_2.9.1.v20100421-0704.jar
> Only in indigoRC4/eclipseJEE/plugins:
> org.apache.lucene.memory_2.9.1.v20100421-0704.jar
> Only in indigoRC4/eclipseJEE/plugins:
> org.apache.lucene.misc_2.9.1.v20100421-0704.jar
> Only in indigoRC4/eclipseJEE/plugins:
> org.apache.lucene.queries_2.9.1.v20100421-0704.jar
> Only in indigoRC4/eclipseJEE/plugins:
> org.apache.lucene.snowball_2.9.1.v20100421-0704.jar
> Only in indigoRC4/eclipseJEE/plugins:
> org.apache.lucene.spellchecker_2.9.1.v20100421-0704.jar
>
I looked around specifically for the "spellchecker" bundle. And, I see it is contributed to common repo by Gyrex. So, that, that Gyrex was not in the repository when this package was built, would explain why they are not in RC5.
I have to admit, I don't know what function is lost or gained by having these bundles in JEE (they were not in Helios SR2) but ... seems it'd be important to "match" what ever was in the released version of the common repo. Someone somewhere must have an optional dependency on it, and according to current behavior of publishers and p2, optional things are installed if they are in the repository.
I suspect this would be a reason to respin the JEE and JS packages with "final repo" ... unless someone else thinks differently?
>
> 4. Odd, these changed from directory? to jar file?
>
> Only in indigoRC4/eclipseJEE/plugins:
> org.eclipse.wtp.epp.package.capabilities_1.3.0.v201005102000
> Only in indigoRC5/eclipseJEE/plugins:
> org.eclipse.wtp.epp.package.capabilities_1.3.0.v201005102000.jar
>
> Only in indigoRC4/eclipseJEE/plugins:
> org.eclipse.wtp.epp.package.jee.intro_1.3.0.v201006142040
> Only in indigoRC5/eclipseJEE/plugins:
> org.eclipse.wtp.epp.package.jee.intro_1.3.0.v201006142040.jar
I can not find any differences in behavior due to this difference (though, is mysterious). Our "intro" still works, and the capabilities work as well as they ever did.
I think "intro" maybe used to have to be a directory, so our custom splash screen could be displayed on startup ... but, doesn't seem it was displayed in RC4 either .... so, I'm thinking maybe we decided not to use that custom splash screen anyway?
(In reply to comment #4) > I suspect this would be a reason to respin the JEE and JS packages with "final > repo" ... unless someone else thinks differently? I need to look into this first... so far, I don't have an opinion apart from the fact that I didn't like the idea of rebuilding again. But as I wrote, I need to understand what IU has what kind of dependency on it. (In reply to comment #5) > I think "intro" maybe used to have to be a directory, so our custom splash > screen could be displayed on startup ... but, doesn't seem it was displayed in > RC4 either .... so, I'm thinking maybe we decided not to use that custom splash > screen anyway? I hope that is not a regression, but it looks suspicious. Bug 278154 covers your old splash screen problem, maybe something that we can work on for Juno next year because would be a major change (i.e. rewriting many things that o.e.plaform provides) so that's an different issue. In both cases, RC4 *and* RC5, the p2 repository has been build on the same machine, with the same JVM and the same version of Buckminster. In both cases it was the p2 director application from the latest S-3.7RC4-201106030909 platform build. And your feature, org.eclipse.epp.package.jee.feature, that includes these bundles (and defines them without unpack="false"), did not change since 2011-04-21. (In reply to comment #4) > > 2. These seemed to be _in_ RC4, but _not in_ RC5? org.apache.lucene.highlighter_2.9.1.v20100421-0704.jar org.apache.lucene.memory_2.9.1.v20100421-0704.jar org.apache.lucene.misc_2.9.1.v20100421-0704.jar org.apache.lucene.queries_2.9.1.v20100421-0704.jar org.apache.lucene.snowball_2.9.1.v20100421-0704.jar org.apache.lucene.spellchecker_2.9.1.v20100421-0704.jar See Gunnar's comment: bug 349267 comment #57 I checked this against the RC4 metadata and can confirm that it is only the org.eclipse.gyrex.features.dependencies.solr.feature.group that groups these bundles that are used in org.apache.solr.core. In addition to that the bundle id='org.apache.lucene' version='2.9.1.v201101211721' defines the optional dependencies that are the reason why these bundles found their way into all RC4 packages. The IU with id='org.apache.lucene' is available with singleton='false' in two versions in RC4: version='1.9.1.v201101211617' (staging repository) and version='2.9.1.v201101211721' (Eclipse Platform repository). The 2.9.1 version of the bundle is used by org.eclipse.help.feature.group org.eclipse.help.base org.eclipse.equinox.transforms.xslt (didn't know that's in Indigo) org.eclipse.m2e.maven.indexer org.eclipse.gyrex.features.dependencies.solr.feature.group org.apache.lucene.core - required by help, solr, gyrex org.apache.solr.core org.apache.solr.servlet This list of dependencies tells me that we could omit a rebuild of the EPP packages, because I don't expect changes in functionality but in size. But I'd like to hear other opinions... What happens with SR1? If a user updates a package and this update itself contains an update of e.g. org.eclipse.help.feature.group, he will get these optional bundles with SR1... I just wanted to mention this as additional consequence if we would leave the packages as they are at the moment. > > This list of dependencies tells me that we could omit a rebuild of the EPP > packages, because I don't expect changes in functionality but in size. But I'd > like to hear other opinions... > Yeah, I'm less keen on it now we've learned why they are included (because someone prereqs an umbrella bundle, not because some would make use of them, if they were installed). > What happens with SR1? If a user updates a package and this update itself > contains an update of e.g. org.eclipse.help.feature.group, he will get these > optional bundles with SR1... I just wanted to mention this as additional > consequence if we would leave the packages as they are at the moment. Perhaps we could even figure out a way to avoid that .. to trim them out, somehow ... if deemed important enough. But, not even sure it would be. (In reply to comment #6) > (In reply to comment #5) > > I think "intro" maybe used to have to be a directory, so our custom splash > > screen could be displayed on startup ... but, doesn't seem it was displayed in > > RC4 either .... so, I'm thinking maybe we decided not to use that custom splash > > screen anyway? I don't have a definitive answer, but the same IUs id='org.eclipse.wtp.epp.package.jee.intro' and id='org.eclipse.wtp.epp.package.capabilities' are taken from the common repository by the EPP repository build. In the common repository they are provided without any special touch point instructions. In EPP these IUs are included in the root feature of the Java EE package; here in the feature they are implicitly defined with unpack="true" which results in the following additional touch point instruction: <instruction key='zipped'> true </instruction> I opened bug 349502 to consider adding a Eclipse-BundleShape to these bundles in the future. Back to the problem: I can see that the same bundles are available from two repositories with slightly different metadata, one is correct, the other one is half-correct. Could it be that at one time the metadata from the common repository has been used, the other time from the EPP repository? My guess is that this would be very hard to reproduce. Since it doesn't seem to affect the functionality I would suggest not to change anything at this point in time. See also bug 349503 (remove org.eclipse.wtp.epp.package.* bundles from EPP package repository). I think we can close this as "all is as designed ... or at least pretty close". :) I've no lingering concerns, and really appreciate your careful, thorough analysis Markus. (In reply to comment #7) > (In reply to comment #4) > > What happens with SR1? If a user updates a package and this update itself > contains an update of e.g. org.eclipse.help.feature.group, he will get these > optional bundles with SR1... I just wanted to mention this as additional > consequence if we would leave the packages as they are at the moment. Just to cross reference .... I'm not sure what the limits are of changes that can be made in maintenance, but I did open a bug to avoiding this "drag along" when ever someone installs the eclipse help system (where the repository they are using just so happens to have the optional bundles required by org.apache.lucene). Bug 349515 - Eclipse Help should prereq precise lucene bundles And, if it can't be fixed, I'm not sure its all that bad to install "extra things" with the Platform. So ... we'll see. |
Created attachment 198036 [details] diff -qr output for the two plugin directories. Everything seems to work ok (in my tiny testing) but I was surprised at some to the differences I saw in plugins directory. I'll attach diff file for Java EE, but similar unexpected differences for JavaScript. Maybe the changes "don't matter", but thought I should document, and get some other eyes on it.