|
||||
|
CC's Build System Other Information
|
Extracting CommonalityThe next step in our build process was to create Maven build files for each individual project. As explained in the first two parts, Basic individual project build and deployment and More advanced project build and deployment, each project can be built with minimal project-specific properties. In a group environment, the chances are that most projects will be developed similiarly to other projects, especially with regards to file and directory naming and layout. One would hope so at least. If this is the case, many properties can be extracted and centrallized for multiple projects, reducing redundancy and maintanence headaches.We have three main Maven build files for our projects: project.xml project.properties maven.xml There is also the possibility of having build.properties files, but they are user-specific files and not part of our checked-in project files. Project.xmlThere is a number of additional project.xml properties that we did not define in the earlier pages. Most of those properties may never need to be defined, but there are a number of properties that may be able to be defined the same for multiple projects. There is a project.xml element called <extend> that allows you to inherit the properties of another xml file as default values and override them if you need to for a specific project. Our parent xml file, called project.xml as well, is located in a parallel directory to our projects (see the introduction repository structure), called 'Builds'. Earlier we had the parent project.xml file one directory above the projects, but developers who use Eclipse as their development environment had problems with that. In all of our individual projects' project.xml file, I added this line:<extend>../Builds/project.xml</extend> In that parent file, I put all the common project properties. At an organization or development group level, it is most likely that many properties can be defined the same for most projects. For instance, we only have one repository server at Concord Consortium, so we can extract the information for deployment and retrieval of artifacts to the server and place them in a main inheritable xml file. Since we have a small development group, the mailing lists and developers section can be centralized. The organization section is also the same across all projects. Here is our current parent project.xml file: <?xml version="1.0" encoding="UTF-8"?>If you notice, there are a couple of variables that are referenced in the file. By defining these variables in the individual project's project.xml files, commonality between the projects can be extracted. There is also a large section for common project dependencies that all projects will inherit. In the individual project files, the content can be pared down to the minimal definitions: <?xml version="1.0" encoding="UTF-8"?> Project.propertiesA nice side-effect of inheriting an xml file in a project's POM file is that a project.properties file and maven.xml file in that directory will also get inherited. I didn't find this documented anywhere, but it's been a big blessing. The inheritance of the project.properties file seems to be unreliable if there is a project.properties file in the local project directory. I had problems with it earlier, but a more recent project that I have been working on has been inheriting properties from a properties file in the 'Projects/Builds' directory as well as the local project directory, so this is a possible Gotcha! warning. The inheritance of a maven.xml file can be done with a Jelly core:import tag explicitly, so need to worry about that.Anyway, all current projects except one are inheriting this property file: maven.repo.remote=http://www.ibiblio.org/maven/,http://source.concord.org/repository/Again, variables defined in the individual project.xml files make this inheritance possible. Maven.xmlAs stated above, the maven.xml can be implicitly inherited or explicitly imported. For our current projects, we do not have any individual project maven.xml files, just one in the 'Project/Builds' directory. This allows all of the pre/post goal actions to be defined once for all of the project sets. See Jelly Hints for more information on coding with Jelly.Get the source code |
|||
All Contents Copyright
© 2005, The Concord Consortium.
All Rights Reserved. Privacy Policy
Last modified: Tuesday, 14-Jun-2005 14:30:54 EDT