cvs commit: xml-cocoon2/src/webapp/stylesheets/system error2html.xsl

crossley2003/02/12 23:25:35 Modified:src/webapp/samples/common/style/xsl/html Tag: cocoon_2_0_3_branch error2html.xsl src/webapp/stylesheets/system Tag: cocoon_2_0_3_branch error2html.xsl Log: Fix broken link to FAQ.

cvs commit: xml-cocoon2/src/webapp/samples/stylesheets/system error2html.xsl

crossley2003/02/12 23:25:29 Modified:src/webapp/samples/common/style/xsl/html error2html.xsl src/webapp/samples/stylesheets/system error2html.xsl Log: Fix broken link to FAQ. Revision ChangesPath 1.2 +3 -2 xml-cocoon2/src/webapp/samples/common/s

Sitemap Scheme is too restricting

Hi, we really have to relax the sitemap scheme. If you look at it you wil notice, that e.g. the configuration of the xslt transformer is hard-coded into the scheme etc. In general, a sitemap component can have any arbitrary configuration and it doesn't make sense to hard-code this into the scheme.

HP-AS

I saw that HP-AS is listed in the Installation document. Just want to highlight that HP-AS is discontinued, and HP has an alliance with BEA to provide a migration path for existing HP-AS users. http://www.hpmiddleware.com/SaISAPI.dll/SaServletEngine.class/sunset/default.jsp Effective Septem

RE: processing (lifecycle) events

Hi Jakob, I think this is a great idea, (because) I need it in several areas as well. Could you expand a little bit more on how to configure the listeners and what their interface should/could look like. This might then help to convince others that listeners are usefull in some scenarios. Thanks

DO NOT REPLY [Bug 16786] - [PATCH] XMLForm Xindice how-to

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 16786] - [PATCH] XMLForm Xindice how-to

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/documentation/xdocs/howto howto-xindice-xmlform.xml

crossley2003/02/12 17:43:53 Modified:src/documentation/xdocs/howto Tag: cocoon_2_0_3_branch howto-xindice-xmlform.xml Log: Added patch from Josema Alonso to fix some source line widths. Reformatted the whole document to enable proper diff later (line-wrap,

cvs commit: xml-cocoon2/src/documentation/xdocs/howto howto-xindice-xmlform.xml

crossley2003/02/12 17:43:36 Modified:src/documentation/xdocs/howto howto-xindice-xmlform.xml Log: Added patch from Josema Alonso to fix some source line widths. Reformatted the whole document to enable proper diff later (line-wrap, indent, dos2unix). Revision ChangesPat

DO NOT REPLY [Bug 16580] - Java compiler requires JARs in the FS; can not use classloader

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: Snapshots, Attn: Pier

On 12/2/03 20:37, "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > Pier Fumagalli wrote: >> I believe you added -name "*.tar.gz", right? :-) Yes, just one little thing, >> it should be '*.tar.gz' (single quotes, not double quotes) to avoid shell >> expansion... Fixed it, now it should be all right...

[XMLForm] Found my problem - Howto resolve this in general? (BUG)

hi all, did some hard core research, and found the following bug in the XMLFormTransformer.java: the "unrolling" of the "recorded" tags like "itemset" and "repeat" is only done if: class XMLFormTransformer { ... Object _value ; ... ... void unrollItemSetTag( DocumentFragment aFragment )

Re: Snapshots, Attn: Pier

Pier Fumagalli wrote: I believe you added -name "*.tar.gz", right? :-) Yes, just one little thing, it should be '*.tar.gz' (single quotes, not double quotes) to avoid shell expansion... Fixed it, now it should be all right... Single quotes make a difference if the quoted string contains shell va

DO NOT REPLY [Bug 16523] - [PATCH] JavadocSource post

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: [XMLForm] xf:itemset how to do it?

Am Mit, 2003-02-12 um 18.20 schrieb Sylvain Wallez: > Jakob Praher wrote: > > >hi all, > >or shall I say, hi noone? > > > >... hopefully this one will be answered ... > > > >allthough I have done it like in the samples, I have some problems > >getting xf:itemset bound to existing values of the mod

Re: AW: alternative to tomcat?

One thing that you'll notice right away is that cocoon deploys to Jetty with a lot less fuss (no copying about of jars to some endorsed directories, etc.). Lastly Jetty has supported JMX for a long time now which is always a nice thing from a management view-point. Cheers, Thor HW On Wednesda

Re: [XMLForm] xf:itemset how to do it?

Jakob Praher wrote: hi all, or shall I say, hi noone? ... hopefully this one will be answered ... allthough I have done it like in the samples, I have some problems getting xf:itemset bound to existing values of the model. here's the story: class MyBean { Map allLanguages; MyBean( ) {

DO NOT REPLY [Bug 16786] - [PATCH] XMLForm Xindice how-to

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 16786] - [PATCH] XMLForm Xindice how-to

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: sample web-app too complex?

On Wed, Feb 12, 2003 at 05:30:27PM +0100, SAXESS - Hussayn Dabbous wrote: > I heavily agree. > > Just another idea going into the same direction: > > Would it make sense to organise something like a > "cocoon core application" plus some zip-files, each of them > containing one complete setup for

[XMLForm] xf:itemset how to do it?

hi all, or shall I say, hi noone? ... hopefully this one will be answered ... allthough I have done it like in the samples, I have some problems getting xf:itemset bound to existing values of the model. here's the story: class MyBean { Map allLanguages; MyBean(

Re: sample web-app too complex?

On Wed, Feb 12, 2003 at 05:07:12PM +0100, Bertrand Delacretaz wrote: > Le Mercredi, 12 f?v 2003, ? 16:56 Europe/Zurich, Michael Melhem a ?crit > : > > >... > > We would also > >have only one or two pipelines using say a basic file generator > >to transform an xml file to HTML etc. I think at a mi

Re: [OT] Stefano's new signature

> This reminds me of my favorite quote : "Perfection is achieved not when > there's nothing more to add, but when there's nothing left to remove" > (Antoine de Saint-Exup?ry, also quoted by ESR in the Cathedral and the > Bazaar). This is pinned on my office wall. Sylvain, wow I like that one to

Re: sample web-app too complex?

I heavily agree. Just another idea going into the same direction: Would it make sense to organise something like a "cocoon core application" plus some zip-files, each of them containing one complete setup for one example. So the user could do : 1.) install cocoon 2.) drop his favorite example zi

Re: sample web-app too complex?

Le Mercredi, 12 fév 2003, à 16:56 Europe/Zurich, Michael Melhem a écrit : ... We would also have only one or two pipelines using say a basic file generator to transform an xml file to HTML etc. I think at a minimum the webapp would aslo need to show basic use of actions views.. ... Does anyone e

Re: sample web-app too complex?

On Mon, Feb 03, 2003 at 02:06:18PM +0100, Christian Haul wrote: > On 03.Feb.2003 -- 01:33 PM, Michael Melhem wrote: > > Hi Cocooners, > > > > I know that we probably have had this discussion before, but is there a > > reason why we dont have simple "Hello-World" sample web-app along side > > the c

Re: AW: alternative to tomcat?

"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > Yes, apparently Jetty has a problem with the classloading of resources > if they don't belong to teh /web-inf/lib but to the /web-inf/classes. That is _really_ odd... While coding the ProxyGenerator I always compiled it in WEB-INF/classes, and I ne

Re: alternative to tomcat?

"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > Pier Fumagalli wrote: >> On 12/2/03 9:56, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: >> >> >>> Scherler, Thorsten wrote: >>> Hello list, is there an ASF alternative to tomcat to run cocoon? >>> >>> unfortunately, not. >> >>

Re: AW: alternative to tomcat?

Pier Fumagalli wrote: "Scherler, Thorsten" <[EMAIL PROTECTED]> wrote: What do you mean? I guess Jetty is faster, more liable (you can bank on it), You'll see this weekend... I don't want to spoil the conference... ...and maybe with Jetty Stefano will be happier (http://article.gmane.o

Re: alternative to tomcat?

Pier Fumagalli wrote: On 12/2/03 9:56, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: Scherler, Thorsten wrote: Hello list, is there an ASF alternative to tomcat to run cocoon? unfortunately, not. Fortunately YES... It's called Jetty... http://jetty.mortbay.org/ Read the question agai

RT: Simplified build automation (was Re: [proposal] aiming to a naked cocoon)

[Centipede vs. Maven] > Krysalis Centipede www.krysalis.org/centiepde/ is a > project that does > what Maven does in a slightly different manner, and > is compatible OOTB with Gump and Forrest. I've now read through the etiquette URLs and through a portion of the Krysalis Centipede site. Haven

Re: Extending I18nTransformer to support multiple resource bundles

From: "Bruno Dumon" <[EMAIL PROTECTED]> > Hi, > > we are looking at extending the I18nTransformer so that it can use > multiple resource bundles at the same time. Thus, when it looks up a > key, it should check multiple different bundles for this key. Great! This was for a very long time in the i

Re: [proposal] aiming to a naked cocoon

Bill Barnhill wrote, On 12/02/2003 13.57: ... If you don't like the idea, fine. There's probably a reason I don't know about, as just about everyone on this project has more experience with Open Source than I do. But if you don't like what I'm saying, at least tell me why. It happens that nobod

Re: Snapshots, Attn: Pier

"Vadim Gritsenko" <[EMAIL PROTECTED]> wrote: > Vadim Gritsenko wrote: > >> Pier, >> >> What happend to those HEADER / README / .htaccess in cocoon snapshots >> directory? Also, file name became unreadable again (because of this >> DescriptionWidth=* in the www root) :'-( > > > Ok, I know, the

Snapshots, Attn: Pier

Vadim Gritsenko wrote: Pier, What happend to those HEADER / README / .htaccess in cocoon snapshots directory? Also, file name became unreadable again (because of this DescriptionWidth=* in the www root) :'-( Ok, I know, they were deleted by this "find" command in the snapshot.sh. Pier, I'v

Extending I18nTransformer to support multiple resource bundles

Hi, we are looking at extending the I18nTransformer so that it can use multiple resource bundles at the same time. Thus, when it looks up a key, it should check multiple different bundles for this key. Our idea is to simply pass multiple bundle names/locations to the I18nTransformer, and it would

Mailing list subject lines (was: [proposal] aiming to a naked cocoon)

Le Mercredi, 12 fév 2003, à 15:05 Europe/Zurich, Bill Barnhill a écrit : Not my day. I thought the message the URL referred to was an etiquette guide for Open Source mailing lists. See "Contribution Notes and Tips" at http://xml.apache.org/cocoon/contrib.html, I don't know if it is complete

Re: AW: alternative to tomcat?

"Scherler, Thorsten" <[EMAIL PROTECTED]> wrote: > What do you mean? I guess Jetty is faster, more liable (you can bank on > it), You'll see this weekend... I don't want to spoil the conference... > ...and maybe with Jetty Stefano will be happier > (http://article.gmane.org/gmane.text.xml.coc

Re: [proposal] aiming to a naked cocoon

Not my day. I thought the message the URL referred to was an etiquette guide for Open Source mailing lists. If someone has such a URL, and/or one explaining posting conventions such as RT:, AW:, and the use of Proposal: please post it to the list so myself and other raw newbies can avoid future mi

Re: [proposal] aiming to a naked cocoon

Thank you for the URL, I hadn't seen a reference to it yet, and for the re-work suggestion. I may do some more work on my own before re-submitting the proposal with a first cut to demonstrate what I'm talking about, as I've already got the source code separated into a set of ccblock-core-* dirs

Re: [proposal] aiming to a naked cocoon

Le Mercredi, 12 fév 2003, à 13:57 Europe/Zurich, Bill Barnhill a écrit : ...Also if I've posted in the wrong way somehow then point me to a url with a project mailing list etiquette guide, or tell me what I did wrong. Assuming you refer to http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=10450

Re: [proposal] aiming to a naked cocoon

FYI Maven handles both versioning and autmatic retrieval of dependencies. Dependencies can come from either a local repository or a remote repository. It also handles automatic unit testing and automatic project site generation, including cross-referenced source code. If you don't like the idea, f

AW: alternative to tomcat?

hi pier, hi list, Actually, on this topic, I have some _shocking_ results after a major benchmark session, and a comparison between Tomcat 4.1.18 and Jetty 4.2.7... What do you mean? I guess Jetty is faster, more liable (you can bank on it), ...and maybe with Jetty Stefano will be happier

AW: alternative to tomcat?

hi list, hi Pier, hi Stefano, cheers mate, I will check it out whether it is "better". Thanks again! -Ursprüngliche Nachricht- Von: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 12. Februar 2003 11:14 An: [EMAIL PROTECTED] Betreff: Re: alternative to tomcat? On 12/2/03

Re: alternative to tomcat?

"Pier Fumagalli" <[EMAIL PROTECTED]> wrote: > On 12/2/03 9:56, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > >> Scherler, Thorsten wrote: >>> Hello list, >>> >>> is there an ASF alternative to tomcat to run cocoon? >> >> unfortunately, not. > > Fortunately YES... It's called Jetty... http:/

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/sax serializer.xconf serializer.xroles

stefano 2003/02/12 03:00:05 Removed: src/java/org/apache/cocoon/components/sax serializer.xconf serializer.xroles Log: removing these since both were unneeded (since already included in the variuos xroles and xconf files)

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

stefano 2003/02/12 02:58:59 Modified:src/webapp/WEB-INF logkit.xconf Log: lower the log level to ERROR (which gives better out-of-the-box performance and better visibility of errors) Revision ChangesPath 1.13 +14 -14xml-cocoon2/src/webapp/WEB-INF/logkit.xconf

cvs commit: xml-cocoon2/tools/lib ant-20030212.jar ant-nodeps-20030212.jar ant-optional-20030212.jar ant-trax-20030212.jar ant-1.5-optional.jar ant-20030101.jar ant-nodeps-20021230.jar ant-swing-20021230.jar ant-trax-20021230.jar

stefano 2003/02/12 02:57:57 Added: tools/lib ant-20030212.jar ant-nodeps-20030212.jar ant-optional-20030212.jar ant-trax-20030212.jar Removed: tools/lib ant-1.5-optional.jar ant-20030101.jar ant-nodeps-20021230.jar ant-swing

Re: [proposal] aiming to a naked cocoon

Nicola Ken Barozzi wrote: Looking into the current trunk, there are a few components that, IMO, should be moved to blocks. They are: - XMLDB stuff - XMLForm - Deli - XScript (what the hell is this anyway?) +1 to all Gianugo IIRC had a block done for XMLDB and didn't commit it. Gianugo?

Re: [proposal] aiming to a naked cocoon

Le Mercredi, 12 fév 2003, à 11:02 Europe/Zurich, Stefano Mazzocchi a écrit : ...why duplicating jars? FOP relies on fop. Batik relies on batik and so on. The blocks that rely on shared jars, will have those jars shared in another location. Besides, how many are we talking about?... Ok, if shar

Re: alternative to tomcat?

On 12/2/03 9:56, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > Scherler, Thorsten wrote: >> Hello list, >> >> is there an ASF alternative to tomcat to run cocoon? > > unfortunately, not. Fortunately YES... It's called Jetty... http://jetty.mortbay.org/ Pier ---

Re: [proposal] aiming to a naked cocoon

Stefano Mazzocchi wrote, On 12/02/2003 10.59: Nicola Ken Barozzi wrote: Krysalis Ruper can already get Jars from a remote repository, and it's an Ant task. IF we decide that we want to keep the repository in the Cocoon CSV, it can already do the above and "synch" with that. How does it work

Re: [proposal] aiming to a naked cocoon

Bertrand Delacretaz wrote: Le Mercredi, 12 fév 2003, à 10:12 Europe/Zurich, Stephan Michels a écrit : ... +1, especially moving the libs into the blocks... Wouldn't the duplication of jars generate a huge CVS repository? It's big enough already. why duplicating jars? FOP relies on fop.

Re: [proposal] aiming to a naked cocoon

Nicola Ken Barozzi wrote: Krysalis Ruper can already get Jars from a remote repository, and it's an Ant task. IF we decide that we want to keep the repository in the Cocoon CSV, it can already do the above and "synch" with that. How does it work offline? -- Stefano Mazzocchi

Re: alternative to tomcat?

Scherler, Thorsten wrote: Hello list, is there an ASF alternative to tomcat to run cocoon? unfortunately, not. -- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] -

Re: [PROPOSAL] Cocoon Science Fiction

Niclas Hedhman wrote: Did I say it was easy?? I realize it is _extremely_ hard, and Andreas proposal tried to make it much easier than it is in reality. But we had similar arguments for Cocoon in the 1.x -> 2.0 jump. Sitemap was a hotly debated issue, but once broken down into smaller pieces an

Re: [proposal] aiming to a naked cocoon

Bertrand Delacretaz wrote, On 12/02/2003 10.20: Le Mercredi, 12 fév 2003, à 10:12 Europe/Zurich, Stephan Michels a écrit : ... +1, especially moving the libs into the blocks... Wouldn't the duplication of jars generate a huge CVS repository? It's big enough already. An option might be

Re: [proposal] aiming to a naked cocoon

Le Mercredi, 12 fév 2003, à 10:12 Europe/Zurich, Stephan Michels a écrit : ... +1, especially moving the libs into the blocks... Wouldn't the duplication of jars generate a huge CVS repository? It's big enough already. An option might be to keep the jars in a well-structured lib/ subdire

alternative to tomcat?

Hello list, is there an ASF alternative to tomcat to run cocoon? > Mit freundlichem Gruss, > > Thorsten Scherler > Marketing / Telefonmarketing > > Weidmüller GmbH & Co. > P.O. Box 2807 > 33058 Paderborn > Tel.:+ 49 - 5252-960-350 > Fax:+ 49 - 5252-960-116 > eMail: [EMAIL PROTECTED] > http://ww

Re: [proposal] aiming to a naked cocoon

On Tue, 11 Feb 2003, Stefano Mazzocchi wrote: > I think the cocoon core (aka 'naked cocoon') is defined by those classes > that don't depend on any external library but those found in /lib/core > and /lib/endorsed. > > Everything else should be a block. > > This allows us to create a build system

Re: [vote] remove interactive build targets

Le Mardi, 11 fév 2003, à 22:07 Europe/Zurich, Stefano Mazzocchi a écrit : I believe interactive targets are harmful and I propose to remove them. +1, using properties to configure builds is much better IMHO. -Bertrand - To un

Re: [proposal] aiming to a naked cocoon

Stefano Mazzocchi wrote, On 11/02/2003 22.32: I think the cocoon core (aka 'naked cocoon') is defined by those classes that don't depend on any external library but those found in /lib/core and /lib/endorsed. Everything else should be a block. This allows us to create a build system where peo

Re: [proposal] aiming to a naked cocoon

Looking into the current trunk, there are a few components that, IMO, should be moved to blocks. They are: - XMLDB stuff +1 - XMLForm +0.5 - Deli +1 - XScript (what the hell is this anyway?) +1 (or is anything but the SOAP logicsheet using it?) anything else I'm missing that sh