Wolfgang Häfelinger wrote: > Dominique Devienne wrote: > > Ant's purpose is as a build tools, not a Java library. > > Perhaps time to change.
It seems to me that a primary objective of the Ant community has been to focus on the build file XML integrity over and above API integrity. If you take the next step and attempt an abstract above the Ant API - e.g. a model for a buildable project using ant as the build implementation - then Ant (as a library dependency) is brittle. However, it is possible to isolate Ant idiosyncrasies as an implementation concern providing one can establish a viable project model. A viable project model introduces the following concerns: (a) resource management (b) dependency management (c) project layout (d) build execution None of the above are trivial concerns. A resource management framework is needed to address general resource of dependencies (jars, preference data, deployment info, etc.) in a secure manner (where 'secure' can be asserted as a system configuration concern -- i.e. it's not a case of saying that something is signed or not - it's about enabling a controlled environment). A dependency management model is needed to ensure integrity with respect to the resources used and consumed by hundreds of projects with respect to build, runtime and test phase dependecies. The ability to construct and manage project layouts is needed in order to support general simplification of build procedures by adding an abstraction between physical file system locations (dirs and files) from the tasks that deliver the ultimate value in build process. A build execution model is needed in order to create the framework for generic processors that can extend/enhance common build procedures without resorting to references to task names or local path definitions. IMO - the above subjects are priority drivers for the evolution of the Ant API. In particular, these priorities focus attention on the following Ant extension points: (a) ProjectHelper (b) ComponentHelper (c) PropertyHelper As a general comment I've found these classes difficult to deal with and the supporting documentation limited. My impression is that the codebase has evolved with the intention of supporting third-party extension however in practice my earlier comment concerning "brittle" comes to mind. Given the solutions out there I prefer Ant probably because of the working 'primary objective' mentioned above -- however, I do believe that the community dealing with Ant as a library needs to step up a take an assertive role in the future direction of this project. I.e. perhaps Dominique's suggestion on the money? Cheers, Steve. -------------------------- Stephen McConnell mailto:[EMAIL PROTECTED] http://www.dpml.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
