Re: [Babeldoc-devel] Welcome to the "Babeldoc-devel" mailing list (fwd)

[Bruce M. <br...@mc...>]

Sorry

This is continuation of the below...

Anyway these modules exist at two levels:  runtime entities; and modular 
build targets.  

Runtime entities.
The idea here is that merely copy these jar files to your classpath.  As 
babeldoc starts, the environment loader will look throught the classpath 
and check each jar file.  The module will be identified based on the 
presence of special attributes in the jar file manifest.  Again this 
primarily defines the name of the module and the list of dependencies.  
Based on these two data, babeldoc will load configuration data in the 
order from the "least dependant" module to most dependent.  This uses the 
configuration merging ability.  This has is hidden from the client code.  

A good example is the services/query configuration file.  In the core 
module there is only the services defined there particular to that module.  
As more modules get added to the classpath, so do more services as their 
properties get merged.  This means that more commands are possible and 
likewise.  

This same merging is handled for all configuration files.  Later 
name=values get merged later than more general name=values.  Thereby 
specializing functions.  At the moment, most of the modules are simply 
additive (no name=value pairs are overwritten).

Build time merging.
The problem here is similar but relates to code dependencies.  This is 
more tricky since ant does not do resursive build in the way that is 
required.  The build, when it starts DOES not know about all the 
dependencies.  Each of the specific modules gets its own build.xml.  There 
are a number of required targets: clean build deploy.   Each can be called 
at anytime.

Each of the modules is defined as a directory of ./modules.  The contents 
of each of these module directories contains at least a build.properties 
and a build.xml.  The build.properties has only three "special" names: 
Module, Depends and JarFile.  The Module gives the unique name of the 
module as it is known to client code and thus to the internal dependancy 
list.  The Depends name lists those other modules that this module is 
dependant on and the  JarFile name provides the name of the resultant jar 
file (although this behaviour is not mandated).

Each of the targets (clean, build and deploy) get called in dependency 
order from the main build.xml.  This discovers those modules in the 
modules directory by reading the build.properties file.  This is the 
common point.  Just keep the build.properties file up to day and you will 
have fewer headaches.  

The operation of both deploy and clean are more open than the build 
target.  The build target must (if it wants to contribute binary code (and 
hence a module.jar file)) dump all jar files and libraries required for 
this module.  The library jar files are usually copied from a "lib" 
directory in the module directory - /modules/core/lib) to the main ./build 
directory.  The bin/babeldoc scripts just simply add all those jar files in 
the ./build directory to the classpath.  From there its easy - the modules 
arrange themselves and you have a complete system.

more later,

Putting junior to bed.

Bruce.


On Mon, 24 Feb 2003, Bruce McDonald wrote:

> Good Developers!
> 
> I have checked in the first release candidate of the version 1 of 
> babeldoc.  Unfortunately I also checked in the build directory :(
> 
> Anyway there it is...  It builds and seems to run ok - I have done almost 
> no testing on it so use it at your peril.  Tomorrow I will clean out the 
> module directories....
> 
> The big idea...
> The big idea is that babeldoc gets broken into smaller modules that have a 
> clear dependency structure.  The unit of dependency is called a module.  
> This module has a name and a list of modules that it is dependent on.  
> This dependency list determines the build order and the runtime 
> initialization order.  
> 
> Bruce.
> 
> 
> 
> -------------------------------------------------------
> 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
> 

--