ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Brown" <>
Subject RE: classpath
Date Fri, 08 Aug 2003 01:10:24 GMT
Absolutely, I've just been waiting to find out if there's a general
interest. If it seems like something that folks want to use, I'll set up a
project on sourceforge or savannah soon. Just let me know...


-----Original Message-----
From: Rosendahl Sten - stro [] 
Sent: Thursday, August 07, 2003 8:00 PM
To: 'Ant Users List'
Subject: RE: classpath

Any chance you'll consider making savant open source?


> -----Original Message-----
> From: Doug Brown []
> Sent: Thursday, August 07, 2003 6:26 PM
> To: 'Ant Users List'
> Subject: RE: classpath
> 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
> used.
> 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=""/>
>     &jar;
>   </project>
> 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
> users.
> 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.
> ;-)
> Doug


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

View raw message