[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-13835 at 5/8/15 4:16 PM: ------------------------------------------------------------ {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" ? If they use the same SHA, the bits are the same. Or is there some instance where it's possible that the SHA in the manifest and the identical SHA in github resolve to different versions of the sources / different commits? -- 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? was (Author: nickboldt): {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)