Community
Participate
Working Groups
I've noticed in the "comparator log" for latest I-build, that there are some surprising MD5 checksum problems listed. http://download.eclipse.org/eclipse/downloads/dropst/I20120411-0906/buildlogs/comparatorlog.txt The many other messages seem innocent enough ... ECLIPSEF.SF has now changed to ECLIPSE_.SF with new certificates and the "Eclipse-SourceReference" changes would not be urgent (if problems at all). But MD5 checksums ... that seems bad. I was pretty sure it wasn't a problem with the Orbit bundles themselves (I'm partial :) but I tracked down to the fact all those listed as having broken md5 checksums are in the "e4-orbit.map", not the "orbit.map", and it is only the orbit.map we run through our "exclude" task to exclude from re-signing/and re-conditioning. Even though these jars are marked so they will not be re-conditioned, we all know jarProcessor "touches" things anyway, so its changing the MD5 checksums (since not "excluded" explicitly, from the beginning). I'm marking as "critical" since I think this is basically "damaging data" and if, somehow, someone ended up getting these jars from our repository, instead of Orbit, then they too would have bad MD5 checksums. while p2 can be told to ignore those errors during install, that's not very good. So, one easy fix is to simply move all those map file entries into our "orbit.map" and then they'd be excluded. But ... while we are on the topic ... what are those e4-orbit.map files doing there to begin with? I would think some feature must be pulling them into the "master feature" ... if I understand the build ... or we'd just ignore them (normally, in most PDE builds, you can have "extra" things in your map files, and it doesn't matter at all. And, if we do need them in our builds, they are pointing to very "old" repositories, from Indigo release, or something, instead of latest Orbit S repository. Any insights appreciated.
Created attachment 213863 [details] short list of MD5 problems These are getting "pulled into" our delivered repository, so I'd think that'd mean there must be some feature that includes them ... so does that mean we are building a feature we should not be building?
From looking at the repository we create, we are definitely pulling in (i.e. need) these bundles below, so I will move them to the orbit.map and remove from the e4-orbit map. (Note, we currently do not "pull in" the "source" versions, but I will move/leave in orbit.map, in case someone wants to add them soon. javax.xml_1.3.4.v201005080400.jar javax.annotation_1.0.0.v20101115-0725.jar javax.inject_1.0.0.v20091030.jar org.w3c.dom.smil_1.0.0.v200806040011.jar org.w3c.css.sac_1.3.1.v200903091627.jar org.apache.batik.util_1.6.0.v201011041432.jar org.apache.batik.util.gui_1.6.0.v201011041432.jar org.apache.batik.css_1.6.0.v201011041432.jar org.w3c.dom.svg_1.1.0.v201011041433.jar = = = As John A mentioned on IRC, the felix.gogo entries are already in the orbit.map (and more current there) so I will just remove them from the e4-orbit.map. = = = = That leaves the following, which I will leave in the e4-orbit.map, even though we don't use it, presumably the e4 incubator builds will need it, and might help to keep straight if leave that e4-orbit.map file in or maps directory for now. Notice I am leaving in the commented out versions ... not sure if incubator is/was doing something with 1.7 versions ... but someone more knowledgeable with those builds can remove if they do not need them. = = = = = = = ! Required by e4 incubator builds. #plugin@org.apache.batik.util,1.7.0=p2IU,id=org.apache.batik.util,version=1.7.0.v200903091627,repository=http://download.eclipse.org/tools/orbit/downloads/drops/S20101204061544/repository #plugin@org.apache.batik.util.source,1.7.0=p2IU,id=org.apache.batik.util.source,version=1.7.0.v200903091627,repository=http://download.eclipse.org/tools/orbit/downloads/drops/S20101204061544/repository #plugin@org.apache.batik.util.gui,1.7.0=p2IU,id=org.apache.batik.util.gui,version=1.7.0.v200903091627,repository=http://download.eclipse.org/tools/orbit/downloads/drops/S20101204061544/repository #plugin@org.apache.batik.util.gui.source,1.7.0=p2IU,id=org.apache.batik.util.gui.source,version=1.7.0.v200903091627,repository=http://download.eclipse.org/tools/orbit/downloads/drops/S20101204061544/repository plugin@org.w3c.css.sac,1.3.1=p2IU,id=org.w3c.css.sac,version=1.3.1.v200903091627,repository=http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository plugin@org.w3c.css.sac,1.3.0=p2IU,id=org.w3c.css.sac,version=1.3.0.v200805290154,repository=http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository plugin@org.w3c.css.sac.source,1.3.1=p2IU,id=org.w3c.css.sac.source,version=1.3.1.v200903091627,repository=http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository plugin@org.w3c.css.sac.source,1.3.0=p2IU,id=org.w3c.css.sac.source,version=1.3.0.v200805290154,repository=http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository plugin@org.apache.commons.jxpath,1.3.0=p2IU,id=org.apache.commons.jxpath,version=1.3.0.v200911051830,repository=http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository plugin@org.apache.commons.jxpath.source,1.3.0=p2IU,id=org.apache.commons.jxpath.source,version=1.3.0.v200911051830,repository=http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository
I somehow missed org.w3c.css.sac,1.3.1 first time through. That only leaves even less in the e4-orbit.map: plugin@org.w3c.css.sac,1.3.0 plugin@org.w3c.css.sac.source,1.3.0 plugin@org.apache.commons.jxpath,1.3.0 plugin@org.apache.commons.jxpath.source,1.3.0
FYI, I've opened bug 376549 to track the continued cleanup of map files.
