Re: CForms slower with JXTemplateGenerator
I can do it if current vote process is positive -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65 Do we need a vote? roy huang
Re: svn commit: r369374 - /cocoon/trunk/pom.xml
At least with Maven 1 this was used by the site plugin to generate the list of developers. I would imagine this would be true of Maven 2. So if Maven is ever used to generate the Cocoon web site (a good idea as it publishes unit test results and code style reports, etc.) then this is a good idea. Committers who have an interest in particular blocks should update the poms for them as well. Ralph Giacomo Pati wrote: I can read the Maven docs. But my question was whether we will later have the same discussion about it as we had with the @author tag. I just want to make sure we don't go forwards and than backwards again. That's wasted time we can save in adance.
Re: svn commit: r369374 - /cocoon/trunk/pom.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jan 2006, Joerg Heinicke wrote: I guess it is more comparable with the list we have in status.xml or at http://cocoon.apache.org/community/members.html. On Mon, 16 Jan 2006, Gianugo Rabellino wrote: I don't think so. I see it as the POMified way of saying "who we are" as in http://cocoon.apache.org/whoweare.html, there is no relationship with actual code which was why @author tags were removed. Ok, I just wanted to be sure :-) Ciao - -- 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) iD8DBQFDzB6gLNdJvZjjVZARAhGSAJ0R2IC2VYC4T0rAXPN+Q+6JS3mCtgCgqkoX Z7kCjiGesTkswc9tswbVc4E= =3yS4 -END PGP SIGNATURE-
Re: [SPAM ?] Re: XCSS = Sumit Sanwal, PCS
On 16.01.2006 12:48, Jorg Heymans wrote: Anyone else been getting these ? Yes, I also already got two or three of them. Also the XCSS message he sent to this list was a mail to the users list by somebody else [1]. There was another one like this last week. Jörg [1] http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=113709105931521&w=4
Re: [jira] Closed: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null
On 16.01.2006 18:45, Jean-Baptiste Quenot (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1687?page=all ] Jean-Baptiste Quenot closed COCOON-1687: Resolution: Fixed See http://svn.apache.org/viewcvs.cgi?rev=369507&view=rev Just a hint: you don't need to add this as comment as Jira finds this out itself: http://issues.apache.org/jira/browse/COCOON-1687?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel You probably only need "COCOON-" in the commit message. Jörg
Re: svn commit: r369374 - /cocoon/trunk/pom.xml
On 16.01.2006 22:27, Giacomo Pati wrote: Just a shy question. Is this comparable to the @author tag in the sources? Developer: Information about one of the committers on this project. Derived from Contributor. Contributor: Description of a person who has contributed to the project, but who does not have commit privileges. Usually, these contributions come in the form of patches submitted. I can read the Maven docs. But my question was whether we will later have the same discussion about it as we had with the @author tag. I just want to make sure we don't go forwards and than backwards again. That's wasted time we can save in adance. We can interpret this whichever we want, but i suggest we don't go too granular with assigning developers and contributors to each module. So we can put a dev@cocoon.apache.org in there as well? I guess it is more comparable with the list we have in status.xml or at http://cocoon.apache.org/community/members.html. Jörg
Re: svn commit: r369374 - /cocoon/trunk/pom.xml
On 1/16/06, Giacomo Pati <[EMAIL PROTECTED]> wrote: > Just a shy question. Is this comparable to the @author tag in the > sources? I don't think so. I see it as the POMified way of saying "who we are" as in http://cocoon.apache.org/whoweare.html, there is no relationship with actual code which was why @author tags were removed. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: svn commit: r369374 - /cocoon/trunk/pom.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jan 2006, Jorg Heymans wrote: Date: Mon, 16 Jan 2006 21:11:06 +0100 From: Jorg Heymans <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: svn commit: r369374 - /cocoon/trunk/pom.xml Giacomo Pati wrote: Just a shy question. Is this comparable to the @author tag in the sources? According to the maven pom docs : Developer: Information about one of the committers on this project. Derived from Contributor. Contributor: Description of a person who has contributed to the project, but who does not have commit privileges. Usually, these contributions come in the form of patches submitted. I can read the Maven docs. But my question was whether we will later have the same discussion about it as we had with the @author tag. I just want to make sure we don't go forwards and than backwards again. That's wasted time we can save in adance. We can interpret this whichever we want, but i suggest we don't go too granular with assigning developers and contributors to each module. So we can put a dev@cocoon.apache.org in there as well? HTH No, actually, it didn't help. - -- 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) iD8DBQFDzA+vLNdJvZjjVZARAvBZAKC9StAp3MqX6NA8Y4mUkse+6KwBJACeIILF TWe5ON+fHFgibd+4y/4c6Tg= =OSkP -END PGP SIGNATURE-
Re: svn commit: r369374 - /cocoon/trunk/pom.xml
Giacomo Pati wrote: > > Just a shy question. Is this comparable to the @author tag in the sources? > According to the maven pom docs : Developer: Information about one of the committers on this project. Derived from Contributor. Contributor: Description of a person who has contributed to the project, but who does not have commit privileges. Usually, these contributions come in the form of patches submitted. We can interpret this whichever we want, but i suggest we don't go too granular with assigning developers and contributors to each module. HTH Jorg
Re: M10N
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jan 2006, Gianugo Rabellino wrote: Date: Mon, 16 Jan 2006 10:39:26 +0100 From: Gianugo Rabellino <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: M10N On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: Daniel Fagerstrom wrote: Ben Pope skrev: When "Building Cocoon Block Deployer" I get a compile error: java.lang.IllegalStateException: basedir src\main\resources\xsd does not exist I get the same error, the directory is there but the castor plugin doesn't find it. Hopefully Reinhard can give a better answer on what is going on. I have no idea what's going wrong here. I just can say it works for me. Don't know if that helps, but I've got it working by changing: src/main/castor/castorbuilder.properties src/main/resources/xsd to: cocoon-deployer/src/main/castor/castorbuilder.properties cocoon-deployer/src/main/resources/xsd But than you cannot build it individually anymore from the cocoon-deployer directory! - -- 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) iD8DBQFDy/oYLNdJvZjjVZARAiHkAJ4wL0BN25HrElyNnCmH3QRKPod4xQCfXmbB 4HQ8ZbUo9F6tiQnYtGJj1iU= =toB2 -END PGP SIGNATURE-
Re: M10N
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jan 2006, Reinhard Poetz wrote: Date: Mon, 16 Jan 2006 09:42:06 +0100 From: Reinhard Poetz <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: M10N Daniel Fagerstrom wrote: Ben Pope skrev: > When "Building Cocoon Block Deployer" > I get a compile error: > java.lang.IllegalStateException: basedir src\main\resources\xsd does not > exist I get the same error, the directory is there but the castor plugin doesn't find it. Hopefully Reinhard can give a better answer on what is going on. I have no idea what's going wrong here. I just can say it works for me. Are you sure? It works for me when I start mvn in the cocoon-deployer directory but not when I run it from the root. Could one of you do mvn clean mvn -X -e package >mvn-output.txt and send the text file to me? I hope you already get one so I don't want to send you mine as well ;-) - -- 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) iD8DBQFDy/nXLNdJvZjjVZARAoi1AKCqw2VTwLD6XfpqJaZP1ckxxVKL3QCgvLfl YoLq60e6mz8OULUW93cVw9k= =EsOZ -END PGP SIGNATURE-
Re: svn commit: r369374 - /cocoon/trunk/pom.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a shy question. Is this comparable to the @author tag in the sources? On Mon, 16 Jan 2006, [EMAIL PROTECTED] wrote: Date: Mon, 16 Jan 2006 06:52:35 - From: [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: cvs@cocoon.apache.org Subject: svn commit: r369374 - /cocoon/trunk/pom.xml Author: bdelacretaz Date: Sun Jan 15 22:52:30 2006 New Revision: 369374 URL: http://svn.apache.org/viewcvs?rev=369374&view=rev Log: added myself Modified: cocoon/trunk/pom.xml Modified: cocoon/trunk/pom.xml URL: http://svn.apache.org/viewcvs/cocoon/trunk/pom.xml?rev=369374&r1=369373&r2=369374&view=diff == --- cocoon/trunk/pom.xml (original) +++ cocoon/trunk/pom.xml Sun Jan 15 22:52:30 2006 @@ -115,6 +115,17 @@ +1 + + bdelacretaz + Bertrand Delacretaz + [EMAIL PROTECTED] + ASF + http://www.apache.org + +Committer + + +1 + jira - -- 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) iD8DBQFDy/ivLNdJvZjjVZARAvBjAKCmuu8AodwWe2ix5Tpe+dwcs3oVZACeK4FA oW+rVaAVPJY5QqHWAx303AU= =xiAg -END PGP SIGNATURE-
Re: Jetty and Eclipse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jan 2006, Gianugo Rabellino wrote: Date: Mon, 16 Jan 2006 00:05:39 +0100 From: Gianugo Rabellino <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Jetty and Eclipse On 1/15/06, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: Jorg Heymans skrev: Jorg Heymans wrote: Anyhow, there seems to be something not quite right yet with our eclipse setup. If you run eclipse:eclipse from the top level pom in whiteboard/cocoon-flat-layout, you'll see that the plugin generates eclipse project dependencies between the different modules (very useful!) . For some reason, it's not doing this in trunk. I'm currently investigating this ... The trick here is to do $mvn clean install eclipse:clean eclipse:eclipse before importing the project. The plugin seems to need the projects to be *installed* before it will generate eclipse project references from a reactor build. I tried it and it worked. Guys, sorry for the wasted electrons but I just feel the compelling need to thank you so much for this most promising work. You made me open my eyes on how Maven 2 could help us getting a solid build system which is a huge first step towards semplification: I'm sold on your approach. I hope this short note from the skeptical camp might cheer you up and let you know how welcome your efforts are! Hehe, welcome to the new world :-) - -- 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) iD8DBQFDy/hGLNdJvZjjVZARAkNfAKCnjmSUJXpk7GzdIzYYR43HaPHDBgCfW9eO 4s1BwYybGhDDhNVlpXHnojU= =3gc6 -END PGP SIGNATURE-
[jira] Closed: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null
[ http://issues.apache.org/jira/browse/COCOON-1687?page=all ] Jean-Baptiste Quenot closed COCOON-1687: Resolution: Fixed See http://svn.apache.org/viewcvs.cgi?rev=369507&view=rev > [PATCH] JXPATHBinding : when saving the form, remove xml elements if the > value of the widget is null > > > Key: COCOON-1687 > URL: http://issues.apache.org/jira/browse/COCOON-1687 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.7 > Reporter: Philippe Gassmann > Attachments: ValueJXPathBinding.java.patch > > When a form is saved using a JXPathBinding, the xml elements that correspond > to null widget values must be removed. > Here is our problem : we have a form containing a "date widget" that is not > mandatory, > 1. the user wants to set a value to this widget ex 2005/05/09 > 2. the user save this form > 3. the user does not want the date to be set anymore (why ? why not !) > 4. the user edit the value removing its content (ie the value of the widget > will be null) > 5. the user save the form > 6. when the user wants to view what's happened, he see : the element > containing the value of the date is present, if he loads the form again he > found : 1970-01-01 in the date field (the org.w3c.util.DateParser return this > value if empty string its given). > In general, it has no sense for kind of data (integer, float, date...) to > have three "state" : empty, null and filled with a value ! > So here is a patch to correct this : -- 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
Ajax and IE empty textarea bugfix
Hello
While ajax'ifying one of my forms, I stumbled upon the following bug:
Empty textareas in a repeater are displayed incorrectly by Internet
Explorer after a round-trip to the server (for example after
adding/deleting a row, or when a validation error occurs!)
Instead of being empty, the textareas display a garbled mix of text and
html-tags occurring in the html document. Submission of the form usually
won't work afterwards...
Only Internet Explorer (IE6?) appears to be affected!
At least, I couldn't reproduce the bug on neither Firefox (on both Windows
and Mac OSX), nor the Safari (OSX) web browsers.
You can reproduce the bug as follows:
-
Create a form definition file with a repeater containing a text widget,
and a repeater action for adding new rows, as in the following snippet:
http://apache.org/cocoon/forms/1.0#definition";>
Add text
Create a jx template file to render the above form, as in the following
snippet:
Edit your sitemap to include the following:
The following flow function only displays the form, nothing more:
function test_form () {
var form = new Form ("test.form");
form.showForm ("render_test");
}
Invoke the 'test' pipeline. Click on the 'Add text' button for adding rows
to the repeater, and look what happens with IE. You really have to see it
to believe it!
Possible explanation:
-
After googling around a bit, I found similar bug descriptions concerning
empty textarea rendering problems: IE doesn't handle tags
correctly! It expects to find a closing textarea tag, and a (possibly
empty) value inbetween those tags...
Problem is, somewhere along the way (xslt transformer, xml serializer?)
our form rendering pipeline is turning empty textarea's into
Convert into , and even the dumbest
web-browser is gonna be satisfied!
Possible bugfix:
I had a look into 'cocoon-ajax.js', and was positively astonished at how
compact it is!
Found it to be the best place for an IE-specific fix. After all, it is a
client-side JS library, and it already (sigh!) contains IE-specific stuff
(...it would have been something akin to a miracle, if no IE-specific code
were required in such a library. But then, Santa Claus doesn't exist
either!)
So I added two lines of code in the IE-specific portion of the
'importNode' method. Those lines replace any occurrence of '' tags with '' (svn diff enclosed below)
- keeping IE happy for whoever cares.
I'm posting this to the dev-list, as I don't like the idea of keeping a
patched 'cocoon-ajax.js' around for my webapps (...as that's one more
pitfall to be aware of during my next Cocoon update!)
I'd therefore rather see some kind of fix in Cocoon's main trunk.
Best regards,
Fabrizio
>svn diff cocoon-ajax.js
Index: cocoon-ajax.js
===
--- cocoon-ajax.js (revision 369434)
+++ cocoon-ajax.js (working copy)
@@ -70,6 +70,10 @@
var div = targetDoc.createElement("DIV");
var text = node.xml;
+ // Workaround for IE's bug
+ var tmatch = new RegExp('(', 'img');
+ text = text.replace(tmatch, "$1>");
+
// Extract scripts
var match= new RegExp(cocoon.ajax.DOMUtils.ScriptRegexp, 'img');
Re: M10N
* Reinhard Poetz: > seems to be a bug either in M2 in general or in the Castor > plugin in particular :-( Indeed, an IRC user and Maven developer, Trygve Laugst, with whom I was chatting about this problem entered an issue here: http://jira.codehaus.org/browse/MOJO-246 -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: tools for pom editing
BURGHARD Éric wrote: > - update dependencies to the latest versions available > - lookup conflicts (same packages but differents versions) and handle > exclusions > - edit pom from the console > the plugin is cool, thanks for the tip !! There is an eclipse plugin for m2 as well [1], has anybody tried this ? Jorg [1] http://maven.apache.org/eclipse-plugin.html
Re: svn commit: r368690 - in /cocoon/branches/BRANCH_2_1_X: src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBTransformer.java status.xml
Jean-Baptiste Quenot wrote: > BTW, no email was sent for my first commit: > > The commit in question: > http://svn.apache.org/viewcvs.cgi?rev=368641&view=rev > > The cvs archive for my commits: > http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&w=2&r=1&s=jbq&q=b You need to be subscribed to the cvs@ list via your apache.org email address. Normally a moderator will see your commit and moderate it through, adding you to the 'allow' list so you can do it in future. I believe I did this for your commit mail when I saw the moderation message. The only thing that could have happened is another moderator replied saying "no", but I think that unlikely. I'd suggest you try another, this time inconsequential commit (add a space to a file or something) so we can moderate you through properly this time! Regards, Upayavira
[EMAIL PROTECTED]: Project cocoon (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 has an issue affecting its community integration. This issue affects 55 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 : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A "jcr:" protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-16012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-16012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-16012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 6 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/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-16012006.jar -Dbuild=build/cocoon-16012006 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools
[EMAIL PROTECTED]: Project cocoon (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 has an issue affecting its community integration. This issue affects 55 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 : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A "jcr:" protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-16012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-16012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-16012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 6 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/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-16012006.jar -Dbuild=build/cocoon-16012006 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools
tools for pom editing
Hi, I just discover a really usefull plugin [1] for m2 that allow you to - update dependencies to the latest versions available - lookup conflicts (same packages but differents versions) and handle exclusions - edit pom from the console I also try to graph the depencies [2] of my project (which is just linked to cocoon-core + forms + authentication). Look at [3]. It's quite funny. I'm sure that m2 is a must on cocoon simplification. Regards. [1] https://svn.mojo.codehaus.org/mojo/trunk/mojo/mojo-sandbox/pomtools-maven-plugin/ [2] http://mojo.codehaus.org/graphing-maven-plugin/ [3] http://eburghar.free.fr/dependencies.png
Re: M10N
On 16/01/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > Gianugo Rabellino wrote: > > On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > > > >>Daniel Fagerstrom wrote: > >> > >>>Ben Pope skrev: > >> > When "Building Cocoon Block Deployer" > I get a compile error: > java.lang.IllegalStateException: basedir src\main\resources\xsd does > not exist > >>> > >>> > >>>I get the same error, the directory is there but the castor plugin > >>>doesn't find it. Hopefully Reinhard can give a better answer on what is > >>>going on. > >> > >>I have no idea what's going wrong here. I just can say it works for me. > > > > > > Don't know if that helps, but I've got it working by changing: > > > > > > > > src/main/castor/castorbuilder.properties > > src/main/resources/xsd > > > > > > to: > > > > > > > > cocoon-deployer/src/main/castor/castorbuilder.properties > > > > cocoon-deployer/src/main/resources/xsd > > > > > > in cocoon-deployer's pom.xml. Looks like a basedir issue... > > which is your working directory? >From memory, it was a clean 2.2 trunk extracted to: E:\development\java\cocoon 2.2\ and "mvn install" was run from that directory. Obviously that's on Windows, mvn is 2.0.1. HTH Ben Pope -- I'm not just a number. To many, I'm known as a string...
Re: svn commit: r368690 - in /cocoon/branches/BRANCH_2_1_X: src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBTransformer.java status.xml
BTW, no email was sent for my first commit: The commit in question: http://svn.apache.org/viewcvs.cgi?rev=368641&view=rev The cvs archive for my commits: http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&w=2&r=1&s=jbq&q=b What went wrong? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: M10N
Gianugo Rabellino wrote:
On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
Gianugo Rabellino wrote:
On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
Uh? Untouched cocoon-trunk, full dir is
/Users/gianugo/dev/src/cocoon/trunk/ from where I'm launching mvn...
Ahh, that's the difference. I'm running it from ./cocoon/trunk/cocoon-deployer/
... seems to be a bug either in M2 in general or in the Castor plugin in
particular :-(
So you mean Cocoon's full build should be run from the cocoon-deployer
directory? How so?
No, that's not possible. I mean that the cocoon-deployer build currently only
works as stand-alone build if called from "cocoon/trunk/cocoon-deployer" and
does *not* work for a full build.
I'd suggest to exclude the cocoon-deployer from the full build pom.xml for now.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Jetty and Eclipse
Gianugo Rabellino wrote: > > Guys, sorry for the wasted electrons but I just feel the compelling > need to thank you so much for this most promising work. You made me > open my eyes on how Maven 2 could help us getting a solid build system > which is a huge first step towards semplification: I'm sold on your > approach. I hope this short note from the skeptical camp might cheer > you up and let you know how welcome your efforts are! Thanks ! Maven is a complex enough beast that needs time getting used to. It's not straigthforward to see all the benefits the first time around, especially given the apparent initial overhead involved for larger projects like cocoon. Jorg
[SPAM ?] Re: XCSS = Sumit Sanwal, PCS
sumit wrote: > > I would be grateful for any hints on where to look. ... > I suggest you look into your spam database first and remove me from it. Anyone else been getting these ? - Sumit Sanwal sent you this last week: https://namesdatabase.com/3h.pl?t3=23214071326 Please recall that Sumit Sanwal sent you the above invitation last week on 01-02-2006. To use it, simply click on it above (if it is clickable), or otherwise copy and paste it into the address bar of your Web browser. If you do not know a Sumit Sanwal, then you may have been sent this message in error. In that case, or if you otherwise wish to deactivate this link that was sent to you, simply visit https://namesdatabase.com/u.pl?cc3=23214071326. Please take care, The Names Database Team Post Office Box 550175 Waltham, Mass. 02451
RE: Cocoon 2.1.8 and SendMailTransformer
> -Original Message- > From: Antonio Gallardo [mailto:[EMAIL PROTECTED] > Sent: vrijdag 13 januari 2006 19:02 > To: dev@cocoon.apache.org > Subject: Re: Cocoon 2.1.8 and SendMailTransformer > Jasha Joachimsthal wrote: > > > > >When I try to use the SendMailTransformer, it only tries to > connect to localhost on port 25. > > > > > > > After building, remove: > > geronimo-spec-javamail-1.3.1-rc5.jar > geronimo-spec-activation-1.0.2-rc4.jar > > Then copy the mail.jar from sun and this works. > > The geronimo files are intended to be mock classes for > compiled. They don't need to be used in production. I looked on the Cocoon site, the Cocoon Wiki and cocoon.zones.apache.org but couldn't find a general page about the SendMailTransformer to add this to the documentation. What is the best place to document this? Jasha Joachimsthal - Hippo Oosteinde 11 1017 WT Amsterdam The Netherlands +31 (0)20 5224466 [EMAIL PROTECTED] www.hippo.nl
XCSS = Sumit Sanwal, PCS
I am setting up a website using Cocoon and want to generate XHTML and use CSS to handle the presentation. Like everyone else I am being bitten by the fact that 90% of all browsers conform to the CSS standard, but the browser that 90% of the users use does not I have been unable to find any references to much like this. I have spent about some time trawling Google, but XSL and CSS are not good search terms (they throw up too many results), and XCSS doesn't throw up anything conclusive, although the results do confirm that I am not the first person who wants to do this. The project JXCSS does the other thing, i.e. convert CSS into XCSS, but the documentation says that there is no transformation available to produce CSS from XCSS: "Stylesheets need to be written to generate and pretty-print CSS source code" I will admit to being reluctant to write such a stylesheet myself because I am already severely sidetracked doing this website, and I need to get back to my other tasks. I would be grateful for any hints on where to look. And if there is a Better Way, please let me know. Thanx, Sumit Sanwal PCS Mumbai, India 9819146942
Re: M10N
On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > Gianugo Rabellino wrote: > > On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > > > > Uh? Untouched cocoon-trunk, full dir is > > /Users/gianugo/dev/src/cocoon/trunk/ from where I'm launching mvn... > > Ahh, that's the difference. I'm running it from > ./cocoon/trunk/cocoon-deployer/ > ... seems to be a bug either in M2 in general or in the Castor plugin in > particular :-( So you mean Cocoon's full build should be run from the cocoon-deployer directory? How so? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: M10N
Gianugo Rabellino wrote:
On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
Uh? Untouched cocoon-trunk, full dir is
/Users/gianugo/dev/src/cocoon/trunk/ from where I'm launching mvn...
Ahh, that's the difference. I'm running it from ./cocoon/trunk/cocoon-deployer/
... seems to be a bug either in M2 in general or in the Castor plugin in
particular :-(
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[jira] Commented: (COCOON-1711) [PATCH] correct position of help popup for tab styling
[
http://issues.apache.org/jira/browse/COCOON-1711?page=comments#action_12362840
]
Werner Masik commented on COCOON-1711:
--
could somebody review this please?
> [PATCH] correct position of help popup for tab styling
> --
>
> Key: COCOON-1711
> URL: http://issues.apache.org/jira/browse/COCOON-1711
> Project: Cocoon
> Type: Bug
> Components: Blocks: Forms
> Versions: 2.1.9-dev (current SVN)
> Reporter: Werner Masik
> Priority: Minor
> Attachments: forms-advanced-field-styling.xsl.diff
>
> Help popups appear in the wrong position when the tab styling is used.
> Usually it pops up below the div that contains the tabbed form, which means
> that the popup is often outside of the visible viewing area.
> Looks like the bug exists since the stylesheets of 2.1.7 and dev branch were
> merged.
> The problem is that the function forms_createPopupWindow does not get called
> when
> the page is loaded into the browser. In current 2.1.X branch the function
> gets called
> directly from the false;" href="#" name="email:help:a" id="email:help:a"> src="resources/forms/img/help.gif">
> So the function is executed when then link to the popup is clicked.
> In 2.1.7 it was called like this:
>
> var helpWinN1003B = forms_createPopupWindow('helpN1003B');
>
> name="N1003B" id="N1003B">
> Here the popup window was created at the first display of the browser page.
> Actually when in tab-styling the whole popup-tree was just copied right below
> the body-tag because of the positioning issues. This was done
> with the forms_moveInBody function which was called in the onload handler of
> the forms.
> Therefore 2 possible solutions exist:
> - revert the code to the old version, to register the handler before the
> onload is executed
> - alter forms-advanced-field-styling.xsl so the divs for the popups are all
> created as a child of the body tag
> The patch I'm submitting takes the second aproach. All it does is create the
> divs where they should be
> from the beginning (below body). This is done by introducing a mode called
> 'forms-help', to make the fi:help
> tags get processed twice. In the first run the divs are created and in the
> second run links for the popups
> are created just behind the field (as usual). Moving the divs with
> javascript therefore becomes obsolete. I think
> that registering the onloadHanlder to call forms_moveInBody can be removed.
> But I was not sure if
> it is needed for something else, so I kept it.
> I'm not a XSLT expert. There might be a better way to process the help
> popups. Feel free
> to make corrections. I also have no experience with ajax. I tested it with
> ajax activated
> and it worked. But I'm not sure if my test was using ajax the right way.
--
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: M10N
On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > Gianugo Rabellino wrote: > > On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > > > >>Daniel Fagerstrom wrote: > >> > >>>Ben Pope skrev: > >> > When "Building Cocoon Block Deployer" > I get a compile error: > java.lang.IllegalStateException: basedir src\main\resources\xsd does > not exist > >>> > >>> > >>>I get the same error, the directory is there but the castor plugin > >>>doesn't find it. Hopefully Reinhard can give a better answer on what is > >>>going on. > >> > >>I have no idea what's going wrong here. I just can say it works for me. > > > > > > Don't know if that helps, but I've got it working by changing: > > > > > > > > src/main/castor/castorbuilder.properties > > src/main/resources/xsd > > > > > > to: > > > > > > > > cocoon-deployer/src/main/castor/castorbuilder.properties > > > > cocoon-deployer/src/main/resources/xsd > > > > > > in cocoon-deployer's pom.xml. Looks like a basedir issue... > > which is your working directory? Uh? Untouched cocoon-trunk, full dir is /Users/gianugo/dev/src/cocoon/trunk/ from where I'm launching mvn... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: M10N
Gianugo Rabellino wrote:
On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
Daniel Fagerstrom wrote:
Ben Pope skrev:
When "Building Cocoon Block Deployer"
I get a compile error:
java.lang.IllegalStateException: basedir src\main\resources\xsd does
not exist
I get the same error, the directory is there but the castor plugin
doesn't find it. Hopefully Reinhard can give a better answer on what is
going on.
I have no idea what's going wrong here. I just can say it works for me.
Don't know if that helps, but I've got it working by changing:
src/main/castor/castorbuilder.properties
src/main/resources/xsd
to:
cocoon-deployer/src/main/castor/castorbuilder.properties
cocoon-deployer/src/main/resources/xsd
in cocoon-deployer's pom.xml. Looks like a basedir issue...
which is your working directory?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[jira] Closed: (COCOON-1683) Allow configuration of expiry in EHDefaultStore
[ http://issues.apache.org/jira/browse/COCOON-1683?page=all ] Johan Stuyts closed COCOON-1683: Resolution: Fixed > Allow configuration of expiry in EHDefaultStore > --- > > Key: COCOON-1683 > URL: http://issues.apache.org/jira/browse/COCOON-1683 > Project: Cocoon > Type: Improvement > Components: * Cocoon Core > Versions: 2.1.7 > Reporter: Johan Stuyts > Attachments: cocoon-ehdefaultstore-configurable-expiry.patch > > EHDefaultStore initializes the cache to never expire entries. This means that > the cache will grow indefinitely (on disk). > This patch allows you to set the expiry of entries in the configuration so > that stale entries will be removed. It simply adds three parameters to the > component which are passed to EHCache. -- 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: M10N
On 1/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > Daniel Fagerstrom wrote: > > Ben Pope skrev: > > >> When "Building Cocoon Block Deployer" > >> I get a compile error: > >> java.lang.IllegalStateException: basedir src\main\resources\xsd does > >> not exist > > > > > > I get the same error, the directory is there but the castor plugin > > doesn't find it. Hopefully Reinhard can give a better answer on what is > > going on. > > I have no idea what's going wrong here. I just can say it works for me. Don't know if that helps, but I've got it working by changing: src/main/castor/castorbuilder.properties src/main/resources/xsd to: cocoon-deployer/src/main/castor/castorbuilder.properties cocoon-deployer/src/main/resources/xsd in cocoon-deployer's pom.xml. Looks like a basedir issue... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: M10N
Daniel Fagerstrom wrote:
Ben Pope skrev:
When "Building Cocoon Block Deployer"
I get a compile error:
java.lang.IllegalStateException: basedir src\main\resources\xsd does
not exist
I get the same error, the directory is there but the castor plugin
doesn't find it. Hopefully Reinhard can give a better answer on what is
going on.
I have no idea what's going wrong here. I just can say it works for me.
Could one of you do
mvn clean
mvn -X -e package >mvn-output.txt
and send the text file to me?
Thanks!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Jetty and Eclipse
Gianugo Rabellino wrote: On 1/15/06, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: Jorg Heymans skrev: Jorg Heymans wrote: Anyhow, there seems to be something not quite right yet with our eclipse setup. If you run eclipse:eclipse from the top level pom in whiteboard/cocoon-flat-layout, you'll see that the plugin generates eclipse project dependencies between the different modules (very useful!) . For some reason, it's not doing this in trunk. I'm currently investigating this ... The trick here is to do $mvn clean install eclipse:clean eclipse:eclipse before importing the project. The plugin seems to need the projects to be *installed* before it will generate eclipse project references from a reactor build. I tried it and it worked. Guys, sorry for the wasted electrons but I just feel the compelling need to thank you so much for this most promising work. You made me open my eyes on how Maven 2 could help us getting a solid build system which is a huge first step towards semplification: I'm sold on your approach. I hope this short note from the skeptical camp might cheer you up and let you know how welcome your efforts are! Thanks! And thanks to all involved, I must say that the Mavenization far exceeds my expectations. /Daniel
