ForrestBot build for cocoon-docs FAILED

2010-03-22 Thread Forrestbot
Automated build for cocoon-docs FAILED
Log attached.

--
Forrestbot run ended at 22 March 12:24 PM
Using Forrest 0.9-dev
Forrestbot administrator: ForrestBot
--

 [echo] 
  ... Forrest render START 2010-03-22 12:12:05
  ... Rendering docs in 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs


check-java-version:
 [echo] This is apache-forrest-0.9-dev
 [echo] Using Java 1.5 from /usr/jdk/instances/jdk1.5.0/jre
 [echo] Using Apache Ant version 1.7.1 compiled on September 26 2008 from 
/export/opt/forrest-trunk/tools/ant

init-props:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

echo-settings-condition:

echo-settings:

check-skin:

init-proxy:

fetch-skins-descriptors:

fetch-skin:

unpack-skins:

init-skins:

fetch-plugins-descriptors:
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/plugins.xml
  [get] To: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml
  [get] local file date : Thu Sep 18 09:05:40 GMT+00:00 2008
  [get] .
  [get] last modified = Wed Dec 03 00:37:14 GMT+00:00 2008
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] To: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml
  [get] local file date : Sun Dec 06 01:05:06 GMT+00:00 2009
  [get] Not modified - so not downloaded
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/plugins.xml.
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/whiteboard-plugins.xml.

init-plugins:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] 
  --
  Installing plugin: org.apache.forrest.plugin.output.pdf
  --
   

check-plugin:
 [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. 
Trying to update it...

init-props:

echo-settings-condition:

echo-settings:

init-proxy:

fetch-plugins-descriptors:

fetch-plugin:
 [echo] Trying to find the description of 
org.apache.forrest.plugin.output.pdf in the different descriptor files
 [echo] Using the descriptor file 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml...
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

fetch-local-unversioned-plugin:

get-local:
 [echo] Trying to locally get org.apache.forrest.plugin.output.pdf
 [echo] Looking in local /export/opt/forrest-trunk/plugins
 [echo] Found !

init-build-compiler:

echo-init:

init:

compile:

jar:

local-deploy:
 [echo] Locally deploying org.apache.forrest.plugin.output.pdf

build:
 [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to 
configure

fetch-remote-unversioned-plugin-version-forrest:

fetch-remote-unversioned-plugin-unversion-forrest:

has-been-downloaded:

downloaded-message:

uptodate-message:

not-found-message:
 [echo] Fetch-plugin Ok, installing !

unpack-plugin:

install-plugin:

configure-plugin:

configure-output-plugin:
 [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl
 [move] Moving 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

configure-plugin-locationmap:
 [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml 
to 

Performance with jx:foreach?

2010-03-22 Thread Hallmann, Marcel
Hi there,
I do have a problem with my cocoon 2.1.9 application:
In flowscript I call a Java method which query a SQL statement.

In the model.xml the widgets for the result table are defined via e.g.:
fd:output id=name
  fd:datatype base=string
  /fd:datatype
/fd:output

and filled in the bind.xml via:
fb:repeater id=list parent-path=. row-path=elements direction=load
  fb:on-bind
fb:value id=name path=name 
direction=load/
  /fb:on-bind
/fb:repeater

The resultset shall be displayed in the template.xml with jx:foreach (which is 
working, but extremly slow):
ft:repeater-widget id=list
  fi:items
jx:forEach var='column' items=${widget.getChildren()}
  tdft:widget id=${columnId}//td (columnId is known)
/jx:forEach
  /fi:items
/ft:repeater-widget

I noticed, that a when I call the widget names directly e.g
tdft:widget id=name//td and so on
and do NOT use the jx:foreach, the performance is much better.

Do you have tips for me, how I can increase the performance using jx:foreach?

Thanks for your help!

Best regards

The content of this e-mail is intended only for the confidential use of the 
person addressed. 
If you are not the intended recipient, please notify the sender and delete this 
e-mail immediately.
Thank you.


RE: Performance with jx:foreach?

2010-03-22 Thread Robby Pelssers
You probably should use a construct like this:
 
 
ft:form action=#{$cocoon/continuation/id}.continue method=POST 
 
  table style=width: 100%;
thead
  tr
th class=header style=width: 5%;ft:widget 
id=selectAll//th
th class=header style=width: 95%;Topic/th
  /tr
/thead
ft:repeater id=topics
  tbody
ft:repeater-rows
  tr
tdft:widget id=selectTopic//td
tdft:widget id=title/ft:widget id=id//td
  
  /tr
/ft:repeater-rows
  /tbody
/ft:repeater
  /table
  div style=margin-top:10px;
ft:widget id=viewXML/
ft:widget id=viewDatasheet/
ft:widget id=downloadZIP_eps/
ft:widget id=downloadZIP_gif/
  /div
/ft:form
 
So instead of using repeaterWidget.getChildren….   Use ft:repeater-rows
 
Kind regards,
Robby Pelssers
 
From: Hallmann, Marcel [mailto:marcel.hallm...@six-group.com] 
Sent: Monday, March 22, 2010 4:21 PM
To: dev@cocoon.apache.org
Subject: Performance with jx:foreach?
 
Hi there, 
I do have a problem with my cocoon 2.1.9 application: 
In flowscript I call a Java method which query a SQL statement. 

In the model.xml the widgets for the result table are defined via e.g.: 
fd:output id=name 
  fd:datatype base=string 
  /fd:datatype 
/fd:output 

and filled in the bind.xml via: 
fb:repeater id=list parent-path=. row-path=elements direction=load 
  fb:on-bind 
fb:value id=name path=name 
direction=load/ 
  /fb:on-bind 
/fb:repeater 

The resultset shall be displayed in the template.xml with jx:foreach (which is 
working, but extremly slow): 
ft:repeater-widget id=list 
  fi:items   
jx:forEach var='column' items=${widget.getChildren()} 
  tdft:widget id=${columnId}//td (columnId is known) 
/jx:forEach 
  /fi:items 
/ft:repeater-widget 

I noticed, that a when I call the widget names directly e.g 
tdft:widget id=name//td and so on 
and do NOT use the jx:foreach, the performance is much better. 

Do you have tips for me, how I can increase the performance using jx:foreach? 

Thanks for your help!
 
Best regards
The content of this e-mail is intended only for the confidential use of the 
person addressed. 
If you are not the intended recipient, please notify the sender and delete this 
e-mail immediately.
Thank you.


[2.1] Is Cocoon 2.1.x officially dead ?

2010-03-22 Thread Cédric Damioli

Hi Cocoon community,

Here at Anyware, we have dozens of Cocoon-2.1 based applications in 
production.
We've hacked Cocoon a lot, so that migrating to most recent releases of 
Cocoon is not an option for us at the moment
Cocoon 2.1 is a *very* stable framework, especially the core, but I 
recently came across a bug and discovered that, even if I provide a 
patch, there will be nobody to commit it, let alone release the next 
2.1.12 maintenance version.
Diving in the ML archives, I discovered than Carsten, the last 2.1 
release manager, resigned from the job almost two years ago [1], and 
that nobody took over.


So I'm wondering if someone around here was still willing to maintain 
the Cocoon-2.1 branch ?
If not, I volunteer to do the job, as this branch is important for us, 
and I don't want to have to fork it in our own repository.

Otherwise, do you have other solutions for me ?

BTW, is there still many Cocoon-2.1 users around here ?

Best regards,
Cédric Damioli

[1] 
http://mail-archives.apache.org/mod_mbox/cocoon-dev/200805.mbox/%3c483cf62f.3000...@apache.org%3e


--
Cédric Damioli
RD director
Ametys CMS
ANYWARE SERVICES
Tel : +33 (0)5 61 00 73 47
Mob : +33 (0)6 87 03 61 63
Fax : +33 (0)5 61 00 51 46
http://www.anyware-services.com
http://www.ametys.org




Re: [2.1] Is Cocoon 2.1.x officially dead ?

2010-03-22 Thread Peter Hunsberger
2010/3/22 Cédric Damioli cedric.dami...@anyware-services.com:

 So I'm wondering if someone around here was still willing to
 maintain the Cocoon-2.1 branch ? If not, I volunteer to do the
 job, as this branch is important for us, and I don't want to have
 to fork it in our own repository. Otherwise, do you have other
 solutions for me ?

 BTW, is there still many Cocoon-2.1 users around here ?


Not sure who might be able to do a commit, in theory I could, but
we're no where close to current on 2.1 and I really don't have time to
bring up a current version and test.  Have you submitted the patch?
If it's a trivial I'm pretty sure someone should be able to look at
it, and maybe even if it's big.

We are using 2.1, but we're still on 2.1.8.

-- 
Peter Hunsberger