On Monday, April 29, 2002, Nicola Ken Barozzi wrote:
> We are in the process of touching the build system to make it easier for > users to build and deploy Cocoon. This is exciting news! > The interactive, installwar and installscratchpadwar targets have been a > first try in that direction. > > What do you think of them, and what would you like to see in the Cocoon > build-installation? + I don't think the default build target is newbie-friendly. I wish typing ./build.sh would bring up projecthelp options. Perhaps there needs to be separate user and developer/advanced build.xml files. + Newbies trip up all the time about how and when to to build clean. Perhaps it needs to be recommended -- interactively -- as an option before a build for a selected target begins. + I wish projecthelp options were more verbose about the "real world" purpose of the targets. Why is there no information at all about subtargets? IMHO are just too many concerns mixed into the single build file. + I think most users miss the fact interactive builds exist. Even if you notice the interactive build files in the tools directory, it's not obvious how to use them. + I'm wonder exactly how many users actually "build" their Cocoon WARS, as opposed to those who simply download the binary version. Do you have access to download statistics? > Please comment and add at will; detailed descriptions of use cases are > very > welcome. > > [ ] default interactive build This would help. Make sure there is some degree of error recovery, if possible with ant. For example, some interactive builds fail if you input the wrong data. This is a little frustrating. > [ ] creation of minimal Cocoon WAR This would be wonderful, but I think opinions will vary as to what is truly "minimal." Perhaps even a minimal build could include some additional degree of interaction? > [ ] creation of personalized build - choose optional components Great, assuming it includes sitemap and cocoon.xconf synchronization. > [ ] GUI installation (how?) Not a high priority for me. Seems to me ant should be sufficient, along with a little more echo-based feedback as the build process unfolds. > [ ] Add your wish + I'm not sure this is the responsibility of a build tool, but there's always a concern, when I'm learning a new software, about when to apply patches, test new scratchpad features, etc. For example, let's say I have my finely tuned Cocoon project, working perfectly, but I'd *really* like to try some new thing announced on the list. I'd like to add this new functionality to my setup, but be able to back out of it, if possible. In other words, deconstruct a build. Perhaps this is a "best practice" tip about working effectively with cvs, not the domain of a build tool. + Is it even practical to think you could generate a head or release target out of a one build session? + Different configuration files, based on the goal of the build target, e.g. development vs. production, recommended memory/cache settings, based on deployment environment, etc. I would love to volunteer for usability testing, down the road, if you need some feedback! Thanks a lot. Diana --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
