Community
Participate
Working Groups
http://build.eclipse.org/webtools/committers/wtp-R3.3.1-M/20110803220843/M-3.3.1-20110803220843/testResults/comparatorUnexpectedMessages.log.txt Message 1 canonical: osgi.bundle,org.eclipse.persistence.jpa.jpql,1.0.0.v20110604-r9504 Difference found for canonical: osgi.bundle,org.eclipse.persistence.jpa.jpql,1.0.0.v20110604-r9504 between file:/home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.3.0/R-3.3.0-20110607160810/repository/ and file:/shared/webtools/projects/wtp-R3.3.1-M/workdir/M-3.3.1-20110803220843/buildrepository/dali-sdk Binary file META-INF/eclipse.inf: sizes differ by 19 bytes. Message 2 canonical: osgi.bundle,org.eclipse.jpt.jpadiagrameditor.doc.user,1.0.0.v201105120001 Difference found for canonical: osgi.bundle,org.eclipse.jpt.jpadiagrameditor.doc.user,1.0.0.v201105120001 between file:/home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.3.0/R-3.3.0-20110607160810/repository/ and file:/shared/webtools/projects/wtp-R3.3.1-M/workdir/M-3.3.1-20110803220843/buildrepository/dali-sdk Binary file "build.xml" is different. Message 3 canonical: osgi.bundle,org.eclipse.persistence.jpa.jpql.source,1.0.0.v20110604-r9504 Difference found for canonical: osgi.bundle,org.eclipse.persistence.jpa.jpql.source,1.0.0.v20110604-r9504 between file:/home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.3.0/R-3.3.0-20110607160810/repository/ and file:/shared/webtools/projects/wtp-R3.3.1-M/workdir/M-3.3.1-20110803220843/buildrepository/dali-sdk Binary file META-INF/eclipse.inf: sizes differ by 19 bytes.
So upon closer inspection of these errors, I see that 2 of the bundles are not built as a part of the WTP, but "included" in the build as a part of Dali. org.eclipse.persistence.jpa.jpql org.eclipse.persistence.jpa.jpql.source I'm not exactly sure what the correct course of action would be at this point, but I believe this would probably be a case where we would exclude these bundles from the comparator. I'm not sure how to do this. Not sure what the problem would be for jpadiagrameditor.doc.user but this we can at least re-tag and later determine if this is a bug in the comparator. See this link for more information on this general issue - http://wiki.eclipse.org/WTP/Build/Accounting_for_history_during_builds.
Retagged and released org.eclipse.jpt.jpadiagrameditor.doc.user. Carl, Any idea on how to exclude certain bundles from the comparison?
Where does org.eclipse.persistence.jpa.jpql come from? EclipseLink project, I presume? My guess would be they are incorrectly changing the contents of their bundle, without changing the version number or qualifier. Those bundles could/should be examined explicitly, to find out what's changed. If that is true (that there is a code difference, but same version/qualifier), we should open a bug on them and get them to not do that. Otherwise, we (and many people) would never "pick up" the new content. We would end up, essentially, delivering something different than they do ... all with the same version/qualifier ... and who knows what a user or adopter would really end up with. But ... if you do decide to exclude those bundles ... there is a couple of ways to do it and I could point you in the right direction. But ... even if there is a "bug in comparator" then we should open a bug on the comparator. Let me know if I've missed something ... but, seems premature to exclude those without understanding what the difference is. Right?
(In reply to comment #3) > Let me know if I've missed something ... but, seems premature to exclude those > without understanding what the difference is. Right? Probably so. It seemed unlikely that this file or anything in this bundle had been changed by the EclipseLink team, but some investigation is certainly warranted.
I couldn't stand the mystery any longer :) so peeked at jars/messages involved with latest build ... eclipse.inf differs by 19 bytes ... I copied and diffed them, and found: $ diff old/META-INF/eclipse.inf new/META-INF/eclipse.inf 2d1 < pack200.args = -E4 So ... this actually would not effect the bundle "jar" ... but could effect the bundle's pack.gz file ... so ... not sure how/why that changed without changing the qualifier ... but, I'll show how to write rule, so exclude these messages.
Yep. Was just looking at the same thing. Seems there was a change as was indicated, but must have been an oversight on updating the version number. So no need to exclude here. We just need to get EclipseLink to update the version number as you suggested. On the topic of exclusion, it would seem that some of the existing Dali related exclusions could be removed? The bugs that were logged against the comparator were fixed, so in theory we could remove the existing exclusion, or have the already been removed?
Yes, we could/should try removing all 3 of the "complete exclusions" ... at least for Indigo and Juno ... but, as commented in createFinalRepo.xml <!-- Note: comparator has fixed this issues in 3.7 stream, but since we use this same code in maintenance stream, with 3.6 based builder, then we need to leave these excluded in place (or, make them stream sensitive, which doesn't seem worth it --> I can't believe I said "doesn't seem worth it"! Must have been in mood that day.
The jpql bundles could be excluded completely, in that "create final repo" script ... or .... if interested in excluding just for some streams, just for those messages ... a new rule similar to following could be added to releng/maps/comparatorfilter.properties. comparator.jpqlquirk.summary = .*org.eclipse.persistence.jpa.jpql.* comparator.jpqlquirk.comparison = comparator.jpqlquirk.reason = ^.*META-INF/eclipse.inf: sizes differ by 19 bytes.*$ Good luck!
(In reply to comment #6) It seems the file that changed was actually inserted into the bundle at build time which explains to some degree why this change was a bit stealth. This opens up an entirely different can of worms on EclipseLink build processes but I won't venture into that here. In any case, I think we have our answers here. We now just need to get our EclipseLink bundle dependencies updated with the next stable 2.3.1 build to pick up the fix. It may be a week or two before a stable 2.3.1 is available, just as a heads up.
Nightly builds are now available with the EclipseLink fixes for these issues in both head 2.4 and maintenance 2.3.1. If we want to go ahead and get rid of these comparator errors we will need to move our EclipseLink dependencies to the latest respective nightly's. I need to start a discussion with the EclipseLink project to produce a weekly integration build that will have a retention policy that we can work with. For the moment there are only milestone builds and nightly builds to work with.
EclipseLin has agreed to begin producing weekly builds with a retention policy that should fit our needs. These errors have been fixed in head and maintenance.
