|
 CM Basics has long enjoyed an excellent column on the intricacies of building software using GNU Make with many excellent tips and suggestions for best usage. My background is much more focused on Software Process improvement especially Software Configuration and Release management. However, in the last couple of years, I had an opportunity to get some hands-on skills and experience with supporting Java builds using Ant 1.6.5, Maven (1&2) and setting up continuous integration (CI) using CruiseControl. While I had previously enjoyed a lot of hands-on experience supporting some rather complex build systems using Makefiles on HP-UX, Java builds on Linux were indeed a new experience for me. The builds that I needed to work with (across two different companies) were pretty complex. Build engineers often have to fix the process and only get as deep as needed into the actually intricacies of how the builds are designed and implemented. Developers usually show us how they build in their own private workspace and we make the build repeatable. Like most struggling beginners I learned a whole lot and frankly had a lot of fun! Read on if you would like to learn more about building complex Java applications too.
Ant or Maven the big debate - the answer is YES! One of the worst experiences that I have ever had was trying to decipher the jelly scripts associated with a Maven 1 build. The scripts seemed obtuse and difficult to read. Every time that I thought that I was getting close some new surprise showed me that I was still a distance away from really understanding how Maven works. Then I quickly switched projects to a much more complicated Maven 2 system that was even more confusing to understand. The developers debated the pros and cons of using Maven versus Ant and I just tried to figure out what was going on at each phase. To this day I can see reasons why Ant might be better for some projects and other reasons why Maven would add value. There are a lot of excellent resources for learning Ant, but frankly only a few books that teach Maven (1 or 2). I found myself downloading the source to Maven 2 just to compile it locally so that I could trace through the code and start understanding how Maven really works. I will be sharing what I learned at each stage of this effort and rest assured that Java developers have some really amazing build tools at their disposable, albeit with a bit of a learning curve in some cases. We'll try to help with that too. The difference between Ant and Maven The Maven literature reads with a distinct tone that is somewhere between evangelizing and outright brainwashing. The Maven enthusiasts exhort the Java developer to drink the cool aide and "realize" that Maven is a huge improvement over Ant. However, I began to feel that every other day I kept hearing the words, "Maven bug" being used to describe some unexplained side effect that impacted the build. The worst part is that it became obvious that most of the developers did not understand how the build worked at all and often came to me for help in figuring out what was going on. When I discovered jars with the same name being built in different locations that actually turned out to be different sizes things got a bit scary. There are definitely complexities that need to be understood and maven builds can be a lot more complicated than one would expect. Ant builds are procedural which means that you have to write the XML to do all of the work. Maven enthusiasts are fond of saying that Maven forces the developer to adhere to certain standards (e.g. directory naming conventions) and then Maven does the "heavy lifting for you". The problem with Maven is more acute when another developer must inherit some maven build XML scripts (known as POMs) and make changes to them. Assumptions are often not documented and surprises can happen. Ant is a lot more clear in that the tasks are defined and there are far less surprises. Maven can also call Ant tasks which is good in that Ant has a lot of neat tools that would not otherwise be available in Maven, but also adds another level of complexity to the POMS. Maven also boasts a shared repository which is used by developers to distribute build dependencies more efficiently. The shared repository is not really a repository at all and really just a directory. The derived objects stored there are not under any real type of version control and I have a perfectly fine jar overwritten by one that was corrupted. Obviously, a code repository would make this situation much better, but is not part of the Maven framework by default (although we could certainly implement this ourselves). Pay attention to the Maven cycle The key to understanding maven is to study the Maven Lifecycle. We'll get into this in more detail but the short list is Validating the XML, Compiling the source, Unit testing, Jarring up the classes, integration testing, verifying the package, installing the objects built into the local repository (more on this in a moment) and deploying to the shared repository. Which repository? Maven 2 has a local (account level) repository and then a shared repository. There are also often shared dependencies that are supported by going out to external websites. In one case our build failed because an external website changed it's URL for the dependencies that we needed. In coming articles I will begin to walk through some of the specific features of both Ant and Maven. Then we will look at continuous integration with tools such as CruiseControl. Please write with your specific questions and suggestions on what would help you to understand your builds a little better! Remember that this is CM Basics so no question is to basic or silly to ask. Pretty soon we'll all be Ant and Maven experts and then we'll publish some best practices in the CM Journal next! Bob Aiello is the Editor in Chief for the CM Journal and the manager of process improvement for a financial services firm in New York City. He has implemented and supported SCM solutions and release management processes at large financial services firms supporting hundreds of developers, located throughout the U.S, Europe and Asia. Bob is one of the original members of the NYC Software Process Improvement Network (CitySPIN) where he has also served as the chair of the NYC CM SIG. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra University.You may reach Mr. Aiello at raiello@acm.org
Set as favorite
Bookmark
Email this
Hits: 4059 Trackback(0)Comments (0)
|
| Last Updated on Thursday, 14 February 2008 18:08 |
TrackBack URI for this entry
Subscribe to this comment's feed