> The current situation is a little bit complicated. We have additional
> components which are only included in the compilation if some
> libraries are available during compilation.
> In addition if these components are compilated there need to
> be some entries either in the cocoon.xconf or in the sitemap.
> This is partially done in the build, too.
>
> Now my problem is that if I look at the huge src directory, I
> don't see which classes will be compilated, which are optional etc.
> Even worse, there are classes in a package which are optional
> and others in the same are not.
Definitely the overall situation is a bit messy, yes.
> Now this all could be made clearer with the following structure:
>
> src + core : The required classes which are always compiled
> |
> |
> + opt - fop : FOP specific classes
> - batik : The SVG stuff
> - Xalan : Xalan specific implementations
> etc.
Sounds absolutely reasonable to me, as long as package names do not
change (i.e. there is no org.apache.cocoon.optional package tree)
> In addition to the src in each opt/{component} directory,
> this directory could contain a cocoon.xconf and sitemap.xmap
> fragment.
The problem here is that you don't know where the fragments have to be
inserted in the main config or sitemap file. How about inserting XUpdate
fragments and let Lexus edit the files? AFAIK there should be no
licensing problems in including Lexus in the Cocoon dist.
> Now the build script knows the dependencies like if library
> (=class) xyz is available, include directory /opt/xyz for
> compilation and append the cocoon.xconf fragment and the
> sitemap.xmap fragment to the configuration files.
Again, the only problem that I see is that you can't just "append" the
snippets and hope that they work...
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
