> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > > Stefano Mazzocchi wrote: > > 2) each cocoon developer has the right to ask for a "whiteboard area" > > without requiring a votation, thus the directory structure will be as > > such > > > > /src/whiteboard/[area]/ > > Segmenting the scratchpad (or whiteboard) will IMO lead people to work > in their area only, and be less tempted to see what's happening in other > areas. This will likely lead to duplication of efforts and integration > problems (know Gump ?). > > Look for example at log4j's CVS : there are some "contrib/JohnDoe" > directories where some obviously dead code lies in. > > Now segmentation can be needed for proposals that either are prototyping > areas, or either impact the existing structure of Cocoon > (backward-incompatible changes). This what Ant and Avalon have with the > "proposal" directory. > > So what about 3 levels : > > - src : official distribution. > > - whiteboard : new components / extensions compatible with the current > distribution, but not (yet) officially in.
+10! Second that! Add also Gerhard's request to this: > From: Gerhard Froehlich [mailto:[EMAIL PROTECTED]] ... > Because a cool build.xml is missing, where you can build and integrate > the scratchpad easily. > It's a PITA when you have to modify the cocoon.xconf and cocoon.roles by > hand each time when you build the scratchpad. I got really angry two days > ago when I integrated my JispFilesystem Store + extra config files into > the scratchpad, because it is so circumstantial. > > What I did, I added a include.scratchpad.lib switch into the build.xml > file to include at least the scratchpad libs into the war file. > > What we need is a sophisticated build file. And I address this to seniors > in this project. ... And we have an easy way to develop/try knew components (like coming MathML). > - proposal/[area] : "thou who enters in, abandon all hope" ;) Code may > not even compile ! There may be a build.xml, duplicated libs, forks of > existing code, etc. > > Important point : forbid [area] names to be people's name. We're all > working on Cocoon, and what identifies who's done what is the @author in > sources. People should not build their private house with fences around > in this community. Agreed. > Now +1 for the install / description files. +1, Same here. > > Sylvain > Vadim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]