To be clear, I'm not advocating time stamped artifacts simply indulging them for now to try and solve a problem that imo doesn't exist except as a thought experiment.
I agree with your assessment of a Maven Repo and that's why we have a build manager to go with it. It keeps records of build meta-data. Sure, A doesn't have the meta-data for B & C but they do and they all got put together at some point (we are integrating no?). The build management system also keeps all of the logs and manages them intelligently based on how for they got promoted in the life cycle. So pretty optimal in my opinion since I do want to pass an audit. The BMS also keeps all of the meta-data in it's db and while that is not *indefinitely*, it's very long when compared to release cycles (driven more by compliance and legal). Keeping the SCC info in the manifest provides excellent traceability. I don't care that Maven can't use it, I can. The real crux here is whether or not B and C are mine or some one else's (even if that is internal). Only my stuff can be a SNAPSHOT and it is either all a snapshot or it is not. So, if B & C are mine it's not an issue, if they belong to some one else's, they can't be SNAPSHOTs, it's that simple. I can even use the enforcer to ensure there isn't a SNAPSHOT set anywhere as part of the inspection process. We release by changing one entry in one POM and all of our stuff gets versioned, built and released. Repeat the process and everything is back to the next SNAPSHOT so we can resume changing things. It seems it is this one discreet activity that CD abhors. You want to defer it to after the fact which doesn't seem any different than what Stephen suggested by waiting for CI feedback and then trigger a CD build. I don't get what event prompts you to wan to go back and reproduce a build to be a release? The ours vs. theirs problem exist for your plugin scenario too. Sure you've created a synthetic POM but have they? If B & C's development is in fact decoupled from yours, why would they? How would they know? If they didn't make one and in turn are using SNAPSHOT deps themselves then you're hosed and your problem is spiraling in complexity. Only the things my team are changing and talking about are allowed to be SNAPSHOTs, this way I have people and interactions making decisions instead of trying to codify all of the possibilities. If your goal is to change anything anywhere at anytime and still deliver any of it, good luck. Even Timothy Fitz's work was just CI with Inspection and Testing along the way. The difference was, Prod deploy was just one more *test* and if anything bad happened it got pulled. Just because in theory any build can be deployed to prod doesn't mean that every build is of production release quality. Just because you can doesn't mean you should. It just means we should be providing the customer with value faster than they want it so there is always a backlog at their disposal ________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time, 600 times a day -----Original Message----- From: Brian Topping [mailto:topp...@codehaus.org] Sent: Monday, November 08, 2010 1:22 PM To: Maven Users List Subject: Re: Continuous Delivery and Maven On Nov 8, 2010, at 12:33 PM, Yanko, Curtis wrote: > Why is that not guaranteed to exist or be reliable? A Maven repository is a cache, not a reliable persistent store. *Yours* may be reliable, but the artifacts that are built to it should not contain metadata that, if lost, would make rebuilding that (or another artifact) exceptionally difficult. > And at the > moment I build A the build log will tell me exactly which SNAPSHOT we > received. So you want to keep build logs around indefinitely to solve this problem? That sounds suboptimal. There's no schema for log output, so pulling the values out by machine is unreliable over time. > I can crack it open and see exactly which SCC revision was used and > which path within the SCC it came from (because we bake that info into > everything we build). But if A depends on B and C and the SCC revisions of B and C are not recorded in A, then there isn't a way to reliably build A. The other side of this question is where to store the revision IDs for B and C. In the manifest? Maven can't use that information. Possibly in the POM as an additional qualifier in the respective <dependency> element of the POM that is stored in the artifact would make more sense, but then Maven needs to be changed with questionable semantics (what happens if there is an impossible combination of <version> and this revision ID qualifier?) This is why I was considering a repository manager plugin. It's site specific, and if it generated throwaway synthetic POMs for reproducing old builds, nothing has to be changed in Maven itself (the repository manager can call the artifacts anything it wants to properly identify the exact versions of B and C, likely returning synthetic POMs for them too). --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
