Re: Cocoon 2.1 the usability release?

[Robert Simmons]

One other feature would be more extensive documentation in the API. To see what I mean, look at the class level documentation on LinkSerializer. Hrmm ... I still don't know what it does. Perhaps its time to bust people's chops to document things.   What I meant about the component documentation, by the way, is basically what is listed if you look at the package page in the API for the various components.   -- Robert ----- Original Message ----- From: Robert Simmons To: Cocoon Users Sent: Monday, January 27, 2003 12:23 AM Subject: Cocoon 2.1 the usability release? Given the recent discussion about the difficulty getting into cocoon, I am wondering if we should start an initiative to make a maintenance release for cocoon that would have a focus on usability for new users. The following is a list of features I propose for this release.   1) A binary distribution stripped of all examples and documentation. This distribution would have only a single static XML and XSL file in a subdirectory called welcome that would be set up as a welcome page. The main sitemap file in the cocoon root directory would have anything not needed to serve this page as HTML commented out or removed. It would contain the mount only for that part of the site.   2) A all of the jars are filed into a single containing jar called cocoon-all.jar and placed in the WEB-INF/lib directory. This should remove "jar shock" from the users new to the system while retaining the modularity. A user can always unpack the cocoon-all.jar or replace a jar in the file if he chooses.   3) A new jar called cocoon-ext.jar. This jar would contain only the needed classes for compiling extensions (such as generators) to cocoon. It would be for users to mount in their development IDEs instead of having to mount the entire cocoon-all.jar. In the distribution, a new directory called dev-libs would be created and this jar would be placed in there.   4) All properties and xconf files that the user doesn't need to routinely edit would be packed into the cocoon-all.jar. The code loading these files would be adapted so that if a user chooses to provide his own xconf files (at his own risk), he can do so. Perhaps the code looks for custom-cocoon.xconf  in the classpath and if it doesn't find it, then it loads the default one in the cocoon-all.jar.   5) Creation of all of these parts would be in the build.xml file, perhaps we can use the target name "golfball" for building the whole cocoon-all.jar. *smirk*   6) Providing both the full documented kitchen sink as well as the stripped jar for binary distribution download.   Features id like to see:   a) Replacing logikit with Log4j. Log4j is by far the most widespread of the logging packages used today and users will typically want to have all of their logging functioning in one product. That way a network admin can use a Log4j viewer tool to monitor the health of the system instead of needing to parse several logs.   b) A reference manual on all the included generators, actions, serializers and so on: and what they do. The target audience for this is the sitemap developer who just wants to wire together pipelines.   b) Reorganization of the documentation to allow a more coherent approach to learning cocoon. Starting with including basic newbie guides to get hello-world up in 15 minutes or less. Users that can get it working fast get excited and go further and faster. Its the hook that draws them in.   Keep in mind I am coming from a usability point only. My basic premise is that newbies coming here will mostly not have the tenaciousness that I do and will be under deadline guns. Hooking them on cocoon by getting them in the door can only be good for the project and its technology.   -- Robert