ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Brown" <>
Subject RE: classpath
Date Thu, 07 Aug 2003 16:25:46 GMT
I've been working on this problem off-and-on for over a year. To handle it,
I created a local build system called "savant" based entirely based on ant,
one that has specific enterprise rules built into it. I am using ant 1.5.x
as the base of savant, and I have added only a single simple taskdef, so
using savant did not require wholesale changing of tools or technologies.

In savant, the developer doesn't select individual jar files, he only
selects complete packages (e.g., tomcat, jboss, jacorb, etc). He can specify
that the "default" version or a specific version for the project should be

Only packages and versions supported by savant are allowed, but it is easy
for a build master to add new packages. It is all controlled by XML files
that are processed by XSL to produce build "snippets" that are then included
by the developer in their build.xml files. Here is an example of a complete
build file:

  <?xml version="1.0"?>

  <!DOCTYPE project [
    <!ENTITY jar SYSTEM ""> ]>

      AceCorbaServer build file

  <project name="AceCorbaServer" default="all" basedir=".">

    <property name="inhouse.Ace" value="default"/>
    <property name="inhouse.AceCorbaCommon" value="default"/>
    <property name="cots.jacorb" value="default"/>

    <property name="manifest.file" value=""/>



A few things to notice:

1) All of the logic is actually in the "jar.xml" entity. Since this is
served up by a web server accessible by all developers, all of the real
enterprise logic is centralized. If a change needs to be made (e.g., if a
new package needs to be supported), it can be done in one place. This gets
around the problem of developers including localized files in the build that
cannot be repeated by the CM/build group. This is especially a problem when
using property files in a large organization, because it is difficult to
make sure that each developer is using the same approved version of the
property file. This almost always leads to later problems during full
integration builds.
2) All external packages are listed as properties named "cots.package_name"
(like the "cots.jacorb" in the example). The property's value can either be
"default" which means that the project's default version should be used, or
it can be an actual number like "3.2.1" if a specific product version must
be used. In no case does the developer specify individual jar files. All of
the logic to specify individual jar files is included in the XML files
supported by the CM/build group. The generated build snippets also detect
and handle invalid build.xml entries, and provide "help" targets in the
build.xml so that the developers can know what packages and versions are
supported. For example, invoking "ant" on the build file above
will produce a list of packages and versions that are available to be used
by this project.

3) All internal packages are listed as properties named
"inhouse.package_name". The value can only be "default", since all inhouse
packages in a project have to use the same versions of other inhouse
packages. E.g., if a project is made up of 3 packages "A", "B", and "C", and
"A" depends on "C", and "B" depends on "C", then the version of "C" that is
used by "A" and "B" must be the same in order to deploy the project.

4) You can't tell from the example, but only direct "leaf node" dependencies
must be specified in the build file. What this means is that if your project
really depends on 30 inhouse packages, but that of the 30, 27 are indirect
dependencies, then the developer only needs to list the 3 packages for which
he has a direct dependency. All indirect dependencies are handled by savant
automatically. The dependency information is entered by the CM/build group
when they create the XML snippets, and then the info can be used by all
developers. In order to figure out the initial dependencies between jars,
I've created another tool based on jdepend that will process legacy jars and
generate an XML file showing all the dependencies between them.

5) The developer can specify a manifest file for the jar as shown above.
This is optional - if your jar file doesn't need a manifest, just leave this
line out. There are several other similar options available for expert

6) The developer doesn't have to name targets, tasks, source files, class
files, jar files, tests, etc. This implies a common target, file, and
directory structure supported by the build system. This is generally a good
thing, although it may annoy some developers. It is usually preferable
though, because it permits developers from other projects to easily
understand the build structure and process of any given project since they
all follow the same rules.

I've tried to handle the dichotomy of philosophies usually found between the
CM/build group and the developers. CM/build groups want full control and
they mandate repeatability of builds above all else. I.e., the build doesn't
really work until the CM/build group can build it. In addition, the CM/build
group folks are usually the ones that have to deconflict problems caused by
multiple independent developers using incompatible package versions. These
problems don't usually show up when the independent developer compiles their
part of the project, they only appear when CM/build does a full integration
build. One of the primary goals of this build system is that if a developer
can build it, then the CM/build group should be able to build it too,
without *any* changes to *anything*.

Developers usually fall into 2 camps: some want absolute full control of
their build files and resent any CM/build group that interferes with their
ability to use new products whenever they want. Others don't care at all
about build systems - they just want something that works and is easy for
them to use. They don't really know about ant and don't want to know.

Savant obviously makes the work of the laissez faire developer pretty
simple. To support the maven developers, the XML files that are used to
generate the build snippets can be easily modified by the build group to
support new products and versions. This can usually be done in minutes, so
there should be no excuse that "CM/build is not responsive", which is
usually the reason given when developers ignore the CM/build group and go
their own way.

So far, I have build file snippets that support jar file creation, idl
generation, junit testing, war file creation, recursing through multiple
build files, etc. I am working on ear files next. There are a lot of other
capabilities built into the system, but this message is already too long.


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

View raw message