Hi all,

Well, I'm not going to pretend that I took in all 75
emails on the topic of builds,  but...

Rod, I, and the others on our team have developed a
common set of targets, directories, and properties
(including dependencies on other jars) that we use for
our builds.  Among our standard targets are six "main"
targets that are guaranteed to be successful on any
project and recursively execute the dependent
subtasks.  Here's the targets we use (the main targets
are marked with an *):

  use* - generate a standard help message, including
         which targets are valid for this project
  clean* - remove all generated files
    clean-build - removes files generated by 
                  build target
    clean-doc - deletes ${dest.doc} directory and 
                runs clean-javadoc
    clean-javadoc - deletes ${dest.doc.api}
                    directory
    clean-javac - deletes ${dest.classes} directory
    clean-webinf - deletes ${dest.webapp.webinf}
                   directory
    clean-resource - deletes ${dest.resource} 
                     directory    
    clean-conf - deletes ${dest.conf} directory
    build-ejbc - create the ejb
  build* - builds the module
    build-javac - compile the source code
    build-webinf - generates the WEB-INF directory and
                   configuration
    build-resource - copy files from
                     ${source.resource} to
                     ${dest.resource}"/>
    build-conf - copies configuration files
  doc* - copies docs from ${source.doc} to ${dest.doc}
         and runs javadoc
    javadoc - generates javadocs
  test* - perform unit tests
  dist* - create jars, wars, etc.
    dist-jar - create a jar
    dist-war - create a war
    dist-ejbc - create the ejb jar
  commmit* - commit jars, wars, ejbs, etc. to CVS

Having this standard list of targets and properties
has allowed us to do two things: 1) easily automate
nightly builds, and 2) use a single "master build
script" which individual projects just inherit.  It's
the second part that's the real time-saver.  We have
about a dozen or so projects that are all minor,
predictable variants of a single master script.  It
seems like something along these lines would solve a
lot of issues, especially with regard to lowering the
cost of entry and providing an easy interface to Gump.
  Below is the build script for one of our projects. 
As you can see, this particular build script doesn't
need any significant change; it simply uses the
standard logic from the master script, plus a few
properties in the build.properties file.  Maybe
something like this could be done for Commons?


Build script sample:
---------------------------------------------------
<!DOCTYPE project [
        <!ENTITY CopyTLDs "
      <!-- put your copy/get tasks here -->
      <!-- make sure you escape double quotes as &#34;
-->
   ">
        <!ENTITY LibCopy "
      <!-- put your copy tasks here -->
      <!-- make sure you escape double quotes as &#34;
-->
   ">
        <!ENTITY DefineFilters "
      <!-- put your filter tasks here -->
      <!-- make sure you escape double quotes as &#34;
-->
   ">  
        <!ENTITY MasterBuildscript SYSTEM
"../../master/build.xml">
]>  
<project name="phreon-lib" default="use" basedir=".">
&MasterBuildscript;
<!-- test comment -->   
</project>


=====
Morgan Delagrange
Britannica.com

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

Reply via email to