Im working on the build scripts at the moment and did the following:
-I followed the best practices by having a build.xml per project, which means that each Portlet Project, Domain Services project has its own build.xml.
Now, i have lots of common tasks like "init.war", "compile.war" etc. Those task are in a common-build.xml at the moment. The question is where to put that common-build.xml ...should i copy that common-build.xml into each project and would be forced to check and guarantee the integrity of those copied common-build.xml (which seems to be a weak concept to me) or do i make a "AntBuild" project with the following structure:
That would just destroy the "one build file per project"-concept...
What do you guys think about? What experience did you do in similar cases?
My co-author an I had a similar situation for the build scripts for our book, where we had a separate project per chapter. What we did was created a separate project that contained the common build task, along with common files we needed for many of the other projects. Then the build.xml for each project included the build-include.xml file in the extra project. This really streamlined the build scripts for the chapters.
Also, this question should have been posted in the Ant forum. Could someone move this post there (I don't have my superpowers yet)? [ October 13, 2008: Message edited by: Peter Johnson ]
uuups sorry but i dont have those superpowers either ;-D
if i externalize the common build configuration xml into such a external project, why not to put all the build files into such a project and guarantee the integrity of those files in one single project.
This would also result in the dependency of such an ant project for all the other projects.
Dont get me wrong im really happy for any input that i can get...im just trying to get the points to together to decide
How would having a build in one project be dependent on a build in another project be any different from having a Java app or library in one project be dependent on a Java library in another project? Either way you still have to be aware of how changes to the common entity (whether build or Java library) might affect the entities that depend on it.
Practically, the build-include.xml file will probably change only very rarely. Once my coauthor any I had that file set up, we had to only occasionally change it, usually to add new targets to build things that we did not build before. And if you have a continuous integration process, you can quickly detect when something goes wrong.
Another thought - if you place all the builds in one separate project, how would you ever test them? You would not be able to until you grabbed the source code for one of the projects and then ran the build used for that project. And then consider the directory structure within version control - the build project would have build files in many directories which would overlap with the source directories. Hmm, that is confusing, perhaps an example will help.
Here is how the directories would be arranged if each project had its own build:
Each project would be extracted (from version control) into its own directory, that is, proj02 gets extracted into a directory named proj02.
But if you placed all of the builds into a single project, you would have this:
Now you would extract each project into the same directory.
That would make keeping the projects separate in Eclipse or NetBeans a little difficult.
Alternately, you could place all of the builds in the same directory (naming each one differently) and then set the basedir for each. This would avoid having the directories in version control, but it would require that everyone use directory names that match the specified basedir.