Re: [RT] Negative Matching Constructs && Mime Type Matching

On Tue, 27 Nov 2001, Stefano Mazzocchi wrote: > Berin Loritsch wrote: > > > > While using Cocoon to generate the developer's docs, I have discovered some use > > cases where a more flexible matcher should be considered. First, let me outline > > how it works (now that we can follow links): >

RE: found the cause of Bug #5060 build docs

Hi, great work! It's also working on W2K with JDK 1.3.1. Carsten > -Original Message- > From: David Crossley [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 28, 2001 3:41 AM > To: [EMAIL PROTECTED] > Subject: Re: found the cause of Bug #5060 build docs > > > David Crossley wrote

why many messages: Could not find component

Does anyone know why there are many messages on Cocoon startup about "Could not find ComponentHandler" and "Could not find component for role"? However, it seems that everything is still functioning properly. Looking from a user point-of-view this could be very confusing. We will probably get hea

DO NOT REPLY [Bug 4487] - Debug level is aways DEBUG when hand-mounting Cocoon webapp on Tomcat4.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-cocoon2/src/org/apache/cocoon/components/language/markup/sitemap SitemapMarkupLanguage.java

crossley01/11/27 22:30:03 Modified:src/org/apache/cocoon/components/language/markup/sitemap Tag: cocoon_20_branch SitemapMarkupLanguage.java Log: Fix broken URL to sitemap documentation for javadoc. Revision ChangesPath No revisi

cvs commit: xml-cocoon2/src/org/apache/cocoon/components/language/markup/sitemap SitemapMarkupLanguage.java

crossley01/11/27 22:27:17 Modified:src/org/apache/cocoon/components/language/markup/sitemap SitemapMarkupLanguage.java Log: Fix broken URL to sitemap documentation for javadoc. Revision ChangesPath 1.8 +2 -2 xml-cocoon2/src/org/apache/

cvs commit: xml-cocoon2/documentation/xdocs/dtd sitemap-v02.dtd

crossley01/11/27 22:22:57 Added: documentation/xdocs/dtd Tag: cocoon_20_branch sitemap-v02.dtd Log: Build upon initial non-authoritative DTD to attempt to document the structure of sitemaps. This is still a draft DTD (see the internal notes). Revis

cvs commit: xml-cocoon2/webapp/resources/entities sitemap-v02.dtd

crossley01/11/27 22:22:49 Added: webapp/resources/entities Tag: cocoon_20_branch sitemap-v02.dtd Log: Build upon initial non-authoritative DTD to attempt to document the structure of sitemaps. This is still a draft DTD (see the internal notes). Rev

cvs commit: xml-cocoon2/documentation/xdocs/dtd sitemap-v02.dtd

crossley01/11/27 22:07:05 Added: documentation/xdocs/dtd sitemap-v02.dtd Log: Build upon initial non-authoritative DTD to attempt to document the structure of sitemaps. Revision ChangesPath 1.1 xml-cocoon2/documentation/xdocs/dtd/sitemap-v02.dtd

cvs commit: xml-cocoon2/webapp/resources/entities sitemap-v02.dtd

crossley01/11/27 21:58:56 Modified:webapp/resources/entities sitemap-v02.dtd Log: Add changes from label/view discussion cocoon-dev 2001-11-15 This is still a draft DTD (see the internal notes). Revision ChangesPath 1.2 +13 -4 xml-cocoon2/webapp/resources/ent

Re: sharing microsoft experience

Ahhh... so you see the benefit is turning forms into prettier forms. I agree that is a good thing. But how do you address someone who wants to enter an article? I agree that willy-nilly editing on the page is a bad thing. But you can show a view of the page with the content section editable in a

Blank generated images in Cocoon documentation

When trying the graphic (jpeg) Hello World example (and also when building docs) I get blank graphic files that don't display on my browser or graphics editor. The generated files aren't empty (some of them are 659 bytes, the others 1011) As a result, for example, the left-side menu of the Cocoon

Re: found the cause of Bug #5060 build docs

David Crossley wrote: > Gianugo Rabellino wrote: > > David Crossley wrote: > > > > > Excellent, thanks everyone. That fixes it. > > > I have committed the changes to CommandlineContext.java > > > into HEAD only. > > > > > > Would people on all platforms, please please confirm that > > > "build d

Re: [PATCH] was: found the cause of Bug #5060 build docs

Christian Schmitt wrote: > Hi, > I believe I made the catalog resolving thing work. > After applying the attached patch file to cocoon_20_branch > I was able to build the documentation as well as run > the Cocoon webapp successfully under Unix (Solaris 8) > and WinNT 4.0. That is great, Christian

cvs commit: xml-cocoon2/src/org/apache/cocoon/environment/commandline CommandlineContext.java

crossley01/11/27 17:52:56 Modified:src/org/apache/cocoon/environment/commandline Tag: cocoon_20_branch CommandlineContext.java Log: contextDir now is the absolute pathname rather than just '.' PR:5060 Revision ChangesPath No re

cvs commit: xml-cocoon2/src/org/apache/cocoon/components/resolver ResolverImpl.java

crossley01/11/27 17:44:09 Modified:src/org/apache/cocoon/components/resolver Tag: cocoon_20_branch ResolverImpl.java Log: parseCatalog() now uses pathname to the default catalog which has an appropriate absolute pathname for the OS and with no leading file:

cvs commit: xml-cocoon2/src/org/apache/cocoon/components/resolver ResolverImpl.java

crossley01/11/27 17:44:03 Modified:src/org/apache/cocoon/components/resolver ResolverImpl.java Log: parseCatalog() now uses pathname to the default catalog which has an appropriate absolute pathname for the OS and with no leading file:/ PR:5060 Submitted by: Christian Schmitt

Fw: sharing microsoft experience

Ahhh... so you see the benefit is turning forms into prettier forms. I agree that is a good thing. But how do you address someone who wants to enter an article? I agree that willy-nilly editing on the page is a bad thing. But you can show a view of the page with the content section editable in a

Re: found the cause of Bug #5060 build docs

Gianugo Rabellino wrote: > David Crossley wrote: > > > Excellent, thanks everyone. That fixes it. > > I have committed the changes to CommandlineContext.java > > into HEAD only. > > > > Would people on all platforms, please please confirm that > > "build docs" now works for you. Then i will add

DO NOT REPLY [Bug 5115] - No more DTM IDs are available

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [RT] Negative Matching Constructs && Mime Type Matching

Berin Loritsch wrote: > > While using Cocoon to generate the developer's docs, I have discovered some use > cases where a more flexible matcher should be considered. First, let me outline > how it works (now that we can follow links): > > 1) By default, all requests for **.html files are ha

Re: [RT] Protocol based sources eliminates almost every generator[was Re: Showstoppers for 2.0 final was RE: [tale+rant] The 2.0 syndromeand [Vote]: Final Release Date]

Jeremy Quinn wrote: > > At 3:51 pm +0100 26/11/01, Giacomo Pati wrote: > >Quoting Berin Loritsch <[EMAIL PROTECTED]>: > > > >> Ugo Cei wrote: > >> > >> > Giacomo Pati wrote: > >> > > > >> > - write a Source (this I hadn't even figured until I read Giacomo's > >> > mail) > > > >This is nothing

Re: sharing microsoft experience

Andre Ulrich wrote: > > Hi all, > > I just want to mention that OEone develop some kind of Abiword Plugin > for Mozilla. At least there is a screenshot: > http://www.oeone.com/pics/wordp.jpg > > Abiword itself is in active development and is nearly plattform > independent. It is possible to imp

[Bug 5115] New: - No more DTM IDs are available

Sorry for crossposting, but this interests both lists. [EMAIL PROTECTED] wrote: > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > . > ANY REPLY MADE TO THIS MESSAGE WILL NOT

Re: [RT] Negative Matching Constructs && Mime Type Matching

On Tue, 27 Nov 2001, Berin Loritsch wrote: > While using Cocoon to generate the developer's docs, I have discovered some use > cases where a more flexible matcher should be considered. First, let me outline > how it works (now that we can follow links): > > 1) By default, all requests for **

Re: found the cause of Bug #5060 build docs

Gianugo Rabellino wrote: > David Crossley wrote: > >> Excellent, thanks everyone. That fixes it. >> I have committed the changes to CommandlineContext.java >> into HEAD only. >> >> Would people on all platforms, please please confirm that >> "build docs" now works for you. Then i will add the ch

Re: found the cause of Bug #5060 build docs

David Crossley wrote: > Excellent, thanks everyone. That fixes it. > I have committed the changes to CommandlineContext.java > into HEAD only. > > Would people on all platforms, please please confirm that > "build docs" now works for you. Then i will add the changes > to cocoon_20_branch. Unfo

Re: sharing microsoft experience

Hi all, I just want to mention that OEone develop some kind of Abiword Plugin for Mozilla. At least there is a screenshot: http://www.oeone.com/pics/wordp.jpg Abiword itself is in active development and is nearly plattform independent. It is possible to import and export all kinds of format such

Re: found the cause of Bug #5060 build docs

Excellent, thanks everyone. That fixes it. I have committed the changes to CommandlineContext.java into HEAD only. Would people on all platforms, please please confirm that "build docs" now works for you. Then i will add the changes to cocoon_20_branch. --David Carsten wrote: > Hi, > perhaps cha

cvs commit: xml-cocoon2/src/org/apache/cocoon/environment/commandline CommandlineContext.java

crossley01/11/27 08:38:37 Modified:src/org/apache/cocoon/environment/commandline CommandlineContext.java Log: contextDir now is the absolute pathname rather than just '.' PR:5060 Revision ChangesPath 1.9 +9 -1 xml-cocoon2/src/org/apa

Re: XSPUtil.formEncode doesn't convert non-ascii character as is should

On Tue, Nov 27, 2001 at 02:13:24PM +0100, Fotis Jannidis wrote: > Thanks for fixing this. Just wanted to point out, that I saw a notice > somewhere on the cocoon website, that the method has been > provided to ensure Java 1.1 compatibility. Probably this is no > argument any longer, just wanted

[RT] Negative Matching Constructs && Mime Type Matching

While using Cocoon to generate the developer's docs, I have discovered some use cases where a more flexible matcher should be considered. First, let me outline how it works (now that we can follow links): 1) By default, all requests for **.html files are handled by a default pipeline 2) We o

[PATCH] was: found the cause of Bug #5060 build docs

Hi, I believe I made the catalog resolving thing work. After applying the attached patch file to cocoon_20_branch I was able to build the documentation as well as run the Cocoon webapp successfully under Unix (Solaris 8) and WinNT 4.0. Cheers, Christian Schmitt On Tue, Nov 27, 2001 at 03:00:31P

DO NOT REPLY [Bug 4487] - Debug level is aways DEBUG when hand-mounting Cocoon webapp on Tomcat4.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: found the cause of Bug #5060 build docs

Hi, perhaps changing the constructor: public CommandlineContext (String contextDir) { this.contextDir = contextDir; this.attributes = new HashMap(); } to something like: public CommandlineContext (String contextDir) { this.contextDir = new File(contextDir).g

Re: found the cause of Bug #5060 build docs

Carsten Ziegeler wrote: > John Morrison wrote: > > > > > -Original Message- > > > From: David Crossley [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, 27 November 2001 8:52 am > > > To: [EMAIL PROTECTED] > > > Subject: found the cause of Bug #5060 build docs > > > > > > > > > > > So it se

Re: New versions of Avalon in HEAD

Christian Haul wrote: > On 26.Nov.2001 -- 04:59 PM, Berin Loritsch wrote: > >>I updated HEAD with the new versions of Avalon, and FOP and Batik (that works with >FOP). >>You will find that everything _should_ work. I would like those of you who are able >to >>ensure that it does. >> > > As b

Re: org.apache.cocoon.components.language.programming.java package

Paul Hammant wrote: > (interloping from the AvalonDB server project) > > We'd like to be able to use a technique where we compile SQL SELECT > statements into Java class "actions". OK, so this is a non-rendering > class, but it has similar aspects to JSP and XSP pages in that it is > cached and u

RE: found the cause of Bug #5060 build docs

John Morrison wrote: > > > -Original Message- > > From: David Crossley [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, 27 November 2001 8:52 am > > To: [EMAIL PROTECTED] > > Subject: found the cause of Bug #5060 build docs > > > > > > > So it seems that there is inconsistency when using ge

Re: [RT] Protocol based sources eliminates almost every generator[was Re: Showstoppers for 2.0 final was RE: [tale+rant] The 2.0 syndromeand [Vote]: Final Release Date]

At 3:51 pm +0100 26/11/01, Giacomo Pati wrote: >Quoting Berin Loritsch <[EMAIL PROTECTED]>: > >> Ugo Cei wrote: >> >> > Giacomo Pati wrote: >> > >> > - write a Source (this I hadn't even figured until I read Giacomo's >> > mail) > >This is nothing I thought of doing. This is something I have b

DO NOT REPLY [Bug 4878] - XSPUtil.formEncode doesn't convert non-ascii character as is should

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-cocoon2/src/org/apache/cocoon/components/language/markup/xsp XSPUtil.java

mman01/11/27 02:16:53 Modified:src/org/apache/cocoon/components/language/markup/xsp XSPUtil.java Log: PR: 4878 form(Encode|Decode) converted to use standard java.net.URL(Encoder|Decoder) Revision ChangesPath 1.8 +5 -43 xml-cocoon2

cvs commit: xml-cocoon2/src/org/apache/cocoon/components/language/markup/xsp XSPUtil.java

mman01/11/27 02:16:52 Modified:src/org/apache/cocoon/components/language/markup/xsp Tag: cocoon_20_branch XSPUtil.java Log: PR: 4878 form(Encode|Decode) converted to use standard java.net.URL(Encoder|Decoder) Revision ChangesPath No

org.apache.cocoon.components.language.programming.java package

Hi, (interloping from the AvalonDB server project) We'd like to be able to use a technique where we compile SQL SELECT statements into Java class "actions". OK, so this is a non-rendering class, but it has similar aspects to JSP and XSP pages in that it is cached and used again later. My re

Re: New versions of Avalon in HEAD

On 26.Nov.2001 -- 04:59 PM, Berin Loritsch wrote: > I updated HEAD with the new versions of Avalon, and FOP and Batik (that works with >FOP). > You will find that everything _should_ work. I would like those of you who are able >to > ensure that it does. As before (http://marc.theaimsgroup.com

Re: [RT] Protocol based sources eliminates almost every generator [was Re: Showstoppers for 2.0 final was RE: [tale+rant] The 2.0 syndrome and [Vote]: Final Release Date]

Stefano Mazzocchi wrote: > 3) a generator is useful when you have lots of logic and small markup > that never changes and the parameters that drive this are not markup. I decided to write a generator, mostly because I have already used XSP and want to test something new. > Can we postpone thi

DO NOT REPLY [Bug 5115] New: - No more DTM IDs are available

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: found the cause of Bug #5060 build docs

> -Original Message- > From: David Crossley [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 27 November 2001 8:52 am > To: [EMAIL PROTECTED] > Subject: found the cause of Bug #5060 build docs > > > So it seems that there is inconsistency when using getResource() > ... > String catalogFile =

Re: Showstoppers for 2.0 final was RE: [tale+rant] The 2.0 syndrome and [Vote]: Final Release Date

Giacomo wrote: > Gianugo Rabellino wrote: > > giacomo wrote: > > > On Mon, 26 Nov 2001, Giacomo Pati wrote: > > >>Quoting Gianugo Rabellino <[EMAIL PROTECTED]>: > > >>>Gianugo Rabellino wrote: > > >>> > > >>> > > >>I just did a fresh checkout. This is Linux Mandrake with Blackdown > > >>1.

found the cause of Bug #5060 build docs

I have isolated the cause of the Bug. It looks like it will be easy to fix :-) though it will need someone else to do it. As described in Bugzilla - here is a summary ... Everything works fine with the entity resolver when Cocoon is running as a webapp. However, when running as commandline contex

DO NOT REPLY [Bug 4020] - Error in request.xsl XSP logicsheet - value-for-name template

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-cocoon2/documentation/xdocs/plan index.xml

crossley01/11/27 00:08:10 Modified:documentation/xdocs/plan index.xml Log: Fixed default system identifier for DTD. Revision ChangesPath 1.3 +1 -1 xml-cocoon2/documentation/xdocs/plan/index.xml Index: index.xml ==

Re: cvs commit: xml-cocoon2/documentation cocoon.xconf

Giacomo wrote: > Sorry, I thought it solves the problem. Can you explain what > my change broke. Hi Giacomo, i was just in the middle of preparing two emails - one to explain this revert (and one where i think that i have tracked down the problem). When you changed the default path in cocoon.xco