[SNIPPED] >I think the point of the descriptor approach is not to model the *tasks* >being performed (that happens in the build file used to generate >deliverables), but to model the project structure itself, so that any >set of tools can be easily applied to the project. > >'The Ant approach' is part of what Maven does, but it does it in a >standardised and consistent way. There is a large amount of effort that >goes into building what I'd consider simple build files and keeping them >up to date. 'Best practices' are hard to follow as well, as they change >over time, and build files become legacy code.
This hits the nail on the head for me. Maintenance of build files in multiple projects is a pain that I could do without. Management of project information/dependencies, build structure, and ease of updating the build system across projects are key features. Keeping the project structure consistent and simple is not easy, Maven provides some guidelines for us. That said, currently there isn't a very clean way to extend the build system and access the maven provided model from within custom targets. Maybe a small xml 'include' file could be produced and include a maven:init target. Custom build files could 'include ( the xml way )' this file and use the maven project properties in custom targets. This may be a way to create (shudder) standard add-on/extensions to mavens ant build system. Maybe a maven-j2ee.xml with targets dealing with that. maven-torque.xml for generating sql and om code, etc. [SNIPPED] >Not really...Maven accomplishes this, as does Krysalis, by using an Ant >task to 'expose' the project model as properties. See the >project-properties task. Correct and the persistence of the project object model doesn't need to be limited to soley a xml represention. Large or multiple project settings could be stored in a database which maven could use to populate/store is model. Berin noted in his post the concept of automake/autoconf gnu build systems. I've brought this up before on irc wrt to Maven. Maybe ant is like 'make' and Maven is like autoconf/automake. This metaphor ( not sure if it is a good one or not ) helps me understand some of the things I want from Maven. I know how to build sources from a gnu tarball as Berin noted. I agree that having this concept extended to java projects would be very powerful. ant maven:update-jars maven:clean maven:jar Gets all the dependencies, cleans the build area, compiles the source, runs the unit tests and creates the jar. Maven is evolutionary? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
