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...
Doug -----Original Message----- From: Rosendahl Sten - stro [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 8:00 PM To: 'Ant Users List' Subject: RE: classpath Any chance you'll consider making savant open source? Sten > -----Original Message----- > From: Doug Brown [mailto:[EMAIL PROTECTED] > 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 "http://www.xxx.com/savant/jar.xml";> ]> > > <!-- > > ============================================================== > ========= > 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="server.mf"/> > > &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 cots.help" 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
