cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <ghow...@crosswalk.com>
Subject RE: Extending the build system for modules
Date Wed, 14 Aug 2002 18:35:24 GMT
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message