Bug 358149

Description David Williams 2011-09-19 14:08:45 EDT

The "repository report" reports that there are no pack.gz files for many wb bundles. 

http://build.eclipse.org/indigo/simrel/reports/pack200data.txt

Mark Russell pointed out to me (in email) that the pack.gz files do exist on the file system, and wondered if something could be wrong with report, or aggregator. 

I've finally had a chance to look at this, and the issue turns out to be the "mapping rules" in the artifacts.jar/xml file for window builder. 

Looking at 
/home/data/httpd/download.eclipse.org/windowbuilder/WB/integration/3.7/artifacts.jar 

I see its mapping rules are 

  <mappings size='3'>
    <rule filter='(&amp; (classifier=osgi.bundle))' output='${repoUrl}/plugins/${id}_${version}.jar'/>
    <rule filter='(&amp; (classifier=binary))' output='${repoUrl}/binary/${id}_${version}'/>
    <rule filter='(&amp; (classifier=org.eclipse.update.feature))' output='${repoUrl}/features/${id}_${version}.jar'/>
  </mappings>


The mapping rules (when pack.gz files are provided) should be similar to the following: 

  <mappings size='5'>
    <rule filter='(&amp; (classifier=osgi.bundle) (format=packed))' output='${repoUrl}/plugins/${id}_${version}.jar.pack.gz'/>
    <rule filter='(&amp; (classifier=osgi.bundle))' output='${repoUrl}/plugins/${id}_${version}.jar'/>
    <rule filter='(&amp; (classifier=binary))' output='${repoUrl}/binary/${id}_${version}'/>
    <rule filter='(&amp; (classifier=org.eclipse.update.feature) (format=packed))' output='${repoUrl}/features/${id}_${version}.jar.pack.gz'/>
    <rule filter='(&amp; (classifier=org.eclipse.update.feature))' output='${repoUrl}/features/${id}_${version}.jar'/>
  </mappings>


Note the two additional ones for "jar.pack.gz' matches. 

So, in effect, when p2 goes to "get" a bundle, it does not know the pack.gz files are there ... it is driven by what is in the artifacts.jar/xml file. 

(And, side note, the order of the rules are significant, the "jar.pack.gz" rule must come before its corresponding "jar" rule.)

(Also note, there could be other required changes/differences to proper artifacts.jar file ... I don't recall ... but I've just learned to check these mapping rules as an "indicator"). 

So ... I'm not sure how you do the "pack200" task. Normally, if you use a p2 API, such as the p2.process.artifacts ant task, it creates the pack200 files, and also updates the artifacts.jar/xml file all at the same time. Highly recommended. I do not recommend "hand editing" the file! I also use p2.process.ant task as one of the final steps of producing a repo for webtools and orbit. 

I suspect there are other ways/tools as well, but, I'm just reporting what the issue is, and perhaps this will give you an idea of where to look next? 

I should also mention, while you could probably tweak what you have, I do not see this as a serious of enough problem to risk "breaking" your indigo repository. I'd suggest targeting and trying to fix this issue in SR2 and Juno. 

Thanks,