>
> |
SteveAnderson - 07 Feb 2008
Creating an MBAT Build from the Subversion Repository
A full MBAT build currently consists of several separate modules that are included when the final MBAT jar file is created. These modules should be checked out separately as follows:
- Create a directory to hold the individual MBAT modules. For example, “mb”.
- Create subdirectories for each module you need. To build mbat, you’ll need at least “common”, “mbSearch”, and “mbat”. Depending on your tasks, other modules such as “install4J” may also be necessary. You may also want to configure your IDE to handle the separate modules. For example, I created a single “mb” IntelliJ project containing individual IntelliJ modules for each SVN module above.
- Checkout the trunk of each required module from the MouseBIRN subversion repository (svn+ssh://cvs.loni.ucla.edu/cvs/MouseBIRN) so that local files are copied into the appropriate directories. Your directory structure should now look like,
.../mb
.../mb/common
.../mb/mbat
.../mb/mbat/src
.
.
.../mb/mbSearch
.../mb/mbSearch/src
.
.
- To build, run “ant” from the mbat/src directory.
Modyifying the MBAT Subversion Directory Layout
Periodically, it may be necessary to change the high-level directory structure of MBAT. Ordinarily this would involve simply refactoring java classes and then making corresponding changes to the build.xml file. However, many of the MBAT GUI components and facilities (work-spaces, for example) use XML scripts that are executed at run-time. This makes high-level changes to the layout more involved because the Java classes that execute these scripts contain references to the location of the script files. The XML scripts themselves also contain references to the location of other script files. Because these references are typically made in hard-coded strings, the automatic refactoring capabilities of the IDE are of no help--the changes to these references must be made manually.
Also note that if hard-coded location references to XML configuration files are incorrect, no compile-time Java error messages are generated. If the reference is in a Java file, however, a run-time error will be produced. But if the reference is inside an XML configuration file, no error message will be produced at all. The component will simply not be loaded.
So here are some suggestions:
- Don’t change the high level directory structure unless absolutely necessary. (By “high level”, I mean any directory that appears in src/build.xml).
- If you do need to change the directory structure, find an xml reference that contains the current directory structure and use that to search for other such references. For example, I recently needed to change the directory structure in a way that caused MBAT icons to be stored in a directory named “mbat/resources”, when they had previously been stored in a directory named “mbat/resources/shiva/resources” . By searching for “shiva/resources”, I was able to identify the many .java and .xml files that needed to be updated.
- If you have to add a new XML file, create a static string variable for the path location in the "Constants" file. When you refer to the location in other Java files, use that variable rather than hard-coded strings in the individual files. This will make things easier to maintain since only the Constants file will need to be updated if the path location changes.
|
