[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-13835: ------------------------------------ {quote}No, I suggest each component site build zips the source they are being built from and produce a source artifact that then gets aggregated.{quote} That would mean for EVERY set of 17 CI builds, we'd be moving an extra 300M of data around, which we won't ever actually release anywhere (other than the /snapshots/ folder. And, the content's the same as what's in github. So this would simply mean we'd be getting the 17 per-project source zips from download.jboss.org instead of github.com. Also, I'd have to link the BUILD_VERSION (timestamp + BUILD_NUMBER) in the manifest.mf files to the /snapshots/builds/JOB_NAME/BUILD_VERSION/, and BUILD_VERSION contains a *differently formatted timestamp* in the two places. So more steps and data processing simply to pull the same zip from a different place. Why is this better? {quote}from possible different content than what was used.{quote} If you don't trust that the value of SHA stored in the plugins' MANIFEST.MF files match values in github, we have a problem. What external changes do you think will happen between "job publishes a CI build from a given SHA" and "aggregate job uses SHAs encoded in the plugins that p2 resolved and placed into site/target/repository/plugins/ to fetch matching sources from github? -- We can certainly make a mojo to produce MD5 sums for all the zips produced at build time instead of at publish time. But maybe we want to produce SHAs instead? I mean if we're going to rewrite stuff, why not improve it instead of just recreating it in another language? -- This message was sent by Atlassian JIRA (v6.3.15#6346)