[ https://issues.jboss.org/browse/JBIDE-13977?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-13977 at 5/10/13 1:18 PM: ------------------------------------------------------------- As mentioned (incorrectly) over on JBIDE-13266... found a new problem. If you mirror, gen metadata, then pack, you end up with metadata based on any packed artifacts you pulled down from eclipse.org... NOT metadata for those you REGENERATED via pack200. And because pack200 sucks (or JDKs are different on eclipse.org vs. on www.qa, whatever) there's a chance that the NEW packed jar will have a different MD5 sum than the one that was previously fetched and pushed into the metadata. So you might end up with this: {code} "MD5 hash is not as expected. Expected: c7e232e42e6fa41dc60dd5336d38a311 and found 4b89fe64fa8b13bd1de2082e59275482."]], "Artifact not found: packed: osgi.bundle,org.eclipse.wst.doc.user,1.2.0.v200806052254." {code} And because tycho can't seem to deal with this by falling back to the UNPACKED jar, the provisioning / build fails utterly. #sadPanda So... I'm thinking the workaround here is to ensure that we run <p2.publish.featuresAndBundles> AFTER packing. Not sure if we have to run it before and after; going to assume there's no harm in ONLY doing after. Testing that now for the wtp 3.5M7 site. Alternatively, if we could tell <p2.process.artifacts> to only generate packed artifacts for things which don't already exist, that'd be great. Unfortunately the only supported filter mechanism is to nest a list of <feature> and <plugin> entries, which isn't as much fun as it sounds. was (Author: nickboldt): As mentioned (incorrectly) over on JBIDE-13266... found a new problem. If you mirror, gen metadata, then pack, you end up with metadata based on any packed artifacts you pulled down from eclipse.org... NOT metadata for those you REGENERATED via pack200. And because pack200 sucks (or JDKs are different on eclipse.org vs. on www.qa, whatever) there's a chance that the NEW packed jar will have a different MD5 sum than the one that was previously fetched and pushed into the metadata. So... I'm thinking the workaround here is to ensure that we run <p2.publish.featuresAndBundles> AFTER packing. Not sure if we have to run it before and after; going to assume there's no harm in ONLY doing after. Testing that now for the wtp 3.5M7 site. Alternatively, if we could tell <p2.process.artifacts> to only generate packed artifacts for things which don't already exist, that'd be great. Unfortunately the only supported filter mechanism is to nest a list of <feature> and <plugin> entries, which isn't as much fun as it sounds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira