Return-Path: Delivered-To: apmail-ant-user-archive@ant.apache.org Received: (qmail 24186 invoked by uid 500); 7 Aug 2003 16:24:40 -0000 Mailing-List: contact user-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list user@ant.apache.org Received: (qmail 24175 invoked from network); 7 Aug 2003 16:24:39 -0000 Received: from gemini.smart.net (205.197.48.109) by daedalus.apache.org with SMTP; 7 Aug 2003 16:24:39 -0000 Received: from vega (dbrown.smart.net [216.253.158.39]) by gemini.smart.net (8.9.1/8.9.1) with ESMTP id MAA31051 for ; Thu, 7 Aug 2003 12:24:41 -0400 From: "Doug Brown" To: "'Ant Users List'" Subject: RE: classpath Date: Thu, 7 Aug 2003 12:25:46 -0400 Organization: Shadysoft Message-ID: <000e01c35d00$96eddce0$0c00a8c0@vega> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3F321C27.9020703@cyberspaceroad.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: ]> &jar; 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. =20 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: user-unsubscribe@ant.apache.org For additional commands, e-mail: user-help@ant.apache.org