> -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED]] > > I've been playing a little with CI tools for the past week > and it seems to me there are 2 possible approach to such tools : > > * Use a project descriptor based approach. This is what Gump > and Maven uses > * Use an Ant approach, i.e. the Ant build file contains the > project information, mixed with actions to perform on this > data. This is the approach that CruiseControl is following. > It is a wrapper around a master Ant build file.
Both provide different needs. For simple projects using maven, Ant's build.xml file isn't really needed at all. Unfortunately, sometimes there are more complex requirements. The project.xml file is useful for a couple of reasons: 1) Documentation framework builds the index.html from the project description. 2) Dependent descriptors for realizing GUMP and JJar distribution networks can be generated from the core. Currently, Maven uses both the build.xml and the project.xml. For most tags, the build.xml file merely delegates work to maven. There is a lot to like with the project descriptor as it stands. Unfortunately, if you deviate from a simple build, things get a bit more complicated. Example: Project Foo has optional dependancies. If the jars exist, Ant will compile the optional jars. This can be accomplished by copying the source and removing the class files that are affected before forwarding the targets to Maven. Maven should be able to download the necessary jars for you--which if it is in the "repository" (directory on Maven's site) it will do that. However, if you have several jars that are built, do you have a project.xml for each jar? That is where the the project descriptor breaks down. You do have to consider what a project descriptor is for: to describe a project. It is not a build file, although it can be used to generate a build file. In fact, that might not be a bad idea. Anyone who has built a C based GNU software project knows that you type "./configure; make all check" to get a binary and run any tests for it. The configure and build scripts are generated from autoconf/automake/libtool build environment scripts. While I don't like the obtuseness of M4 as a language, the concept is fairly powerful. If Maven could be moved into the role of the autoconf/automake/libtool, we can have the advantage of both a project descriptor and a templated build file. Maven would generate the *real* Ant build file from the template in the project directory. Something like this could work: /foo project.xml build.template build.xml Build.template would look something like this: <project xmlns:maven="http://jakarta.apache.org/turbine/maven/template/v1.0";> <target name="docs"> <maven:docs> <maven:src> <pathelement file="...."/> </maven:src> </maven:docs> </target> </project> That way the project developers have finer grained control over the actual build process without massacering the project.xml and forcing it to do things it should not do. Thoughts? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
