On Nov 8, 2010, at 2:27 PM, Yanko, Curtis wrote: > > 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.
Yup, feel the same way. > 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). Also fair. But if were talking about "generalized solutions" instead of "localized means of coping", it's a bit of a different problem space. Agreed that the BMS as a whole should not be losing it's cache so often that one needs to look at the logs very often, if ever. I'm just making the point that if a solution is going to adhere to standards set by it's dependent subsystems, it ought to solve the problem within those constraints or make it an explicit non-requirement. Sometimes searching logs is the only way to solve a database corruption or loss issue, but it's a disaster recovery response, not business-as-usual. > Keeping the SCC info in the manifest provides excellent traceability. I > don't care that Maven can't use it, I can. The adage from the world of disaster recovery can be summed up as "it doesn't matter if your data is backed up, it matters if someone else can restore it". DR situations usually arise when someone needed the archives ten minutes ago and found them corrupted. I was never an advocate of foolproof DR tools until I had to wear the hat of a recovery guy with a half-dozen frustrated users crawling all over me because someone set up a system that wasn't built to be restored. > The real crux here is whether or not B and C are mine or some one else's > (even if that is internal). Indeed, and all bets are off once the transitive facilities stop communicating sufficient information. > 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? There was a time I wouldn't have felt naked without a CI server. I would "never" institute CD, but then who would ever need more than 640KB? Things change. Any tool can either provide generalized facilities to enable (if not support) these kind of requests or sometimes find itself delegitimized by cocky upstarts with more hype than heat. I like Maven and want it to remain the favorite build tool, so it makes sense to help consider these kinds of arguments. I look forward to being surprised someday. In the mean time, if someone wants to put their head in this area, why discourage them? > 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. The site-specific policy that groups make today are still valid. I generally don't allow external SNAPSHOTs into Nexus, and this is probably a sufficient means to solve the problem if their RM can't transitively supply the facilities required to interoperate to provide a named snapshot (i.e. their RM doesn't run the plugin). I simply can't imagine a partnership where I have no clue about what an external partner is doing but still want their bleeding-edge work product deployed to my production server in a CD process. On the other hand, if I am tight enough with them to know what they are doing and we agree I do want their bleeding-edge going live on my server, it's not farfetched at all that we would be sharing a lot more than just build artifacts. We would probably be pretty well-integrated as teams and would collectively see the benefits of both doing CD or eschew it altogether. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
