Vadim Gritsenko wrote: > > Carsten Ziegeler wrote: > > >Hi Team, > > > >we recently had our thread about Cocoon organization etc. and > >it's now time to recapitulate the results. > > > >One main result is to split the core from optional things that > >we from now on call modules (and not blocks!). > > > >This is the proposed directory structure: > > > >/src/java The core > > webapp > >/modules/fop/src > > samples > > conf > > > > And every module has build script: > /modules/fop/build.xml > Yes.
> > >A build results in a separate jar file for the src and if > > > > With option of creating one JAR file. > Hmm, ok, why not. > > >the webapp target is choosen the configuration is merged > >into the webapp and if samples are choosen as well, the > >samples are copied to the webapp/samples directory. > > > >So, there remain some open problems: > > > >a) Documentation > > > >Where does the docs belong to? I think they should go into > >the modules directory, so for examples /modules/fop/xdocs. > > > >The build script can then automatically combine all these xdocs > >sections during build, so it's in the end no difference if the > >docs are residing in the module directory or not. > > > > > > I don't think it is great idea to fragment documentation. I imagine that > you can turn on only some features, then explore documentation, see that > you need some feature you don't have, turn this feature on, and continue > grow usage of components this way. > Yes, of course - ok, I forgot to mention the detail that the docs of the optional modules are not controlled by any dependency checks. So if you build the docs, you get the docs for all optional modules wheter they will appear in your web application or not. > > >b) Libraries > > > >Where are libraries for the optional components stored? A natural > >fit would be directly in the modules, like /modules/fop/lib. > > > > Agreed, seems natural. > > > >But I think this is not a good idea, because it could be that > >two different modules require the same optional library. And > >storing the jar twice is no solution. > > > >So, here is my suggestion: Everything stays at it is. All > >jars go either into lib/core or lib/optional (or lib/local). > >The optional modules check these places for availability of > >libraries. > >And now the fun part: The build system checks which optional > >libraries are really used and only copies those to the webapp! > > > > module-specific build.xml will copy jars it needs to the build > directory. Ant will not copy it more then once. > Yes, that's easier. > > >Why not simply copying all optional jars? For example, imagine > >the fop.jar in the lib/optional directory (which is there by > >default) and you built Cocoon without fop module, then you don't > >want the fop.jar in your app. > >I think this checking can be done by the... > > > > > > build.xml in module directory should be enough, and there is no need for > dep checker (for jar dependencies). But is still needed for > inter-modules dependencies. > Yup. > > >c) Dependency Checker > > > >Now, we need a dependency checker like Avalon Excalibur with the > >ability to specify inter-module dependencies and libraries dependencies. > >If we have this dependency information it should be easy to implement > >the above topic b). (Collection which optional modules where build > >and which libraries they require and then copying only these libs). > >Or a simpler solution is that the optional libraries are not copied > >at all by the main (=core) build script but by the module build scripts. > > > > Exactly. > > > >Then automatically only the required ones are copied. > > > >d) A deeper hierarchy for modules? > > > >Do we want this? For example grouping similar modules, like > > > >modules/pdf/fop > > pdf/itext > > webapps/session > > webapps/authentication > > > > No. > > > >or is only a plain hierarchy allowed? > > > >modules/fop > >modules/itext > >modules/session > >modules/authentication > > > > Yes. > > > >e) A selection system > > > >were a user can specify which modules she wants (like an interactive > >build) - the default should be all modules (which can be built). > >This could simply be done by an ant properties file, like > > > >modules.pdf.fop=no > >modules.pdf.itext=yes > > > > YESSS!!! > > > >f) Something I forgot > > > > What's your vision - lots of small modules or several coarse-grained? I > think consensus was - several coarse-grained modules. > > My vision is functional modules which can range from small to coarse-grained. For example fop is for me a module which is rather small. The flow engine is the opposite. But I think we will have several smaller modules. Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
