Stefan, This may be a post 2.0 consideration, but there are a large number of tasks in Ant that can be used as part of an software installation project. I already use it for just this purpose. Of course this would probably entail branching off Ant so that the common components/tasks would be part of both development efforts. This way Ant would not be bastardized with installation tasks and vice versa. What do you think?
john -----Original Message----- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Friday, October 27, 2000 6:29 AM To: [EMAIL PROTECTED] Subject: Some Thoughts on Ant 1.3 and 2.0 Hi, back to Cologne again. In London I've talked about Ant to a couple of people and would like to share my thoughts with you. This is more or less a brain storming at the moment ... (nonetheless quite long and still incomplete I'm afraid). First of all, the number of people actually using Ant in their projects has outgrown all expectations - this is great and should also make us feel a little responsible for their projects. Ant is in the middle of a consolidation phase towards what will be Ant 2.0 (see below for my vision of what Ant 2.0 should be). To get there we needed to break some build files during the transition from 1.1 to 1.2 and we will probably need to break some others again with Ant 2.0. My aim is that we are going to break them no more than _once_ more. I.e. we should try to get a clear vision of what we want to achieve with Ant 2.0, *document* it and then stick to it, at least for the near future. I'm going to give it a start by modifying spec/core.html to reflect what has been actually implemented in Ant 1.2 and rearrange some things. Should happen sometime early/mid of next week. I think the process to get there might take some time. On the other hand there will be a couple of changes, bug fixes and new features that won't affect old build environments. I feel we should be prepared to have a Ant 1.3 release (or 1.2.1 or similar) and maybe even releases following that (though I hope not) to address this - personally I'd prefer to get to a shorter release cycle than we had. This means we'd need to defer all things that could break older environments to a final step from Ant 1.x to 2.0, using a branch for that if necessary. What I'd like to see for 1.3 ============================ (*) Vincent's submissions in the data type area. Collecting command line arguments that occur over and over again for example. Vincent, what do you think about <argset> and <arg> as separate entities instead of overloading <arg> to be a container and a single argument at the same time? (*) Probably a couple of new tasks. I've been thinking about exec-all and transform to accompany execon and corresponding javaon, javaall and jtransform tasks. The execon task should get smarter (i.e. the argument generated from the fileset doesn't have to be the last one) and transform would push the idea a little bit further. This task would generate the name of a target file from the name of a source file (like *.c -> *.o), check whether the target file exists and only execute if it doesn't or the source is newer and provide both the source- and target name to the executable. I'd like to refactor all those tasks that have a scanDir method that filters the files to process (by the <uptodate> logic) at the same time. Proposal on how I think we could do this will follow. These tasks should help to satisfy most use cases that ask for loops. (*) some additional features - like adding out-attributes to a couple of tasks and so on. (*) expanding ${} (almost) everywhere This should include all attributes of <project> and <target> - except id? - and the #PCDATA sections handled by addText. I'm not sure whether the latter would interfere with <script> though. (*) bug fixes of course. What I'd like to see for 2.0 ============================ (*) Switch to JAXP 1.1 and SAX2. Could happen in 1.3 as well if JAXP 1.1 should be ready by then. (*) Change of the documentation system to an XML based one. No matter which DTD or Schema we want to use, it should be something that can be used to generate HTML as well as printable (PDF) information. At the same time I'd like to put more documentation burden on the task writer (i.e. don't accept new tasks unless they are documented in the "correct" format). (*) Change of the property system one last time No matter what we do, there are still some things that need to be resolved and finalized. Mainly (1) Master projects overwriting properties in sub projects. Sometimes you want this to happen, in other cases you do so by accident. The easiest solution that doesn't change the behavior of current build files would be something like <property name="foo" value="bar" scope="file" /> for properties that should not overwrite properties of the same name in sub builds. If you want to overwrite, use scope="global" which would need to be the default unless we want to break something existing. Alternatively add something like <localproperty> for what scope="file" would do. (2) Do we want mutable properties or not? Regardless of what we come up with, we should document it and stick to it. (*) Make <antstructure> support Schema. At the same time maybe make tasks give some more help to antstructure to identify required arguments, default values and so on. Schema is a lot more expressive than a DTD. This could happen in 1.3 of course, it's a matter of time. (*) Use a consistent naming for attributes Instead of using srcdir, dir and basedir for the same thing, we should agree on one and use it throughout Ant. (*) Extension tasks Make extending Ant as simple as possible, i.e. drop a jar file in a specific directory (ANT_HOME/ext globally or ~/.ant/ext on a user by user basis). This jar file must include <taskdef>s to define the tasks, Schema files to describe the tasks and documentation in the XML format we agreed on. The Schema file is there to support GUI tools for example. They could prompt for required attributes, let you select enumerated attributes from a list, require integer attributes to really contain numbers ... I don't view Ant using it itself at the moment. <taskdef> will probably need some extension so that the author can specify required libraries and other things. Things I'd like to see beyond/parallel to that ============================================== (*) A GUI tool. Hope Anthill will really get on the way. Frederic, if you should need help (like a CVS space to live in), please let us know. (*) Some kind of front end to satisfy the more complex needs of some users. This is where I'd see support for enhanced conditionals and other things. To quote Duncan: a tool that would be "to Ant what configure is to make". Stefan
