Difference between revisions of "BetterAntBuilds"

From CitconWiki
Jump to navigationJump to search
(New page: Tip of the session: in order to "unit test" your common Ant scripts, have a test project that you can run the scripts against. You can then assert that the required artifacts are created a...)
 
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
Tip of the session: in order to "unit test" your common Ant scripts, have a test project that you can run the scripts against. You can then assert that the required artifacts are created as expected.
 
Tip of the session: in order to "unit test" your common Ant scripts, have a test project that you can run the scripts against. You can then assert that the required artifacts are created as expected.
  
There was a demonstration by Joe of the Ant Script Library (http://www.exubero.com/asl/), an open source library of re-usable build targets
+
There was a discussion by Joe of the [http://www.exubero.com/asl/| Ant Script Library], an open source library of re-usable build targets
 +
 
 +
Jeff pointed out a similar library in this area: the [http://code.google.com/p/ant-master-build-scripts/| Ant Master Build Scripts]. The author of these scripts also presented a talk at JavaOne called [http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-4166&yr=2009&track=javase| Object Oriented Ant Scripts for the Enterprise]
  
 
Ivan talked about the problem of putting too much programming logic into build scripts, and looked for input about the best way to avoid this problem. Jeff suggested that choreographing complex logic in Ant is probably best done inside a custom Ant task, instead of trying to set up targets, or using Ant Contrib.
 
Ivan talked about the problem of putting too much programming logic into build scripts, and looked for input about the best way to avoid this problem. Jeff suggested that choreographing complex logic in Ant is probably best done inside a custom Ant task, instead of trying to set up targets, or using Ant Contrib.
 +
 +
Bonus discussion: string literals are not always bad! For example: people often use a property for the directory containing all the library jars, calling it something like "library.dir", which means it must be referred to as "${library.dir}" where ever it is used. This is a lot harder than just typeing "lib", which is where pretty much everyone puts their jars, anyway!
 +
 +
Julian [http://www.build-doctor.com/2009/09/20/better-apache-ant-builds| blogged].  Joe [http://www.exubero.com/joe/2009/09/citcon-09-better-ant-builds/| blogged].

Latest revision as of 14:16, 21 September 2009

Tip of the session: in order to "unit test" your common Ant scripts, have a test project that you can run the scripts against. You can then assert that the required artifacts are created as expected.

There was a discussion by Joe of the Ant Script Library, an open source library of re-usable build targets

Jeff pointed out a similar library in this area: the Ant Master Build Scripts. The author of these scripts also presented a talk at JavaOne called Object Oriented Ant Scripts for the Enterprise

Ivan talked about the problem of putting too much programming logic into build scripts, and looked for input about the best way to avoid this problem. Jeff suggested that choreographing complex logic in Ant is probably best done inside a custom Ant task, instead of trying to set up targets, or using Ant Contrib.

Bonus discussion: string literals are not always bad! For example: people often use a property for the directory containing all the library jars, calling it something like "library.dir", which means it must be referred to as "${library.dir}" where ever it is used. This is a lot harder than just typeing "lib", which is where pretty much everyone puts their jars, anyway!

Julian blogged. Joe blogged.