commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McNally <>
Subject attempting to formalize build process in commons
Date Mon, 24 Jun 2002 23:07:43 GMT
A discussion on whether components should be able to alter their build
system to involve anything other than a default ant install has started
based around some components choice to use maven and not maintain an ant
only build.  

Ant is used to build every project in jakarta that I am aware of.  As
this is not imposed on the projects it shows that ant is a very powerful
useful tool.  Commons does not have a single build system, instead each
component is expected to supply its own build system.  The commons
components have tended till now to adopt the informal standard that ant
be used to create a built component.

There are other projects in jakarta and elsewhere that are attempting to
build upon ant to take some of the drudgery and complexity out of
creating a build system around pure ant.  These projects generally
provide other value add making them attractive for use jakarta projects
and commons components and most likely more attractive as they gain

The choice by some components to become early adopters of these new
technologies has led to some to call for a requirement that these
components continue to provide an ant only build process.  As that is
really the only common thread until recently among the various builds of
commons components, some would prefer to make that a formal requirement.
As value-add's to ant become more common there is going to a tendency of
commons components to want to use them.  So do we want to require a
formal adoption by commons by vote before a component is allowed to use
anything that has not already been approved by common use or formally.

One such example (and if my details are wrong, the example is still
valid as a hypothetical) is the use of unit testing.  As it stands there
are no required targets or actions that would occur in a given target. 
But most projects have 'jar' and 'dist' targets that give a java library
and the library along with documentation.  The default target is likely
to be one of these targets but is not uniform either.  Now if we decide
that a component be buildable using the default target by a default ant
installation then components will not be able to have unit tests (using
junit as the most likely example) run by default.  The developers of
some components might be more influenced by XP than others and want the
unit tests as part of the default build.  Should these components be
required to move the unit tests so that the jar/dist/default targets are
not dependent on them.  Or should the "buildable by default ant"
requirement by imposed by requiring a 'ant-only-jar' target?

It would seem common's components would benefit from some degree of
uniformity in their build process and as they are all under the same
subproject there exists the ability to try to enforce some uniformity. 
But is it really possible given that the build process can be seen
differently by different groups of developers and they have already been
given free rein?

I come down on the side that more uniformity would be good, but it is
going to be difficult to achieve by vote a year late.  That is why I am
supporting maven as a potential solution that will not require
conformance by fiat.  As it supplies enough value add that components
will be likely to adopt it eventually.  And the current practice of
components deciding their own build process and what libraries are
required to build does not have to change.  Do others have more
confidence in another process.

Should a formal commons wide vote be required before components are
allowed to use value-add projects like junit, maven, or centipede?

I started out thinking I would try to lay out some possibilities for
standardization, but I have already rambled too long and I am not
confident that such a goal is possible, so I'll just stop and see if
there are others that think standardization is possible.

john mcnally 

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message