Re: Maven vs. Scripted Build Systems
Hi folks, after setting up and maintaining complex build environments using ANT and Maven for a couple of years I have some thought about the topic +) a fool with a tool is still a fool - if a complex build system is falling apart it has most of the times nothing to do with the underlying tools being used - if you do your job properly it will work +) a related problem is that many companies hire juniors for this setting up and maintaining a build system - it is not real programming after all ... :-) ... later on the know better +) the complexity does not go away - the complexity remains no matter of the build system but it might be less visible - so if you have problems they are hard to fix no matter what you are using +) once you have it you have it - that was an important topic with my current customer for rolling out a M2 build - it would be really difficult and depressing to kick out M2 and replace it with something else. And M2 is not really undisputed around here ... :-) Cheers, Siegfried Goeschl Mykel Alvis wrote: I agree with Graham's assessment that the bigger the project, the more useful. However, it does come with a price. You've got to get used to the idea of hard-versioning artifacts and moving toward controlled releases. And a number of the plugins are pretty...interesting...to use. I'm of the opinion that you shouldn't switch builds unless there's a compelling reason to do so. If your scripted/ant build performs the build tasks that you need, then use it until it becomes unmanageable or until you need something else...like consistency and reporting. In every case that I've installed maven in an enterprise environment, those are not just the most compelling reasons that someone wanted/liked it. They WERE the reasons. Ramp-up time for a new developer capable of building whatever system and/or component needed dropped from several hours (even days) into the 10's of minutes and is ridiculously easy. Likewise, the reporting available to a maven build stands on its own. Anyone looking at the default generated reporting gets pretty excited, and when you can add other sorts of reports (we like JDepend, pmd, and Findbugs for example), it really shines. As a side note, it has been my experience that low-to-mid-skill developers rarely understands or wants to understand the software construction process, and management practically never does. Builds are a thing that are either (a) laughably easy or (b) handled by someone else. If you're implementing a complex build, that someone is probably you. More than anything else, it seems that resistance to a new (maven) build is inevitable since it forces you to do some things that you might not otherwise do or to do them in a particular way. Prepare for that. As for scaling into large builds, I'd note that that a lot of that depends on patterns in your code. For instance, we (now) have about 100 active components being built, 80+ of which are in the hands of the coders (as opposed to being built exclusively by the build engineer). Of those, they can be divided out into about 15 classes of components. Once the build process is defined for each class of components, then managing becomes simpler for any new component of that class. For example, EJBs and their clients are 2 classes of components in our systems. We can produce a build for a new EJB in about 5 minutes and have a skeletal project waiting to be checked out of SCM ready for the developer to write code. If we had to manage 100 unique types of artifacts, this system would definitely be less scalable, and I'd probably be wanting to go looking for a new job. I haven't tried buildr, but am certainly interested in it. As for the Maven Uncertainty Principle they describe, I'm going to say that I've definitely encountered that effect but it seems that we generally had no problem defeating it with proper planning and project organization. Projects that force maven to bend to the will of the project tend to be less successful with maven integration than those that are structured around the maven way. Note that the maven way is much like the DJB way. It's flexible within limits, but you definitely get more bang for your buck if you conform to the way. Maven's definitely got it's warts, just like any product, and your mileage for responses on the lists may vary, but it's my current tool-of-choice and I've not regretted the decision to anywhere near the point of replacing it yet. On 5/8/07, Graham Leggett [EMAIL PROTECTED] wrote: On Mon, May 7, 2007 6:24 pm, Peter Kahn wrote: How does maven's declarative convention over configuration stack up against scripted solutions like buildr, groovy/ant or scons when it comes to maintenance costs for large projects? {snip} - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven vs. Scripted Build Systems
On Wed, May 9, 2007 12:30 pm, Siegfried Goeschl wrote: +) a related problem is that many companies hire juniors for this setting up and maintaining a build system - it is not real programming after all ... :-) ... later on the know better I've seen over an over again how a lack of basic software discipline can reduce a quickly running project down to an absolute crawl. One of the most key benefits of a system like maven is that it (within limitations) enforces discipline within a project. When you've made a policy decision that the maven release plugin (for example) will be used to make releases, you are now implicitely saying that the underlying code needs to build, the version control rules need to be followed properly, the maven repository to which you're publishing releases needs to be configured properly. Instead of trying to educate developers on some weird home grown way of maintaining software discipline (a task akin to herding cats), you say let's use the maven way - something you learn once, and apply everywhere. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven vs. Scripted Build Systems
On 5/9/07, Graham Leggett [EMAIL PROTECTED] wrote: let's use the maven way - something you learn once, and apply everywhere. Learn once, apply everywhere, that reminds me something :) Maybe our next marketing slogan, who knows. Stéphane Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven vs. Scripted Build Systems
On Mon, May 7, 2007 6:24 pm, Peter Kahn wrote: How does maven's declarative convention over configuration stack up against scripted solutions like buildr, groovy/ant or scons when it comes to maintenance costs for large projects? Scripted systems have an Achilles heel - build systems are not the primary task at hand in a large project, the code is. As a result scripted build systems are generally poorly designed and implemented, even though the tools on which they are built (like ant) are top notch quality. The scripted systems in every large project I've ever encountered were complex, incomprehensible, platform specific and incomplete, and ultimately thrown out. The standardisation efforts of maven save a fortune - in our case on a big project, releasing the project takes the form of mvn release:prepare and mvn release:perform, and that is it. This means that any member of a project team can make a release, and that release will probably work first time, or fail for very clear and obvious reasons. how sustainable is maven for large scale projects Implementing maven is not a walk in the park in a complex project. There are times when the classic maven design philosophy of let maven figure this out for you doesn't always hold true, meaning you have to understand enough about the build process to make sure things work together. Some of the maven plugins are not as reliable, or as complete than others. But - having implemented a maven build system, all the maven features, from release management, to documentation management, come for free. This investment in standardisation pays big dividends in the future. In short, the bigger the project, the more useful maven becomes. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven vs. Scripted Build Systems
I like to compare it to pure JDBC vs. Object relational tools. With OR you lose control of the small details but overall you get a better, simpler solution, worrying on the aspects you really care about On 5/8/07, Graham Leggett [EMAIL PROTECTED] wrote: On Mon, May 7, 2007 6:24 pm, Peter Kahn wrote: How does maven's declarative convention over configuration stack up against scripted solutions like buildr, groovy/ant or scons when it comes to maintenance costs for large projects? Scripted systems have an Achilles heel - build systems are not the primary task at hand in a large project, the code is. As a result scripted build systems are generally poorly designed and implemented, even though the tools on which they are built (like ant) are top notch quality. The scripted systems in every large project I've ever encountered were complex, incomprehensible, platform specific and incomplete, and ultimately thrown out. The standardisation efforts of maven save a fortune - in our case on a big project, releasing the project takes the form of mvn release:prepare and mvn release:perform, and that is it. This means that any member of a project team can make a release, and that release will probably work first time, or fail for very clear and obvious reasons. how sustainable is maven for large scale projects Implementing maven is not a walk in the park in a complex project. There are times when the classic maven design philosophy of let maven figure this out for you doesn't always hold true, meaning you have to understand enough about the build process to make sure things work together. Some of the maven plugins are not as reliable, or as complete than others. But - having implemented a maven build system, all the maven features, from release management, to documentation management, come for free. This investment in standardisation pays big dividends in the future. In short, the bigger the project, the more useful maven becomes. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven vs. Scripted Build Systems
I agree with Graham's assessment that the bigger the project, the more useful. However, it does come with a price. You've got to get used to the idea of hard-versioning artifacts and moving toward controlled releases. And a number of the plugins are pretty...interesting...to use. I'm of the opinion that you shouldn't switch builds unless there's a compelling reason to do so. If your scripted/ant build performs the build tasks that you need, then use it until it becomes unmanageable or until you need something else...like consistency and reporting. In every case that I've installed maven in an enterprise environment, those are not just the most compelling reasons that someone wanted/liked it. They WERE the reasons. Ramp-up time for a new developer capable of building whatever system and/or component needed dropped from several hours (even days) into the 10's of minutes and is ridiculously easy. Likewise, the reporting available to a maven build stands on its own. Anyone looking at the default generated reporting gets pretty excited, and when you can add other sorts of reports (we like JDepend, pmd, and Findbugs for example), it really shines. As a side note, it has been my experience that low-to-mid-skill developers rarely understands or wants to understand the software construction process, and management practically never does. Builds are a thing that are either (a) laughably easy or (b) handled by someone else. If you're implementing a complex build, that someone is probably you. More than anything else, it seems that resistance to a new (maven) build is inevitable since it forces you to do some things that you might not otherwise do or to do them in a particular way. Prepare for that. As for scaling into large builds, I'd note that that a lot of that depends on patterns in your code. For instance, we (now) have about 100 active components being built, 80+ of which are in the hands of the coders (as opposed to being built exclusively by the build engineer). Of those, they can be divided out into about 15 classes of components. Once the build process is defined for each class of components, then managing becomes simpler for any new component of that class. For example, EJBs and their clients are 2 classes of components in our systems. We can produce a build for a new EJB in about 5 minutes and have a skeletal project waiting to be checked out of SCM ready for the developer to write code. If we had to manage 100 unique types of artifacts, this system would definitely be less scalable, and I'd probably be wanting to go looking for a new job. I haven't tried buildr, but am certainly interested in it. As for the Maven Uncertainty Principle they describe, I'm going to say that I've definitely encountered that effect but it seems that we generally had no problem defeating it with proper planning and project organization. Projects that force maven to bend to the will of the project tend to be less successful with maven integration than those that are structured around the maven way. Note that the maven way is much like the DJB way. It's flexible within limits, but you definitely get more bang for your buck if you conform to the way. Maven's definitely got it's warts, just like any product, and your mileage for responses on the lists may vary, but it's my current tool-of-choice and I've not regretted the decision to anywhere near the point of replacing it yet. On 5/8/07, Graham Leggett [EMAIL PROTECTED] wrote: On Mon, May 7, 2007 6:24 pm, Peter Kahn wrote: How does maven's declarative convention over configuration stack up against scripted solutions like buildr, groovy/ant or scons when it comes to maintenance costs for large projects? {snip} -- I'm just an unfrozen caveman software developer. I don't understand your strange, modern ways.
Maven vs. Scripted Build Systems
How does maven's declarative convention over configuration stack up against scripted solutions like buildr, groovy/ant or scons when it comes to maintenance costs for large projects? Is there anyone out there who is involved with a large complex project who can weigh in on how sustainable maven has been and how much work it has required to keep bit rot at bay? I have a project with 20+ sub-projects which I'm planning to convert from a home grown maven like system written in shell scripts and ant to maven. It seemed like a no brainer, the system's process matched maven's model quite well. Then I read these two pieces and while I disagree with them I need to ask... how sustainable is maven for large scale projects http://blog.labnotes.org/2007/04/18/introducing-buildr-or-how-we-cured-our-maven-blues/ http://blog.labnotes.org/2007/05/03/buildr-or-when-ruby-is-faster-than-java/ Scripted solution can be much more concise than declarative, but they can also become very complex very quickly. I'm of the belief that I can use or misuse any technology and create a smoothly running system or a maintenance nightmare. I just want reassurance that maven doesn't have some hidden cost, or how best to avoid the pitfalls if it does. FYI, I already know about the Better Builds with Maven and the sonatype books and am working my way through them. Thanks for the help... -- Peter Kahn [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] http://kahnstipation.blogspot.com | http://analogoustendencies.blogspot.com/ Awareness - Intention - Action
Maven vs. Scripted Build Systems
I had worked before extensively with Ant, and I create a complete end-to-end build system. When I started to work with Maven, I noticed that I was able to version dependencies in a more organized manner, and that I was able to establish a folder structure which all projects shared. The site creation mechanism of Maven is more standardized than what needs to be done in Ant to create project websites. Also, if you ever need to use any Ant code in a Maven project, you could place the Ant code in the maven-antrun-plugin. Thank you. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1]
Re: Maven vs. Scripted Build Systems
Hello, I have been using maven for several years now, and switch from custom grown ant scripts to maven1.0 in 200? (can't recall exactly the year). The reason we switched is the usual one: - growing complexity and fragmentation of scripts - uniformity and industrialisation - standard way of building, structuring and documenting projects. - reporting This was true in maven1.X and is all the more so in maven2. I have set up maven on a project with +50 sub projects using custom archetype: maven is great for industrializing development, when you have a base project and several different modules that are built the same. The profile system is extremely flexible and allows you to write in a single place configurations for different environments (eg. development, testing, production). The greatest feature, in my opinion, is the reporting system. It can be somewhat tricky to put at work, but when properly configured, it generates consistent information on your system, centralizes documentation, project management info and quality reports. With continuum and (hopefully) archiva maturing, this makes for a complete production system. There are drawbacks to maven's approach: lack of flexibility, tricky configuration, centralized process, uniform way of building; and not all plugins/components work as advertized but the list is responsive. My 50 cents -- OQube software engineering \ génie logiciel Arnaud Bailly, PhD \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]