Hi Ivelin, In the near future I plan on donating this: http://www.superlinksoftware.com/cocoon/samples/bringmethis/ along with documentation on the pieces of it, why they were used, "best practices", etc. The intent is for this to serve as a "pet shop example" minus the recent connotation. I hope others will help refactor it into *best* practices, etc.
Now, do I think this should be CLOSELY associated with Cocoon (read: docs featured on the website, stored on apache.org, YES) Do I think it needs to go in the xml-cocoon2 module? Not necessarily. Do I hope to be a committer of cocoon-apps? Absolutely (it will be a pain in the a** for anyone else to keep up with the patches to the bringmethis reverse auctions example). Do I think that should make me a committer to xml-cocoon2 module? No. So while I understand your concerns, I think we need this BECAUSE documentation is a priority for Cocoon. Secondly, look at the new cocoon documentation wiki: http://outerthought.net/wiki/Wiki.jsp. Notice the activity! Its been DAILY! And already I think there are several better examples of how to configure the sitemap than in the Cocoon doc body. -Andy Ivelin Ivanov wrote: >Thanks for the clarification. > >I like the idea of splitting applications as a parallel CVS repo for >mutliple reasons. > >However is the number of Cocoon apps really big enough to expand beyond >scratchpad just yet? > >Wyona, CocoBlog, Portal. What else? > >Slashedit is a demo, not a full blown app. Wrong? > >I consider the Authentication, XMLForm & i18n extensions, which need to >mature and eventually become part of 2.1 core. > >Isn't it most important to stabilize the build, finish the documentation >effort and prepare cocoon 2.1 with forrest for prime time. > >If I remember correctly Stefano's release plan, he wanted 2.1 early next >year. One year release cycle is a good rythm that we shouldn't disturb if >possible. > >Are we not taking on too many tasks at once, risking neither one to be done >right and within a reasonable time frame. > >A month ago everyone was very excited about Dianna's initiative to >coordinate the project documentation. Now, there are hardly any emails on >the cocoon-doc list. We moved to the next exciting thing...again. > >Documentation is still a big problem. >Look at the emails on the cocoon-user list. People are asking for >documentation and examples. >Let's finish that first and then integrate with Forrest. > >Am I totally out of whack here ?-) > >Cheers, > >Ivelin > > > >----- Original Message ----- >From: "Andrew C. Oliver" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Thursday, August 08, 2002 9:03 AM >Subject: Re: [PROPOSAL] Cocoon-apps CVS module > > > > >>Ivelin Ivanov wrote: >> >> >> >>>Seems like I am reading emails backwards. >>>Would the cocoon apps be an alternative to scratchpad or independent of >>> >>> >it? > > >>> >>> >>scatchapad = immature extensions to Cocoon >> >>cocoon-apps = Cocoon based applications, such as example apps, >>cocoon-based solutions like Cocco blog. >> >>Committers to cocoon-apps would *not necessarily* be committers to >>Cocoon. All cocoon committers would >>be committers to cocoon-apps. >> >>Lucene already does this. >> >>It wouldn't have full project status. >> >> >> >>>----- Original Message ----- >>>From: "Steven Noels" <[EMAIL PROTECTED]> >>>To: <[EMAIL PROTECTED]> >>>Sent: Thursday, August 08, 2002 7:42 AM >>>Subject: Re: [PROPOSAL] Cocoon-apps CVS module >>> >>> >>> >>> >>> >>> >>>>Andrew C. Oliver wrote: >>>> >>>> >>>> >>>> >>>> >>>>>I'd like to see a seperate CVS module (irrelevant of Cocoblog) for >>>>>cocoon-apps. Which is for sample applications >>>>>using cocoon. The bar for giving people commit access would be lower >>>>>than the core. The main purpose would be >>>>>to encourage folks to write example apps. Such usage example would be >>>>>REALLY useful to me. >>>>> >>>>> >>>>> >>>>> >>>>Please remember that you will need to provide *every* cocoon-app >>>>committer with commit rights for that module. From >>>> >>>> >>>> >>>> >>>> >>http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=HEAD&content-ty >> >> >p > > >>>e=text/vnd.viewcvs-markup, >>> >>> >>> >>> >>>>I gather it will be pretty debatable whether we want this or not. >>>> >>>>Warning: I'm not being the Apache commit status elitist here (I'm just a >>>>neighbourhood Forrest committer anyhow), but I believe cocoon-apps >>>>should be regarded as an xml.apache.org subproject, *or* that the PMC >>>>should come up with a solution. >>>> >>>>Anyway, I shouldn't be posting anymore since I want to go home early >>>>today, and I'll be off-list for two weeks anyhow. Just make sure that we >>>>are able to live with the consequences of our decisions. We already have >>>>a Hall of Fame of considerable weight >>>>(http://xml.apache.org/cocoon/who.html), not sure whether we want to >>>>open up the gates for *everybody* who comes up with some Cocoon-based >>>>app. Even so, there should be rules laid out - *prior* to moving >>>> >>>> >forward. > > >>>></Steven> >>>>-- >>>>Steven Noels http://outerthought.org/ >>>>Outerthought - Open Source, Java & XML Competence Support Center >>>>[EMAIL PROTECTED] [EMAIL PROTECTED] >>>> >>>> >>>>--------------------------------------------------------------------- >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>For additional commands, email: [EMAIL PROTECTED] >>>> >>>> >>>> >>>> >>>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, email: [EMAIL PROTECTED] >>> >>> >>> >>> >>> >>> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, email: [EMAIL PROTECTED] >> >> >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
