I think our fundamental schism is that you see managing POM's as too hard where as I see them as so easy and a no brainer when it comes to ROI especially considering the alternatives.
We have plenty of initiatives that span system boundaries but those need to be addressed in architecture and not CI systems. My mantra is this, if you are feeling pain in your process, do it more often which should force you to either solve the problem or realize it's upstream. You're trying to solve a two-sided jello view of a system at build time, perhaps what you need is to refactor you architecture (and why SaaS, Cloud and federated systems lend themselves to CD). Maven is your pain point but I say you're just not doing it right. I have projects with enough internal modules to exhaust the alphabet in our little A->B->C game. Then there is twice as many more 3rd party libraries often times with conflicting transient dependencies of their own. The level of complexity is really quite astounding imo. But, thanks to maven we can think in terms of technology stacks reducing 50 dependencies into just a handful of high level components. *Managing* our POMs has been streamlined in such a way that they are very easy to manage. And yes, there are times when I have to touch that whole alphabets of POM but you know what, that's why someone solved the general problem with find-n-replace, followed by one atomic commit. So, after we *find something valuable* we can release it trivially. ________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time, 600 times a day -----Original Message----- From: jhumble [mailto:j...@jezhumble.net] Sent: Monday, November 08, 2010 3:40 PM To: users@maven.apache.org Subject: Re: Continuous Delivery and Maven > > 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. > This goes back to my original example. In large development teams it is very common for different groups to work on different modules which must all be integrated together for the application to work. In those situations it is common for all of the modules to change quite regularly. As a result, you want each of those teams to use snapshots because it's too painful to be always creating new release versions and update the pom files by hand. But you also don't want to throw away the testing you do with those snapshots. This is what motivates the idea of including enough metadata with the snapshots so that the binaries can ultimately be released *if required.* > 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? > But if you are continuously integrating the modules, which you should be (CI applies at the module level, not just at the code level), then you'd be changing the POMs *all the time*. > 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. > If creating the extra metadata is built in to the tool, then we ensure that everybody has the pom with the extra metadata and there isn't a problem. Anyone who doesn't need it can ignore it. > If your goal is to change anything anywhere at anytime and still > deliver any of it, good luck. No, that's absolutely not my goal. I want to make what I think is a very simple change to the way Maven works so that people can carry on with their existing methodology, but incrementally create a full deployment pipeline too if they find it to be valuable. -- Jez Humble Co-author, *Continuous Delivery <http://continuousdelivery.com/>* http://continuousdelivery.com/ http://jezhumble.net/ -- View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370 p3255726.html Sent from the Maven - Users mailing list archive at Nabble.com. 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
