You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Barrie Treloar <Ba...@camtech.com.au> on 2000/09/20 08:51:31 UTC
Re: martin fowler paper on continuous integration
> 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:
> http://www.martinfowler.com/articles/continuousIntegration.html
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
discussion.
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.
BVT:
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
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.
======================================================================
regards,
Barrie
--
Barrie Treloar
____________________________________________________________________
Barrie Treloar Phone: +61 8 8303 3300
Senior Analyst/Programmer Fax: +61 8 8303 4403
Electronic Commerce Division Email: barrie@camtech.com.au
Camtech (SA) Pty Ltd http://www.camtech.com.au
--- Level 8, 10 Pulteney Street, Adelaide SA 5000, Australia. ---
____________________________________________________________________
Re: martin fowler paper on continuous integration
Posted by burtonator <bu...@relativity.yi.org>.
Barrie Treloar wrote:
<snip>
> 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.
<snip>
I would be +1 for seeing something like this under Alexandria...
(http://java.apache.org/alexandria) ... there has been talk there of
already integrating it.
Kevin
--
** Should SUN Open Source Java? Please Vote:
http://relativity.yi.org/java **
Kevin A Burton (e-mail: burton@apache.org, UIN: 73488596, ZKey:
burtonator)
http://relativity.yi.org | http://www.openprivacy.org
Message to SUN Microsystems: "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme
excellence consists in breaking the enemy's resistance without fighting.
- Sun Tzu, 300 B.C.
Re: martin fowler paper on continuous integration
Posted by burtonator <bu...@relativity.yi.org>.
Barrie Treloar wrote:
<snip>
> 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.
<snip>
I would be +1 for seeing something like this under Alexandria...
(http://java.apache.org/alexandria) ... there has been talk there of
already integrating it.
Kevin
--
** Should SUN Open Source Java? Please Vote:
http://relativity.yi.org/java **
Kevin A Burton (e-mail: burton@apache.org, UIN: 73488596, ZKey:
burtonator)
http://relativity.yi.org | http://www.openprivacy.org
Message to SUN Microsystems: "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme
excellence consists in breaking the enemy's resistance without fighting.
- Sun Tzu, 300 B.C.