|
CM Basics offers readers the answers to their configuration management "how-to" questions with tips from the experts, real-life case studies, product reviews and industry news coverage. Subscribe to the CM Basics RSS Feed - 
|
|
Written by Bob Aiello
|
|
Monday, 30 November 2009 00:00 |
|
 In my previous article I introduced Maven, the maven cycle and discussed the local repository. Maven has a lot of implied structure that you need to be aware of or you just won’t understand why things are happening behind the scenes. While Maven is great is presenting a consistent set of standards, sometimes it can be hard to figure out what happening behind the scenes. POMs are key to directing maven to do your bidding, they can also be a real challenge to decipher.
|
|
Last Updated on Tuesday, 01 December 2009 10:49 |
|
|
Written by Bob Aiello
|
|
Monday, 30 November 2009 00:00 |
|
It’s become increasingly popular to combine Agile practices with Lean principles as described in Mary and Tom Poppendieck’s work on Lean Software Development.
In Lean there are seven Lean Principles:
|
|
Last Updated on Tuesday, 01 December 2009 13:37 |
|
Written by Bob Aiello
|
|
Monday, 02 November 2009 15:10 |
 Maven is a popular build framework that is used by many technology professionals to manage large scale java application development. The Apache Maven website (http://maven.apache.org) states that "Maven is a software project management and comprehension tool". Maven builds are based upon a project object model (POM) which is coded in XML. Maven is used to manage a project's build, reporting and documentation from a central place. I have worked with both Maven 1.0.2 and the very popular Maven 2. For this article I used Maven 2.2.1 on RHEL 5.3.
|
|
Last Updated on Wednesday, 04 November 2009 10:36 |
Do you need agents? |
E-mail |
|
Written by Bob Aiello
|
|
Tuesday, 01 September 2009 11:01 |
 Recently, I worked with a few of my colleagues to implement an Application Lifecycle Methodology (ALM) solution that included a full build infrastructure that provided most of the functionality of a Continuous Integration (CI) server. This was part of a rich and powerful technology solution that managed all aspects of the Software Development Lifecycle. During this effort, I realized that some of my colleagues did not fully grasp the scope and purpose of using a build agent.
|
|
Last Updated on Sunday, 06 September 2009 10:07 |
Running a Makefile from Ant |
E-mail |
|
Written by Bob Aiello
|
|
Monday, 31 August 2009 13:05 |
 I recently got an assignment where I needed to run all of my build scripts from Ant. The reason was simply that the ALM solution that I was implementing could only accept build status return codes from an Ant directive. Since the project involved C/C++ all of the build scripts were written using GNU Make. My goal was to be able to execute the Makefile from within an Ant build.xml and receive the return code back in the Ant script. Here is how I approached the solution.
|
|
Last Updated on Sunday, 06 September 2009 10:07 |
Rules With Multiple Outputs in GNU Make |
E-mail |
|
Written by Eric Melski
|
|
Tuesday, 04 August 2009 00:00 |
 One problem that Makefile writers sometimes have is the need to write a single rule that produces multiple output files, to accomodate tools that don't fit the standard one-command-one-output model generally assumed by make. The classic example is bison, a parser generator used in crafting compilers and interpreters. Bison takes an input file like parser.i and generates both parser.c and parser.h. The Makefile hacker is left with a dilemna: how do you express this relationship in GNU Make syntax? In this article we'll look at the obvious answer and why it is wrong. Then we'll look at a few alternatives, including the one and only way to truly capture the relationship in GNU Make syntax.
|
Deciphering a “hand-me-down” build |
E-mail |
|
Written by Bob Aiello
|
|
Tuesday, 04 August 2009 00:00 |
 The conversation usually starts with my boss calling me into his (or her) office and asking me to help out with a task that has suddenly popped up. Usually, it is a matter of a developer leaving the organization and I need to quickly take over the build engineering that had previously been handled by this developer. If I am lucky, I may get a few minutes to shake hands with the departing colleague (luckier still if I can exchange links via my linkedin profile). But, more often than not, I just inherit a build that may or may not be in very good shape.
|
|
|
|
|
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
|
|
Page 1 of 16 |
