Re: [M10N] Rhino -- js
Antonio Gallardo wrote: In ibiblio, there is rhino 1.6R1: http://www.ibiblio.org/maven2/rhino/js/1.6R1/ currently, we use: http://cvs.apache.org/repository/rhino/jars/ sure go ahead. cvs.apache.org is really only there for projects that aren't releasing to ibiblio yet. Jorg
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Le 7 nov. 05, à 08:36, Sylvain Wallez a écrit : ...So I kindly ask people to carefully read and understand the rationale and motivation behind ':'. Ok, thanks for your (repeated I think ;-) explanation, then: [+1 ] foo.bar:input (colon, not CSS-friendly because of IE) -Bertrand
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Il giorno 07/nov/05, alle ore 08:36, Sylvain Wallez ha scritto: So I kindly ask people to carefully read and understand the rationale and motivation behind ':'. Alright, you convinced me. I hereby revert my previous vote and vote +1 on using the colon. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: The initial foo.bar:input proposal *structucally* prevents name all crispy clear now. I revert my previous +1 and +1 this proposal instead. Jorg
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: [X] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Jeroen
Re: [VOTE] Naming rule for HTML IDs generated by CForms
On Sun, 2005-11-06 at 11:51 +0100, Sylvain Wallez wrote: So please choose one proposal below: [ ] foo.bar:input (colon, not CSS-friendly because of IE) +1 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Jorg Heymans wrote: Sylvain Wallez wrote: The initial foo.bar:input proposal *structurally* prevents name all crispy clear now. Phew! Sometimes, when there's a lot of background, producing a clear explanation is not an easy task ;-) Now I'm glad I finally was able to do it, and will make sure this is written in the docs, to avoid the same effort later in the future :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[daisy] how to enter comments for revisions?
Is there a way to add a revision comment when editing stuff in Daisy at cocoon.zones.apache.org/ ? Use case (fairly obvious ;-) : I just corrected a typo and would like to add the comment I just corrected a typo to this revision. Bear with me if the answer is obvious: it's only Monday here... -Bertrand
RE: [VOTE] Naming rule for HTML IDs generated by CForms
Hi all, [X] foo.bar:input (colon, not CSS-friendly because of IE) +1 from me as well. It's the least evil one, it does interfere with the libraries meaning of :, however, since it is in effect hidden from the user, it's okay. Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
[jira] Created: (COCOON-1680) New design/ layout proposal for Cocoon documentation
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 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: [VOTE] Naming rule for HTML IDs generated by CForms
Hi, [+1] foo.bar:input (colon, not CSS-friendly because of IE) (do people still use IE? ;-) Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
cocoon 2.1.8rc1
...don't kill the messenger but unless I am mistaken we still have some issues with 2.1.8rc1 1) I get a NPE for all the OpenOffice examples http://localhost:/samples/hello-world/hello.sxw 2) At least on OSX the MS Word 2003 example does not work with MS Word 2004. Just doesn't recognize the file. 3) TextEdit says that something is wrong with RTF file example although Word can open it just fine. 4) Why do we have per person credits at http://localhost:/samples/modules/xml.html 5) In the Lucene examples I've created an index but got a ResourceNotFound for http://localhost:/samples/blocks/lucene/statistic And also an IOException when accessing index2 (how can I create index2??) http://localhost:/samples/blocks/lucene/findIt2? queryString=cocoon 6) The XMLDB Source exmaples give a http 500 error see http://localhost:/samples/blocks/xmldb/db/cocoon/?xpath=/ samples/group 7) Invalid XML for the Axis sample http://localhost:/samples/blocks/axis/status.xsp 8) javaflow examples http://localhost:/samples/blocks/javaflow/editForm2.do gives Attribute 'unique-row-id' is no more supported, use fb:identity instead 9) on the jcr example http://localhost:/samples/blocks/jcr/browse/jcr:system I get a javax.jcr.RepositoryException: No type info found for node type 'rep:system' at /jcr:system 10) proxy block http://localhost:/samples/blocks/proxy/wsproxy/ org.xml.sax.SAXException: Can not resolve namespace prefix: xalan cheers -- Torsten PGP.sig Description: This is a digitally signed message part
[jira] Updated: (COCOON-1680) New design/ layout proposal for Cocoon documentation
[ http://issues.apache.org/jira/browse/COCOON-1680?page=all ] Milan Andrejevic updated COCOON-1680: - Attachment: screenshot.gif screenshot 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, 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: cocoon 2.1.8rc1
On 7 Nov 2005, at 10:12, Torsten Curdt wrote: 5) In the Lucene examples I've created an index but got a ResourceNotFound for http://localhost:/samples/blocks/lucene/statistic And also an IOException when accessing index2 (how can I create index2??) http://localhost:/samples/blocks/lucene/findIt2? queryString=cocoon Hi Torsten It is a shame, but these samples never got over the loss on the xml docs that used to be distributed with Cocoon. These were what were indexed for those samples AFAIR. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: cocoon 2.1.8rc1
On 07.11.2005, at 11:33, Jeremy Quinn wrote: On 7 Nov 2005, at 10:12, Torsten Curdt wrote: 5) In the Lucene examples I've created an index but got a ResourceNotFound for http://localhost:/samples/blocks/lucene/statistic And also an IOException when accessing index2 (how can I create index2??) http://localhost:/samples/blocks/lucene/findIt2? queryString=cocoon Hi Torsten It is a shame, but these samples never got over the loss on the xml docs that used to be distributed with Cocoon. These were what were indexed for those samples AFAIR. Remove them? PGP.sig Description: This is a digitally signed message part
Re: cocoon 2.1.8rc1
Le 7 nov. 05, à 11:12, Torsten Curdt a écrit : ...we still have some issues with 2.1.8rc1... ...3) TextEdit says that something is wrong with RTF file example although Word can open it just fine... Most probably an oold jfor issue that's been in there for a long time, I don' think it's a regression. The RTF functionality of FOP has been progressing recently, it might be ripe to replace jfor soon. -Bertrand
Re: [M10N] fixing repo for cocoon
I just tried the m2 build for the test structure in the whiteboard and get the following error: [INFO] Failed to resolve artifact. GroupId: saxon7 ArtifactId: saxon7 Version: 7.9.1 Reason: Unable to download the artifact from any repository saxon7:saxon7:7.9.1:jar Am I the only one getting this? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Strange caching issue: need to reload twice
2005/11/3, Sylvain Wallez [EMAIL PROTECTED]:
Hmm... could this be related to the refresh delay of the directory
generator[1]?
What happens if you add map:parameter name=refreshDelay value=0/
in the generate type=directory ?
Sylvain, we tested value=0, and got the same effect.
Going slightly further, we tried with value=-1, and amazingly
enough, it worked.
AFAICS, this must be a bug somewhere, as Cocoon is not refreshing at
the first attempt even after an amount of time far longer than one
second (except with value=-1). We have little knowledge on Cocoon
internals, but we were looking into the DirectoryGenerator (and
DirValidity) and found nothing strange.
Hello,
I finally found something strange in DirectoryGenerator that could
explain the bug. In DirValidity we added some traces:
public int isValid() {
if (System.currentTimeMillis() = expiry) {
logger.debug(this + : isValid() == 1 (not expired));
return 1;
}
expiry = System.currentTimeMillis() + delay; /* *
SHOULD THIS LINE BE REMOVED? !!! * */
int len = files.size();
for (int i = 0; i len; i++) {
File f = (File)files.get(i);
if (!f.exists()) {
logger.debug(this + : isValid() == -1 (file
+f+ removed));
return -1; // File was removed
}
long oldDate = ((Long)fileDates.get(i)).longValue();
long newDate = f.lastModified();
if (oldDate != newDate) {
logger.debug(this + : isValid() == -1 (different
dates for +f+: +oldDate+!=+newDate+));
return -1;
}
}
// all content is up to date: update the expiry date
expiry = System.currentTimeMillis() + delay;
logger.debug(this + : isValid() == 1 (all valid));
return 1;
}
I think the tagged line should be removed. I can't see why it is
there, and I think it is responsible for the harm. When reloading
after changing a file, we get:
[sitemap.generator.directory]
[EMAIL PROTECTED]
Expiry: 1131363743861 - Delay: 1000: isValid() == -1 (different dates
for /home/fiol/ficheros-intranet/compartido/paginas/actualidad/resumen-noticias:
1131037742000!=1131363738000)
[sitemap.generator.directory]
[EMAIL PROTECTED]
Expiry: 1131363743861 - Delay: 1000: isValid() == 1 (not expired)
So apparently isValid is called twice, with inconsistent results
(first is OK, second is wrong, unless *I* am wrong ;-).
Aside from that, is the recycle method called before calling
generate() if cache is invalid? Supposing it is not, how is the
DirValidity refreshed with new files? More specifically, how are old
ones removed? There is no point in the code where this.validity is
made null other than the recycle method.
As I told you, I know very little about Cocoon internals, but there
seems to be something broken here.
--
Antonio
Re: [M10N] fixing repo for cocoon
Carsten Ziegeler wrote: I just tried the m2 build for the test structure in the whiteboard and get the following error: [INFO] Failed to resolve artifact. GroupId: saxon7 ArtifactId: saxon7 Version: 7.9.1 Reason: Unable to download the artifact from any repository saxon7:saxon7:7.9.1:jar Am I the only one getting this? I have the same problem for saxon7-jdom. And also for: GroupId: jaxen ArtifactId: jaxen Version: 1.0-FCS-full Reason: Unable to download the artifact from any repository jaxen:jaxen:1.0-FCS-full:jar /Daniel
Re: [M10N] fixing repo for cocoon
Carsten Ziegeler wrote: I just tried the m2 build for the test structure in the whiteboard and get the following error: [INFO] Failed to resolve artifact. GroupId: saxon7 ArtifactId: saxon7 Version: 7.9.1 Reason: Unable to download the artifact from any repository saxon7:saxon7:7.9.1:jar I'm pretty sure saxon was on cvs.apache.org already, who removed it ? The recommended maven way of solving this would be to nag to the project maintainers to get them to release to ibiblio. Jorg
[jira] Commented: (COCOON-1680) New design/ layout proposal for Cocoon documentation
[ http://issues.apache.org/jira/browse/COCOON-1680?page=comments#action_12356951 ] Helma van der Linden commented on COCOON-1680: -- Thanks for the work done, it really looks much more modern. I like the general layout and the simplicity of the menu and main content window. I noticed a kind of top level menu in the bar at the top. I find this very cluttered, i.e. too many entries. Maybe you could go one level up for that or reduce it to: - about Cocoon (about us, status, and other info on downloads, svn access, mailing list, links etc) - user guide (narrative info about Cocoon, i.e. explanations of concepts, beginners' info etc) - reference guide (more in-depth info about various aspects of Cocoon) - apidocs and the two Cocoon/ASF links at the right. I do like this: simple and clear. Although you might change ASF to Apache since not every one is familiar with the meaning of ASF. I noticed lines above certain letters of the links. I assume they are used for keyboard shortcuts? If so, the idea is fabulous, but I would suggest to move the line below the letter or change the color of the letter. Both are more compatible with user expectations. I like it that the search bar is less prominent but as a whole I find the top block very cluttered. Is it possible to reduce the left image with the feather? 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, 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: [daisy] how to enter comments for revisions?
On 07 Nov 2005, at 10:38, Bertrand Delacretaz wrote: Is there a way to add a revision comment when editing stuff in Daisy at cocoon.zones.apache.org/ ? Nope, there isn't. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: [M10N] fixing repo for cocoon
Carsten Ziegeler wrote: I just tried the m2 build for the test structure in the whiteboard and get the following error: [INFO] Failed to resolve artifact. GroupId: saxon7 ArtifactId: saxon7 Version: 7.9.1 Reason: Unable to download the artifact from any repository saxon7:saxon7:7.9.1:jar Am I the only one getting this? Carsten It is in the dependencies in excalibur-xmlutil-2.1, see: http://www.ibiblio.org/maven2/excalibur-xmlutil/excalibur-xmlutil/2.1/excalibur-xmlutil-2.1.pom The xmlutil have an enourmous amount of dependencies, any ideas why it use both saxon and saxon7 and even saxon7-sql? /Daniel
[jira] Commented: (COCOON-1680) New design/ layout proposal for Cocoon documentation
[ http://issues.apache.org/jira/browse/COCOON-1680?page=comments#action_12356955 ] Milan Andrejevic commented on COCOON-1680: -- Everything is changeable, but let's see some more comments. How many (maximum) menu entries are there? Please give structure for top menu(s) and sidebar menu you would like to have. I assume they are used for keyboard shortcuts? Yes you assume right. 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, 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: [VOTE] Naming rule for HTML IDs generated by CForms
On Nov 7, 2005, at 3:26 AM, Sylvain Wallez wrote: Jorg Heymans wrote: Sylvain Wallez wrote: The initial foo.bar:input proposal *structurally* prevents name all crispy clear now. It was clear then. As always there are trade offs. In this case Its between possible naming conflicts and a CSS incompatibility (bad practices aside) in 90% of users browsers. Which error will be easier to detect? Which is most likely to affect users? Phew! Sometimes, when there's a lot of background, producing a clear explanation is not an easy task ;-) Now I'm glad I finally was able to do it, and will make sure this is written in the docs, to avoid the same effort later in the future :-) as opposed to sooner in the future? ;-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
[jira] Created: (COCOON-1681) Generator directory: Caching too much
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 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] Commented: (COCOON-1681) Generator directory: Caching too much
[ http://issues.apache.org/jira/browse/COCOON-1681?page=comments#action_12356956 ] Antonio Fiol commented on COCOON-1681: -- Workaround: Set map:parameter name=refreshDelay value=-1 / so the expiry check is disabled. 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 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
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: So please choose one proposal below: [X] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) -- 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
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Andrew Savory wrote: Hi, [+1] foo.bar:input (colon, not CSS-friendly because of IE) (do people still use IE? ;-) only a 90% minority does :) -- 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
Re: [M10N] fixing repo for cocoon
Daniel Fagerstrom wrote: It is in the dependencies in excalibur-xmlutil-2.1, see: http://www.ibiblio.org/maven2/excalibur-xmlutil/excalibur-xmlutil/2.1/excalibur-xmlutil-2.1.pom The xmlutil have an enourmous amount of dependencies, any ideas why it use both saxon and saxon7 and even saxon7-sql? That pom is just plain dodgy. We should go through the excalibur libs and fix the poms once and for all. Can we do this ourselves or is there still a project maintainer to nag ? Jorg
[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 54 projects, and has been outstanding for 3 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-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-07112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-07112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-07112005/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: 16 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 -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-07112005.jar -Dbuild=build/cocoon-07112005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[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 54 projects, and has been outstanding for 3 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-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-07112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-07112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-07112005/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: 16 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 -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-07112005.jar -Dbuild=build/cocoon-07112005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Ezkovich Glen wrote: snip/ Phew! Sometimes, when there's a lot of background, producing a clear explanation is not an easy task ;-) Now I'm glad I finally was able to do it, and will make sure this is written in the docs, to avoid the same effort later in the future :-) as opposed to sooner in the future? ;-) Sooner or later, it all depend on when that doc will be written :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [M10N] fixing repo for cocoon
Jorg Heymans wrote: Daniel Fagerstrom wrote: It is in the dependencies in excalibur-xmlutil-2.1, see: http://www.ibiblio.org/maven2/excalibur-xmlutil/excalibur-xmlutil/2.1/excalibur-xmlutil-2.1.pom The xmlutil have an enourmous amount of dependencies, any ideas why it use both saxon and saxon7 and even saxon7-sql? That pom is just plain dodgy. We should go through the excalibur libs and fix the poms once and for all. Can we do this ourselves or is there still a project maintainer to nag ? We can do this ourselves I think - the best (but most time consuming)way would imho be to convert excalibur to use maven 2. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [M10N] fixing repo for cocoon
Carsten Ziegeler wrote: We can do this ourselves I think - the best (but most time consuming)way would imho be to convert excalibur to use maven 2. Well, the poms are partially converted so that's a big part done already. Provided the repository is somewhat properly organized, going through the poms and stripping them of unnecessary cruft shouldn't take too long - even though it's utterly boring! Is excalibur still being developed? Last svn commit seemed to be 3 days ago. Jorg
Re: [M10N] fixing repo for cocoon
Jorg Heymans wrote: Carsten Ziegeler wrote: We can do this ourselves I think - the best (but most time consuming)way would imho be to convert excalibur to use maven 2. Well, the poms are partially converted so that's a big part done already. Provided the repository is somewhat properly organized, going through the poms and stripping them of unnecessary cruft shouldn't take too long - even though it's utterly boring! :) But these are the low hanging fruits most people are waiting for, or? ;) Is excalibur still being developed? Last svn commit seemed to be 3 days ago. Yes; it's not that active anymore but from time to time minor features or bug fixes are added. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [M10N] fixing repo for cocoon
Jorg Heymans wrote: Carsten Ziegeler wrote: We can do this ourselves I think - the best (but most time consuming)way would imho be to convert excalibur to use maven 2. Well, the poms are partially converted so that's a big part done already. Provided the repository is somewhat properly organized, Excalibur is built with Maven1 so it should be properly organized. going through the poms and stripping them of unnecessary cruft shouldn't take too long - even though it's utterly boring! Is excalibur still being developed? Last svn commit seemed to be 3 days ago. It is maintained rather than developed. If you feel like taking care of it, just subscribe to dev@excalibur.apache.org and ask about M2. Even if the list isn't that active, many of the Excalibur and Avalon developers read it so you probably get respons. Before, Cocoon committers automatically got commit access to Excalibur, don't know if that is the case anymore. /Daniel
[jira] Reopened: (COCOON-889) NPE in AbstractEnvironment class
[ http://issues.apache.org/jira/browse/COCOON-889?page=all ] Antonio Fiol reopened COCOON-889: - I found the same proble under 2.1.7, when I call a pipeline from a cron job. The pipeline calls flowscript which calls another pipeline at the end. I am reopening the issue although I cannot currently test with 2.1.8-rc1. If you feel it should solved in current SVN, please feel free to close it. NPE in AbstractEnvironment class Key: COCOON-889 URL: http://issues.apache.org/jira/browse/COCOON-889 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.2 Environment: Operating System: Linux Platform: PC Reporter: Ivan Kurmanov Assignee: Ivan Kurmanov java.lang.NullPointerException at org.apache.cocoon.environment.AbstractEnvironment.release(AbstractEnvironment.java:521) at org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(MutableEnvironmentFacade.java:332) at org.apache.cocoon.generation.FileGenerator.recycle(FileGenerator.java:89) at org.apache.avalon.excalibur.pool.ResourceLimitingPool.put(ResourceLimitingPool.java:438) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:245) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:452) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:336) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:326) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:323) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.recycle(AbstractProcessingPipeline.java:641) at org.apache.cocoon.components.pipeline.impl.BaseCachingProcessingPipeline.recycle(BaseCachingProcessingPipeline.java:112) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.recycle(AbstractCachingProcessingPipeline.java:961) at org.apache.avalon.excalibur.pool.ResourceLimitingPool.put(ResourceLimitingPool.java:438) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:245) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:452) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:336) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:326) at org.apache.cocoon.components.EnvironmentDescription.release(CocoonComponentManager.java:602) at org.apache.cocoon.components.CocoonComponentManager.endProcessing(CocoonComponentManager.java:212) at org.apache.cocoon.Cocoon.process(Cocoon.java:660) at org.apache.cocoon.bean.CocoonWrapper.getPage(CocoonWrapper.java:535) at org.apache.cocoon.bean.CocoonBean.processTarget(CocoonBean.java:521) at org.apache.cocoon.bean.CocoonBean.process(CocoonBean.java:372) at org.apache.cocoon.Main.main(Main.java:388) The same exception repeated three times for a single request/file, although it is generated through three different calling classes. The general picture: I use Forrest, which got me 2.1.2-dev version of Cocoon. I edited the sitemap.xmap to remove unnecesary things, like PDF generation (FO processing) and alike. Didn't change pool-* settings. In site.xml I have an item with href='/'. This item is referenced in one of the pages. This quite well might be a Forrest bug, but maybe Cocoon also need to be more careful about null pointers in this case. -- 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] Closed: (COCOON-889) NPE in AbstractEnvironment class
[ http://issues.apache.org/jira/browse/COCOON-889?page=all ] Sylvain Wallez closed COCOON-889: - Resolution: Fixed Assign To: (was: Ivan Kurmanov) There were some nasty multi-threading bugs fixed that were causing NPEs in pipelines called from cron jobs. So this should be fixed in 2.1.8. Reopen it *only* if it still breaks with the latest revision. NPE in AbstractEnvironment class Key: COCOON-889 URL: http://issues.apache.org/jira/browse/COCOON-889 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.2 Environment: Operating System: Linux Platform: PC Reporter: Ivan Kurmanov java.lang.NullPointerException at org.apache.cocoon.environment.AbstractEnvironment.release(AbstractEnvironment.java:521) at org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(MutableEnvironmentFacade.java:332) at org.apache.cocoon.generation.FileGenerator.recycle(FileGenerator.java:89) at org.apache.avalon.excalibur.pool.ResourceLimitingPool.put(ResourceLimitingPool.java:438) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:245) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:452) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:336) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:326) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:323) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.recycle(AbstractProcessingPipeline.java:641) at org.apache.cocoon.components.pipeline.impl.BaseCachingProcessingPipeline.recycle(BaseCachingProcessingPipeline.java:112) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.recycle(AbstractCachingProcessingPipeline.java:961) at org.apache.avalon.excalibur.pool.ResourceLimitingPool.put(ResourceLimitingPool.java:438) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:245) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:452) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:336) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:326) at org.apache.cocoon.components.EnvironmentDescription.release(CocoonComponentManager.java:602) at org.apache.cocoon.components.CocoonComponentManager.endProcessing(CocoonComponentManager.java:212) at org.apache.cocoon.Cocoon.process(Cocoon.java:660) at org.apache.cocoon.bean.CocoonWrapper.getPage(CocoonWrapper.java:535) at org.apache.cocoon.bean.CocoonBean.processTarget(CocoonBean.java:521) at org.apache.cocoon.bean.CocoonBean.process(CocoonBean.java:372) at org.apache.cocoon.Main.main(Main.java:388) The same exception repeated three times for a single request/file, although it is generated through three different calling classes. The general picture: I use Forrest, which got me 2.1.2-dev version of Cocoon. I edited the sitemap.xmap to remove unnecesary things, like PDF generation (FO processing) and alike. Didn't change pool-* settings. In site.xml I have an item with href='/'. This item is referenced in one of the pages. This quite well might be a Forrest bug, but maybe Cocoon also need to be more careful about null pointers in this case. -- 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: cocoon 2.1.8rc1
Torsten Curdt wrote: ...don't kill the messenger but unless I am mistaken we still have some issues with 2.1.8rc1 1) I get a NPE for all the OpenOffice examples http://localhost:/samples/hello-world/hello.sxw Fixed. This was a namespace-handling problem in ZipArchiveSerializer 2) At least on OSX the MS Word 2003 example does not work with MS Word 2004. Just doesn't recognize the file. This is because it used the XML Word format, which Word 2004/Mac doesn't understand 3) TextEdit says that something is wrong with RTF file example although Word can open it just fine. Don't know. Maybe Mr JFor, that happens to use a Mac, could have a look ;-) 4) Why do we have per person credits at http://localhost:/samples/modules/xml.html Removed. In the i18n samples also. 5) In the Lucene examples I've created an index but got a ResourceNotFound for http://localhost:/samples/blocks/lucene/statistic And also an IOException when accessing index2 (how can I create index2??) http://localhost:/samples/blocks/lucene/findIt2?queryString=cocoon 6) The XMLDB Source exmaples give a http 500 error see http://localhost:/samples/blocks/xmldb/db/cocoon/?xpath=/samples/group 7) Invalid XML for the Axis sample http://localhost:/samples/blocks/axis/status.xsp Fixed. 8) javaflow examples http://localhost:/samples/blocks/javaflow/editForm2.do gives Attribute 'unique-row-id' is no more supported, use fb:identity instead Fixed, replaced by fb:identity 9) on the jcr example http://localhost:/samples/blocks/jcr/browse/jcr:system I get a javax.jcr.RepositoryException: No type info found for node type 'rep:system' at /jcr:system Yeah, there is no JCRNode - source mapping for this system-defined collection... Need to add some auto-configuration stuff to the JCRSource. 10) proxy block http://localhost:/samples/blocks/proxy/wsproxy/ org.xml.sax.SAXException: Can not resolve namespace prefix: xalan Fixing this leads to another error related to XMLForm. And the other sample is related to CocoonHive, which now has nothing more to do with Cocoon. Samples disabled, we'll have to revisit this proxy stuff anyway. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
portal+cform+ajax problem in 2.1.8 rc1
Hi,all
I try to combine portal+form(with ajax) in 2.1.8 rc1,all is fine but one
problem,I don't know if is a bug,and just show my step here:
1.change block portal in samples,copletdata.xml,config like:
coplet-data id=app-test-two name=standard
titleApplication Test/title
coplet-base-dataCachingURICoplet/coplet-base-data
attribute
namebuffer/name
value xsi:type=java:java.lang.Booleantrue/value
/attribute
attribute
namehandleParameters/name
value xsi:type=java:java.lang.Booleantrue/value
/attribute
attribute
nameuri/name
value
xsi:type=java:java.lang.Stringcocoon:/coplets/html/application/value
/attribute
attribute
nametemporary:application-uri/name
value
xsi:type=java:java.lang.Stringcocoon://samples/blocks/forms/do-datasourceChooser.flow/value
/attribute
/coplet-data
I just point the url to a form ajax sample
2.change portal skin files to make form render correctly.
3.change form block datasource_chooser_template.xml,from
ft:form-template action=#{$cocoon/continuation/id}.continue
method=POST ajax=true
to
ft:form-template action=continue method=POST ajax=true
ajax-action=/samples/blocks/forms/continue
ft:continuation-id/
this change will still make the sample run good.
Now I run the server and enter portal block sample,it works fine only
when finally I click ok button.
If it is not a ajax form or run the form seperatly,I should see the
result information,but now I see the form restart.
I check the aceess log and add some debug code in js file,the
flowscript did't run after
form.showForm(datasource_chooser-display-pipeline.jx);
and the seperate form sample will run continue twice when I click ok
but only once under this condition.
I guess the ajax code missing one click to make showForm complete in
this situation,so it may be a bug.
Regards
Roy Huang
_
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
Re: cocoon 2.1.8rc1
2) At least on OSX the MS Word 2003 example does not work with MS Word 2004. Just doesn't recognize the file. This is because it used the XML Word format, which Word 2004/Mac doesn't understand Strange ...not downwards compatible? 3) TextEdit says that something is wrong with RTF file example although Word can open it just fine. Don't know. Maybe Mr JFor, that happens to use a Mac, could have a look ;-) I dare to ask - who is Mr JFor? Thanks for fixing this all up, mate cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: cocoon 2.1.8rc1
Torsten Curdt wrote: 2) At least on OSX the MS Word 2003 example does not work with MS Word 2004. Just doesn't recognize the file. This is because it used the XML Word format, which Word 2004/Mac doesn't understand Strange ...not downwards compatible? No, it's a completely different format. 3) TextEdit says that something is wrong with RTF file example although Word can open it just fine. Don't know. Maybe Mr JFor, that happens to use a Mac, could have a look ;-) I dare to ask - who is Mr JFor? No need for that, he should be around: have a look at http://sourceforge.net/projects/jfor/ Bertrand ?!? Thanks for fixing this all up, mate Hey, I want this 2.1.8 out now! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: portal+cform+ajax problem in 2.1.8 rc1
黄 海冬 wrote: Hi,all I try to combine portal+form(with ajax) in 2.1.8 rc1,all is fine but one problem,I don't know if is a bug,and just show my step here: snip/ Now I run the server and enter portal block sample,it works fine only when finally I click ok button. If it is not a ajax form or run the form seperatly,I should see the result information,but now I see the form restart. I check the aceess log and add some debug code in js file,the flowscript did't run after form.showForm(datasource_chooser-display-pipeline.jx); and the seperate form sample will run continue twice when I click ok but only once under this condition. I guess the ajax code missing one click to make showForm complete in this situation,so it may be a bug. Well, my colleagues that succeeded in using CForms+Ajax in the portal told me this is much more complicated than that, and I shamely admit that I haven't understood their explanations. So it's not really a bug: the CForms+Ajax coplets must be written in a very special way. I'll try to have a better answer tomorrow, as we're here past the work hours now. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: cocoon 2.1.8rc1
Le 7 nov. 05, à 18:58, Sylvain Wallez a écrit : ...3) TextEdit says that something is wrong with RTF file example although Word can open it just fine. Don't know. Maybe Mr JFor, that happens to use a Mac, could have a look ;-) I dare to ask - who is Mr JFor? No need for that, he should be around: have a look at http://sourceforge.net/projects/jfor/ Bertrand ?!? As I said, this is probably an ooold bug/incompatiblity in jfor, not a regression. Fixing those kinds of things in RTF is a pain, and I don't have a need for that ATM. Anyone's free to have a go if they need it ;-) -Bertrand
Re: cocoon 2.1.8rc1
Bertrand Delacretaz wrote: Le 7 nov. 05, à 18:58, Sylvain Wallez a écrit : ...3) TextEdit says that something is wrong with RTF file example although Word can open it just fine. Don't know. Maybe Mr JFor, that happens to use a Mac, could have a look ;-) I dare to ask - who is Mr JFor? No need for that, he should be around: have a look at http://sourceforge.net/projects/jfor/ Bertrand ?!? As I said, this is probably an ooold bug/incompatiblity in jfor, not a regression. Fixing those kinds of things in RTF is a pain, and I don't have a need for that ATM. Anyone's free to have a go if they need it ;-) Ah, sorry I missed you answer! Do you know if/when the FOP people plan to release the new version? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[OTAnn] Feedback
I was interested in getting feedback from current mail group users.We have mirrored your mail list in a new application that provides a more aggregated and safe environment which utilizes the power of broadband.Roomity.com v 1.5 is a web 2.01 community webapp. Our newest version adds broadcast video and social networking such as favorite authors and an html editor.It?s free to join and any feedback would be appreciated.S.Broadband interface (RIA) + mail box saftey = Apache_Cocoon_Developer_List.roomity.com*Your* clubs, no sign up to read, ad supported; try broadband internet. ~~1131397868569~~
Re: [OTAnn] Feedback
shenanigans wrote: I was interested in getting feedback from current mail group users. We have mirrored your mail list in a new application that provides a more aggregated and safe environment which utilizes the power of broadband. Roomity.com v 1.5 is a web 2.01 community webapp. Web 2.01? Wow, JavaWebStart is ahead of the Ajax crowd when it comes to version numbering :-) Our newest version adds broadcast video and social networking such as favorite authors and an html editor. It?s free to join and any feedback would be appreciated. Sorry, but having the JavaWebStart application asking for full access to my computer immediately stopped the evaluation... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: cocoon 2.1.8rc1
Le 7 nov. 05, à 21:57, Sylvain Wallez a écrit : ...Do you know if/when the FOP people plan to release the new version?... Should happen soon, but I don't know how extensive the RTF support will be, haven't tested it lately. -Bertrand
[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 54 projects. 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-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-07112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-07112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-07112005/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: 18 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 -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-07112005.jar -Dbuild=build/cocoon-07112005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
Re: cocoon 2.1.8rc1
Torsten Curdt wrote: Jeremy Quinn wrote: Torsten Curdt wrote: 5) In the Lucene examples I've created an index but got a ResourceNotFound for http://localhost:/samples/blocks/lucene/statistic And also an IOException when accessing index2 (how can I create index2??) http://localhost:/samples/blocks/lucene/findIt2? queryString=cocoon It is a shame, but these samples never got over the loss on the xml docs that used to be distributed with Cocoon. These were what were indexed for those samples AFAIR. Remove them? Erk, that is bad. How about just leaving them there, knowing that they are broken, with a notice on the Lucene Samples page. Someone might be able to later add a specific set of example docs. There is another side-effect of ripping out the sources for docs. There are many links from samples directly to local documentation. -David
Re: cocoon 2.1.8rc1
Torsten Curdt wrote: ...don't kill the messenger but unless I am mistaken we still have some issues with 2.1.8rc1 The new documentation is not yet ready, so we will not be able to update the website following the release as we normally do. See the many issues over the last few days. Here is one thread, but there were also others. http://marc.theaimsgroup.com/?t=11312132773 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113132799820935 -David
Re: Ajax libraries: let's wait a bit
Hi Sylvain and other AJAX gurus ;-)
I wonder, if you heard of Taconite [1] which seems to have released 1.0
recently?
It is licensed under the Apache License, but I don't know, if it does
what we need.
Additionally to the list of AJAX libraries already posted [2] I found an
other one in [3].
But unfortunately Taconite isn't mentioned in both lists.
Cheers,
Andreas
[1] http://taconite.sourceforge.net/
[2] http://wiki.osafoundation.org/bin/view/Projects/AjaxLibraries
[3] http://ajaxpatterns.org/Ajax_Frameworks
Sylvain Wallez wrote:
Hi all,
A few days ago, I raised some concerns [1] about the Scriptaculous
JavaScript library which we started to use in the Ajax block, because of
modifications made to JavaScript base classes made by the underlying
Prototype library on which it is based.
I had no satisfying answer on the Scriptaculous mailing-list, and
removing the base classes extensions in Prototype would mean rewriting a
lot of things in Scriptaculous and is thus very unlikely to happen.
Furthermore, I also wanted to use the Sortable [2] class for CForms
repeaters, but had to make important modifications to the class itself
for this to work with CForms because the conventions used are different.
Considering this, I decided that Scriptaculous was a wrong choice and
looked to other alternatives.
The most promising so far is the Dojo Toolkit [3] :
- it has a very cool load on demand feature that allows to have only
bootstrap script tags in the page, and then load other scripts when
they are needed using require('foo.bar.baz'). A must have in Cocoon
where each block may bring its own client-side scripts. Also in CForms
where you do not want e.g. to have htmlarea and calendar loaded in all
pages if not used in these pages.
- it is not only about cool effects: it provides a number of data
structures, can use iframes when xmlhttprequest is not present, tackles
the browser history problem in Ajax apps, etc.
- its development is community-driven, even if the original creator
plays the benevolent dictator
- it has an interesting test system that uses Rhino, and the ability to
assemble and compress a number of files in a single one to speedup
things in production.
The current drawback of Dojo is that the all the spiffy effects are
there (and more [4]), but lack a close integration with background page
update. But that should be a couple of classes.
All this to say that before making a choice for a client-side JS library
that more and more blocks are likely to use with the progression of Ajax
needs, we need to take a bit of time to find the pros and cons of the
various alternatives.
As 2.1.8 will be released soon, I will rollback changes to the CForms JS
library so that is uses the little home-grown stuff I wrote back in
July. I will also remove the Ajax examples that rely on Scriptaculous
(sorry Jeremy!), which will be reinstalled once we've taken the time to
make a choice.
Thoughts?
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112921787207346w=2
[2] http://script.aculo.us/demos/ajax/sortable_elements
[3] http://dojotoolkit.org/
[4]
http://dojotoolkit.org/~alex/dojo/trunk/tests/widget/test_FisheyeList.html
