|
From: Bruce M. <br...@mc...> - 2003-02-26 00:45:47
|
Dejan, All: You might have noticed but I have a real problem with large, unweildy build processes. I do have some experience here and there is a potential problem where babeldoc build and configuration gets out of hand. I really want to make the babeldoc build quite decoupled. The only coupling that I want to support is the dependency relationship between modules of code. If you put all the configuration options in a single file, then it becomes a really issue to support major forward deltas in the source code. By forward deltas, this means that as functionality changes in the individual modules, these changes will probably need to be reflected in the mega configuration file. This means that it is up to the developer to maintain the relationship between this mega file and the individual files. The current 1.0 builds manages this fine. Here is the big problem... Let us consider the case of the web module. The web module does not participate in the commandline babeldoc relationship. In order words, the web package needs to be somewhat different than the babeldoc-core.jar, etc. These means that the build products are copied into the build directory, ready for the babeldoc.bat script file to add to the CLASSPATH. Heres what the web module must do... 1. Build the web code as before. Produce a babeldoc-web.jar 2. Build a babeldoc-web.war file which includes the jars in the build directory, the server XML files and web documents. A complete war file to support all the servlets, etc is then placed into the build directory. 3. A script in the bin/ directory which will deploy the war files to a particular deployment directory and whatever commands to (possibly) start the webserver. We can configure the script to operate based on properties in the module/web/build.properties. This is basically a filtering copy, to the bin directory. Again the principle is clear - the web module builds based on its configuration. There is a small issue: How do configurations override the web configuration - like a different tomcat installation directory, etc, etc. THis i propose be done another toplevel properties file, a locals.properties. This properties file will be read by the web/build.xml and will provide overrides by virtue of its being read AFTER the build.properties. If this file is not present, it is not read. what do you think? I will be working with the web module and the j2ee module. Where are the holes, what are the problems... Bruce. On Tue, 25 Feb 2003, Bruce McDonald wrote: > Having one configuration file for babeldoc is not going to happen for the > simple reason is that it couples non-coupled code. As for ant having one > big configuration file - this is a real problem and lots of projects break > apart the build.xmls. There are lots of reasons why this is a problem - > the most imporant one is that it becomes hard to manage. > > > > On Tue, 25 Feb 2003, Dejan Krsmanovic wrote: > > > What about having one xml file for configuration stuff for all aspects of > > Babeldoc? So instead of many properties file in many folders we could have > > one large xml file with all configuration. Just like in ant's build xml. > > > > What should be changes? I guess we should have new class for that implements > > IConfigService or extends ConfigService class, right? The problem is > > probably with some module specific functionality. For examples scanner is > > separeted module from core. Anyway, I would like to have scanner > > configuration in the same file as other stuff. But what if one day we create > > some new cool stuff like scanners are? Then we should change shema for xml > > configuration file and that is not good. > > > > Maybe we could handle this by introducing some kind of plugin api for > > scanners and other possible extrensions to core babeldoc. Or we could just > > leave scanner configuration out of the core babeldoc config. > > Any toughts?! > > > > Best regards, > > Dejan > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Babeldoc-devel mailing list > > Bab...@li... > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > -- |