Re: Please remove me from maillist!
On 3/07/2003 3:32 steeven wrote: Please remove me from maillist! Can NOT unsubscribe the list :( Here you go (hopefully). If not, please get back to us. Being a bit friendlier would be nice, though, since there's a good chance you've subscribed yourself. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: JXTemplate* and FOM moved to core
On 8/07/2003 8:03 Christopher Oliver wrote: I've moved the FOM implementation and JXTemplate* to the core. For now I've left the original flow implementation in place as a second interpreter, so Woody, Linotype, XMLForm, and the Flow samples will continue to work without change until we can migrate them. Petstore, JXForms, and Garbage are still in the scratchpad but have been updated to use FOM. For the moment, the new FOM interpreter is called javascript, and the original interpreter is still called JavaScript. To me the most important next step is to update the documentation, so that's what I'll try to do when I have time. Thanks, Chris! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: cvs commit: cocoon-site/site/2.1/*
On 9/07/2003 0:02 Joerg Heinicke wrote: A complete website update would take hours ... and megabytes ... This was only the root directory (for removing links to invalid mail-lists.html) and nearly 1 MB. But it seems that I can not login on daedalus as written at daedalus. Whom should I ask? Can someone else do the update? I'll try give it a go 'tomorrow' afternoon. Are we using Forrest CVS HEAD now? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Alternatives to XMLForm: what's the state of art?
On 9/07/2003 15:32 [EMAIL PROTECTED] wrote: My question is: have you done this and incorporated this features from xmlform.org into the JXForm? I don't know whether Ivelin or anyone else had backported any of the xmlform.org changes into Cocoon CVS, be it in XMLForm or JXForms. I don't even know whether xmlform.org can still be considered 'alive' - or else maybe the implementation is considered to be finished. Either case, I would strongly suggest to ask for a definitive statement about merging/backporting or intentions to do this from the xmlform.or people, since that code hasn't been developed inside the Cocoon community. I understand this is a problem for current XMLForm users, but we cannot support something which has no development community around it (that's a neutral constatation). With two other frameworks, JXForms Woody, both supported by active committers, even if a bit rough around the edges, I think we offer decent diversity and choice for form handling in Cocoon. HTH, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: New lists at gmane
On 10/07/2003 15:01 Andreas Hartmann wrote: Hi Cocoon developers, could anyone update the new list addresses at gmane? I guess this needs an account, doesn't it? I guess you just have to notify the gmane admin - there's an email addy on that website somewhere will you take care of that? cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Discussion of Cocoon TLP Guidelines
Dear all, I've just checked in a verbatim copy of the Jakarta Guidelines (located at http://jakarta.apache.org/site/proposal.html) in the cocoon-site module, that could serve as a starter to base our own project guidelines upon. Before we became a TLP (top level project), we were supposed to follow the XML TLP guidelines (which are currently under debate, a decent RC can be found at http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=1.14content-type=text/vnd.viewcvs-markup), but after reading both, I believe the Jakarta guidelines might be a good foundation to start working from. The guidelines are supposed to regulate the day-to-day operations of the Cocoon TLP, which of course includes any existing and possible new subprojects. So in an attempt to start the debate about the Cocoon TLP guidelines, I copy/paste/search/replaced through the Jakarta set of guidelines, and provide this as a starter for further discussions. Our DRAFT version is located at http://cvs.apache.org/viewcvs.cgi/cocoon-site/src/documentation/content/xdocs/guidelines.xml?rev=1.1content-type=text/vnd.viewcvs-markup Some topics which, IMHO, need further debate are: - PMC composition and rules for admitting new PMC members (currently, any committer can self.propose() to become a member of the PMC, and any committer is allowed on the PMC list - but we need to discuss, maybe change and at the very least formalize this) - rules and guidelines for incubating projects, w.r.t. PMC participation, cohabitation with Incubator guidelines - basically do a sanity check of the lenghty Jakarta original and see what might be eradicated from it (less is more) - check voting guidelines I would suggest to start the discussion over here ([EMAIL PROTECTED]), we can move to the Wiki if discussing the document becomes too difficult, and in any case I'd like to use the formal CVS logs as a change tracking mechanism ASAP - hence putting a draft in CVS rather than in the Wiki. I will come up with some patches myself, but not directly in CVS, I'd like to run them through the list. Please take your time reading through it, it ain't as bad as it looks like, and it concerns you: developers contributors of the Cocoon project(s). And let's try and keep this as lightweight as feasible. If it comes to (a) vote(s), anybody's opinion is appreciated, so please speak up. Binding votes about the Cocoon guidelines can be cast by Cocoon committers only - the original members of the 'founding' PMC that is. If that would need to be changed, it's the time to implement that, as well. Thanks for your attention, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: cvs commit: cocoon-site/src/documentation/content/xdocs guidelines.xml
On 29/07/2003 11:34 [EMAIL PROTECTED] wrote: cziegeler2003/07/29 02:34:47 Modified:src/documentation/content/xdocs guidelines.xml Log: Typo -allowing them to affect the future of the subproject./p +allowing them to affect the future of the project./p Euh: it still must be subproject, I guess. The Cocoon TLP project is structured as follows: Cocoon TLP (has a PMC) - Cocoon (Sub) Project (has committers) - Lenya (Sub) Project (has committers) (under incubation) Of course, since the Project groups the Subprojects, a committer, by changing a Subproject, is changing something within the Project /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [RT] Revisiting Woody's form definition
On 29/07/2003 18:17 Sylvain Wallez wrote: Marc Portier wrote I do understand this might break some backwards compat stuff, but the block is labeled 'unstable' and 'alfa' precisely because we know this is bound to happen nevertheless Bruno is doing an effort to notify the users list of important changes in the usage of Woody (making sure were not abusing our early adopters here)... I would like us to continue that effort Can't we provide a compatibility mode by running an XSL transformation to the newer format triggered by an older namespace ? Speaking against my own case: I would seriously loath to see _already_ compatibility layers being introduced into Woody at this early stage. If Woody is to become a real value proposition for some serious form handling in Cocoon-space and the community is willing to refactor (and break compatibility) the hell out of it to arrive at this stage, I find the current rate of adoption of Woody isn't big enough to already warant compromises and compatibility stuff. I find it much more important that as much people as possible intellectually 'own' Woody's design and code than having to explain early adopters (even if we (=OT) made them do so) that stuff will be breaking from here until Woody stabilizes. I'm pretty sure these early adopters will see the value of using code that is 'owned' by more than OT-peeps only. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
On 30/07/2003 0:13 Michael Wechner wrote: Steven Noels wrote: If it comes to (a) vote(s), anybody's opinion is appreciated, so please speak up. Binding votes about the Cocoon guidelines can be cast by Cocoon committers only - the original members of the 'founding' PMC that is. I guess that as long as Lenya is under incubation, Lenya committers won't be able to vote, right? Which is fine with personally, but I think it's important to clarify what you mean by *original members of the 'founding' PMC* the situation with xml.apache.org is that all committers can vote for new subproject proposals (and it needs a majority vote), and that PMC peeps get to vote on chapter changes IIUC of course, we are setting everything up as we go along, and it's a bit of a chicken/egg problem: *we* should decide whether committers of incubating projects can cast binding votes in this matter, and if I state that such 'incubating' committers are allowed to vote on such a decision, well... I think the outcome would be pretty obvious ;-) aside type=pmc chair hat offThere's another thing about project incubation that kinda interests me: what happens upon incubation failure? To me, there's a difference between the people and the project involved. The subproject can fail, but committers of failed incubation projects can still stick around - even though committers are very much tied to (sub)projects. In this sense, I think any committer, even if this used to be for a now-failed incubating project, has been deemed worthy once to carry the Apache feathers, so he/she should be able to speak up on regulatory matters. Collaterally, since Lenya peeps are apache.org peeps with a particular interest in Cocoon, I wouldn't mind if they cast binding votes on the formation of the Cocoon charter./aside /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [ANN] Apache Cocoon 2.1 Release Candidate
On 30/07/2003 11:25 Carsten Ziegeler wrote: The Apache Cocoon team is proud to announce the new release of Apache Cocoon. ... which was again a masterly execution of the CaRsTeN-3000-meepzoid-release-bot. Thanks! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [ANN] Apache Cocoon 2.1 Release Candidate
On 30/07/2003 11:25 Carsten Ziegeler wrote: The Apache Cocoon team is proud to announce the new release of Apache Cocoon. I went in afterwards and edited README.html, .htaccess and HEADER.html in order to downsize and rationalize the download area (http://www.apache.org/dist/cocoon/) - please crosscheck. Carsten, I found some files (a symlink) which aren't chmod g+w - could you change these? lrwxr-xr-x 1 cziegeler cocoon32 Jul 29 02:16 cocoon-2.1rc1-src.tar.gz lrwxr-xr-x 1 cziegeler cocoon29 Jul 29 02:16 cocoon-2.1rc1-src.zip Also, the +x bit shouldn't be set on .sig files in the SOURCES directory. Thanks! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
[less is more] interestiing blog from Michael Feathers
http://www.artima.com/weblogs/viewpost.jsp?thread=8826 Good morning, all. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [ANN] Apache Cocoon 2.1 Release Candidate
On 31/07/2003 13:27 Stefano Mazzocchi wrote: I removed references to the publishing framework and added a CSS stylesheet to both the cocoon directory and lenya's using a headinsidebody hack (dirty, but it works on all the browsers I tried and it downgrades nicely). looking very nice, thanks! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: J2EE+native http 1/3 performance of integrated server!
On 31/07/2003 13:28 Nicola Ken Barozzi wrote: On page 15 I read that from the tests, they found out that running a native webserver and a J2EE container on the same machine was *1/3* of the performance of the integrated solution. Does this mean we should all go for Orion, Jetty, or (hm) Tomcat in standalone mode then? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
On 31/07/2003 13:35 Stefano Mazzocchi wrote:
On Wednesday, Jul 30, 2003, at 18:48 Europe/Rome, Nicola Ken Barozzi
wrote:
http://blog.xesoft.com/jon.lipsky/blog/Java/
?permalink=workflow_viewlets.html
did you guys ever programmed java with JavaStudio? it was a nice little
app that sun released in the early java days. it was visual programming
of java code thru LabView style drag-drop-link of javabeans.
Yep. Sugar candy appealing to lusers like myself. :-)
It was sooo cool when you saw a demo.
Horrible to work with it.
why? visual programming is bullshit.
It take half an hour to write a visual representation of something like
if (blah) {
dothis();
} else {
dothat();
}
Still, I found the demos pretty valuable with the process variables
being explicitely being created in a separate pane. Makes one think more
about what he is doing.
The nice thing of such a GUI is that it enforces people to make use of
the exposed API, and makes hacks around it, reaching for areas where
scripting authors shouldn't come, a bit more difficult.
- 0 -
I just had a discussion in the car with Bruno about where Apples is
heading (basically he bringing me uptodate - thank you Bruno), and my
layman's conclusion is that different schools of development style are
emerging when building webapps with Cocoon.
1) glueing together ready-made available components using XSPs and the
bag of available Actions
2) Actions and custom Avalon-Cocoon components, which tend to overload
the sitemap with programmatic constructions in the long run
3) 'Webcontinuations flow with Javascript', where people depend on the
availability of Javascript wrappers for common libraries (JDBC, OR
frameworks, ...) - with the challenge of coming up with decent JS
libraries to make sure one doesn't have to reach at too many Java stuff
using 'Packages' - the really cool thing is of course the instant
gratification of save/reload/test
4) 'Apples' which shifts the encapsulation of business and service
components back to full-blown Java, with a simple Apple class calling
upon them while exposing flow decisions in a very lighweight manner in
order to call the correct pipelines
5) 'Dywel' which seems to be going after Struts practices with a nice
dash of Avalonization to go with that
3) and 4) being heavily dependent on the JXTransformer approach (which
is a Good Thing IMHO)
How we are going to manage and support these five schools of thought, I
honestly don't know (not even if we need to be worried altogether), but
I envision some some white-bearded guy is already chuckling in his
corner (http://strongbrains.com/images/darwin.jpg)
interlude advise=don't take this too seriously
More stupidity being put forward, I would humbly suggest to explicitely
name the methodologies:
1) 'Barbara', in kind remembrance of B. Post
2) 'Carsten, the Early Years'
3) 'SchemoVidiuChrismatron'
4) 'Species' - since Apples and Pears are way to generic already, and
it's what Darwin was all about
5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly
misspelled
... in order to be able to ask a Cocoonie: what religion are you in?
Oh, I used to be an early CultofBarbara groupie, but now I tend to
worship the mighty SchemoVidiuChrismatron.
/interlude
Kidding aside, is my categorization more or less correct? Might be cool
to put on a slide once.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
On 31/07/2003 14:23 Steven Noels wrote: 1) 'Barbara', in kind remembrance of B. Post 2) 'Carsten, the Early Years' 3) 'SchemoVidiuChrismatron' 4) 'Species' - since Apples and Pears are way to generic already, and it's what Darwin was all about 5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly misspelled and Bruno reminds me of Schools I forgot about: - the who said I shouldn't use Tomcat filters to manage Hibernate sessions school, just be happy that I don't system.exec() a shell script to do the same - the look at me calculating a CRC checksum of a creditcard number using XPath school of XMLForms I'm signing off for this afternoon, so I'll stop nagging the list with frivolous mails - don't you worry. ;-) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing 2.1]
On 31/07/2003 18:13 Stefano Mazzocchi wrote: Just one thing: what about moving the wiki on cocoon.apache.org/wiki/ before release? I was actually thinking of asking infrastructure@ to migrate the Wiki to the new beefy minotaur. As a transition, we could check whether mod_proxy/proxy_pass would be possible, possibly with mod_cache - people knowledgeable in this would be helpful. But from what I read on the infrastructure@ list, it appears nagoya might still be the place to go for heavy use Java apps, yet I understand Pier hasn't got time yet to upgrade/reconfigure nagoya. Infrastructure peeps: this is about the JSPWiki-based Cocoon wiki running on wiki.cocoondev.org. Having run regularly upgraded this beasty for considerable time, I can attest it's a neat Wiki implementation and runs quite well. I'd be happy to further help maintaining it anywhere it is hosted. Your comments are very much welcomed. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor]
On 1/08/2003 11:15 Reinhard Pötz wrote: For the actual code see http://nagoya.apache.org/bugzilla/show_ bug.cgi?id=21900 Marc, why don't you put Apples it into scratchpad? Karma request is in process, he isn't listed in the avail file yet. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Apache newsletter in progress
On 1/08/2003 13:04 Stefano Mazzocchi wrote: You could add a link to the GT page, so that people would know how to follow up on that (and maybe how to submit proposals for talks and stuff like that) I'm busily preparing a real website for the GetTogether and hope to get ready to have that link included in the Newsletter by August 8th. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Promotion of [XPath]TraversableGenerators to main trunk
On 1/08/2003 14:28 Vadim Gritsenko wrote: I can spell hierarchy too when not too drunk, it just takes more mental resources ;-P Is there anybody against CollectionGenerator? Could we have that with one 'l' for alcoholics, since they tend to draw anyhow? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Possible Wiki vandalism
On 1/08/2003 13:26 J.Pietschmann wrote: Hi, could someone have a look at http://wiki.cocoondev.org/Wiki.jsp?page=UnusedPages and perhaps clean up, just in case this wasn't intended... That page is autogenerated from a list of non-linked pages attachments - something I tend to clean out in my copious free time. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.5.0 now available
On 1/08/2003 15:29 Vadim Gritsenko wrote: The Xerces-J team is very happy to announce that version 2.5.0 of Xerces-J is now available. This release provides a partial partial implementation of the XML Inclusions (XInclude) W3C Candidate Recommendation Has anybody seen this / tried this with Cocoon? Our own Transformer already does XPointer XML Base. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing2.1]
On 1/08/2003 19:32 Justin Erenkrantz wrote: If you are willing to take the initiative and set it up and maintain it, we can figure out a solution that works. But, the infrastructure@ group can't/won't baby-sit everything on its own. So, at least two committers have to step up and be willing to maintain it. Of course, and count me in on that. As a starting point, I'd recommend setting up the server on a high port on minotaur and get everything working just right. Once it's all 'up', infrastructure@ can figure out what to do next. But, doing this first will ensure that all of the software can/does run on minotaur. If it doesn't run on FreeBSD (or there are problems), then you'll have to run it on nagoya (which is a Solaris box). The upgrade Pier was planning seems a bit over my capabilities to assist with, but if someone can point me out how a servlet container _should_ be installed on minotaur (where on the FS, what UID should be owning it, any related suggestions) I'd like to step up (together with Gianugo would be great) to start with a trial instance on a higher port. Integrating it with the httpd daemon in a sensible way might require access and assistance from root people anyhow, depending on the strategy we follow (mod_proxy, or mod_name_your_favourite_version_jk), so assistance in that perspective is welcomed as well. If you do run into problems, please let infrastructure@ know and we can try to help you work through it. But, it's unlikely we'll take initiative on our own. I never meant to force work upon you guys, but if there's thoughts towards a shared servlet container setup where JSPWiki for Cocoon is one of many deployed webapps, it's better to discuss here before moving in, IMHO. As an aside, have you considered using the SubWiki install? ;-) If you'd be willing to use that, I might be enticed to help you migrate to that away from JSPWiki. See: http://cvs.apache.org/wiki/ It's written in Python! Oh no! -- justin For the record: I like Python - and I'm pretty much agnostic towards specific WikiEngine implementations. But I don't like migrating 533 pages of Wiki content from one WikiEngine to another. In terms of sizing, here's some rough stats on the current instance: (per month, rough rounding) Successful requests: ~400K Average successful requests per day: ~15K Successful requests for pages: ~120K Average successful requests for pages per day: ~4K Data transferred: ~2.5 GB Average data transferred per day: ~85 MB /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.5.0 now available
On 1/08/2003 17:06 Gianugo Rabellino wrote: out implementation is partial and probably not going anywhere, theirs might be much more supported and vital. That _might_ be just the case. ;-) I wouldn't downplay what we are doing with low-level XML handling stuff, and also this often results in bugs being reported to the parser gurus. I've been doing some light XSLT development today, and I ended up being slightly annoyed with the quality of error handling in Xalan (let alone the way the eventual messages are being thrown forward in Cocoon). I'd like to see a more unified approach however to the (n)Include stuff, it might be better to extend the standards syntax with specific constructs available as features in Cocoon's own Include transformer, rather than having two Include transformers side-by-side. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Questions/Suggestions for Woody
On 2/08/2003 8:57 Marc Portier wrote: but if they all do, then you'll have to make some decissions on smart management of stylesheets and the like to get most if not everything from one (at least a limited number of) source-file... I think it will take some of us actually doing these things before we get a real feel to the matter (we plan on a smaller try-out with WML in the not too distant future) Another issue I see however is the mismatch of number of widgets per screen for each of these targets... this might call for splitting up a lot more of these sources then the big XML dream was promising :-) Still Woody could at least do a best effort to ensure that all these targets can be reached by applying the same competence mix somewhat. ... what Marc is trying to convey is that automagical multiple-device rendering and reuse of one form definition might be a dream, but very difficult to achieve. A form of set of forms represents a use-case. We are quite convinced, even if Woody might support multiple renditions, that the use-case across devices might be totally different. You typically don't want a one-on-one translation from a complicated HTML form to the set of simple widgets provided in a WAP environment: you are going to provide your users with entirely different use-case. Does that makes sense? As I said, this doesn't mean we think Woody would put something in the way of moving forward in the direction you mentioned. But a one-on-one, even a smart one auto-translation maintaining the same form model across media, might not be what your users are looking for. HTH, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing2.1]
On 2/08/2003 22:21 Justin Erenkrantz wrote: ProxyPass can't be in .htaccess. That's what I was already afraid of. Redirect directives can. But, they'll see the 'real' URL in the browser. Sure, and since we try and advocate cool URIs whenever we can, I really hope we can eventually make proper use of mod_proxy or mod_jk. If I get a chance in the next few days, I'll try to run a simple load test against it to see how the JDK fares. -- justin That would be great - I was thinking of doing the same but a bit reluctant to stress our new hardware yet. Besides, I'm no Java guru on the FreeBSD platform. I'll make sure logging is switched to WARN or ERROR only so that debug messages don't mess up performance. Thanks for your help, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
On 4/08/2003 14:02 Stefano Mazzocchi wrote: - rules and guidelines for incubating projects, w.r.t. PMC participation, cohabitation with Incubator guidelines I would say that we remove that paragraph and avoid dealing with it altogether. the part of new subprojects as well. if somebody asks, we send them to incubation right away. If the concept and process of incubation is properly defined and offers more than bouncing off the ball to the incubating PMC, I would be perfectly happy with that. So far, I think it is reasonable to say that the Incubator is still FUD with the prospect of becoming something valuable. Also, I loath to see projects being incubated without a clear destination PMC in mind. While you are absolutely correct in theory, practice is teaching us something else, so I'd like to discuss this before moving either way. Off-loading work to a disfunctional project isn't a way to get the work done. Closely collaborating with the Incubator might be better, IMHO. well, too much mentioning of vetos, IMHO, but I can live with that. Exactly - I will try and wordsmith along that way. Vetos are community killers and a discourse of distrust. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: preparation of board report
On 11/08/2003 14:42 Steven Noels wrote: Hi all, it's time to prepare our report for the ASF board meeting of August 20th. I'm looking to collect noteworthy news about our community project, and so far these are the topics I'm planning to put in the report. Comment add as you see fit: fyi: here's the previous one: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105344074224116w=2 /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
On 4/08/2003 14:02 Stefano Mazzocchi wrote: Two points in addition to Carsten's: It states that new features need to be voted before committing. I believe that this is either unpractical (and sure not happening ATM) or/and not precise enough. Perhaps major new features would be better, but then, what's major? OK, it's only a guideline I would say that anything that changes the contracts has to be voted. New features that are added sideways, don't (say scratchpad or scratchpad blocks). But anything that enter the trunk should be voted. Let's stick to contract or API changes of released versions requiring a formal vote. New stuff - I honestly don't think so. the part that indicates what to do with patches is too much to place there. I would remove it. OK - will look into that. the part of new subprojects as well. if somebody asks, we send them to incubation right away. How does other people feel about this? Most commonly, an incubating project needs a destination PMC, so we would be involved some way anyhow. Thanks, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: cvs commit: cocoon-2.1 README.txt CREDITS.txt announcement.xml
On 5/08/2003 11:49 [EMAIL PROTECTED] wrote: new marketing strategy and dealing with all the due credits and copyright restrictions Thanks for the copyright stuff! Some remarks: + Apache Cocoon is a web development framework built around the concept + of separation of concerns (that is: allowing people to do their job + without having to step on each other toes) and component-oriented web + RAD. The term RAD has a very (out)dated sound in my ears. Surely RAD is OK, but people will hear RAD and understand '4GL'. My rephrasing: Apache Cocoon is a web development framework built around the concepts of separation of concerns (making sure people can interact and collaborate on a project, without stepping on each other toes) and component-based web development. + Cocoon implements these concepts around the notion of 'component + pipelines' modelled after the 'process chain' concept where each + worker specializes on a particular operation. This makes it possible + to use a Lego(tm)-like approach in building web solutions where + these components can be hooked together into pipelines without + requiring further programming. That first sentence is very 'jserv-like'. ;-) I would reduce verbiage into: Cocoon implements these concepts around the notion of 'component pipelines', each component on the pipeline specializing on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions, hooking together components into pipelines without any required programming. + We like to think at Cocoon as web glue for your web application + development needs. But most important, a glue that can keep + concerns separate and allow parallel evolution of the two sides, + improving development pace and reducing the chance of conflicts. What two sides?... Also, maybe we should sound a little bit stronger: Cocoon is web glue for your web application development needs. It is a glue that keeps concerns separate and + Cocoon has been designed to interoperate side-by-side with your J2EE coexist and interoperate? (introducing more verbiage ;-) + existing solutions or give them new functionality without requiring + any change in the existing infrastructure. snip/ +This product includes software developed by the IronSmith Project +(http://www.ironsmith.org/). Eh? +Portions are Copyright (c) 2001 Tivano Software GmbH +(http://www.tivano.de). All Rights Reserved. Eh? +Portions are Copyright (c) 2001 Scott Robert Ladd. All rights reserved. Eh? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [QUICK-VOTE] Release Date for 2.1 final
On 12/08/2003 10:22 Carsten Ziegeler wrote: Reinhard Pötz wrote: Shouldn't this text be part of the website and the documentation (src\documentation\xdocs\index.xml)? Yes, can someone take care of it. Note: I didn't start the release process yet, so there is enough time. I'm CVS updating as we speak and will finish this before noon (Europe time). /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [QUICK-VOTE] Release Date for 2.1 final
On 11/08/2003 15:16 Reinhard Pötz wrote: Last week there were some mails about a new (and better) description of Cocoon that reflects that it is a Web Application framework too. Is it already included into the documentation (first page) and the site CVS? I don't think so - but the discussion was on the list. I can't look into this before tomorrow, so if anyone would check the archives and change accordingly, that would be great. http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106010158816970w=2 /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [QUICK-VOTE] Release Date for 2.1 final
On 12/08/2003 11:24 Steven Noels wrote: I'm CVS updating as we speak and will finish this before noon (Europe time). Done - please cross-check. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing2.1]
On 2/08/2003 22:21 Justin Erenkrantz wrote: On Sat, Aug 02, 2003 at 10:16:47PM +0200, Steven Noels wrote: I tried mapping this under the final destination URI space cocoon.apache.org/wiki/ by adding a .htaccess directive under the cocoon.apache.org document root on daedalus which reads as follows: Proxy * Order deny,allow Allow from all /Proxy ProxyPass /wiki/ http://minotaur.apache.org:38080/ ProxyPass can't be in .htaccess. Redirect directives can. But, they'll see the 'real' URL in the browser. If I get a chance in the next few days, I'll try to run a simple load test against it to see how the JDK fares. -- justin The trial instance has been up on minotaur (http://minotaur.apache.org:38080/) for little more than a week - so I was wondering whether anyone already had been load-testing it. So far, it seems stable, even after dualit.netcraft.com has been hitting it with a lot of exploit URLs. I'm able to do some load testing myself, but don't want to interfere with ongoing operations, and I'm sure people over here know better where to watch for. Also, I would like your advise as to how to mount the new Wiki location in the cocoon.apache.org namespace: using mod_proxy or mod_jk, and also what we should do with (Tomcat) access log files: disable them and let httpd take care of logging, or add some log rotation scripts. Thanks, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Help for Release
On 12/08/2003 13:47 Carsten Ziegeler wrote: Hi, I'm just uploading the release to our dist directory. As I have to do some work for the rest of the day :(, can someone please update our website and the README.html and HEADER.html? Done. Please cross-check. I will give the mirrors one day time and send the release mail tomorrow. Maybe wait until late evening so that the changed README.html and HEADER.html are mirrored as well. My nearby mirror (http://www.apache.org/mirrors/#be), which has a good reputation, hasn't sync'ed the new dists yet. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Flow + Hibernate sample offer
Jeremy Quinn wrote: But I suggest you create a Wiki page and add your example as a zip file to this page. Instead of having links to your own CVS. or cocoondev as Vadim suggested . who do I approach for cocoondev ? Me. I'm a bit swamped ATM, but will try and follow up ASAP. Hm. Maybe it doesn't warrant a full 'project' on its own, with separate mailing list and CVS module and all that. I might as well make a general purpose CVS module for license-incompatible Cocoon-related scratchpad thingies on cocoondev.org, and give anyone who wants commit access. Will think some more! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Flow + Hibernate sample offer
Vadim Gritsenko wrote: I meant your code (if any) which has imports of hybernate packages. I'm not sure that it can have ASL/BSD license. If it's stored in Apache CVS and redistributed with Cocoon, it can't. Outside Apache, you can't add (c) ASF anyhow, since you're operating on your own, but you are perfectly free to copy the license verbatim, change it into (c) Jeremy and import/invoke LGPL'ed method signatures. You might however inform your users that the no-strings-attached redistribution clause of ASF/BSD-style licenses isn't necesseraly compatible with clause 6 of the LGPL license, and that the FSF goes at length in denying the existence of this problem. If the Hibernate peeps change the license for their API, that's something entirely different. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
accessing sitemap parameters in a flow script
Hi all, I guess the title says about all. ;-) I want to dynamically load a Woody form definition, its name being based on the URI invoking the flow function. What's the easiest way to do this? I saw some very similar questions pass by, but I fail to find out whether this is already implemented, and if so, whether one can access the parameter by name, instead of depending on the sequence of attributes. Thanks, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: accessing sitemap parameters in a flow script
Sylvain Wallez wrote:
map:call function=foo
map:parameter name=bar value=baz/
/map:call
and
function foo() {
var x = cocoon.parameters[baz];
}
Easy, no ?
Ha. ;-)
Added to the Wiki. :-)
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
[ot] effective copywriting
http://today.java.net/today/news/#http://jakarta.apache.org/site/elsewhere.html#20030813.1 Thanks, Stefano, for the nagging about our lousy marketing. It was inspiring, and even if it costed me some sleep during a late night rush of wordsmithing, it's nice to read these words on today.java.net :-) This release marks the transition from being a publishing-oriented XML/XSLT server engine to a componentized XML-based web application development framework. Let's go, and humbly, silently, kick some ass. :-D /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: HTMLGenerator
Vadim Gritsenko wrote: Switch to google *immediately*! Say, http://directory.google.com/ -- that's what we were pulling from yahoo What about http://news.google.com/news/en/us/technology.html Should be less static. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon2.1 Released - binary??)
Jay Freeman (saurik) wrote: Are you recommending that I do all of my development as a patch to a sitemap rather than as a sitemap, It won't help you ATM, but for the xconf, that's the way we work with Cocoon on our projects... the project sitemap however is mounted as a subsitemap, and contains explicit definitions for all components relevant to that project. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: preparation of board report
Steven Noels wrote: Hi all, it's time to prepare our report for the ASF board meeting of August 20th. I'm looking to collect noteworthy news about our community project, and so far these are the topics I'm planning to put in the report. Comment add as you see fit: * ramping up towards a 2.1 release * the noteworthy, tough but fruitful discussion about Flow balcanization * first (baby)steps towards form handling framework unification * new committers * Lenya's ongoing incubation + intention to participate with the GT * (slowly) ongoing effort to migrate the Wiki - ASF equipment * charter discussions (I hope to be able to attach a revised voted-upon charter for approval by the board, so stay tuned for more) OK, here's the report I'll be sending out tomorrow noon 12:00 CET: - 0 - Here's the report on Cocoon's state of affairs. We do hope this gives the board a feeling on how we are doing. Let's first start with a brief run-through of the previous report (http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105344074224116w=2) and see how we proceed: 1), 2), 3): no further action required or taken 4) recursive Cocoon charter: still needs to be worked upon 5) use of Cocoon brand by cocoondev.org and cocooncenter.com: ditto 6) ditto - work is slowly progressing with the infrastructure team to migrate the Cocoon wiki to ASF infrastructure, together with Steven Noels and Gianugo Rabellino from the Cocoon team - we believe it is fair to indicate that an ASF-operated shared and managed Java hosting service might accelerate this, and do hope the eventual migration of our Wiki might serve as an example to move further along that road. 7) solved: the XMLForms effort is being actively deprecated in favor of other form handling frameworks (JXForms and Woody). 8) transfer of HSSF (Excel) serializer from Cocoon - POI: no further action has been taken yet. 9) Avalon Excalibur dependencies: Cocoon committers have now commit karma to an Avalon CVS module that hosts code in heavy use by the Cocoon project, making sure bugs can be fixed and patches applied in due time. 10) the Milestone release scheme has been applied successfully, and has resulted in a 2.1 release mid August. 11) Lenya incubation is still ongoing and monitored by the Cocoon PMC. 12), 13), 14): satisfactory ongoing. New matter: 1) The Cocoon project has released a 2.1 version mid of August, and work is under its way to release a forthcoming 2.1.1 quickfix release. 2) Discussions are starting on the upcoming 2.2 development. 3) Most notable discussion was about the existence (and/or creation) of several overlapping ideas and frameworks for flow and form handling inside Cocoon, and even though the discussions were lenghty, at the verge of being flame-infested, the main discussion participants came to an agreement, showing off the maturity of the Cocoon community even when starting off from a discours of extreme technical dissonance. 4) As a result of all this, work is under its way to refactor and augment specific form handling code (Woody) into a truly community-owned artefact, and API changes have been allowed to make sure specific implementations (JS Flow with Continuations) leave room for alternatives, should the community see fit. 5) Several new committers since the previous report: Ugo Cei, Marc Portier, Guido Casper, Reinhard Pötz, Upayavira and Joerg Heinicke. There's a de facto policy that all committers can subscribe to the PMC list, but formalization of this, and whether this means they can cast a binding PMC vote still needs to be discussed. There's a certain tendency that there should be no distinction between active committership and PMC membership. Lenya hasn't signed up any new committers since it went into incubation, yet. 6) The Cocoon project guidelines and revised charter are under construction, being based on a de-formalized branch of the Jakarta ones. Overall, the Cocoon project is a healthy and friendly community working along the Apache spirit, and we expect no sudden problems to emerge. - 0 - Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Database.js
Hi peeps,
I'm messing around with the GetTogether registration page, which gives
me a chance to test all this new wonderful Woody flow stuff, but I'm
stuck on the usage of Database.js. I'm not planning to use any O/R
mapping, since I'll have two tables at most.
In PetStoreImpl.js, there's a code fragment that reads:
PetStore.prototype.getConnection = function(id) {
if (true) {
// temporary hack to avoid requiring datasource config in
cocoon.xconf
java.lang.Class.forName(org.hsqldb.jdbcDriver);
var jdbc =
java.sql.DriverManager.getConnection(jdbc:hsqldb:., sa, )
var conn = new Database(jdbc);
if (this.hsql == null) {
// keep hsql in-memory database alive
this.hsql =
java.sql.DriverManager.getConnection(jdbc:hsqldb:., sa, );
}
return conn;
} else {
// lookup datasource in cocoon.xconf
return Database.getConnection(id);
}
}
but since I want to use my cocoon.xconf datasources config, I'm trying
to set up a connection using:
cocoon.load(resource://org/apache/cocoon/components/flow/javascript/Database.js);
Registration.prototype.getConnection = function(id) {
return Database.getConnection(id);
}
and:
var conn = this.getConnection(id);
somewhere.
I'm greeted however with the interesting message: The undefined value
has no properties. Has anyone already played with this? I'm looking for
a snippet of sample code, without the weight that Petstore carries, to
open a connection to a cocoon.xconf-defined pool.
Thanks,
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Re: Woody flow example do not work
Leszek Gawron wrote:
I do not think it's a thing to be put into bugzilla so it goes here:
while the standard woody form example is fully functional the flow version
does not allow you to add or remove a contact.
We've debugged this offline already (Marc and myself during a car ride
this afternoon), and changing line 156-157 into:
if (validator != undefined) {
finished = validator(this) finished;
will solve this as far as we can see now. But since Sylvain was quite
specific about this in his commit changing the original version some
days ago, we've not patched this before getting the word out to him.
Anyway, the reverting patch is attached if you can't wait.
Cheers,
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Index: src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js,v
retrieving revision 1.8
diff -u -r1.8 woody.js
--- src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js 16 Aug
2003 13:22:28 - 1.8
+++ src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js 20 Aug
2003 18:37:12 -
@@ -153,8 +153,8 @@
} else {
this.submitId = undefined;
}
-if (finished validator != undefined) {
-finished = validator(this);
+if (validator != undefined) {
+finished = validator(this) finished;
}
if (finished) {
break;
Re: Need help fixing a Woody flow sample
Marc Portier wrote: in terms of best practice I would probably be advocating the use of jxtemplate in combinaion with flow rather then xsp +1 JXTemplate is massive but works nice and dandy. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: can you reach sitemap params from JXTemplate?
Jeremy Quinn wrote:
On Thursday, August 21, 2003, at 10:27 AM, Unico Hommes wrote:
What build are you using. This wasn't working a few weeks ago but has
been fixed.
2.1.1-dev, a couple of days old.
... and I'm running into the same problem, with HEAD from this afternoon.
sitemap:
map:match pattern=foo/*/bar/*
map:generate src=forms/{1}-baz.xml type=jx/
map:transform src=style/site2html.xsl/
map:serialize/
/map:match
jxpage:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
[...]
jx:choose
jx:when test=${parameters.getParameter('status') == 'success'}
pWe love you./p
/jx:when
jx:otherwise
pUnfortunately, the processing of your payment failed./p
/jx:otherwise
/jx:choose
[...]
/content
/page
I also tried any permutation of JEXL and JXPath, but no luck.
Some thoughts aside:
- The contract for exchanging (named) parameters between sitemap,
flowscript and jxtransformer needs to be solidified (but we knew that)
- I'm slightly annoyed by the abundance of choice with JEXL and JXPath.
Wouldn't it be better to stick with only one of them?
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Re: can you reach sitemap params from JXTemplate?
Tony Collen wrote: Steven, When I tried wrapping my head around this stuff, I was boggled at the choice of two different syntaxes. IMO this is a weakness and we should choose one or the other, but having both makes everything a million times more complicated. Sure. Another thing for the JXTransformer todo list: taking into account XML comments. When I'm debugging, I put sections of jxpage code inside a comment. They are still executed IIUC. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [WIKI-UPDATE] Main Eventos ExampleApps LeftMenu Fri Aug 22 17:00:052003
[EMAIL PROTECTED] wrote: Page: http://wiki.cocoondev.org/Wiki.jsp?page=Main , version: 224 on Fri Aug 22 14:01:55 2003 by 80.58.50.235 - Welcome to the little Cocoon documentation Wiki. It is not large, it is not small, it is simply available to anyone actually feeling like adding some info to complement what's on the [main Cocoon web site|http://cocoon.apache.org/]. Type away! Explore the publicist in You! + Welcome gay marcos to the little Cocoon documentation Wiki. It is not large, it is not small, it is simply available to anyone actually feeling like adding some info to complement what's on the [main Cocoon web site|http://cocoon.apache.org/]. Type away! Explore the publicist in You! ?+++ OK, that was interesting. deny from 80.58.50.235 If anyone else sees obvious trolls, please tell me. Now, go away, idiot. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote: I know, actions are not liked by everyone, but this is one of the best applications for them. are you suggesting we don't think about adding interception in flow because otherwise this would kill the only place where actions have a reason to exist? So, please provide a more convincing use case for the introduction of AOP in Cocoon ;-) Yawn... ;-) I still believe authentication code should be orthogonal to actual application logic, and rather be defined by the container. In this discussion, I think 'sitemap' == 'container'. Also, since authentication-requiring realms are a part of the overall URI namespace, when finding out which parts need authentication, I would check first with the container (web.xml) - sitemap.xmap - flowscript. Not making authentication handling part of your application is one of the first things I learned over here, when greeting Giacomo at ApacheCon in London. So, if you guys are talking about authentication with actions vs flowscript interceptors, what are you talking about: doing the authentication, or checking authorization? I'm curious and want to understand better. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: If you talk to os kernel folks, they think authentication should happen right at TCP/IP stack level, if you talk to httpd, they will give you an apache module, if you talk to servlet engine folks, they will give you a web.xml descriptor or, if you are lucky, a servlet filter, if you talk to sitemap lovers, they will give you an action. Out-of-the-blue-thought (and I had way too much wine last night): shouldn't this 'action-in-sitemap' thing be alleviated by an 'orthogonal-to-the-matchers' thing in the sitemap? So that you end up with a section in the sitemap describing the content-generating artefacts, and another one listing the authentication realms, maybe using the same matcher-like constructs describing which portions of the URI space should be protected? I'm having the slight feeling we are moving stuff into flowscript that can mess up good URI practices. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: One day I hope the anti-flow/pro-action people will simply stop sneaking doubts and come up with real arguments on why we shouldn't heavily bet on the flow. I thought we were done with this balkanization thing, didn't we? I for one have just finished my first tiny flow-based application, and while I still find the edge layer where Java Javascript meet each other quite murky, I had good fun while hacking on it. It's not about just black white, Stefano. dreaming What I would like to see, even if some of it might be nonsense, is a seriously integrated scripting environment to code the behaviour of a webapp, and flowscript is a nice way to start exploring that concept. With serious, I mean there should be a way to work with persistency, security, and back-end business logic without this stupid Packages thing, and, because of the continuous bouncing back forward between Java and JS, not having to worry about the automagic typecasting that happens on the border between Java Javascript. Syntax-wise, I have about the same problem with JS as I have with Java, but that's because I find Python a tad more readible. There's people around here that would rather like to code flow in real Java, with dynamic recompilation and all that. There's room for diversity, and we should exploit that. Even Apples hooks in with the flow at some point. asideAnd Apples doesn't mean anything more to me than a personal adventure of a guy I like, on the same level of appreciation that Dywel has in my mind: nothing wrong with it, but where's the community?/aside We should work on serious JS-wrapping of services typically used in webapps, and extensive Avalonization of existing Cocoon code can help with that. There should be formalization of the border area between Java JS, or we will kill ourselves with recurring user questions about the lack of explicit semantics casting. Over time, I still hope that some Jython guru will pop up and make all this also possible using a language I've come to appreciate above JS, but that's entirely IMHO. /dreaming Of course, if we start from a discours of either you're with us, or you're against us, well, all this might take a long time to happen. As much as you repeatedly come back on this so-called split between pro and contra, I'm quite sure that you are currently misguiding yourself (and through such remarks, also this community) about this so-called polarization. For myself, I started hating overweight sitemaps a long time ago. I'm also pretty sure some of the old action-farts will be amongst the people who, eventually, will make sure flowscript reaches the same level of robustness, documentation and user support that the 'old stuff' already has. Oh, and I did read the rest of your mail, and you were right about AAA, interceptors and flow. I understand now. Thanks for your repeated efforts in educating the clueless. ;-D Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: 'Production' build for Cocoon?
Antonio Gallardo wrote: P.S: I dont want to fight with nobody here and I am not trying to attack nobody. Please take my message in the most good sense. Really we need to work together :) ... and your relentless efforts at such are very much appreciated, Antonio! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
[EMAIL PROTECTED] wrote: cziegeler2003/08/25 00:41:18 Modified:.gump.xml lib jars.xml Added: src/blocks/portal/java/org/apache/cocoon/portal/reading ProxyReader.java src/blocks/portal/java/org/apache/cocoon/portal/application PortalApplicationConfig.java PortalApplicationConfigFactory.java src/blocks/portal/java/org/apache/cocoon/portal/coplet/adapter/impl ApplicationCopletAdapter.java CachingURICopletAdapter.java src/blocks/portal/java/org/apache/cocoon/portal/transformation LinkTransformer.java NewEventLinkTransformer.java ProxyTransformer.java lib/optional jtidy-04aug2000r7-dev.jar src/blocks/html/lib .cvsignore Removed: src/blocks/html/lib jtidy-04aug2000r7-dev.jar Log: Contributions to the portal from Friedrich Klenner ([EMAIL PROTECTED]), Gerald Kahrer ([EMAIL PROTECTED]) and Gernot Koller ([EMAIL PROTECTED]). I'm getting increasingly annoyed that, to the best of my knowledge, these contributions have been made off-list. ASF CVS is _not_ a corporate dumping ground. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Joerg Heinicke wrote: Ui, Steven, hard words. I can understand your irritation, it's not the way I would like to see such stuff goes. But offending somebody in such an aggressive way on the public list ?? Well, it's the classical case of not paying enough attention before pressing the send button. I'm really good at this. :-| So apologies for the tone, it was intended for the PMC list, and I was composing a follow-up message already. But I guess I'd better continue the discussion in public: First, let's make this clear: it's good that people contribute to the new portal framework. So thanks, Friedrich, Gerald and Gernot, for donating this back to the community. Also, I fully trust Carsten in reviewing the code before committing. OTOH, I'm still seriously concerned with this happening, especially since I've seen this before. We (= the Cocoon PMC) have the duty to provide legal oversight over the ASF Cocoon codebase. For anything else than bugfixes and minor patches, especially for new code, we must ensure copyright is correctly transferred, and that the ASF cannot be subject of patent infringement lawsuits, and all that. Hence the CLA all committers are supposed to sign and fax. Of course, I'm very confident that Carsten has done this with the best possible intentions, but Contributions to the portal is hardly an intuitive commit message, and a quick search for the three people involved didn't bring up much prior discussion on the lists. If people show up off-list with anything but trivial contributions, they should be discussed or at the very least mentioned on the dev list before being committed. I know I'm not making myself popular here and now, but given the increased number of commercial entities involved with Cocoon and its community, we're better safe than sorry. Sorry again for the tone. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
http://cocoon.apache.org/ access forbiden (fwd)
There's a number of things going on: - the migration of all websites from daedalus - minotaur - subsequent change of IP addresses and DNS propagation - apparently, the ASF is also participating with the SW Patents protest action I'm pretty sure infrastructure peeps are on the ball, even though a 403 Forbidden is kinda strange... I'm pretty sure it's the DNS thing though. /Steven -- Forwarded message -- Date: Wed, 27 Aug 2003 03:45:24 -0600 (CST) From: Antonio Gallardo [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: http://cocoon.apache.org/ access forbiden Hi: please check the main site of cocoon. It seems like it is down. Best Regards, Antonio Gallardo
EU Software Patents protest action
Hi peeps, my colleagues are just back from the live demonstration in front of the EU offices. Several hundreds of people where effectively there, and while we will never know whether such actions have any effect, I was proud to be able to tell them that all ASF sites were participating with the online action. So whoever who made the necessary changes acting under the root account on minotaur: thanks! /Steven
Re: Vote for Cocoon on the O'Reilly Open source Directory.
On Wed, 27 Aug 2003, Geoff Howard wrote: Robert Simmons wrote: Go vote http://www.osdir.com/Downloads-req-ratedownload-lid-11-ttitle-Cocoon.html Hmmm - the description is taken from the 2.0 site, and no wonder -- the link is to http://xml.apache.org/cocoon -- http://cocoon.apache.org/2.0/ Who can fix that redirect now that 2.1 is released? And anyone know if we can fix the blurb at osdir.com? IIRC, Matthew knows the guy behing osdir.com quite well. /Steven
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
On Thu, 28 Aug 2003, Robert Simmons wrote: It is .. Ive been wrong before and I admit Im no Avalon or cocoon source code expert. Im very direct in my style and I wish people wouldnt take it offensively. I merely abhor cheerleading. There are lots of things I love about cocoon but the logging irritates me. *shrug* =^) From someone who learned this himself the hard way: In an email conversation, don't expect your recipients to cope with 'your style' just because you have explained them you mean no harm, and you 'just happen to be direct'. I find it much more effective if you try and shape your style towards optimal reception by your recipients: not by easy excuses for your directness, but by showing _you_ are aware of this directness, and are willing to tone down in respect for your recipients. I'll now refrain from helping you in getting connected with this community, and I do hope you are able to flex your directness into a more positive style of communication. Don't expect us to feel honoured just by your presence. The fact you are coming back says all. With the best intentions, Cheers, /Steven
Re: Blocks Manual
On Thu, 28 Aug 2003, Robert Simmons wrote: Like I said before, I tend to be direct in my language and if I offend, I certainly dont mean to and I appologize. You don't seem to understand what I'm trying to explain, so pardon my shouting: QUIT APOLOGIZING - DO SOMETHING ABOUT IT. Except for the JMS logging thing, most of your remarks make some sense. Now, what if nobody cares enough to actually do the work for you? Will you do it yourself? Cheers, /Steven
Re: [Proposal] Simple production build directions
Roger I Martin PhD wrote: Thanks Cocoon developers for thinking thru and working this out. It is much appreciated. Your patience with us, poor human beings, is even more appreciated. Cheers! /Steven
Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl/html woody-default.xsl
Sylvain Wallez wrote: Example : wt:widget id=foo wi:styling type=textarea rows=10/ /wt:widget The type attribute defines the style type and all other attributes are dependent on this type (and here, copied as is). What do you think ? Including the style element directly rather than referring to it with a type attribute leaves for more future expansion room and won't mess up namespaces if you include direct output elements in the wi:styling/ element, IMHO. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl/html woody-default.xsl
Sylvain Wallez wrote: Furthermore, use of attributes ensures uniqueness of styling type, which is not guaranteed with nested elements. E.g. what happens if we write : wt:widget id=foo wi:styling textarea rows=10/ password size=20/ /wi:styling /wt:widget Will this widget be rendered as a textarea or as a password ? With textarea or password being defined by the unique type attribute, this problem cannot happen. Well, it will be up to the stylesheet to define what will happen. And since we can't control how people will make use of that stylesheet (edit it, or better: import it), I was thinking to just give them an isolated zone where they can add any styling info they want, which most likely will be copied verbatim to the output form. Your suggestion hints at having some definitive list of style widgets, something which I doubt will happen. Or we are in a mutual misunderstanding, of course. ;-) Or do we want wi:styling to be able to hold different styling directives and let the layout stylesheet decide which one is best ? Mmmh... too much magic... Definitely. People should be prepared to do some XSL hacking, but we shouldn't provide them with anything but a very basic stylesheet. Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: CommandManager issues [was Re: Releasing 2.1.1?]
Nicola Ken Barozzi wrote: I'll have to start to play golf just to find a use for my tonsils) Eeeck. Spare us the details! ;-) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Blocks Manual
On Wed, 27 Aug 2003, Robert Simmons wrote: Greetings, Is there a manual that describes all of what each block in cocoon 2.1 does ? Perhaps I missed it. Nope, it isn't there. Don't forget to have a look at http://cocoon.apache.org/2.1/plan/index.html, http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Cocoon+2short_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=%27Importance%27, http://wiki.cocoondev.org/Wiki.jsp?page=RT as well, and http://cocoon.apache.org/community/contrib.html as a way to solve all this. It's good to have you back, Robert. While we ain't a bunch of academics, we still primarily scratch our own itches. We hope our users do as well, and this, together with some respect for the time all of us voluntarily contribute to the Cocoon project, is essentially what community-based open source development is all about. The 'strategy' behind shipping software with rough edges is two-fold: (1) Cocoon won't be finished until its community declares so, by no longer contributing to it, and (2) we like to see every user as a possible future contributor. We don't employ a professional helpdesk, since our users happen to help each other, and several devs are keen to help with major issues. All this is done in the best possible spirit, and I hope you can respect that. Your enquiries are meaningful, and many of them would merit being implemented, but it's not by simply stating them that they effectively will be resolved. The leaky abstraction in software communities is human beings doing the actual work. Cheers, /Steven
Re: dynamic flowscript
Sylvain Wallez wrote: I've seen this behaviour with static files : FlowScript doesn't seem to check changes on scripts loaded with cocoon.load(). This is a bug, and the current workaround is to touch the main script file. I've been experiencing the same, even in the main script. I have: var properties = new Properties(); properties.put(mail.smtp.host, foobar.tld); var mailSession = new Session.getDefaultInstance(properties); var mailMessage = new MimeMessage(mailSession); when changing foobar.tld, saving and hitting reload, the mailSession instance still points to the old smtp server. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Vote] Releasing 2.1.1
Reinhard Poetz wrote: more seriously: How do we deal with bugfix releases in the future if we don't have a branch or another repository? Like we do with 2.0.x? It's just a matter of releasing, actually. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Bug?] Problems with proxy [was [Vote] Releasing 2.1.1 ]
Carsten Ziegeler wrote: So, is this only a typo or really a bug? typo. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Vote] Releasing 2.1.1
Reinhard Poetz wrote: I understand your feelings ... IMO we should be able to release 2.1.x version in the future. Mabe I'm a bit afraid of the changes (blocks, fortress, virtual sitemap components) and how long it takes us to release stable versions of Cocoon (not beta, not milestone or something else) again if we don't branch or fork our repository. Look at what happened to 2.0.x: quite some stuff has been backported onto it even after 2.1 started achieving release quality. As long as anyone goes for it, starting another module or not doesn't mean we aren't able to bugfix, backport and release older versions. Of course, having a separate module for major versions (2.x) makes shifting things around a lot easier. I think so many people (of course including me) were waiting for 2.1 and I really want to use it for some time in production without doing alpha/beta testing of 2.2 and I like to have support of bugfix releases of 2.1 (see the security holes Sylvain fixed recently, maybe we can release a stable Cocoon Forms, ...). Am I (and Carsten) alone with this opinions? Not at all. Don't forget the silent majority. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Vote] Releasing 2.1.1
Reinhard Poetz wrote: I haven't got it: How are we able to release e.g. 2.1.2 without a branch/new repository without using e.g. Fortress as container (nothing against Fortress, I'm no specialist in these container things and maybe this is the reason for my concerns)? I would like to give us some time until we do a production ready release with all those new things. In the meantime we should always be able to do a stable 2.1.x release? Did I miss something? Nope, you've got my 'hint'. ;-) IMHO, it's simply unworkable to have major stuff going on in one module, over two branches, at the same time. We've been there before with the docs and Cocoon2. Now however, some people were quite vocal in explaining they still wanted to stick to one module branch. If they do the actual work, they get to decide how things are done (tm). But vice-versa as well, of course, which seems to be what Carsten is pointing at. See Sylvain's reply as well. I'm +1 on a 2.2 module, and +1 on 2.1.1 on Friday. Fortress might be something for 2.2 rather than 2.1.1, but I'll leave that to the people doing the actual work to decide. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Vote] Releasing 2.1.1
Steven Noels wrote: I'm +1 on a 2.2 module, and +1 on 2.1.1 on Friday. Fortress might be something for 2.2 rather than 2.1.1, but I'll leave that to the people ^ duh: 2.1.x, of course /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Supporting ApacheCon
Carsten Ziegeler wrote: What do you think of putting the nice logo which can be found at http://jakarta.apache.org announcing the ApacheCon on our website as well? Peeps on the Apachecon list have asked to wait for another week IIRC. Otherwise: +1 /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Cocoon GetTogether 2003 website opened
Dear all, we've been frantically preparing the information and registration website for the upcoming Cocoon GetTogether 2003 on October 7th in Ghent, Belgium, and we are very pleased to say that we are open for business now. Please check out http://www.orixo.com/events/gt2003/ On this site, you'll find the program, speakers and all necessary travel and lodging info, which will be updated as the event date approaches. Last year, we had more than 100 people registering for this unique opportunity to meet and intermingle with fellow Cocoonies, and we hope to double that number this year. Mind you that this is *not* a developers-only event, and that many sessions are really mini-tutorials which will give you a jumpstart while exploring the Cocoon framework. On the Wiki, you'll also find some relevant pages: - http://wiki.cocoondev.org/Wiki.jsp?page=GetTogetherAttending in case you want to know who's coming as well - http://wiki.cocoondev.org/Wiki.jsp?page=GT2003Hackathon for developers that want to participate with the Hackathon on the 6th We have been careful in making this event as low-cost as possible, while moving to a larger and better accessible venue, and we are fully committed to provide you with many bangs for your bucks. On behalf of Orixo, I'd like to cordially invite you to participate with this year's edition, and I really look forward to see you in Ghent on October 7th. Cheers, /Steven - GT 2003 co-organizing puppet -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Future build
Antonio Gallardo wrote: Thanks for the reply. It is comfortable. :) ^^^ Even though cocooning requires comfortable couches and plush pillows, I'd rather say 'comforting' here, Antonio. ;-) Cheers, and tnx of course, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Problems integrating Cocoon build in our build system
Joerg Heinicke wrote:
We have a global repository that now also stores the Cocoon 2.1.1
sources. If one wants to use Cocoon in his project he has to build it
after setting some properties (the normal local.*.properties). The
Cocoon sources in the repository shall stay untouched of course.
Therefore I set the properties ${build.root}, ${tools.tasks.dest},
${tools.loader.dest} and almost everything works ...
Joerg, off the top of my head: have you looked at
http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject
We use this approach for a large Woody-based project we are working on
with a customer, and it works rather well.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Re: Announcing 2.1.1
Joerg Heinicke wrote: We are helpless without Carsten :-) Joerg Sylvain Wallez wrote: Hi team, The 2.1.1 should now have reached the mirrors. Does someone know how to update the web site and send the announcements ? I'll update the main website tomorrow (just the news page on the cocoon.apache.org). I wouldn't update the complete cocoon.apache.org/2.1/ right now, since the current content is still valid, and the reshuffling that Carsten started seems more aimed at an upcoming 2.2 release, and might need some more work. That leaves us with the security warning missing from the 2.1 site... maybe a partial update of the main page is enough. I'll send out an announcement after that. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Announcing 2.1.1
Christopher Oliver wrote: Unfortunately I think 2.1.1 contains a Rhino regression I temporarily introduced while trying to fix bug 22513 which will cause any scripts with nested functions to fail. This includes some of the flow samples like PetStore and JXForms. Duh. Showstopper? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
on better release and version management
Hi folks, forgive me for putting on my BOFH hat, while making the following observations... 1) We suck at freezing and stabilizing the codebase prior to releases. I would suggest that, from now on, the Release Manager puts forward a release date after discussion on the dev list, and that there's a two-day (!) freeze period where only glaring bugs can be fixed after a vote (!) on the list. The Release Manager him/herself is also only allowed to commit obvious version number changes and all that during this two-day Sperr-zone. During the past few releases, there was a flurry of quick fixes and commits happening just hours before Carsten made the tarball, and while I'm not immediately aware of any nasty side-effects caused by this, it sure doesn't look like there was time for any peer review on these late commits, neither did it look organized at all. 2) We need to break from the impasse of 2.1.1 vs 2.2 I suggested yesterday night that the reshuffling of docs that Carsten started really seems more apt for a 2.2 release. Also, the switch to Fortress and Real Blocks are destined towards that 2.2 release. I understand some Avalon peeps are glad to dive in and help us with that, which is great, but we should facilitate them. Some people want to start with a 2.2 CVS module right away, others seem more relunctant and want the HEAD of 2.1 to evolve into 2.2. We need to decide on this, since it's blocking progress. My personal opinion is that 2.2 might warrant its own module, but we need to discuss its structure and coexistence with old-style blocks code in more depth before we ask for its creation to the infrastructure peeps. 3) Given the breakage in the Rhino stuff, and the lack of serious testing on the 2.1.1 release, I would refrain from announcing 2.1.1 (not retracting it, though) and go for a new target release date for 2.1.2 on September 24th. That way, we can discuss at leisure what we are going to do with the docs-reshuffling, and people can spend more time on testing new stuff. Please comment! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cocoon's FOP hardcoded with JAI?
Jeff Turner wrote: I'd be interested to know if any other users experience this problem, and also why Cocoon needs a recompiled FOP jar in the first place. Me too, as I'm experiencing the exact same problem as you described, with jimi.jar on the classpath. Even worse, there isn't a supported version of JAI for Mac OSX. With the latest binary release version of FOP, I have no problems at all, so unless someone objects, I'll revert to that one. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Using FOP's Batik in Cocoon (Re: Cocoon's FOP hardcoded with JAI?)
Joerg Heinicke wrote: I know FOP should be built with JAI and JIMI and I thought I have done it. Sorry for any inconvenience. No problem - it brings a sense of reality about our user base and their upgrade frequency, when we discover these things ourselves only after a few weeks or so. ;-) The remaining question: Is Fop 0.20.5 incompatible to Batik 1.5? Is building a fop.jar for Cocoon the correct way or must we downgrade the Batik version? From what I see on forrest-dev, Jeff has switched back to batik-1.5b4-fop.jar which comes with FOP. Maybe we should do that as well. I'm on JDK1.4.1 without need for SVG processing though, so I cannot easily test eventual 1.3.1 issues. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Removing usage of LogKitManager / LogKitManagable
Joerg Heinicke wrote: Ok, with this change we should have satisfied Robert Simmons at the end. A day worthy of remembrance. Thanks, Peter! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
Reinhard Poetz wrote: I expect this and that's the reason why I think that a stable 2.2 release will take some time (I think that's not a matter of a few months but much more) and why I like Carsten's proposal. Grmbl. Bruno and I were just trying to argumentize against each other about both scenarios, and I'm stuck with a few issues that I would like the repository reshuffling see resolve. Here's some feelings (not facts) I want to share with this discussion: 1) There's a decent amount of (positive!) FUD about the new blocks. All in all, I don't think that the actual coding of the new classloading and block deployment architecture code is much more cumbersome that what Sylvain once did with the TreeProcessor, and Stefano did with the build system. Yes, it will take time, but it's just a matter of finding time, motivation and energy to do the job. We tend to discuss for a long time about such issues, possibly longer than the actual coding actually requires. In the end, it's about getting on with it, and someone (which we will be very grateful for) diving deep into it and resurfacing when it's done. Ditto with Fortress. I'm naively hoping that some F2F time during the GT will help in finding that energy, and getting some commitment from people who need to shift between for-pay and for-free work on a daily basis. 2) My main concern with all this restructuring is however release management, and the user-facing perspective of our community work. We need to arrive to a situation where blocks can be independently released from Cocoon core releases, so that people who feel a faster drive to work on specific features can get on with the job, without being demotivated by long periods of no releases due to one zillion dependencies. So maybe we should move all blocks code into a separate module, and establish an independent release schedule (at the whim of the actual block release manager) for them. 3) This brings us to the eternal discussion about the definition of core and non-core. Maybe, be splitting out block code from the main module, and actively trying to slim down the main one even more, we will end up with a better community sense of what can be considered 'core', and what should be consired a block. We could even consider the TraxTransformer a block on its own, if we restrict the core to the pipeline, caching, sitemap and flow machinery. We could envision a packaged stable build of Cocoon which includes the core and then some core blocks. The rest is developed and released on its own schedule, and can, given the dependency checking in the new blocks paradigm shift (yes, it's more about a shift of perception than actual rearchitecturing) be safely released outside the main release schedule. This is just a quick braindump of my current feelings about all this. Hopefully it can contribute positively to this recurring discussion. Ending on a filosophical note: in the end, we should be driven by hope, not by fear. If we manage to come up with a stable 2.1.2 release within some weeks, I'm pretty sure our users have plenty of new, stable releases to play with while we get our act together. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
Geoff Howard wrote: I am undecided but something occurred to me in the shower this AM which made me wonder whether Carsten's proposal will work. As blocks evolve into real blocks, the changes will need to happen right in the src/blocks. Can we guarantee (or will it be too painful to ensure) that all changes will be back-compatible with 2.1? IOW, we will soon start having new configurations, etc. moving into the blocks source, possibly shuffling around of dir structure and probably deprecating some things currently necessary (like some of the configuration patching). Just thinking out loud... Exactly, and also one of my concerns with Carsten's proposal. We can't demand backwards-compatibility from block developers, and if blocks are shared between version from inside the 2.1 workspace, this would be the case. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
[OT] when is software finished [was: Re: on better release and version management]
Reinhard Poetz wrote: From: Bruno Dumon [mailto:[EMAIL PROTECTED] snip/ I expect Woody to also take another year or so before it can be considered stable (in terms of interfaces, not code). ... that long? I expected it to be stable sooner (end of this year). What's open? (I already added this discussion point to http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon) On a lighter note: we have a running joke over here about when is software considered 'finished'. It can be because the community around it dies, or because the author considers it to be perfect, and not requiring any fixes, refactorings or feature additions anymore. The funny thing is that an author sometimes declares its child finished because the community has died. OTOH, 'ls', 'tar' or 'deltree' could well be considered finished software without any negative connotations. Oh well, this is all geek humor (which is another running joke around here [1]), which we all be glad to share with all of you on the 7th of October (hint hint ;-)) [1] Geek humor being the kind of humor that erupts from male IT professionals if they've spent too much time behind their terminals, thinking what they have been doing will effectively change the rotational direction of our green globe. Geek humor can have two side effects: 1) you make a joke of yourself, being aware of the fact that many other things in life can have much more effect on that rotation than the lines of code and email you have been creating during the day, or 2) others make fun of you since you, taking yourself to serious, passionately start to explain how much fun it would be to change the earth's rotation, just because you can. Continuously swapping both perspectives while working in an open source community caters for longer periods between burn-outs. :-D /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. +1 A warm welcome to both of you. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [ANN] Apache Forrest 0.5 released
Jeff Turner wrote: The Forrest team is pleased to announce the release of Apache Forrest 0.5. The release is available at http://www.apache.org/dyn/closer.cgi/xml/forrest/ Congrats, folks! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [shameless plug] Let's GetTogether
Stefano Mazzocchi wrote: I'm writing this because the more we are, the more fun we get and the more cocoon will grow and the more fun we can get in the future. Gee, thanks, Stefano. That was a pleasant surprise. :-) As the person who organized this last year, and who, after careful consideration, decided to 'give the event away' to a larger organisation, and who is now frantically reloading the attendee counter page, please allow me to step forward and express some of my thoughts: - people attract people, so for sure the lengthy registration period last year helped with attracting lots of attendees. Since the event is now carefully scheduled away from ApacheCon, the preparations had to be starting during the summer, which, as you all know, is a great period for planning (not). - because it was free last year, we had 115 registrations, of which however 25 didn't show up. People who were there will remember the huge amount of leftover toasts and sandwiches near the end of the evening reception. - this year however, things have changed. Due to the financial loss my company incurred after the first GT (you'll hear no complaints from me about that, since it was well worth it, exactly because of the things Stefano mentioned), I decided to 'give the event away' to a larger organization. There's two benefits to that: the GT can survive me and my company, and we can start travelling around Europe. - the way Orixo cooperates on this, is through some sort of insurance service. Outerthought still pays the bills and all that, but when we incur losses, they will be split across the participating companies. We do not - repeat: do not - intend to make money over the GT, ever. Also, we carefully budgetted the registration fee to back that claim. - given these thoughts, and the hope that the event would grow bigger during its second year, we went for a larger venue, which is also more easily accessible than last year. I paid them a visit this morning, and took some snapshots during that: http://outerthought.net/~stevenn/GT2003Venue/GT2003Venue.html. - surely you shouldn't come because it is held in a beautiful historical building (although I'm sure this will add to the GT atmosphere). You should come because you want to learn about Cocoon and its community. - my personal pet-peeve-worry is that _users_ of Cocoon are afraid to register since they fear the GT is for hard-core-geeks- or committers-only. I urge you to take a look at the program, and change that perception (if it exists at all). As many people told me last year: they learned more about Cocoon during that one day, than by spending a year on the mailing lists. I hope I didn't waste too much time with this plea, and I really hope that the GT becomes an annual tradition for us, Cocoonies. If you have anything to say about this, please contact me, on- or off-list. Warm regards, /Steven - no hats, just being myself ;-) -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
Carsten Ziegeler wrote: snip type=happy agreement/ I tried to address this issue several times in the last weeks, well, without much success. One thing I want to stress again: *if* we would make a new repository for 2.2 and duplicate all code, this would include the blocks as well. So we would not only end up with the two versions to maintain for the core but for each and every block as well! And this makes imho no sense. It's ok for the core, if we say 2.1 is only bug-fixing from now on. But it makes absolutely no sense for blocks. I think the development of blocks should be independent from the development of the core. With duplicating the code we loose this. So, whatever we decide, I'm -1 on duplicating the block code. My problem with the blocks code is that reusing the 2.1 blocks code would force people to make blocks upwards-compatible, slowing down transitioning between old- and new-style blocks. During the Hackathon on the 6th, I will be busy with GT preparations, so I won't be able to participate much with the discussions. :-( Anyway, please be assured that Bruno and I discussed the aspect of compatibility at length, and IIRC Bruno has been jotting down notes for this bound-to-be-happening IRL discussion. I don't think that we can 1) require 2.2 compatibility by all blocks, since some of them are only worked on by a few people, and 2) we should hinder progress on 2.2 blocks by requiring them to be stuck in the 2.1 repository. I know that we will try and do our best to keep the 2.1 version of Woody in a sane state after 2.2 development starts, most probably also backporting new things that happen along the 2.2 'branch'. Still, we want a freeway for 2.2 development, should the need arise. Does that help? Or do I misunderstand your view on this matter? (me being happy to at least being able to contribute _something_ this days) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
Stefano Mazzocchi wrote: A few points: 1) there is no *block* code in cocoon 2.1, everything is done by the builder. Hey, I knew that already! ;-) 2) blocks in 2.1 and blocks in 2.2 are a single block.xml file away. Given all this stuff of block-specific classloading and much more technical details that I'd love to understand all about, I'm seriously wondering whether a block.xml will be the only difference between a 2.1 and a 2.2 block. Or am I completely misguided by my phantasy? (could well be, I have a vivid imagination) Help? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
Sylvain Wallez wrote: Yeah. That's one of my qualities/defaults (depending on the context) : I hear all opinions, make a synthesis and sometimes claim that it's my own idea ;-) Ha. :-) You couldn't get away with it this time! :-D /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Event handling in Woody
Sylvain Wallez wrote: Marc Portier wrote: in fact I thought about this from the start, but failed to explain to myself how it should look like (I also kept on mixing it up with client-side javascript) Well, if you fail to explain to yourself, I understand why we sometimes don't understand your posts ;-D A ROFL from the peanut gallery. :-D In the office, there's of course the benefit of a whiteboard and all visual clues of body language - maybe Marc should augment his posts with a video taping of himself. ;-) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
Joerg Heinicke wrote: IMO this is difficult to maintain. If someone wants to look on the code base of a block he has to search for its dependencies first or search for the code at different places. Can't we extract the blocks from 2.1 as they are at the moment and move them to cocoon-blocks module, so that they are collected at one place. I like this: +1 /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [proposal] Keep the docs list for wiki updates only
Joerg Heinicke wrote: +1 I have no problems with the proposal. Even the wiki messages are sometimes not that useful, because only the last change in an hour is sent. If an unfriendly person knows that he can spoil a page and obscure his act by a simple re-save. Yep. I'll have a look at that - dunnow if the individual page history is available across the XMLRPC interface though. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Vote] Releasing next version
Carsten Ziegeler wrote: With respect to the recent thread about release management, I propse a release date of October, 1th which would include a freeze of the cvs starting on monday, 29th. +1 - let's do a serious freeze this time. a) Make a 2.1.2 release on October, 1th +1 /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
issues running forrest on cocoon-site module
Hi all, the idea behind the project.site-dir=site property in the forrest.properties in cocoon-site module must be that Forrest overwrites the site subdir in that module with updated html when one regenerates the main website. My problem however is that existing files seem not to be overwritten by the CLI, outputted HTML files seem to be passed into the bitbucket. I've seen this behaviour both on W2K and MacOSX, and am now wondering how you guys regenerate that site section. Bruno checked on his machine and this behaviour seems to be reproducible on Linux as well, so I guess it's a CLI bug, since the output directory seems to be passed nicely into the CLI invocation build.xml section. Can anyone confirm this? Thanks, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: issues running forrest on cocoon-site module
Joerg Heinicke wrote: The pages are generated at cocoon-site/build/ context/ tmp/ site/ (don't know the exact path). I copied them by hand to cocoon-site/site. So the CLI works, but either the output directory is wrong (or interpreted in a wrong way) or the pages have to be copied. Yep, that's what I've been doing so far. If you change project.site-dir to '.', the output gets written alongside the source documents. Logical, but weird. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [IMP] Code Freeze and Release [was: [Vote] Releasing next version]
Carsten Ziegeler wrote: This implies - as discussed - a code freeze starting on monday morning. From that point on, only changes to the docs and bug fixes are allowed to be checked in. ... only AFTER discussion/notification on the dev list. (I'd add: ,existing patches in Bugzilla notwithstanding., but I'm afraid some of them are a bit aged, and would warrant some public review and discussion before being applied during the freeze period. Something we'll all have to decide at our own discretion.) Let's try and make this a decent freeze period. Thanks, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: CVS + Tunneling + Commit Messages
Tony Collen wrote: I can checkout, update, commit things just fine, and it appears that the tunnel is working correctly. However, when I commit something, the message does not seem to be hitting the list. I suspect one of the following: 1) I am not actually doing anything wrong, or 2) My strange setup is causing the mail to not go out, 3) The cvs list is lagged Nope, we just had to moderate your first commits through, and have you put on the -allow list for future commits. Should be OK now. Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [GT] Ghent 2003 - Meeting on Sunday Evening?
Christian Haul wrote: Hi. As many arrive already on Sunday evening, I'd like to propose to meet and share a some food or a beer (maybe two,...). Steven suggested de Vooruit http://www.vooruit.be/ It's a large Grand Cafe, used to be the bastion of the Socialist Workers Union. No real food, though, but there's stuff in the neighbourhood. For the geographically inclined, it is situated near het Zuid, which used to be the quarter of many pleasures quite some time ago. It's about a 20 minute walk from the city center. Oh BTW: Ghent is a quite peaceful place at night. And yes, once you booked yourself into your room, you should be able to wander around by foot in Ghent, it's pretty compact if you know your way around. A map is required, though: the city has been build before geographical planning became a common practice. So, I suggest those interested in meeting should turn up starting 2000h. Look out for some English talking Geeks with GetTogether 2002 T-shirts ;-) Opinions? I'll pop in for a drink around 21:00 is all goes well. Spoiling Marc's fun of a first post, we switched plans for the Hackathon on Monday as well. The Hackathon will be held in Het Pand as well, which will reduce the transportation problem considerably. But he will put stuff up on the Wiki to inform those who attend. Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [BUG] Building docs failed
David Crossley wrote: I see three solutions: a) Revert the restructuring b) Update the site c) Do nothing What do you think? We have a dilemma, or is that a trilemma. Lets make it a quadrilemma ... d) One of us rolls back just our site.xml, or whatever it is that creates the menus, and commits just the generated changes.html Yeah, still risky but it is another option. e) forego the entire, increasingly clumsy CVS deployment mechanism and do an scp instead. The live copy of the website resides in /www/cocoon.apache.org/, the CVS repo of cocoon-site resides in /home/cvs/cocoon-site/, on the same physical server. The CVS deployment mechanism has been invented to give infrastructure@ people the possibility to easily rebuild the website(s) from the cvs modules upon a server crash. Given the fact that both resources reside on the same machine, I don't know how this would work. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
