ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject single source point (was Re: martin fowler paper on continuous integration)
Date Fri, 22 Sep 2000 05:37:44 GMT

there are two separate issues here, I think. The first is the way you group
your files into top-level folders. Let's assume that we have a project with
10 or so different components. You could have one folder for each
component, or one big folder. We've chosen one big folder, simply because
it makes using an IDE much easier. We also put all of our output files
files (class files) in a single folder for the same reason. However,
there's no reason why you couldn't put your java files for all of your
components in one directory, but compile them separately. Ant makes it very
easy to choose which subset of files to compile within a javac call. You
could also put them in separate directories and compile them together.
Whatever works for your project.

The bigger issue is really how you version things. One way is to version
each component separately (this obviously works only if your components are
in separate directories). Each component then basically depends on specific
versions of other components. For example, you could develop your "gui"
code against version 1.0 of your "util" code, until you explicitly decide
to upgrade to version 1.1. That way you have a stable base to build your
gui code on. This process gets *nasty* as the number of components
increases. For example, if you decide that your gui should start using
version 1.1 of util, every other component that uses the gui component, or
is used by the gui component, must be upgraded at the same time to use
version 1.1 of util...

The alternative is to develop and label everything together, which works
much better, in my experience. You mention that "the latest verisons [of
each component] should inter-operate correctly", so I think we're on the
same page. The overhead of labeling the entire project when you're only
releasing parts seems trivial to me...

Matt Foemmel
ThoughtWorks, Inc.

                    Barrie Treloar                                                       
                    <Barrie.Treloar@camte        To:  
          >                   cc:     Ant Developers Mailing List <>
                                                 Subject:     Re: martin fowler paper on continuous
                    09/20/2000 01:51 AM                                                  
                    Please respond to                                                    

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.

View raw message