I agree with you up to a point. Ant is useful as a process control tool and the process can be outside the realm of build. A build process is only one type of process that Ant can handle. Other types of processes may lend themselves to your ideas better than build.
For example, a localization process can be controlled through an Ant file (that is what I am using it for). Given that we may have a database to use in the l10n process we may want to include some process control information in it for specific projects. If this process control information were in the form of an Ant blob then we could use the database to help manage the process right along with managing the translations. For this purpose we may need your extensions for the <import> and <properties> elements. I don't have any specific requirements at this time but I am glad to see that there is a possible route to extending your ideas to satisfy a more general requirement. Thanks. Bill Bill Rich Wilandra Consulting LLC 1325 Addiewell Place San Jose, CA 95120-3905 phone: +1 408 268-2452 mobile: +1 408 410-9713 Santa Cruz: +1 831 464-9007 fax: +1 413 669-9716 [EMAIL PROTECTED] http://www.wilandra.com -----Original Message----- From: Robert Dockins [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 8:51 PM To: Bill Rich Subject: RE: AW: parsing ant build scripts from unusual sources On Fri, 2004-10-15 at 12:11, Bill Rich wrote: > Here is a real example of what Dominique is referring to. snip.... > In this example, if all the .xml files are contained in db blobs what > would I need to do to the <import> to make this work? How could I > develop the XML file using the file system them store it in the db without changing it? The cop-out answer is, make all build files self-contained and don't use <import>; <properties> et al will be resolved relative to ${basedir} The slightly more realsitic answer is that, because we are using the ant API to initilize and run builds, we can simply use the enclosing application to "import" multiple build files if necessary. I think it could work something like this: Project project = new Project(); MyHelper helper = new MyHelper(); //hacked up helper that loads from InputSource helper.parse( project, mainBuildFileStream ); helper.parse( project, auxiliryBuildFileStream ); for( Iterator i=myProps.getKeys().iterator(); i.hasNext(); ) { String key=(String) i.next(); project.setUserProperty( key, myProps.getProperty(key) ); } project.init(); project.executeTarget("main"); ... I think this pattern is most usable for the kind of applications I have in mind (ie, using ant as a kind of "action engine", where the ant build syntax becomes a user-visible scripting tool). To answer the question you have put, however, requires rethinking how ant finds build script resources (and perhaps other resources as well). You would assign them some kind of identifier, which would be interpreted depending on the context and delivered into the build. Perhaps we could add a <BuildResource> type or similar and do something like: <import> <BuildResource id="L10NProcess/L10NProcess-macros"/> </import> <properties> <BuildResource id="${USER}"/> </properties> In a filesystem context, the id's are interpreted in a straightforward manner. In other contexts, some manner of mapping would have to be performed (eg, for a database, perhaps something like "select script_text from scripts where scrip_id = ?"). Is it worth the trouble? Not for me. I'll probably live with the fact that I can't <import>. Other people might be interested in doing something like this. However, I can't imagine a situation where migrating filesystem-based build scripts to a database context would be desirable. I'm thinking of scripts that are designed with the limitations of the database context in mind (in fact, this discussion is helping me discover exactily what those limitations are). For the people willing to accept the limitations, I think being able to load from funky sources is a great way to repurpose ant. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
