WTP/Build/Accounting for history during builds

From Eclipsepedia

Jump to: navigation, search








Process during WTP Builds




  • The build makes use of PDE's "gather repo" flags to create the 'buildrepo', which is literally the byte codes as built, in the form of a handy repo. (Bundles are signed, by this point, when doing a production build).
  • In a "create final repo" ant script in our builds, the p2.mirror operation is used to created the final 'repository'. It mirrors content from the 'buildrepo', but if it happens to find an IU (bundle or feature jar) with the exact same version as in the 'reference repositories', then it uses the one from the 'reference repository'.
  • During that mirror operation, if it finds two IUs with the same version, then in addition to using the old one for the final repository, it also uses the jar comparator task from p2 team, to see if there is some difference in content. If not, fine, but if it does, then it prints that information to the 'comparator.log'.
  • In an ideal world, that'd be it; we'd just look if the comparator log had any messages, to know if there were issues to address. But the reality is there are actually lots of "differences" found ... most of which we do not care about. Therefore, we run a release engineering test to filter out expected messages from unexpected messages and throw an error if there are any unexpected messages.
  • Not shown in diagram, any zips created or tests are ran with the final repository (not the 'build repo').
  • The 'repository' shows a dashed line back to the 'reference repositories', as once a build is declared, then it becomes one of the reference repositories. The reference repositories are a composite, made up of previous release and subsequent builds. This currently takes a "manual" step to add a repo to the reference repository. Note: on the production build machine, where all builds are accessible via the file system, the composite reference repo simply uses the file system. If someone were to do a "local" build, they'd likely want to create the reference repository ahead of time on their local system, for efficiency during the build itself. But, note, if there is no reference repository found (such as for a local, test build), then the operation continues and essentially the final 'repository' consists of what ever was in the 'buildrepo', which is probably fine for a test build.

Differences found for which no correction is needed.


All the "known cases" are codified in a property file called comparatorfilter.properties that is used during the releng test to filter out some messages. If filtered out, the message is still printed in a file called "excludedMessages" on our test results page. This can be pretty much ignored ... but wouldn't hurt for committers to examine at some points to see if anything is mistakenly being filtered out.

  • aboutmappings
  • testjars
IOException comparing ... Error opening zip file  
  • docbuildxml
There's several little differences found in "doc" bundles. Honestly do not know exactly what these mean ... but, assuming for now its just dates or similar. [Note: the Eclipse Platform automatically excludes all "doc" bundles from comparator examination, presumably since there are frequently small unimportant changes].

Significant, unexpected differences and what to do about them.



  • differences in feature contents
Difference found for canonical:
org.eclipse.update.feature,org.eclipse.wst.xml_sdk.feature,3.3.0.v201007311522-7A78-8DXJQUlJHRDD2LBB_qiiymz between 

The entry "Feature: org.eclipse.wst.xml_ui.feature

The entry "Feature: org.eclipse.wst.xml_ui.feature.source




Some files always excluded
