> Geoff Howard wrote: > > > 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 > > Yes, please do this. I don't think I've seen this comment in the > > discussion, but the solution to move jars out of the way before > > each build essentially makes keeping up with head, or reasonably > > updating a build impractical. > > > What do you exactly mean? Sorry, I was rushing out the door when I wrote that.
Currently, the method for building without fop, or any other optional "module" is to remove jars from the lib/optional directory. This is fine the first time you build, but they are replaced on every cvs update requiring moving/deleting them again. For anyone trying to keep up with HEAD, that means a lot of going back and figuring out which jars you don't need each time. Since the first step in debugging a problem is often "make sure you have the latest version of HEAD" this can be a real PITB. The same is true of xconf, and sitemap. I would want to be able to upgrade the core of cocoon, or any needed modules without having to manually edit xconf (currently we've added a database resource, a custom component, configured the stores, etc. in xconf) or the sitemap. Am I adequately painting a picture of the problem? Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
