Re: generating the 2.1 Changes page (Was: [Vote] Releasing 2.1.8 tomorrow)
Le 11 nov. 05, à 04:26, David Crossley a écrit : ...The top-level docs are now building the changes page by getting the status.xml file from the 2.1 branch svn. Not ideal, but it works Great! http://forrest.zones.apache.org/ft/build/cocoon-site/changes.html The problem is that that page will not be added to the 2.1 docs package, but at least we can update it on the website... You mean, the page will not be in the distribution? The status.xml page is in there, which is good enough I think, given that the changes will be available on the website. -Bertrand
Problem with ReloadingClassLoader
I have a nasty error that I can't track down. I'm using the ReloadingClassloader
of trunk and include it with following code:
I declare a couple of components like generators and actions. Using an action
works as it has been doing for months but since an upgrade to the latest SVN I
get following error when declaring a custom generator:
The HTTP response is:
HTTP ERROR: 500 my.CustomGenerator (Bad index in constant pool.)
At the console following stacktrace appears:
java.lang.ClassFormatError: my.CustomGenerator (Bad ind
ex in constant pool.)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
at java.lang.ClassLoader.defineClass(ClassLoader.java:448)
at org.apache.cocoon.components.classloader.ReloadingClassLoaderFactory$
DefaultClassLoader.fastFindClass(ReloadingClassLoaderFactory.java:182)
Any ideas?
BTW, currently ReloadingClassLoaderFactory doesn't work out of the box as it
isn't declared in any xconf and also requires commons-io which is optional.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 10 Nov 2005, Joerg Heinicke wrote: Date: Thu, 10 Nov 2005 23:59:14 +0100 From: Joerg Heinicke <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacro sHelper.java On 10.11.2005 19:50, Giacomo Pati wrote: The widgets in the repeater rows need to be displayed wrt some properties of a single object (let's say its a 'state of completness'). Now from MVC POV it's the viewer (template) that knows how to display the properties of the business model and thus needs a way to instruct the technology used (CForm) to respect that. Sorry, but I absolutely don't follow you here. MVC is for decoupling model, view and controller, i.e. to have as few as possible dependencies between the three aspects. There are three you need: the controller changing the model, the controller selecting the view and the view accessing the properties of the model. But the latter one must be a read-only process, otherwise the view does not only depend on the model, but also the model on the view, as the view would not be interchangeable. I thought I've said eactly this: The View knows how to display the Model (where do you read in my mail that the View changes the Model?) In your sample a property of the model (viewable or not, editable or not) shall be changed by the view, what is plain wrong IMO. It is the task of the controller to take care of it. Actually the flow is supposed to be glue code between Controller and Model of MVC not actually the Viewer part. Isn't flow supposed to be *the* controller (or at least part of it)? Yes, part of the Conroller Jörg - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdDUdLNdJvZjjVZARAu9NAJ9njBkLdk5Y4GS/WoAt8F8Af2IK2ACgqqpf KXtdMhnyQ9aNJ3b8BnCi+aw= =+74W -END PGP SIGNATURE-
Re: ForrestBot build for cocoon-site succeeded
> Automated build for cocoon-site succeeded Woops, forgot to set "notify.on.success" value="false" Fixed now. -David
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 11 November 05:10 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-11-11 05:02:06 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: 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 [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 init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. 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 files 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 /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [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. fetch-plugin: [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 findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.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-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Thu Nov 10 12:07:13 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-cocoon: [copy] Warnin
ForrestBot build for cocoon-site succeeded
Automated build for cocoon-site succeeded Log attached. -- Forrestbot run ended at 11 November 04:59 AM Using Forrest 0.8-dev Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-11 04:59:06 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/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 init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/locationmap.xml to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.projectInfo check-plugin: [echo] org.apache.forrest.plugin.input.projectInfo is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [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. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/plugins-1.xml to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins//org.apache.forrest.plugin.input.projectInfo.zip [get] [get] last modified = Fri Nov 11 03:07:05 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.projectInfo downloaded, ready to install fetchplugin: [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/plugins-2.xml to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.projectInfo.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.projectInfo [delete] Deleting 1 files from /export
ForrestBot build for cocoon-site succeeded
Automated build for cocoon-site succeeded Log attached. -- Forrestbot run ended at 11 November 03:59 AM Using Forrest 0.8-dev Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-11 03:59:06 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/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 init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/locationmap.xml to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.projectInfo check-plugin: [echo] org.apache.forrest.plugin.input.projectInfo is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [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. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/plugins-1.xml to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins//org.apache.forrest.plugin.input.projectInfo.zip [get] . [get] last modified = Fri Nov 11 03:07:05 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.projectInfo downloaded, ready to install fetchplugin: [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/plugins-2.xml to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.projectInfo.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.projectInfo [delete] Deleting 1 files from /expor
generating the 2.1 Changes page (Was: [Vote] Releasing 2.1.8 tomorrow)
David Crossley wrote: > Bertrand Delacretaz wrote: > > David Crossley a ?crit : > > >...As i warned a long time ago, the re-arrangement of > > >documentation should not have been done until the > > >2.2 release... > > > > Fully agreed, staying with the old docs for 2.1.8 seems much easier, > > and 2.2 is a good time to make a transition on the docs. > > > > >...If people are not going to help fix the new Daisy-based > > >documentation for this release, then we we need to > > >repair the old documentation building system, e.g. the > > >index.xml file seems to be missing and various other > > >source files have been deleted... > > > > Could we do the release and regenerate only the index and news pages? > > I don't think there have been much changes to other parts of the "old" > > docs. > > > > I'm strongly for releasing 2.1.8 with the "old" docs and take our time > > to improve them for 2.2. > > Good idea, i was wondering about that as a workaround. > We can easily update the complete top-level docs, same > as before. > http://wiki.apache.org/cocoon/CocoonWebsiteUpdate > > We might be able to repair the old 2.1 docs sufficiently > to get the changes.html page built and update only that page. > > Doing 'svn log status.xml' shows that quite a lot > of changes (~130) are noted since 2.1.7 (March 23 2005). Okay i tried various ways to do that and now have one solution working. It would have been better get the cocoon-daisy-to-docs to process the Changes (since they belong with 2.1). However i cannot do that because the Forrest Daisy plugin seems to intercept everything and map it to Daisy. So the projectInfo plugin can't handle it. The top-level docs are now building the changes page by getting the status.xml file from the 2.1 branch svn. Not ideal, but it works. http://forrest.zones.apache.org/ft/build/cocoon-site/changes.html The problem is that that page will not be added to the 2.1 docs package, but at least we can update it on the website. -David
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 11 November 02:10 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-11-11 02:02:06 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: 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 [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 init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. 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 files 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 /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [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. fetch-plugin: [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 findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.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-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Thu Nov 10 12:07:13 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-cocoon: [copy] Warnin
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Sylvain Wallez wrote: I totally agree with your concern of malicious requests, and that was actually one of the motivations behind widget states. Now, as said in my previous post, I consider this a business logic concern that has nothing to do in the template. +1 Best Regards, Antonio Gallardo. Sylvain
Re: ForrestBot build for cocoon-docs FAILED
Hmm, looking further at the messages, there are just a few broken links ... http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml -David
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: > hepabolu wrote: > > > > -/changes.html > > > >This is so outdated (see http://cocoon.apache.org/changes.html) that I > >would be ashamed to put it up again. So it's missing from Daisy (also > >because it's toplevel) and therefore from forrest.zones. Not correct, please read the other recent threads about this. > This is generated from status.xml > (http://cocoon.apache.org/2.1/changes.html), same as todo.html. The reason that that page appears to be "outdated" is that no committers have found the wherewithall to update the website since the last release. These pages are generated, so if no-one does it then it doesn't happen. As i said in another thread there are hundreds of new entries recorded in the status.xml file. As i said in another thread i am still trying to find new ways to generate that since the old Cocoon-2.1 docs build is now broken. -David
Re: ForrestBot build for cocoon-docs FAILED
Ross Gardler wrote: > [EMAIL PROTECTED] wrote: > >Automated build for cocoon-docs FAILED > >Log attached. > > ... > > > [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs > > [echo] Oops, something broke > > Interesting... > > Every build overnight (for me) worked, but this one failed. I can't look > into this right now, but I don't see any commits or changes that would > cause this. Hopefully it is a network glitch. > > New build due in around 30 minutes. Sorry, i looked on the forrest zone and found that the config file was set to only send the message to me. I reverted that change at 07:28 GMT and prior to that i was not getting any failure messages. So it must be something changed in the previous 3 hours. -David
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 10 November 11:10 PM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-11-10 11:02:06 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: 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 [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 init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. 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 files 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 /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [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. fetch-plugin: [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 findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.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-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Thu Nov 10 12:07:13 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-cocoon: [copy] Warnin
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
On 10.11.2005 19:50, Giacomo Pati wrote: The widgets in the repeater rows need to be displayed wrt some properties of a single object (let's say its a 'state of completness'). Now from MVC POV it's the viewer (template) that knows how to display the properties of the business model and thus needs a way to instruct the technology used (CForm) to respect that. Sorry, but I absolutely don't follow you here. MVC is for decoupling model, view and controller, i.e. to have as few as possible dependencies between the three aspects. There are three you need: the controller changing the model, the controller selecting the view and the view accessing the properties of the model. But the latter one must be a read-only process, otherwise the view does not only depend on the model, but also the model on the view, as the view would not be interchangeable. In your sample a property of the model (viewable or not, editable or not) shall be changed by the view, what is plain wrong IMO. It is the task of the controller to take care of it. Actually the flow is supposed to be glue code between Controller and Model of MVC not actually the Viewer part. Isn't flow supposed to be *the* controller (or at least part of it)? Jörg
Re: [DOCS] Building for release - update round 2
Ross Gardler wrote: Note, somehow only the menu is up on forrest.zones, all linked pages are gone. I suspect this is due to the split in the navigation doc in Daisy and should be fixed when Ross adjusts the appropriate files in Forrest. I'm not seeing this. I see the full contents of the site, all looking lovely, with the corect URLspace. Are you still seeing this problem? Just checked: no everything seems fine. There are three broken links in the site build now, I'll look at those tomorrow morning (UTC), if someone else wants to have a go at it the broken links are shown on: http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml IIUC there are four broken links, but I have no clue how to fix it, sorry. Bye, Helma
Re: [DOCS] Building for release - update round 2
hepabolu wrote: Vadim Gritsenko wrote: Results are encouraging - now diff between old URI space and new version is much smaller (attached as well) Note that there are several numbered docs in there - either mislabelled old docs or newly added docs, i have not checked. Note, somehow only the menu is up on forrest.zones, all linked pages are gone. I suspect this is due to the split in the navigation doc in Daisy and should be fixed when Ross adjusts the appropriate files in Forrest. I'm not seeing this. I see the full contents of the site, all looking lovely, with the corect URLspace. Are you still seeing this problem? There are three broken links in the site build now, I'll look at those tomorrow morning (UTC), if someone else wants to have a go at it the broken links are shown on: http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml They look like they are in the index file since they are referenced from a great many pages. Here are snippets of your diff that I want to comment on: I'll look at this later in the thread, after I have read Vadims response. Ross
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 10 November 08:10 PM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-11-10 08:02:06 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: 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 [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 init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. 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 files 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 /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [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. fetch-plugin: [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 findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.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-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Thu Nov 10 12:07:13 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-cocoon: [copy] Warnin
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 10 Nov 2005, Sylvain Wallez wrote: Date: Thu, 10 Nov 2005 17:32:02 +0100 From: Sylvain Wallez <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacro sHelper.java Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, lets discuss this :-) maybe there are other ways to do it. To make things clear: I reverted the change, as we were (supposedly :-) ) very close to the release, and this seemed to me a significant change that needed to be discussed. Agreed. The point is that this change introduced the ability for the view to change the state of the model, which violates the principles of MVC. Hence the need We can also discuss whether the Form model is part of the business model or the View from a MVC POV. for discussing it first, rather than committing it silently just before the release. Ok. The use case to this is: a) Suppose you have a repeater showing some informations. b) Suppose the users viewing that information can have different role. Now, depending on the role the user has 1) he may not see some of the rows (which would be filtered out before passing it to the template of course) 2) he may see some of the row (output state) 3) he may even edit some of the rows (input state) How would you accomplish this in a repeater without enabling the template to change the state in the repeater according to the role of the viewing user (which is passed down the pipeline)? Role management is not a concern of the view, but of either the controller or the business logic, that should set the correct widget state before displaying the form. Otherwise, you end up with mixing page layout and authorization logic in the view, which IMO isn't good. Actually the sample given isn't the best. How about a simpler one: The widgets in the repeater rows need to be displayed wrt some properties of a single object (let's say its a 'state of completness'). Now from MVC POV it's the viewer (template) that knows how to display the properties of the business model and thus needs a way to instruct the technology used (CForm) to respect that. Using widgets per role is very ugly (I've tried that) and may complicate validation of not displayed widgets in a row. Sure. Any suggestion would be welcome otherwise I'd like to have that change going into the repository (this or the following release). Setting widget states in the flowscript: doesn't it fit your need? Actually the flow is supposed to be glue code between Controller and Model of MVC not actually the Viewer part. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDc5ZrLNdJvZjjVZARAlFtAJ9cVrX6/owAOztHns6LrQgxsjwkPwCgws/R p6XdAyM1W1cv6ruS25iJrh8= =kYiI -END PGP SIGNATURE-
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 10 November 05:10 PM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-11-10 05:02:06 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: 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 [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 init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. 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 files 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 /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] .. [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [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. fetch-plugin: [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 findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.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-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] [get] last modified = Thu Nov 10 12:07:13 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-cocoon: [copy] Warnin
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Max Pfingsthorn wrote: Hi! I actually like this for exactly the reason Giacomo pointed out. The thing I am always afraid of is vulnerability to malicious requests, which this actually prevents. This is in itself not a template (i.e. rendering) option but changes the model on the fly, which can be considered as a "view" of the model, so I would think it does belong into the template. Alternatively, you can of course take care of this in your flowscript which calls the template pipeline in the first place, but then you have to know the correct ID of the widget, which can be rather hard, especially if you use libraries or some other way to generate forms. I totally agree with your concern of malicious requests, and that was actually one of the motivations behind widget states. Now, as said in my previous post, I consider this a business logic concern that has nothing to do in the template. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, lets discuss this :-) maybe there are other ways to do it. To make things clear: I reverted the change, as we were (supposedly :-) ) very close to the release, and this seemed to me a significant change that needed to be discussed. The point is that this change introduced the ability for the view to change the state of the model, which violates the principles of MVC. Hence the need for discussing it first, rather than committing it silently just before the release. The use case to this is: a) Suppose you have a repeater showing some informations. b) Suppose the users viewing that information can have different role. Now, depending on the role the user has 1) he may not see some of the rows (which would be filtered out before passing it to the template of course) 2) he may see some of the row (output state) 3) he may even edit some of the rows (input state) How would you accomplish this in a repeater without enabling the template to change the state in the repeater according to the role of the viewing user (which is passed down the pipeline)? Role management is not a concern of the view, but of either the controller or the business logic, that should set the correct widget state before displaying the form. Otherwise, you end up with mixing page layout and authorization logic in the view, which IMO isn't good. Using widgets per role is very ugly (I've tried that) and may complicate validation of not displayed widgets in a row. Sure. Any suggestion would be welcome otherwise I'd like to have that change going into the repository (this or the following release). Setting widget states in the flowscript: doesn't it fit your need? IIRC there is no place other than the template to handle the repeater model content associated to a widget. Sorry, I don't follow you here: you can access the full form model from the flowscript. Did I missed something? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [DOCS] Building for release - update round 2
hepabolu wrote: Here are snippets of your diff that I want to comment on: > +/692.html > +/692.html > +/692.html I'm not sure where you found this one, Me too. Had this in locationmap src="http://publish:[EMAIL PROTECTED]:9263/publisher/document?documentId=692&includeNavigation=false&locale=en_US&version=live"/> because it doesn't show up on the forrest.zone set. In Daisy I used it to work around a little problem in the navigation doc: if a group contains only links to external pages, it doesn't open because there is no internal document to display. The content of this page is reflected in the forrest.zones set similar to the cocoon.apache.org set, with one exception: the "Links" section is not present in forrest.zones although it is present in Daisy. > -/catalog-test.html IIUC this is only present in the repository, but not on cocoon.apache.org and also not in Daisy. It is beyond me to grasp the value of this page, so AFAIC I won't put any effort into it to get it on the website. Again, this is toplevel, so that explains its absence as well. No this is not top level, everything in this diff is under /2.1/. I removed this document as its value was only for testing running Cocoon instance, and it is not needed to be on docs site. > -/changes.html This is so outdated (see http://cocoon.apache.org/changes.html) that I would be ashamed to put it up again. So it's missing from Daisy (also because it's toplevel) and therefore from forrest.zones. This is generated from status.xml (http://cocoon.apache.org/2.1/changes.html), same as todo.html. > +/developing/portal/authentication.html In the original site, this points to /developing/webapps/authentication.html. Although Daisy also refers to the same document, it is now available under two urls. No showstopper for me. > /developing/portal/coplets.html > +/developing/portal/coplets/cachinguricoplet.html > +/developing/portal/coplets/uricoplet.html The two pages below are extracted from the huge coplets.html file and put in separate pages to keep the info more readable. They can be reached through the menu see forrest.zones. There was an issue with an extra /portal/ in the url. I've fixed that. Only thing that remains are the samples: daisy export: /developing/portal/samples/forms.html + .../basket.html cocoon.apache.org: /developing/portal/forms.html + .../basket.html > +/developing/portal/layout_skins.html > +/developing/portal/wsrp.html New content > +/developing/webapps/604.html Fixed > +/developing/webapps/application_management.html > +/developing/webapps/authenticating_user.html > +/developing/webapps/module_management.html > +/developing/webapps/pipeline_patterns.html > +/developing/webapps/summary.html > +/developing/webapps/user_administration.html > +/developing/webapps/user_management.html Same as for the portal: this was all part of one huge "authentication.html" file. I've split it into different smaller files to keep it more readable. They are all in the menu. > -/installing/requirements.html Fixed > -/plan/changes-doc.html > -/plan/issues-doc.html > -/plan/review-sitemap-docs.html > -/plan/todo-doc.html These are very old and very outdated. The info is either done or not valid any more. When we want to have a "hip and modern" Cocoon, these pages provide the opposite signal. Since they deal with documentation only, I suggest to simply leave them out. If people think the information is worthwhile keeping, I suggest we either move them to Daisy but only for archiving purposes, or we move the info to the wiki. I'd prefer to remove them too. > -/todo.html IIUC this is genererated from status.xml, so I didn't do anything with this, although I think this is a good candidate for either Jira (most obvious place) or a Daisy document (easier to get an overview). > +/userdocs/forms/ajax.html > +/userdocs/forms/formlibraries.html > +/userdocs/forms/improving_sample.html > +/userdocs/forms/selectionlists.html > +/userdocs/forms/templating.html > +/userdocs/forms/widget_class.html > +/userdocs/forms/widget_form.html > +/userdocs/forms/widget_group.html > +/userdocs/forms/widget_imagemap.html > +/userdocs/forms/widget_tree.html > +/userdocs/forms/widget_union.html > +/userdocs/forms/widgetstates.html > +/userdocs/forms/xmlbinding.html > +/userdocs/matchers/template-matcher.html New content > -/userdocs/generators/sessionattribute-generator.html > -/userdocs/transformers/jpath-transformer.html > -/userdocs/transformers/role-filter-transformer.html > -/userdocs/transformers/simple-form-instance-transformer.html > -/userdocs/transformers/simple-form-transformer.html I've recreated the pages, with hardly any info in it, for url-compatibility sake. There were already links to the apidocs for these classes. > +/userdocs/transformers/463.html > -/userdocs/transformers/i18n-transformer.html Fixed, 463 = i18n-transformer Thanks Vadi
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 10 November 02:10 PM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-11-10 02:02:06 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: 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 [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 init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. 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 files 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 /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [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. fetch-plugin: [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 findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.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-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Thu Nov 10 12:07:13 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-cocoon: [copy] Warnin
[EMAIL PROTECTED]: Project cocoon-block-cron (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-cron has an issue affecting its community integration. This issue affects 5 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-cron : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-repository : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [cron-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/gump_work/build_cocoon_cocoon-block-cron.html Work Name: build_cocoon_cocoon-block-cron (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-10112005 -Dblock-name=cron gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-10112005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-10112005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-10112005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-10112005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-10112005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-10112005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jxpath/dist/commons-jxpath.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/common
[EMAIL PROTECTED]: Project cocoon-block-cron (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-cron has an issue affecting its community integration. This issue affects 5 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-cron : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-repository : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [cron-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/gump_work/build_cocoon_cocoon-block-cron.html Work Name: build_cocoon_cocoon-block-cron (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-10112005 -Dblock-name=cron gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-10112005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-10112005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-10112005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-10112005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-10112005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-10112005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jxpath/dist/commons-jxpath.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/common
[EMAIL PROTECTED]: Project cocoon-block-jcr (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-jcr has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - cocoon-block-jcr : A "jcr:" protocol for Cocoon Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-jcr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [jcr-block.jar] identifier set to project name -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/blocks/jcr-block.jar -ERROR- See Directory Listing Work for Missing Outputs -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-jcr/gump_work/build_cocoon_cocoon-block-jcr.html Work Name: build_cocoon_cocoon-block-jcr (Type: Build) Work ended in a state of : Success Elapsed: 19 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=10112005 -Dblock-name=jcr gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon/blocks/jcr/dest:/usr/local/gump/public/workspace/cocoon/build/cocoon/blocks/jcr/test:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-10112005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-10112005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-10112005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-10112005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-10112005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-10112005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-10112005.jar:/usr/local/gump/public/works
[EMAIL PROTECTED]: Project cocoon-block-jcr (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-jcr has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - cocoon-block-jcr : A "jcr:" protocol for Cocoon Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-jcr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [jcr-block.jar] identifier set to project name -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/blocks/jcr-block.jar -ERROR- See Directory Listing Work for Missing Outputs -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-jcr/gump_work/build_cocoon_cocoon-block-jcr.html Work Name: build_cocoon_cocoon-block-jcr (Type: Build) Work ended in a state of : Success Elapsed: 19 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=10112005 -Dblock-name=jcr gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon/blocks/jcr/dest:/usr/local/gump/public/workspace/cocoon/build/cocoon/blocks/jcr/test:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-10112005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-10112005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-10112005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-10112005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-10112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-10112005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-10112005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-10112005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-10112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-10112005.jar:/usr/local/gump/public/works
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: Results are encouraging - now diff between old URI space and new version is much smaller (attached as well) Note that there are several numbered docs in there - either mislabelled old docs or newly added docs, i have not checked. Note, somehow only the menu is up on forrest.zones, all linked pages are gone. I suspect this is due to the split in the navigation doc in Daisy and should be fixed when Ross adjusts the appropriate files in Forrest. Here are snippets of your diff that I want to comment on: > +/692.html > +/692.html > +/692.html I'm not sure where you found this one, because it doesn't show up on the forrest.zone set. In Daisy I used it to work around a little problem in the navigation doc: if a group contains only links to external pages, it doesn't open because there is no internal document to display. The content of this page is reflected in the forrest.zones set similar to the cocoon.apache.org set, with one exception: the "Links" section is not present in forrest.zones although it is present in Daisy. > -/catalog-test.html IIUC this is only present in the repository, but not on cocoon.apache.org and also not in Daisy. It is beyond me to grasp the value of this page, so AFAIC I won't put any effort into it to get it on the website. Again, this is toplevel, so that explains its absence as well. > -/changes.html This is so outdated (see http://cocoon.apache.org/changes.html) that I would be ashamed to put it up again. So it's missing from Daisy (also because it's toplevel) and therefore from forrest.zones. > +/developing/portal/authentication.html In the original site, this points to /developing/webapps/authentication.html. Although Daisy also refers to the same document, it is now available under two urls. No showstopper for me. > /developing/portal/coplets.html > +/developing/portal/coplets/cachinguricoplet.html > +/developing/portal/coplets/uricoplet.html The two pages below are extracted from the huge coplets.html file and put in separate pages to keep the info more readable. They can be reached through the menu see forrest.zones. There was an issue with an extra /portal/ in the url. I've fixed that. Only thing that remains are the samples: daisy export: /developing/portal/samples/forms.html + .../basket.html cocoon.apache.org: /developing/portal/forms.html + .../basket.html > +/developing/portal/layout_skins.html > +/developing/portal/wsrp.html New content > +/developing/webapps/604.html Fixed > +/developing/webapps/application_management.html > +/developing/webapps/authenticating_user.html > +/developing/webapps/module_management.html > +/developing/webapps/pipeline_patterns.html > +/developing/webapps/summary.html > +/developing/webapps/user_administration.html > +/developing/webapps/user_management.html Same as for the portal: this was all part of one huge "authentication.html" file. I've split it into different smaller files to keep it more readable. They are all in the menu. > -/installing/requirements.html Fixed > -/plan/changes-doc.html > -/plan/issues-doc.html > -/plan/review-sitemap-docs.html > -/plan/todo-doc.html These are very old and very outdated. The info is either done or not valid any more. When we want to have a "hip and modern" Cocoon, these pages provide the opposite signal. Since they deal with documentation only, I suggest to simply leave them out. If people think the information is worthwhile keeping, I suggest we either move them to Daisy but only for archiving purposes, or we move the info to the wiki. > -/todo.html IIUC this is genererated from status.xml, so I didn't do anything with this, although I think this is a good candidate for either Jira (most obvious place) or a Daisy document (easier to get an overview). > +/userdocs/forms/ajax.html > +/userdocs/forms/formlibraries.html > +/userdocs/forms/improving_sample.html > +/userdocs/forms/selectionlists.html > +/userdocs/forms/templating.html > +/userdocs/forms/widget_class.html > +/userdocs/forms/widget_form.html > +/userdocs/forms/widget_group.html > +/userdocs/forms/widget_imagemap.html > +/userdocs/forms/widget_tree.html > +/userdocs/forms/widget_union.html > +/userdocs/forms/widgetstates.html > +/userdocs/forms/xmlbinding.html > +/userdocs/matchers/template-matcher.html New content > -/userdocs/generators/sessionattribute-generator.html > -/userdocs/transformers/jpath-transformer.html > -/userdocs/transformers/role-filter-transformer.html > -/userdocs/transformers/simple-form-instance-transformer.html > -/userdocs/transformers/simple-form-transformer.html I've recreated the pages, with hardly any info in it, for url-compatibility sake. There were already links to the apidocs for these classes. > +/userdocs/transformers/463.html > -/userdocs/transformers/i18n-transformer.html Fixed, 463 = i18n-transformer Bye, Helma
RE: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Hi!
I actually like this for exactly the reason Giacomo pointed out. The thing I am
always afraid of is vulnerability to malicious requests, which this actually
prevents.
This is in itself not a template (i.e. rendering) option but changes the model
on the fly, which can be considered as a "view" of the model, so I would think
it does belong into the template.
Alternatively, you can of course take care of this in your flowscript which
calls the template pipeline in the first place, but then you have to know the
correct ID of the widget, which can be rather hard, especially if you use
libraries or some other way to generate forms.
So, in general, +1 for this change.
max
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Giacomo Pati
> Sent: Thursday, November 10, 2005 13:36
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r330598 -
> /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/genera
> tion/JXMac
> rosHelper.java
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Ok, lets discuss this :-) maybe there are other ways to do it.
>
> The use case to this is:
>
> a) Suppose you have a repeater showing some informations.
> b) Suppose the users viewing that information can have different role.
>
> Now, depending on the role the user has
>
>1) he may not see some of the rows (which would be
> filtered out before
> passing it to the template of course)
>2) he may see some of the row (output state)
>3) he may even edit some of the rows (input state)
>
> How would you accomplish this in a repeater without enabling the
> template to change the state in the repeater according to the role of
> the viewing user (which is passed down the pipeline)?
>
> Using widgets per role is very ugly (I've tried that) and may
> complicate
> validation of not displayed widgets in a row.
>
> Any suggestion would be welcome otherwise I'd like to have
> that change
> going into the repository (this or the following release).
>
> IIRC there is no place other than the template to handle the repeater
> model content associated to a widget.
>
> Thanks and ciao
>
> Giacomo
>
> On Thu, 3 Nov 2005, [EMAIL PROTECTED] wrote:
>
> > Date: Thu, 03 Nov 2005 18:17:42 -
> > From: [EMAIL PROTECTED]
> > Reply-To: dev@cocoon.apache.org
> > To: cvs@cocoon.apache.org
> > Subject: svn commit: r330598 -
> >
> /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/genera
> tion/JXMacro
> > sHelper.java
> >
> > Author: sylvain
> > Date: Thu Nov 3 10:17:39 2005
> > New Revision: 330598
> >
> > URL: http://svn.apache.org/viewcvs?rev=330598&view=rev
> > Log:
> > Reverting r328311: allowing the template to change the
> widget is a fundamental change that must be discussed prior
> to be included in a release
> >
> > Modified:
> >
> cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generat
> ion/JXMacrosHelper.java
> >
> > Modified:
> cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generat
> ion/JXMacrosHelper.java
> > URL:
> http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/o
rg/apache/cocoon/forms/generation/JXMacrosHelper.java?rev=330598&r1=330597&r2=330598&view=diff
> ==
> ---
> cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
> (original)
> +++
> cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
> Thu Nov 3 10:17:39 2005
> @@ -287,10 +287,6 @@
> */
> public void generateWidget(Widget widget, Map arguments) throws
> SAXException {
> // Needs to be buffered
> -String state = (String)arguments.get("state");
> -if (state != null) {
> -widget.setState(WidgetState.stateForName(state));
> -}
> RootBufferingPipe pipe = new RootBufferingPipe(this.cocoonConsumer,
> arguments);
> this.pipeStack.push(pipe);
> widget.generateSaxFragment(pipe, this.locale);
>
>
>
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDcz7KLNdJvZjjVZARAk35AJoDUnrsJHorEvSl4/Itmu2qM+SZbgCgh2Xe
fmH48PeQmNUoOAGYg2QTKXo=
=Cbm2
-END PGP SIGNATURE-
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, lets discuss this :-) maybe there are other ways to do it.
The use case to this is:
a) Suppose you have a repeater showing some informations.
b) Suppose the users viewing that information can have different role.
Now, depending on the role the user has
1) he may not see some of the rows (which would be filtered out before
passing it to the template of course)
2) he may see some of the row (output state)
3) he may even edit some of the rows (input state)
How would you accomplish this in a repeater without enabling the
template to change the state in the repeater according to the role of
the viewing user (which is passed down the pipeline)?
Using widgets per role is very ugly (I've tried that) and may complicate
validation of not displayed widgets in a row.
Any suggestion would be welcome otherwise I'd like to have that change
going into the repository (this or the following release).
IIRC there is no place other than the template to handle the repeater
model content associated to a widget.
Thanks and ciao
Giacomo
On Thu, 3 Nov 2005, [EMAIL PROTECTED] wrote:
Date: Thu, 03 Nov 2005 18:17:42 -
From: [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: cvs@cocoon.apache.org
Subject: svn commit: r330598 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacro
sHelper.java
Author: sylvain
Date: Thu Nov 3 10:17:39 2005
New Revision: 330598
URL: http://svn.apache.org/viewcvs?rev=330598&view=rev
Log:
Reverting r328311: allowing the template to change the widget is a fundamental
change that must be discussed prior to be included in a release
Modified:
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Modified:
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
URL:
http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java?rev=330598&r1=330597&r2=330598&view=diff
==
---
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
(original)
+++
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Thu Nov 3 10:17:39 2005
@@ -287,10 +287,6 @@
*/
public void generateWidget(Widget widget, Map arguments) throws
SAXException {
// Needs to be buffered
-String state = (String)arguments.get("state");
-if (state != null) {
-widget.setState(WidgetState.stateForName(state));
-}
RootBufferingPipe pipe = new RootBufferingPipe(this.cocoonConsumer,
arguments);
this.pipeStack.push(pipe);
widget.generateSaxFragment(pipe, this.locale);
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDcz7KLNdJvZjjVZARAk35AJoDUnrsJHorEvSl4/Itmu2qM+SZbgCgh2Xe
fmH48PeQmNUoOAGYg2QTKXo=
=Cbm2
-END PGP SIGNATURE-
[jira] Closed: (COCOON-1674) Improved user support for portlets
[ http://issues.apache.org/jira/browse/COCOON-1674?page=all ] Carsten Ziegeler closed COCOON-1674: Resolution: Fixed > Improved user support for portlets > -- > > Key: COCOON-1674 > URL: http://issues.apache.org/jira/browse/COCOON-1674 > Project: Cocoon > Type: Task > Components: Blocks: Portal > Versions: 2.2-dev (Current SVN) > Reporter: Carsten Ziegeler > Assignee: Cocoon Developers Team > Fix For: 2.2-dev (Current SVN) > > A portlet has access to the current user via the PortletRequest object > (username, principal, isUserInRole). Currently this is just a wrapper for the > httprequest. As the portal might use different authentication mechanisms, we > have to provide a username etc. in this case as well. > I already started to add factories for own wrappers of the portletrequest > objects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1679) New cocoon logo proposal
[ http://issues.apache.org/jira/browse/COCOON-1679?page=all ] Jörg Heinicke reassigned COCOON-1679: - Assign To: Cocoon Developers Team > New cocoon logo proposal > > > Key: COCOON-1679 > URL: http://issues.apache.org/jira/browse/COCOON-1679 > Project: Cocoon > Type: Improvement > Reporter: Milan Andrejevic > Assignee: Cocoon Developers Team > Priority: Trivial > Attachments: cocoon.png, cocoon.svg > > This is just an idea of new cocoon logo. See attachment. > Spent some hours to create. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1680) New design/ layout proposal for Cocoon documentation
[ http://issues.apache.org/jira/browse/COCOON-1680?page=all ] Jörg Heinicke reassigned COCOON-1680: - Assign To: Cocoon Developers Team > New design/ layout proposal for Cocoon documentation > > > Key: COCOON-1680 > URL: http://issues.apache.org/jira/browse/COCOON-1680 > Project: Cocoon > Type: Improvement > Components: - Documentation > Reporter: Milan Andrejevic > Assignee: Cocoon Developers Team > Priority: Minor > Attachments: asf20051107.zip, asf20051108.zip, screenshot.gif, screenshot.gif > > I made new design/ layout proposal for Cocoon documentation. Just one html > and screen css. I understand you need to "modernize" site (see Upayavira > comment for COCOON-1679). This is my try, I hope you like it. > There are two layouts user can choose. Layout info is stored in cookie > "_asfstyle" for 30 days. > Added access keys on top menu. > Navigation on right contains only sub-section selected form top menu > Minimal resolution set to 800px. > Starting design is done in Macromedia Fireworks (_src/cocoon.png) were you > can find all picture slices. > I have checked this design in: > Windows: > Firefox 1.0.7 > Internet Explorer 6.0 > Opera 8.5 > Linux: > Firefox 1.0.7 > Konqueror 3.3.2 > Mozilla 1.7.5 > Netscape 7.2 > Lynx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1665) Test release against JVM 1.3/5.0 and different Tomcat versions
[ http://issues.apache.org/jira/browse/COCOON-1665?page=all ] Jörg Heinicke reassigned COCOON-1665: - Assign To: Cocoon Developers Team > Test release against JVM 1.3/5.0 and different Tomcat versions > -- > > Key: COCOON-1665 > URL: http://issues.apache.org/jira/browse/COCOON-1665 > Project: Cocoon > Type: Task > Versions: 2.1.8-dev (Current SVN) > Reporter: Ralph Goers > Assignee: Cocoon Developers Team > Priority: Minor > Fix For: 2.1.8-dev (Current SVN) > > Before voting on the release, I would like to know if anyone tested on Java > 1.3 and 5.0 and on Tomcat amd on what versions. Actually, it would be great > if we had a testing matrix of JVMs, Servlet Containers and operating systems > that we could check off when doing a release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1682) Custom headers for Sendmail Action/Logicsheet/Transformer needed
[ http://issues.apache.org/jira/browse/COCOON-1682?page=all ] Jörg Heinicke reassigned COCOON-1682: - Assign To: Cocoon Developers Team > Custom headers for Sendmail Action/Logicsheet/Transformer needed > > > Key: COCOON-1682 > URL: http://issues.apache.org/jira/browse/COCOON-1682 > Project: Cocoon > Type: Wish > Components: Blocks: Mail > Versions: 2.1.7 > Reporter: Lauri Pitkänen > Assignee: Cocoon Developers Team > Priority: Minor > > Possibility to add multiple custom headers to messages from Sendmail > Action/Logicsheet/Transformer would eliminate the need for adding > missing fixed optional headers like ReplyTo one by one. > This is something that is already available in the AxKit XSP tag library:: > http://search.cpan.org/~kjetilk/AxKit-XSP-Sendmail/Sendmail.pm#%3Csendmail:header%3E > Configuration example: > bulk > Something > Headers in the message: > Precedence: bulk > X-My-Header: Something -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1678) HTMLArea unable to set target and title to a "link"
[ http://issues.apache.org/jira/browse/COCOON-1678?page=all ] Jörg Heinicke reassigned COCOON-1678: - Assign To: Cocoon Developers Team > HTMLArea unable to set target and title to a "link" > --- > > Key: COCOON-1678 > URL: http://issues.apache.org/jira/browse/COCOON-1678 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8-dev (Current SVN) > Reporter: Philippe Gassmann > Assignee: Cocoon Developers Team > Priority: Minor > > I do the following test on > http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/htmlarea : > Type some text in the "in a table" HTMLArea. > Select a portion of the text, click on the link button. > Type the address : http://www.google.com > Type a title : test > Select a target. > Submit, > The result is : > > > > > > > a > http://www.google.fr";>new > test > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1673) Unable to insert html links in the HTMLArea sample.
[ http://issues.apache.org/jira/browse/COCOON-1673?page=all ] Jörg Heinicke reassigned COCOON-1673: - Assign To: Cocoon Developers Team > Unable to insert html links in the HTMLArea sample. > --- > > Key: COCOON-1673 > URL: http://issues.apache.org/jira/browse/COCOON-1673 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8-dev (Current SVN) > Reporter: Philippe Gassmann > Assignee: Cocoon Developers Team > Priority: Minor > > With Firefox 1.0.x, when I try to insert a html link, a javascript error > occurs. No link is created. > I test it at : > http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/htmlarea -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1660) [Link] Warsztat
[ http://issues.apache.org/jira/browse/COCOON-1660?page=all ] Jörg Heinicke reassigned COCOON-1660: - Assign To: Cocoon Developers Team > [Link] Warsztat > --- > > Key: COCOON-1660 > URL: http://issues.apache.org/jira/browse/COCOON-1660 > Project: Cocoon > Type: Improvement > Components: - Documentation > Versions: 2.1.7 > Reporter: g[R]eK > Assignee: Cocoon Developers Team > Priority: Minor > > URL of the website: http://www.gamedev.pl > Title of the website: Warsztat > Cocoon version used: 2.1.7 > Short summary: Polish site in early stage of development that aims at keeping > polish game programming community together and provide some useful resources. > How can we verify this site is actually built with Cocoon? > Check HTTP headers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1664) Jaas based Authenticator
[ http://issues.apache.org/jira/browse/COCOON-1664?page=all ] Jörg Heinicke reassigned COCOON-1664: - Assign To: Cocoon Developers Team > Jaas based Authenticator > > > Key: COCOON-1664 > URL: http://issues.apache.org/jira/browse/COCOON-1664 > Project: Cocoon > Type: Improvement > Components: Blocks: Authentication Framework > Reporter: Ryan Slack > Assignee: Cocoon Developers Team > Priority: Minor > Attachments: JaasAuthenticator.java > > It was not particularly hard, but I wrote, and have somewhat tested, a Jaas > implmentation of Authenticator. > It should also be possable to utilize Java's security as an alternate to the > current authentication Actions. > This implementation has the CallbackHandler in the same class as the > Authenticator, however that isn't really required. Also, I will be looking at > using the Cocoon configuration system, instead of the default jaas config > file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1681) Generator "directory": Caching too much
[ http://issues.apache.org/jira/browse/COCOON-1681?page=all ] Jörg Heinicke reassigned COCOON-1681: - Assign To: Cocoon Developers Team > Generator "directory": Caching too much > --- > > Key: COCOON-1681 > URL: http://issues.apache.org/jira/browse/COCOON-1681 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.8-dev (Current SVN), 2.1.7 > Reporter: Antonio Fiol > Assignee: Cocoon Developers Team > > In some cases, an update to the directory is not detected by the > DirectoryGenerator. > Debugging the issue, I discovered that isValid() is called twice on the same > DirValidity, but it returns different values (-1 the first time, 1 the second > time). > Apparently, the reason for the inconsistency would be solved by removing the > first of the two lines that update the expiry time in the isValid() method in > DirValidity, but I am not sure whether this could cause problems in other > places. > A possibility would be that a DirValidity stores the fact that it already > detected it is invalid, and is changed so that it always return -1. But... > Are DirValidity objects reused? Could this change cause problems? I have not > tested, so I don't know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1671) Form not binding when prefix in binding definition is unequal to that in the instance data for the same namespace.
[ http://issues.apache.org/jira/browse/COCOON-1671?page=all ] Jörg Heinicke reassigned COCOON-1671: - Assign To: Cocoon Developers Team > Form not binding when prefix in binding definition is unequal to that in the > instance data for the same namespace. > -- > > Key: COCOON-1671 > URL: http://issues.apache.org/jira/browse/COCOON-1671 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8-dev (Current SVN) > Reporter: Suzan Foster > Assignee: Cocoon Developers Team > Attachments: JXPathTest.java, form2_bind_xml1.xml, form2_bind_xml2.xml, > form2_bind_xml3.xml, form2_data.xml > > In the situation where the binding definition and the instance data share the > same namespace uri but have different namespace prefixes the binding will > fail. However, when the binding definition and the instance data share the > same namespace prefix but not the same namespace uri the binding will be > successful. This is incorrect as it shound match on the namespace uri's and > not on the prefixes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1170) [PATCH] precompile xsp's without starting URI
[ http://issues.apache.org/jira/browse/COCOON-1170?page=all ] Jörg Heinicke reassigned COCOON-1170: - Assign To: Cocoon Developers Team > [PATCH] precompile xsp's without starting URI > - > > Key: COCOON-1170 > URL: http://issues.apache.org/jira/browse/COCOON-1170 > Project: Cocoon > Type: Bug > Components: - Components: Avalon > Versions: 2.1.5 > Environment: Operating System: All > Platform: PC > Reporter: Andrea Poeschel > Assignee: Cocoon Developers Team > Attachments: precompile-xsp.zip, xsp-precompile-patch > > I want precompile my xsp's with the Command line Interface using by ant. > snipped from build.xml: > > in Cocoon 2.1.4 works this fine, but not Cocoon 2.1.5 > Error: Please, specify at least one starting URI. > Snipped from your documentation: > "If no URIs are specified, it will scan all directories within the context > directory looking for XSP files, each of which will be compiled." > Only we can use this variant. The variant with the starting URI functioned > not > with ant without application server, datebase, ours license service etc. > Greetings from > Andrea Pöschel > Knowledge Engine Development -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1676) Portlet/Coplet deployment
[ http://issues.apache.org/jira/browse/COCOON-1676?page=all ] Jörg Heinicke reassigned COCOON-1676: - Assign To: Cocoon Developers Team > Portlet/Coplet deployment > - > > Key: COCOON-1676 > URL: http://issues.apache.org/jira/browse/COCOON-1676 > Project: Cocoon > Type: New Feature > Components: Blocks: Portal > Versions: 2.2-dev (Current SVN) > Reporter: Carsten Ziegeler > Assignee: Cocoon Developers Team > Fix For: 2.2-dev (Current SVN) > > We need a way for deployment of portlets (and perhaps of coplets as well). We > could either use the code from the pluto adminportlet or use the jetspeed2 > components. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1675) Improve i18n support
[ http://issues.apache.org/jira/browse/COCOON-1675?page=all ] Jörg Heinicke reassigned COCOON-1675: - Assign To: Cocoon Developers Team > Improve i18n support > > > Key: COCOON-1675 > URL: http://issues.apache.org/jira/browse/COCOON-1675 > Project: Cocoon > Type: Task > Components: Blocks: Portal > Versions: 2.2-dev (Current SVN) > Reporter: Carsten Ziegeler > Assignee: Cocoon Developers Team > Fix For: 2.2-dev (Current SVN) > > We should collect requirements and see how we can improve the i18n support in > the portal. (What about coplet titles, named-items etc.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1674) Improved user support for portlets
[ http://issues.apache.org/jira/browse/COCOON-1674?page=all ] Jörg Heinicke reassigned COCOON-1674: - Assign To: Cocoon Developers Team > Improved user support for portlets > -- > > Key: COCOON-1674 > URL: http://issues.apache.org/jira/browse/COCOON-1674 > Project: Cocoon > Type: Task > Components: Blocks: Portal > Versions: 2.2-dev (Current SVN) > Reporter: Carsten Ziegeler > Assignee: Cocoon Developers Team > Fix For: 2.2-dev (Current SVN) > > A portlet has access to the current user via the PortletRequest object > (username, principal, isUserInRole). Currently this is just a wrapper for the > httprequest. As the portal might use different authentication mechanisms, we > have to provide a username etc. in this case as well. > I already started to add factories for own wrappers of the portletrequest > objects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1616) source that declares namespace fails JXPath/Linkrewriter/Input Modules
[ http://issues.apache.org/jira/browse/COCOON-1616?page=all ] Jörg Heinicke reassigned COCOON-1616: - Assign To: Cocoon Developers Team > source that declares namespace fails JXPath/Linkrewriter/Input Modules > -- > > Key: COCOON-1616 > URL: http://issues.apache.org/jira/browse/COCOON-1616 > Project: Cocoon > Type: Bug > Components: - Components: Sitemap > Versions: 2.2-dev (Current SVN) > Environment: Operating System: other > Platform: Other > Reporter: David Crossley > Assignee: Cocoon Developers Team > > At Apache Forrest we use the wonderful Cocoon Linkrewriter block. When we > upgrade from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar then we get > failures with the linkrewriter protocols "site:" etc. > This issue can also be demonstrated as broken in the current Cocoon trunk > samples for Linkrewriter. Make the following change to > src/blocks/linkrewriter/trunk/samples/sitedemo/linkmap.xml and then note that > the sample shows the links in their unresolved form. > -- > - > +http://apache.org/cocoon/linkmap/1.0";> > -- > Not sure whether it is due to an incomplete implementation in the Linkrewriter > or something to do with the Cocoon input modules or both. > There is more discussion about the issue at Forrest > http://issues.apache.org/jira/browse/FOR-675 > There is a relevant note about the namespaces at > http://jakarta.apache.org/commons/jxpath/release-notes-1.2.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1670) portal tools i18n doesn't work
[ http://issues.apache.org/jira/browse/COCOON-1670?page=all ] Jörg Heinicke reassigned COCOON-1670: - Assign To: Cocoon Developers Team > portal tools i18n doesn't work > --- > > Key: COCOON-1670 > URL: http://issues.apache.org/jira/browse/COCOON-1670 > Project: Cocoon > Type: Bug > Components: Blocks: Portal > Versions: 2.1.8-dev (Current SVN) > Reporter: roy huang > Assignee: Cocoon Developers Team > > check archive mail-list > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111692234511897&w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1667) Generation of documentation
[ http://issues.apache.org/jira/browse/COCOON-1667?page=all ] Jörg Heinicke reassigned COCOON-1667: - Assign To: Cocoon Developers Team > Generation of documentation > --- > > Key: COCOON-1667 > URL: http://issues.apache.org/jira/browse/COCOON-1667 > Project: Cocoon > Type: Wish > Components: - Documentation > Versions: 2.1.8-dev (Current SVN) > Reporter: Vadim Gritsenko > Assignee: Cocoon Developers Team > Fix For: 2.1.8-dev (Current SVN) > > Docs are not generated in 2.1 URI space yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (COCOON-1657) VelocityGenerator: error when sending string containing ampersand
[ http://issues.apache.org/jira/browse/COCOON-1657?page=all ]
Jörg Heinicke reassigned COCOON-1657:
-
Assign To: Cocoon Developers Team
> VelocityGenerator: error when sending string containing ampersand
> -
>
> Key: COCOON-1657
> URL: http://issues.apache.org/jira/browse/COCOON-1657
> Project: Cocoon
> Type: Bug
> Components: Blocks: Velocity
> Versions: 2.1.7
> Reporter: Andreas Deininger
> Assignee: Cocoon Developers Team
>
> Take this flowscript:
> function velotest() {
> cocoon.sendPage("abstract.vm", { "test" : "vm&vm" } );
> }
> With abstract.vm being an velocity template processed by the Velocity
> Generator:
>
> $test
> You receive the following error, due to the occurence of the
> ampersand-sign in the "vm&vm" string::
> An Error Occurred: The reference to entity "vm" must end with the ';'
> delimiter.
> This seems to be due to the fact that the sent value is not escaped, i.e. &
> remains & and does not get converted to & in the resulting XML.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Aktualisiert: (COCOON-1662) Portal basket sample does not work well with uploaded items
[ http://issues.apache.org/jira/browse/COCOON-1662?page=all ] Jörg Heinicke updated COCOON-1662: -- Summary: Portal basket sample does not work well with uploaded items (was: Portal basket ample does not work well with uploaded items) Assign To: Cocoon Developers Team > Portal basket sample does not work well with uploaded items > --- > > Key: COCOON-1662 > URL: http://issues.apache.org/jira/browse/COCOON-1662 > Project: Cocoon > Type: Bug > Components: Blocks: Portal > Versions: 2.1.8-dev (Current SVN), 2.1.7 > Reporter: Philippe Gassmann > Assignee: Cocoon Developers Team > > It seems not to be possible to view or download an uploaded file in the > basket sample : when I try to view, it just write in the Content coplet : > The item is not XML. > This is true, but it should be possible to download this file even it is not > XML. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Aktualisiert: (COCOON-1170) [PATCH] precompile xsp's without starting URI
[ http://issues.apache.org/jira/browse/COCOON-1170?page=all ] Jörg Heinicke updated COCOON-1170: -- Bugzilla Id: (was: 29360) Description: I want precompile my xsp's with the Command line Interface using by ant. snipped from build.xml: in Cocoon 2.1.4 works this fine, but not Cocoon 2.1.5 Error: Please, specify at least one starting URI. Snipped from your documentation: "If no URIs are specified, it will scan all directories within the context directory looking for XSP files, each of which will be compiled." Only we can use this variant. The variant with the starting URI functioned not with ant without application server, datebase, ours license service etc. Greetings from Andrea Pöschel Knowledge Engine Development was: I want precompile my xsp's with the Command line Interface using by ant. snipped from build.xml: in Cocoon 2.1.4 works this fine, but not Cocoon 2.1.5 Error: Please, specify at least one starting URI. Snipped from your documentation: "If no URIs are specified, it will scan all directories within the context directory looking for XSP files, each of which will be compiled." Only we can use this variant. The variant with the starting URI functioned not with ant without application server, datebase, ours license service etc. Greetings from Andrea Pöschel Knowledge Engine Development Assign To: (was: Upayavira) Priority: Major (was: Critical) > [PATCH] precompile xsp's without starting URI > - > > Key: COCOON-1170 > URL: http://issues.apache.org/jira/browse/COCOON-1170 > Project: Cocoon > Type: Bug > Components: - Components: Avalon > Versions: 2.1.5 > Environment: Operating System: All > Platform: PC > Reporter: Andrea Poeschel > Attachments: precompile-xsp.zip, xsp-precompile-patch > > I want precompile my xsp's with the Command line Interface using by ant. > snipped from build.xml: > > in Cocoon 2.1.4 works this fine, but not Cocoon 2.1.5 > Error: Please, specify at least one starting URI. > Snipped from your documentation: > "If no URIs are specified, it will scan all directories within the context > directory looking for XSP files, each of which will be compiled." > Only we can use this variant. The variant with the starting URI functioned > not > with ant without application server, datebase, ours license service etc. > Greetings from > Andrea Pöschel > Knowledge Engine Development -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Aktualisiert: (COCOON-1588) JXPath expressions within are broken
[ http://issues.apache.org/jira/browse/COCOON-1588?page=all ] Jörg Heinicke updated COCOON-1588: -- Bugzilla Id: (was: 36462) Description: JXPath expressions within of a CForms template using jx-macros.xml are evaluated to the empty string. A workaround is to use to remember the objects contained in flow attributes. was: JXPath expressions within of a CForms template using jx-macros.xml are evaluated to the empty string. A workaround is to use to remember the objects contained in flow attributes. Priority: Major (was: Critical) > JXPath expressions within are broken > - > > Key: COCOON-1588 > URL: http://issues.apache.org/jira/browse/COCOON-1588 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.8-dev (Current SVN) > Environment: Operating System: other > Platform: Other > Reporter: Jean-Baptiste Quenot > Assignee: Cocoon Developers Team > Attachments: jxpathtest.tgz, jxpathtest.tgz > > JXPath expressions within of a CForms template using > jx-macros.xml are evaluated to the empty string. A workaround is to use > to remember the objects contained in flow attributes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Aktualisiert: (COCOON-1622) [PATCH] SendMailTransformer and HTML body
[ http://issues.apache.org/jira/browse/COCOON-1622?page=all ] Jörg Heinicke updated COCOON-1622: -- Bugzilla Id: (was: 36949) Priority: Major (was: Critical) > [PATCH] SendMailTransformer and HTML body > - > > Key: COCOON-1622 > URL: http://issues.apache.org/jira/browse/COCOON-1622 > Project: Cocoon > Type: Bug > Components: Blocks: Mail > Versions: 2.1.8-dev (Current SVN) > Environment: Operating System: other > Platform: Other > Reporter: Philippe Gassmann > Assignee: Cocoon Developers Team > Fix For: 2.1.8-dev (Current SVN) > Attachments: 20051006-sendmailtr, 20051020-sendmailtr > > The SendMailTransformer is unable to handle XML tags directly in the SAX flow. > ex : > > smtp > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > >Bogus sendmailtrasformer > > > > this is a paragraph > another > > > > It simply remove xml tags in the body ! > It a a strange behaviour since DEFAULT_BODY_MIMETYPE = "text/html" ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Aktualisiert: (COCOON-1678) HTMLArea unable to set target and title to a "link"
[ http://issues.apache.org/jira/browse/COCOON-1678?page=all ] Jörg Heinicke updated COCOON-1678: -- Component: Blocks: Forms Priority: Minor (was: Critical) > HTMLArea unable to set target and title to a "link" > --- > > Key: COCOON-1678 > URL: http://issues.apache.org/jira/browse/COCOON-1678 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8-dev (Current SVN) > Reporter: Philippe Gassmann > Priority: Minor > > I do the following test on > http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/htmlarea : > Type some text in the "in a table" HTMLArea. > Select a portion of the text, click on the link button. > Type the address : http://www.google.com > Type a title : test > Select a target. > Submit, > The result is : > > > > > > > a > http://www.google.fr";>new > test > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Aktualisiert: (COCOON-1642) Calling SitemapSource.getInputStream() twice
[ http://issues.apache.org/jira/browse/COCOON-1642?page=all ] Jörg Heinicke updated COCOON-1642: -- Bugzilla Id: (was: 37049) Description: Hello, It seems that Cocoon is broken WRT calling SitemapSource.getInputStream() twice. The first invocation is okay, but the second one is doing a refresh(). Then the environment's context is reset, which is making the request fail. was: Hello, It seems that Cocoon is broken WRT calling SitemapSource.getInputStream() twice. The first invocation is okay, but the second one is doing a refresh(). Then the environment's context is reset, which is making the request fail. Priority: Critical (was: Blocker) > Calling SitemapSource.getInputStream() twice > > > Key: COCOON-1642 > URL: http://issues.apache.org/jira/browse/COCOON-1642 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.8-dev (Current SVN) > Environment: Operating System: other > Platform: Other > Reporter: Jean-Baptiste Quenot > Assignee: Cocoon Developers Team > Priority: Critical > Attachments: sitemapsource.tar.gz > > Hello, > It seems that Cocoon is broken WRT calling SitemapSource.getInputStream() > twice. > The first invocation is okay, but the second one is doing a refresh(). Then > the environment's context is reset, which is making the request fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Aktualisiert: (COCOON-1673) Unable to insert html links in the HTMLArea sample.
[ http://issues.apache.org/jira/browse/COCOON-1673?page=all ] Jörg Heinicke updated COCOON-1673: -- Priority: Minor (was: Blocker) > Unable to insert html links in the HTMLArea sample. > --- > > Key: COCOON-1673 > URL: http://issues.apache.org/jira/browse/COCOON-1673 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8-dev (Current SVN) > Reporter: Philippe Gassmann > Priority: Minor > > With Firefox 1.0.x, when I try to insert a html link, a javascript error > occurs. No link is created. > I test it at : > http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/htmlarea -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DOCS] Building for release - update
Ross Gardler wrote: Vadim Gritsenko wrote: Ross Gardler wrote: There are now three possible workarounds, it's up to others to pick one and go with it in order to get the release out: I managed to get enough time before my plane to look at the current problem with the new Daisy navigation + Forrest solution. I'm not sure why overnight builds didn't report problems, but there was an issue in the Forrest plugin. Now resolved, I think - again not tested, I'm about to leave the airport so can't do that. If you want to use any of the other solutions that's fine by me, I'm just killing dead time. Ross
Re: [ExceptionHandling] Catching "Content length exceeds maximum upload size"
* Jeroen Reijn: > I have a Cform with a file upload widget. When I submit the > form with a file that is bigger then the max allowed file size, > it throws a nice "Content length exceeds maximum upload size" > error. This occurs in the processing of the HTTP request thus cannot be handled by your pipeline. But this problem has been adressed, see http://svn.apache.org/viewcvs.cgi?view=rev&rev=280876 -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
Re: AJAX Page update effect
* Leszek Gawron: > Sylvain Wallez wrote: > > Leszek Gawron wrote: > > > - If a combobox is not required (no asterisk in default > > > rendering) even if you have page update effect active you > > > won't see anything as the combobox itself does not change > > > colour. Blinking surrounding span does not work as the > > > combobox fills the span completely. > > Yup. Combo boxes don't seem to inherit their background > > color from their parents. What's the effect of setting their > > background to "inherit" in CSS? > Partially did the trick for FF. There is a little problem > though: The background of combobox list is now grey by default > and it resets to proper color if the control gets "ajax > activated". It is not working for IE at all. IE is very bad at « inherit » AFAICT. -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. ... [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke Interesting... Every build overnight (for me) worked, but this one failed. I can't look into this right now, but I don't see any commits or changes that would cause this. Hopefully it is a network glitch. New build due in around 30 minutes. Ross
Re: [DOCS] Building for release - update
Vadim Gritsenko wrote: Ross Gardler wrote: There are now three possible workarounds, it's up to others to pick one and go with it in order to get the release out: Why can't we write locationmap.xml and supply it to Forrest instead of torturing Daisy's navigation doc & Forrest Daisy plugin? Would it work? The site.xml file is also being generated from the daisy navigation document. This is not a problem though, we should be able to use the "old" XDoc site.xml. It should work though, although I can't guarentee it since the locationmap is also used to resolve internal links using the "daisy:" protocol. There will need to be a minor change to the 2.1/**.xml matchers in daisy-to-docs sitemap.xmap to handle this since we will no longer be using the daisy navigation document to define the URLspace. Attached is my take on locationmap.xml, mostly removing path fragments. Results are encouraging - now diff between old URI space and new version is much smaller (attached as well) It's the internal links that will be a problem now :-( Note that there are several numbered docs in there - either mislabelled old docs or newly added docs, i have not checked. Helma posted late last night that these had been removed. Not sure when you generated this locationmap. Ross
[ExceptionHandling] Catching "Content length exceeds maximum upload size"
Hi guys, I hope somebody can help me out.Here is the situation: I have a Cform with a file upload widget. When I submit the form with a file that is bigger then the max allowed file size, it throws a nice "Content length exceeds maximum upload size" error. I'm under the impression that I could use the ExceptionSelector to catch this error. So this is what I did: Define the selector in my sitemap: I've put both matchers in a seperate pipeline with a handle-errors part: But when I get the error nothing happens. The selector does not get triggered. It returns the same error I got before. Any clues? Or is there a better way of doing this? Thanks in advance! Jeroen Reijn
Re: recovering forrest.properties (was: [Vote] Releasing 2.1.8 tomorrow)
David Crossley wrote: > > Double Uh'oh ... the "docs" target was also removed, > so that means that for someone to build the "Changes" > they will need to go back to an old version of cocoon-2_1_X > and use todays status.xml file. Need to do 'build docs' > and then do 'forrest' as described at: > http://wiki.apache.org/cocoon/CocoonWebsiteUpdate > and set "project.start-uri=changes.html" in forrest.properties Hmmm, having trouble to find a working revision of the branch for this fallback for building changes.html So going to try some other ways to get Forrest to build it. -David
[jira] Commented: (COCOON-1680) New design/ layout proposal for Cocoon documentation
[ http://issues.apache.org/jira/browse/COCOON-1680?page=comments#action_12357206 ] Milan Andrejevic commented on COCOON-1680: -- Where can I find ASF logo, new version of the feather (IIRC ASF) in vector format, or large raster format? This would help a lot. > New design/ layout proposal for Cocoon documentation > > > Key: COCOON-1680 > URL: http://issues.apache.org/jira/browse/COCOON-1680 > Project: Cocoon > Type: Improvement > Components: - Documentation > Reporter: Milan Andrejevic > Priority: Minor > Attachments: asf20051107.zip, asf20051108.zip, screenshot.gif, screenshot.gif > > I made new design/ layout proposal for Cocoon documentation. Just one html > and screen css. I understand you need to "modernize" site (see Upayavira > comment for COCOON-1679). This is my try, I hope you like it. > There are two layouts user can choose. Layout info is stored in cookie > "_asfstyle" for 30 days. > Added access keys on top menu. > Navigation on right contains only sub-section selected form top menu > Minimal resolution set to 800px. > Starting design is done in Macromedia Fireworks (_src/cocoon.png) were you > can find all picture slices. > I have checked this design in: > Windows: > Firefox 1.0.7 > Internet Explorer 6.0 > Opera 8.5 > Linux: > Firefox 1.0.7 > Konqueror 3.3.2 > Mozilla 1.7.5 > Netscape 7.2 > Lynx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [cforms] settable Field 'required' property?
Carsten Ziegeler wrote: Philipp Schmidt wrote: Hi, Sylvain Wallez wrote: Mark Lundquist wrote: Sometimes you just really want to say someWidget.required = false; in flowscript. Why shouldn't that be possible? I attached a path for the field widget which makes this possible :-) Philipp, thanks for your patch - it's applied. Granted, this is a minor modification, but aren't we supposed to be in code freeze before the release? And this settable "required" also applies to other widgets that have a value such as upload. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
