ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barrie Treloar <>
Subject Re: martin fowler paper on continuous integration
Date Wed, 20 Sep 2000 06:47:59 GMT
>  Martin Fowler has written up a paper on the build process we use for my
>  current project, if anyone's interested. There's not much in there about
>  Ant specifically, but it does describe some of the benefits of having an
>  automated build:


Apologies for cross-posting but I thought this article would be
useful on ant-user as well.

Also apologies for the length of this email.  I'm hoping this contains
useful information to others and that it shouldn't be a private

I'm interested in knowing some more detail in a prioritised order:

        - The Master Build
        - BVT
        - Single Source Point


The Master Build:

Writing an automated build process is not my core business.  Are you
willing to share this code?  Can we get it included into the Jakarta
project in some shape or form?  It would probably sit on top of Ant.


How do tests get added to the BVT.  Is it simply a matter of editing
the main BVT entry point and adding the extra junit tests?

I'd also be interested in how you run your tests in a J2EE
environment.  How do you unit test when it depends upon the J2EE
environment?  Do you write test session beans in order to provide an
entry point into the system?  I've not given this enough thought yet
but this seems a reasonable way to go.

A greater discussion of how the tests interact with the build would be
useful.  The problems with testing in a J2EE environment has slowed
down the introduction of automated testing and this is causing me
concern as I would like being used.

Single Source Point:

I would like to know how the build scripts handle building multiple
components from a single source tree.  

I've had projects which contained all the source but found it
difficult to label individual applications built from the components.
I guess that at worst I am labelling source which is not used by the

I've also had projects which have a separate directory per component.
The problem with this approach is that you get lots of tiny jar files
which need to be included when building a component that is dependent
on them.  But it does mean that I can label only the components
that are necessary in the building of the application.

If I have a single source tree I have to recompile everything, with a
per component approach I only need the latest jar for the component.
I disagree with the comment 
        "The trouble with this [per project approach] is then people
        have to remember which versions of which components work with
        which versions of other components"
as the latest versions of each component should work with the each
other.  So there is no need to remember anything, if you need to
recreate a previous version then all your components are labelled with
the information needed to obtain the versions of the components that
work together correctly.

Multiple projects makes editing files more tedious since you need to
change directory structures in order to open files in different
projects.  I'm not sure how IDE's handle this but with emacs and a tag
file I can open the correct file and not be concerned about its

I'd be interested in adding to the following list of pros and cons.
So far I've been happier with the multiple project line of thinking
and require some convincing.

Single Source: Pros

        Simple build process, ie javac *.java

        Easy to find source since its located as 
                <srcdir>/<package>/<hierarchy>/<to>/<java file>

Single Source: Cons          
        Difficulty in separating out the class files into different
        applications built from source.

        Difficult to build only source needed for an application
        without building everything.

Multiple Projects: Pros

        Each component has a smaller number of files to compile.  This
        may speed build process, but it a once off penalty that is
        being saved.

        Its obvious and explicit which components an application
        depends upon from the build process.

        Re-basing a component does not require re-compilation of
        dependent component source as you just need the latest version
        of the component's jar.

        Each application can be labelled individually with the
        components that it depends upon.  (Note: Labelling components
        individually requires the inter-component dependencies to be
        tracked.  This overhead provides little benefit since the
        latest versions should inter-operate correctly and once stable
        the application plus its components are labelled together.  It
        is irrelevant what versions of the components may be useful
        together as they do not form a usable whole)

Multiple Projects: Cons

        Many "tiny" jar files which must be included in order to build
        a component.  

        Many "tiny" jar files should be joined into a single jar for
        deployment.  Currently done via tedious unjar/jar.

        Finding and editing source from different components may be an
        issue depending on whether your IDE can support the multiple
        directory structure.

        Changes in code that break existing interfaces can cause a
        massive ripple in the component interaction which requires
        re-jarring and version controlling multiple components.
        Compared to a single recompile/jar for a single source.

Barrie Treloar

  Barrie Treloar                      Phone: +61 8 8303 3300
  Senior Analyst/Programmer           Fax:   +61 8 8303 4403 
  Electronic Commerce Division        Email:
  Camtech (SA) Pty Ltd      
 --- Level 8, 10 Pulteney Street, Adelaide SA 5000, Australia. ---

View raw message