Re: Setting values in XMLForm (via JXPath)

Not really. I was hoping to avoid creating a dependency on JavaScript objects in Form.java http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/java/org/apache/cocoon/components/xmlform/Form.java?rev=HEAD&content-type=text/plain since I implemented the JXPath Pointer interface for JavaS

Re: Setting values in XMLForm (via JXPath)

Apparently I missed this letter before. Yes Chris, this is the reason why the collection is being replaced. Any ideas for improvement? -=Ivelin=- - Original Message - From: "Christopher Oliver" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent:

Re: cli in cocoon.bat

> > So for some reason, the shift isn't working for me. I presume it > > worked for you? > > I tried "cocoon cli -help" and it showed me the help. I thought this > meant it was working just fine. See the patch I've just submitted. It allows the user to specify a config (xconf) file, which is mu

DO NOT REPLY [Bug 17553] - [PATCH] CLI Config file extensions+more

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

DO NOT REPLY [Bug 17553] New: - [PATCH] CLI Config file extensions+more

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

XMLForms and O/R bridge. The Road Ahead.....

Hi! After seeing how Christian and Ugo greatly done the relation between XMLForms and Flow. A Bean is the model of the MVC, XMLForm the View and Flow the controller. A short of this can be B-XMLF-F. :-) Now still stay in the air the question of how to handle the "down" side of the persistent Mod

Re: [New build system] Status of samples

Stefano Mazzocchi wrote, On 28/02/2003 11.50: Carsten Ziegeler wrote: ... > 1) Refactor the project-info.xml to split in several files contained > > in the blocks themselves. > Just like Eclipse plugin.xml files in their plugins, a plugin is > installed by just dropping it in the plugins dir.

[PATCH] nag on prereq failures

I could be a smartass, and commit this patch, but figured that it merits further discussion. It *might* be worth committing the first block of the patch, however. - Sam Ruby Index: gump.xml === RCS file: /home/cvs/xml-cocoon2/gump.x

cvs commit: xml-cocoon2/src/webapp/samples/xmlform/flow feedbackWizard.js

coliver 2003/02/28 11:14:35 Modified:src/webapp/samples/xmlform/flow feedbackWizard.js Log: Removed tabs, and updated to use XForm.getValue() instead of the now nonexistent XForm.xpath() method Revision ChangesPath 1.2 +73 -68xml-cocoon2/src/webapp/samples/xmlf

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/flow/javascript system.js

coliver 2003/02/28 11:12:13 Modified:src/java/org/apache/cocoon/components/flow/javascript system.js Log: Removed tabs, added getValue() and iterate() methods to XForm and removed xpath() method Revision ChangesPath 1.9 +114 -96 xml-cocoo

Re: Gump Integration

Stefano Mazzocchi wrote: My two cents: what you just did was significantly reduce the number of people who can keep this updated. My experience in the past has been that this always is a bad thing, but perhaps Cocoon will prove me wrong. I'm aware of the fact that it significantly reduced the nu

Re: [New build system] Status of samples

On Friday, February 28, 2003, at 02:44 PM, Stefano Mazzocchi wrote: Jeremy Quinn wrote: On Friday, February 28, 2003, at 10:50 AM, Stefano Mazzocchi wrote: Finally, I think the Cocoon build should also allow you to build your own cocoon web site. In this case, your stuff should becomes nothing d

RE: [OT]; SAX parsing speed

Jakob Praher <[EMAIL PROTECTED]> wrote: > > Am Fre, 2003-02-28 um 17.48 schrieb Hunsberger, Peter: > > Pier Fumagalli wrote: > > > > > > "Hunsberger, Peter" <[EMAIL PROTECTED]> wrote: > > > > > > > Niclas Hedhman wrote: > > > >> > > > >> I'm playing with the idea of making an attempt at a > S

RE: [OT]; SAX parsing speed

Am Fre, 2003-02-28 um 17.48 schrieb Hunsberger, Peter: > Pier Fumagalli wrote: > > > > "Hunsberger, Peter" <[EMAIL PROTECTED]> wrote: > > > > > Niclas Hedhman wrote: > > >> > > >> I'm playing with the idea of making an attempt at a SAX hardware > > >> accelerator, just for the heck of it, but w

Re: Gump Integration

Stefano Mazzocchi wrote, On 28/02/2003 17.41: ... Cocoon will (sooner or later) move to an indirect dependency graph. This will require a special build system, probably with special ant tasks. I think we'll make an effort to make these tasks bootstrappable with basic Ant and JAXP dependencie

RE: [OT]; SAX parsing speed

Pier Fumagalli wrote: > > "Hunsberger, Peter" <[EMAIL PROTECTED]> wrote: > > > Niclas Hedhman wrote: > >> > >> I'm playing with the idea of making an attempt at a SAX hardware > >> accelerator, just for the heck of it, but won't bother if it is > >> already in the "ignorable" > >> magnitude. >

Gump Integration

Sam Ruby wrote: Stefano Mazzocchi wrote: - apart from that, I don't think so. Isn't this a gump descriptor? I just made it became so. Previously it was just a copy and the real descriptor was in the jakarta-gump repository. Now, Gump picks it up from here so this means we have to keep it upda

[Fwd: Re: cvs commit: jakarta-gump/project xml-cocoon2.xml]

FYI Original Message Subject: Re: cvs commit: jakarta-gump/project xml-cocoon2.xml Date: Fri, 28 Feb 2003 15:47:12 +0100 From: Leo Simons <[EMAIL PROTECTED]> Reply-To: "Gump code and data" <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Newsgroups: gmane.comp.jakarta.gump References: <

Re: [New build system] Status of samples

Carsten Ziegeler wrote: >> First, my feeling is that if there is a better syntax, I would like >> to simply adopt it. I don't care what the definition of better is: >> technical, community, whatever. >> > So where is the right place to discuss the syntax? In short: Cocoon > has many dependencies b

cvs commit: xml-cocoon2/src/blocks/deli/WEB-INF/deli/config namespaceConfig.xml

butlermh2003/02/28 08:36:20 Modified:src/blocks/deli/WEB-INF/deli/config namespaceConfig.xml Log: Revision ChangesPath 1.3 +0 -1 xml-cocoon2/src/blocks/deli/WEB-INF/deli/config/namespaceConfig.xml Index: namespaceConfig.xml

Re: [OT]; SAX parsing speed

"Hunsberger, Peter" <[EMAIL PROTECTED]> wrote: > Niclas Hedhman wrote: >> >> I'm playing with the idea of making an attempt at a SAX >> hardware accelerator, >> just for the heck of it, but won't bother if it is already in >> the "ignorable" >> magnitude. > > You mean something like: > > http:

cvs commit: xml-cocoon2/src/blocks/deli/WEB-INF/deli/config namespaceConfig.xml

butlermh2003/02/28 07:59:07 Modified:src/blocks/deli/WEB-INF/deli/config namespaceConfig.xml Log: Removed unnecessary experimental configuration. Revision ChangesPath 1.2 +0 -5 xml-cocoon2/src/blocks/deli/WEB-INF/deli/config/namespaceConfig.xml Index: nam

RE: [OT]; SAX parsing speed

Niclas Hedhman wrote: > > I'm playing with the idea of making an attempt at a SAX > hardware accelerator, > just for the heck of it, but won't bother if it is already in > the "ignorable" > magnitude. You mean something like: http://www.datapower.com/products/xa35.html Of course, it doesn't

Re: Support for Eclipse JDT Compiler

"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: >> Note: There is no snapshot anymore available on the Cocoon web site. > > Really? Yes > Pier? Well, we had our script for snapshotting both 2.0 (branch) and 2.1 (head), but the problem is that the root script installed for snapshotting all other

cvs commit: xml-cocoon2 build.xml

jefft 2003/02/28 07:27:24 Modified:.build.xml Log: Now with JDK 1.4's javadoc, @todo items are included in generated HTML (and don't cause warnings) Revision ChangesPath 1.347 +2 -2 xml-cocoon2/build.xml Index: build.xml ===

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/xml/dom DocumentWrapper.java

jefft 2003/02/28 07:26:03 Modified:src/java/org/apache/cocoon Constants.java src/java/org/apache/cocoon/components/modules/input XMLFormInput.java src/java/org/apache/cocoon/components/source SourceUtil.java src/java/

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation SourceWritingTransformer.java

cziegeler2003/02/28 07:16:42 Modified:src/java/org/apache/cocoon/transformation SourceWritingTransformer.java Log: Optimizing code Revision ChangesPath 1.21 +6 -27 xml-cocoon2/src/java/org/apache/cocoon/transformation/SourceWritingTransfo

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation SourceWritingTransformer.java

cziegeler2003/02/28 07:12:44 Modified:src/java/org/apache/cocoon/transformation SourceWritingTransformer.java Log: Optimizing code Revision ChangesPath 1.20 +13 -43 xml-cocoon2/src/java/org/apache/cocoon/transformation/SourceWritingTransfo

Re: XMLForms code

Am Fre, 2003-02-28 um 14.22 schrieb [EMAIL PROTECTED]: > I have done the example off the site for XMLForms. > Having got this to work i have tried to create a new form. I want to > put a dropdown list in but have no idea what the code is. > > Is coding for XMLForms the same as XForms, so in this

RE: [New build system] Status of samples

Sam Ruby wrote: > > I totally agree, even if the choice of separating blocks into their own > > gump projects makes it easier to obtain a clean cocoon run in Gump by > > lowering the dependency needs for the core (Sam, did we ever > get a clean > > Cocoon2 gump build?) > > We have gotten close, but

Re: [New build system] Status of samples

Stefano Mazzocchi wrote: - apart from that, I don't think so. Isn't this a gump descriptor? I just made it became so. Previously it was just a copy and the real descriptor was in the jakarta-gump repository. Now, Gump picks it up from here so this means we have to keep it updated. My two cents:

Re: [New build system] Status of samples

Jeremy Quinn wrote: On Friday, February 28, 2003, at 10:50 AM, Stefano Mazzocchi wrote: Finally, I think the Cocoon build should also allow you to build your own cocoon web site. In this case, your stuff should becomes nothing different from a microblock. (please, don't start using this termino

cvs commit: xml-cocoon2 build.xml

cziegeler2003/02/28 06:43:37 Modified:.build.xml Log: Validating works again Revision ChangesPath 1.346 +2 -2 xml-cocoon2/build.xml Index: build.xml === RCS file: /home/cvs/xml-cocoo

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation CIncludeTransformer.java

cziegeler2003/02/28 06:28:15 Modified:src/java/org/apache/cocoon/transformation CIncludeTransformer.java Log: And add a warning Revision ChangesPath 1.26 +3 -1 xml-cocoon2/src/java/org/apache/cocoon/transformation/CIncludeTransformer.jav

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation CIncludeTransformer.java

cziegeler2003/02/28 06:26:53 Modified:src/java/org/apache/cocoon/transformation CIncludeTransformer.java Log: Remove the need of the cache manager Revision ChangesPath 1.25 +20 -10 xml-cocoon2/src/java/org/apache/cocoon/transformation/CInc

Re: [New build system] Status of samples

Stefano Mazzocchi wrote, On 28/02/2003 15.19: ... Sam, is it possible to have Gump obtain a dynamically generated project descriptor? what would allow us to keep our block descriptors as we like and generate a gump descriptor dynamically. We can make a Gump descriptor for each project, but it w

Re: cli in cocoon.bat

Upayavira wrote: 2) There are %2...%9, which gives you eight options. If you need to specify a context dir, a config file, a working directory and a destination directory, you've used them all up and haven't specified any targets. Switching to %* almost sorted it (I know that this is NT only), exce

Re: [New build system] Status of samples

Carsten Ziegeler wrote: Stefano Mazzocchi wrote: > > 1) Refactor the project-info.xml to split in several files contained > > in the blocks themselves. > Just like Eclipse plugin.xml files in their plugins, a plugin is > installed by just dropping it in the plugins dir. Usecase: This will > make i

DO NOT REPLY [Bug 17527] - XMLUtils.serializeNodeToXML adds XML declaration.

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

DO NOT REPLY [Bug 17527] - XMLUtils.serializeNodeToXML adds XML declaration.

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/java/org/apache/cocoon/transformation SourceWritingTransformer.java

jefft 2003/02/28 06:07:17 Modified:src/deprecated/java/org/apache/cocoon/environment WriteableSource.java src/documentation/xdocs/userdocs/transformers sourcewriting-transformer.xml src/java/org/apache/cocoon

Re: Support for Eclipse JDT Compiler

[EMAIL PROTECTED] wrote: I thing that the new build system comes with the last Cocoon-2.1dev snapshot. Is it documented? Yessir. Read INSTALL.txt Sylvain (T) Note: There is no snapshot anymore available on the Cocoon web site. Really? Pier? -- Stefano Mazzocchi <[E

DO NOT REPLY [Bug 17527] - XMLUtils.serializeNodeToXML adds XML declaration.

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

DO NOT REPLY [Bug 17527] New: - XMLUtils.serializeNodeToXML adds XML declaration.

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: [New build system] Status of samples

Stefano Mazzocchi wrote: > > > > 1) Refactor the project-info.xml to split in several files contained > > > in the blocks themselves. > > Just like Eclipse plugin.xml files in their plugins, a plugin is > > installed by just dropping it in the plugins dir. Usecase: This will > > make it easy

cvs commit: xml-cocoon2 gump.xml build.properties build.xml project-info.xml

stefano 2003/02/28 05:34:12 Modified:.build.properties build.xml Added: .gump.xml Removed: .project-info.xml Log: fixing gump dependencies (now Gump picks up the project dependencies directly from here, it's a first step toward better continous

XMLForms code

I have done the example off the site for XMLForms. Having got this to work i have tried to create a new form. I want to put a dropdown list in but have no idea what the code is.   Is coding for XMLForms the same as XForms, so in this case i would do a ? Im sure there is going to be more th

Re: CVS weirdness

On Fri, Feb 28, 2003 at 12:45:52PM +, Andrew Savory wrote: > > Hi, > > I'm trying to get a copy of cocoon 2.1 prior to the major refactoring, > using: > > cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic -z3 checkout -D 2003-02-16 -r HEAD > xml-cocoon2 -D checks out for a specific timesta

Re: CVS weirdness

On 28/2/03 12:45 pm, "Andrew Savory" <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm trying to get a copy of cocoon 2.1 prior to the major refactoring, > using: > > cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic -z3 checkout -D > 2003-02-16 -r HEAD xml-cocoon2 > > ... but it doesn't seem to work

CVS weirdness

Hi, I'm trying to get a copy of cocoon 2.1 prior to the major refactoring, using: cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic -z3 checkout -D 2003-02-16 -r HEAD xml-cocoon2 ... but it doesn't seem to work. It grabs all the files, then deletes them. I'm wondering: - am I doing something

Re: [New build system] Status of samples

On Friday, February 28, 2003, at 10:50 AM, Stefano Mazzocchi wrote: Finally, I think the Cocoon build should also allow you to build your own cocoon web site. In this case, your stuff should becomes nothing different from a microblock. (please, don't start using this terminology, it sucks, it's

Re: [New build system] Status of samples

From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> > Samples are 'integration oriented' while blocks are 'separation oriented'. Yes indeed they are. > Get the 'hello-world' sample directory: this depends on many different > blocks (fop,batik and so on). Refactoring this into pieces and XconfTool > pat

RE: New Cocoon Committer

Please note new e-mail address: All 'norit-bodycare.co.uk' addresses are now changing to 'bodycare-int.co.uk'

Re: cli in cocoon.bat

> > 2) There are %2...%9, which gives you eight options. If you need to > > specify a context dir, a config file, a working directory and a > > destination directory, you've used them all up and haven't specified > > any targets. Switching to %* almost sorted it (I know that this is > > NT only), e

Re: problem with forehead

> I tried Classworlds and I found it incredibly slow. I tried to look into > the code to see why and I saw too many classloading and it does too many > things for the super-simple layer of classloading abstraction I wanted, > so I decided to write my own tiny one (took me half an hour). Since we

cvs commit: xml-cocoon2/src/documentation/xdocs who.xml

bruno 2003/02/27 14:39:05 Modified:src/documentation/xdocs who.xml Log: Added myself (bruno) to active committers. Revision ChangesPath 1.38 +1 -0 xml-cocoon2/src/documentation/xdocs/who.xml Index: who.xml ===

cvs commit: xml-cocoon2/src/blocks/html/java/org/apache/cocoon/generation HTMLGenerator.java

bruno 2003/02/27 14:25:19 Modified:src/blocks/html/java/org/apache/cocoon/generation HTMLGenerator.java Log: disable namespace normalization on DOMStreamer Revision ChangesPath 1.5 +2 -1 xml-cocoon2/src/blocks/html/java/org/apache/coc

RE: Problem with HTMLGenerator

On Fri, 2003-02-28 at 09:12, Carsten Ziegeler wrote: > Bruno Dumon wrote: > > > > On Thu, 2003-02-27 at 22:14, Miles Egan wrote: > > > After updating cvs and rebuilding I get this error when using the > > > HTMLGenerator: > > > > > > [NamespaceNormalizingDOMStreamer] Encountered a DOM Element wi

RE: Support for Eclipse JDT Compiler

I thing that the new build system comes with the last Cocoon-2.1dev snapshot. Is it documented? Sylvain (T) Note: There is no snapshot anymore available on the Cocoon web site. -Message d'origine- De: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Date: vendredi, 28. février 2003 12:04 À:

Re: Support for Eclipse JDT Compiler

[EMAIL PROTECTED] wrote: Is there a link between this bug 16580 and my problem below?? When I compile my project in Eclipse and then try to load the samples page this error appears: org.apache.cocoon.ProcessingException: Failed to load sitemap from file:/C:/jakarta-tomcat-4.1.12/webapps/cocoon/s

Re: [New build system] Status of samples

Carsten Ziegeler wrote: Hi, is anybody working on getting the samples working again with the new build system? I am, but it's such a pain in the ass :( What is missing? I can help, if required. The problem is simple, the solution complex. Samples are 'integration oriented' while blocks are 'sep

RE: Support for Eclipse JDT Compiler

Is there a link between this bug 16580 and my problem below?? When I compile my project in Eclipse and then try to load the samples page this error appears: org.apache.cocoon.ProcessingException: Failed to load sitemap from file:/C:/jakarta-tomcat-4.1.12/webapps/cocoon/samples/sitemap.xmap: org

Re: Samples broken

Jeff Turner wrote: If it's work in progress that's cool - I'll add a stating as much. Yes, it is, will do that. -- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --

cvs commit: xml-cocoon2 PURITY.txt

stefano 2003/02/28 02:09:36 Added: .PURITY.txt Log: added purity file to list all the current code defects that have low priority Revision ChangesPath 1.1 xml-cocoon2/PURITY.txt Index: PURITY.txt ==

Re: [proposal] Pruning up the CVS tree for real

Ovidiu Predescu wrote: Getting a copy should be as simple as logging on cvs.apache.org and taring up /home/cvs/xml-cocoon2/. Then install them on cocoondev.org in the CVS directory. Returning late to this thread, have been doing some customer work and it looks like there has been quite some flu

RE: Support for Eclipse JDT Compiler

> -Oorspronkelijk bericht- > Van: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Verzonden: vrijdag 28 februari 2003 1:47 > Aan: [EMAIL PROTECTED] > Onderwerp: Re: Support for Eclipse JDT Compiler > > > Christopher Oliver wrote: > > > Please test it and let me know of any problems. > > I can

Re: Problem with HTMLGenerator

Ugo Cei wrote: Isn't there anything better than JTidy for converting HTML to XHTML? How about CyberNeko (http://www.apache.org/~andyc/neko/doc/index.html)? I never tried it, but might start using it in a short timeframe if it proves to be useful... Ciao, -- Gianugo Rabellino Pro-netics s.r.

Re: cli in cocoon.bat

> > 2) There are %2...%9, which gives you eight options. If you need to > > specify a context dir, a config file, a working directory and a > > destination directory, you've used them all up and haven't specified > > any targets. Switching to %* almost sorted it (I know that this is > > NT only), e

Re: [OT]; SAX parsing speed

Niclas Hedhman wrote: I'm playing with the idea of making an attempt at a SAX hardware accelerator, just for the heck of it, but won't bother if it is already in the "ignorable" magnitude. I'm pretty sure you are aware of http://www.datapower.com/products/xa35.html in that area? -- Steven Noe

RE: New Cocoon Committer

Thanks Brian. Welcome Bruno! :) J. > From: Brian Behlendorf [mailto:[EMAIL PROTECTED] > > No problem. Account created, password sent, commit privs granted. :) > > Brian === Information in this email and any attachmen

[OT]; SAX parsing speed

Does anyone have an indication of the total SAX parsing time, i.e. how much time is spent parsing the XML and the XSL relatively to all other operations for a complete transform. Would there be any "point" to bring this to "I/O speed", meaning as fast as the characters can be read from the dis

Re: Problem with HTMLGenerator

Bruno Dumon wrote: On Thu, 2003-02-27 at 22:14, Miles Egan wrote: After updating cvs and rebuilding I get this error when using the HTMLGenerator: [NamespaceNormalizingDOMStreamer] Encountered a DOM Element without a localName. DOM Level 1 trees are not supported by this DOMStreamer. Is this a

[New build system] Status of samples

Hi, is anybody working on getting the samples working again with the new build system? What is missing? I can help, if required. (PS: I really need the samples working again soon) Carsten Carsten Ziegeler Open Source Group, S&N AG

RE: Problem with HTMLGenerator

Bruno Dumon wrote: > > On Thu, 2003-02-27 at 22:14, Miles Egan wrote: > > After updating cvs and rebuilding I get this error when using the > > HTMLGenerator: > > > > [NamespaceNormalizingDOMStreamer] Encountered a DOM Element without a > > localName. DOM Level 1 trees are not supported by this

cvs commit: xml-cocoon2 build.xml

cziegeler2003/02/28 00:09:34 Modified:.build.xml Log: Final dependency fix for cocoon.roles Revision ChangesPath 1.344 +8 -2 xml-cocoon2/build.xml Index: build.xml === RCS file: /hom

cvs commit: xml-cocoon2 build.xml

cziegeler2003/02/28 00:04:56 Modified:.build.xml Log: First dependency fix: we must build the cocoon.jar after everything else is compiled, because we need the aggregated cocoon.roles file. (This will change when we have blocks working). Now, we build the cocoon.jar

cvs commit: xml-cocoon2/src/webapp/WEB-INF cocoon.xconf

cziegeler2003/02/28 00:00:34 Modified:src/java/org/apache/cocoon cocoon.roles .build.xml build.properties src/webapp/WEB-INF cocoon.xconf Added: src/deprecated/conf deprecated.xroles deprecated.xconf Log: Moving deprecated configuration i