You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by mp...@ThoughtWorks.com on 2000/09/22 07:37:44 UTC
single source point (was Re: martin fowler paper on continuous integration)
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: ant-user@jakarta.apache.org
ch.com.au> cc: Ant Developers Mailing List <an...@jakarta.apache.org>
Subject: Re: martin fowler paper on continuous integration
09/20/2000 01:51 AM
Please respond to
ant-dev
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
application.
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
location.
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.