[jira] Commented: (COCOON-1802) Script for m10n of old blocks
[ http://issues.apache.org/jira/browse/COCOON-1802?page=comments#action_12371192 ] Reinhard Poetz commented on COCOON-1802: I will work on the scripts together with Andreas next week (29.3.). Script for m10n of old blocks - Key: COCOON-1802 URL: http://issues.apache.org/jira/browse/COCOON-1802 Project: Cocoon Type: New Feature Components: - Build System: Maven Versions: 2.2-dev (Current SVN) Reporter: Andreas Hochsteger Assignee: Reinhard Poetz Attachments: m10n-blocks.zip, m10n-blocks.zip, m10n-blocks.zip, m10n-blocks.zip See thread starting with http://www.mail-archive.com/dev@cocoon.apache.org/msg42233.html for discussion details. Here's the info from the file README.txt: What is it? --- m10n-blocks.sh is a script which automates parts of the conversion from the old blocks to the new mavenized ones. Configuration - Only 2 variables have to be adjusted: blksrc: Local directory where https://svn.apache.org/repos/asf/cocoon/blocks is checked out blkdest: Local directory where https://svn.apache.org/repos/asf/cocoon/trunk is checked out Usage - # ./m10n-blocks.sh blockname... Example: # ./m10n-blocks.sh asciiart faces Conventions --- The script assumes, that every block will consist of a parent block (cocoon-blockname), an implementation block (cocoon-blockname-impl) and a sample block (cocoon-blockname-sample). TODOs - The subversion commands are currently untested and commented-out. The implementation pom has to be manually merged with the original pom of the old block. In many cases it is enough to add the dependencies. The build section should not be merged, since the new directory structure uses maven defaults and thus doesn't need a special configuration. -- 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: ForrestBot build for cocoon-docs FAILED
David Crossley wrote: Bruno Dumon wrote: BTW, this time not because the zone was restarted. Not sure what the problem is though. I investigated a bit yesterday, but cannot see what is the problem. Notice that today there are less breaks than yesterday. However, looking at the cocoon-docs mailing list diffs from Daisy i cannot see any relevant changes. http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml It complains about Daisy IDs 786 and 655 which are navigation documents. Surely Forrest's Cocoon had already processed those resources. Strange. I am stumped. Ross seems busy with other stuff. Curiouser and curiouser. At the next 12-hourly run there is only one breakage and for a different ID. -David On Mon, 2006-03-20 at 12:22 +, [EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. snip/ [java] * [372/7] [0/296] 4.138s 53.3Kb 2.1/userdocs/core/image-reader.html [java] * [373/6] [0/296] 3.547s 48.8Kb 2.1/userdocs/widgets/widget_row_action.html [java] * [375/4] [0/296] 3.646s 50.2Kb 2.1/userdocs/profile-generator.html [java] * [376/3] [0/296] 3.742s 46.7Kb 2.1/faq/faq-selectors.html [java] X [0] 2.1/userdocs/concepts/validation.html BROKEN: Resource not found: cocoon://daisy.site.786 [java] X [0] 2.1/userdocs/text-serializer.html BROKEN: Resource not found: cocoon://daisy.site.655 [java] X [0] 2.1/userdocs/svgpng-serializer.html BROKEN: Resource not found: cocoon://daisy.site.655 [java] Total time: 20 minutes 10 seconds, Site size: 16,404,087 Site pages: 324 [java] Java Result: 1 [echo] Copying broken links file to site root. [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke
[Vote] Release plan for 2.1.9
Although we already agreed informaly on the release plan, we should do a formal vote. As I won't be able to do the release on the 31st of March, we have to delay it by one week (unless someone else volunteers to do it). So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Can't access the samples
Hi Daniel, thank you for your quick response. Daniel Fagerstrom wrote: I guess you are talking about Cocoon trunk. Yes, indeed. In the previous Ant based build system module.xml was automatically generated from gump.xml and block.properties. In the new Maven based build system, the last step of putting together the sample webapp is still missing. There is ongoing work on that however. Ah, ok. No sweat, you guys are doing a remarkable job ! Currently one need to do some manual copying to put together the samples. See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2, for details. And as there is no module.xml you will not get a start page for the samples, but need instead point directly to them. Ok. Is it reasonable to point you at these missing or not working things in the trunk at the moment ? If not, I will wait and try to give some support later on opening JIRA issues and so forth. Greetings Armin
Re: [RT] a simple release plan
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: Didn't work for me. I copied configuration files and samples as described in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114085759822501w=2 and still gets the same problem as Ben reports in the link above. I.e. that components are not inherited properly to subsitemaps. Stack trace below. Ok, you're right (of course): the hierarchy of bean factories is correctly initialized, including for example the jx generator. For some strange reason, the tree processor of a sub sitemap is creating the correct bean factory but using the root bean factory. Therefore the jx generator can't be found. What's the easiest way to debug the code? Can I easily run jetty in debug mode? I do most development in Eclipse and use the Jetty plugin (see http://marc.theaimsgroup.com/?t=11371588818r=1w=2 about setup), the Jetty plugin works fine with debugging. During development of the blocks fw I have used ServletUnit and tests at the functional level. So during most of the debugging I have started the main servlet from ServletUnit instead. The base test class can be found here http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-servlet-impl/src/test/java/org/apache/cocoon/ServletTestCase.java, and an example of using it here http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-servlet-impl/src/test/java/org/apache/cocoon/blocks/servlet/BlocksManagerTestCase.java, it will use a webapp in the same package, http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-servlet-impl/src/test/resources/org/apache/cocoon/blocks/servlet/. The testing system is quite primitive but has been very useful despite that. We could move the base class to core (and maybe even make it less primitive and combine it with the HtmlUnit tests from 2.1.x), if others are interested. /Daniel
Re: [RT] a simple release plan
On 3/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Daniel Fagerstrom wrote: Didn't work for me. I copied configuration files and samples as described in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114085759822501w=2 and still gets the same problem as Ben reports in the link above. I.e. that components are not inherited properly to subsitemaps. Stack trace below. Ok, you're right (of course): the hierarchy of bean factories is correctly initialized, including for example the jx generator. For some strange reason, the tree processor of a sub sitemap is creating the correct bean factory but using the root bean factory. Therefore the jx generator can't be found. What's the easiest way to debug the code? Can I easily run jetty in debug mode? http://tinyurl.com/s66vt Just change to suspend=n and you should be ready to go! Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [Vote] Release plan for 2.1.9
Le 21 mars 06 à 09:20, Carsten Ziegeler a écrit : ...So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens).. +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] Release plan for 2.1.9
Bertrand Delacretaz said the following on 21-03-2006 09:46: Le 21 mars 06 à 09:20, Carsten Ziegeler a écrit : ...So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens).. +1 Bye, Helma
Re: [Vote] Release plan for 2.1.9
Carsten Ziegeler wrote: Please cast your votes +1 Thanks, 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/
Re: ForrestBot build for cocoon-docs FAILED
On Tue, 2006-03-21 at 19:11 +1100, David Crossley wrote: David Crossley wrote: Bruno Dumon wrote: BTW, this time not because the zone was restarted. Not sure what the problem is though. I investigated a bit yesterday, but cannot see what is the problem. Notice that today there are less breaks than yesterday. However, looking at the cocoon-docs mailing list diffs from Daisy i cannot see any relevant changes. http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml It complains about Daisy IDs 786 and 655 which are navigation documents. Surely Forrest's Cocoon had already processed those resources. Strange. I am stumped. Ross seems busy with other stuff. Curiouser and curiouser. At the next 12-hourly run there is only one breakage and for a different ID. FYI: I've had a look at the Daisy log files, and don't see anything there. The server has also been continuously up. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Release plan for 2.1.9
On Tue, 2006-03-21 at 09:20 +0100, Carsten Ziegeler wrote: Although we already agreed informaly on the release plan, we should do a formal vote. As I won't be able to do the release on the 31st of March, we have to delay it by one week (unless someone else volunteers to do it). So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes +1 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: ForrestBot build for cocoon-docs FAILED
Bruno Dumon wrote: On Tue, 2006-03-21 at 19:11 +1100, David Crossley wrote: David Crossley wrote: Bruno Dumon wrote: BTW, this time not because the zone was restarted. Not sure what the problem is though. I investigated a bit yesterday, but cannot see what is the problem. Notice that today there are less breaks than yesterday. However, looking at the cocoon-docs mailing list diffs from Daisy i cannot see any relevant changes. http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml It complains about Daisy IDs 786 and 655 which are navigation documents. Surely Forrest's Cocoon had already processed those resources. Strange. I am stumped. Ross seems busy with other stuff. Curiouser and curiouser. At the next 12-hourly run there is only one breakage and for a different ID. FYI: I've had a look at the Daisy log files, and don't see anything there. The server has also been continuously up. I've not looked into this in any detail. I'm swamped right now. But it looks to me like there are intermittent network problems between the two zones. I've noticed this failure come and go without anyone touching our Forrestbot or the sources. Is this possible, as far as I am aware they are on the same physical machine, but separate virtual machines. Perhaps there is a time out occuring. Is there a way of increasing the timeout on files being generated from http: sources? Not a solution, but it would be a workaround. Ross
Re: [Vote] Release plan for 2.1.9
Carsten Ziegeler wrote:
Although we already agreed informaly on the release plan, we should
do a formal vote.
As I won't be able to do the release on the 31st of March, we have to
delay it by one week (unless someone else volunteers to do it).
So the proposed plan to release 2.1.9 is:
- Start code freeze on the 31st of March
- Release on the 6th of April (if nothing bad happens)
+1 (but won't spend much time for tests)
--
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: [Vote] Release plan for 2.1.9
So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: [Vote] Release plan for 2.1.9
On 21 Mar 2006, at 08:20, Carsten Ziegeler wrote: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) +1 please! Pier smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] Release plan for 2.1.9
Il giorno 21/mar/06, alle ore 09:20, Carsten Ziegeler ha scritto: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes +1 Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
Re: error handling in aggregations
Many thanks for the links Vadim !! regards Jeremy On 20 Mar 2006, at 18:01, Vadim Gritsenko wrote: Jeremy Quinn wrote: On 20 Mar 2006, at 12:41, Bruno Dumon wrote: On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote: Lets say the aggregation part that is in error, is a cocoon:// pipeline, it is possible that the called pipeline has it's own local error-handler . if this is the case, it could be interesting to see if that one exception could run that one error-handler whose output would replace the output of that one aggregation part, instead of the whole pipeline. I can imagine this would be useful. Maybe it even works if the called pipeline has an error handler with when='internal' ? I had never seen this attribute before, or find any documentation all I can find is the code ... Vote Thread: http://marc.theaimsgroup.com/?t=11107614872r=1 Change Log (since changes.html is broken): http://marc.theaimsgroup.com/?l=xml-cocoon-devm=65425228965 Samples: http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/ webapp/samples/errorhandling/ Vadim smime.p7s Description: S/MIME cryptographic signature
RE: [Vote] Release plan for 2.1.9
So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) +1 max
Re: [Vote] Release plan for 2.1.9
Carsten Ziegeler wrote: Although we already agreed informaly on the release plan, we should do a formal vote. As I won't be able to do the release on the 31st of March, we have to delay it by one week (unless someone else volunteers to do it). So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes +1 Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [Vote] Release plan for 2.1.9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 21 Mar 2006, Carsten Ziegeler wrote: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes +1 - -- 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.2 (GNU/Linux) iD8DBQFEH/cELNdJvZjjVZARAnpQAJ9JxRBkZt/lIzCSiYOGop+lwGe1aQCgiS5w tpUZ+ysKWniW5ExGmFKZJoY= =SWy2 -END PGP SIGNATURE-
Re: [Vote] Release plan for 2.1.9
On 3/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes +1 -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
RE: error handling in aggregations
Hi!
Yes, this works well. I've tested it and with 'when=external' on
'map:handle-errors', it does stop the serializer from dumping the data before
the error page. Also, 'when=internal' works wonderfully inside the aggregate!
I would be all for this change before 2.1.9 comes out. If noone objects, I'll
commit it within the hour.
max
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 19, 2006 14:33
To: dev@cocoon.apache.org
Subject: Re: error handling in aggregations
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard
name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching
name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProc
essingPipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px
20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid; border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;
border-style: solid; border-color: #336699; }span {color: #336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color:
#336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be found/ppspanSender:/
span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation :
sitecontent1//site
Then the generic error message.
If I now comment out the line parameter name=outputBufferSize
value=32768/ from the map:pipe. then I only get the
error message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if
an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its
execution. This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
There's a little bit more to it though. In case of an error the output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
which is much less then your buffer size of 32768, so normally Cocoon
should still be able to reset the output before generating the error
page.
Someone asked the exact same question a week or two ago on the users
list, at which time I had a quick look into this. The cause
is that the
ContentAggregator class, which does the aggregation, will
still generate
the endDocument event in case an exception occurs. IMO, it
should not do
this (unless it would also catch the exception). Here is the relevant
fragment:
try {
SourceUtil.parse(this.manager, part.source,
Re: Can't access the samples
Armin Ehrenfels skrev: Hi Daniel, thank you for your quick response. Daniel Fagerstrom wrote: I guess you are talking about Cocoon trunk. Yes, indeed. In the previous Ant based build system module.xml was automatically generated from gump.xml and block.properties. In the new Maven based build system, the last step of putting together the sample webapp is still missing. There is ongoing work on that however. Ah, ok. No sweat, you guys are doing a remarkable job ! Currently one need to do some manual copying to put together the samples. See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2, for details. And as there is no module.xml you will not get a start page for the samples, but need instead point directly to them. Ok. Is it reasonable to point you at these missing or not working things in the trunk at the moment ? If not, I will wait and try to give some support later on opening JIRA issues and so forth. It is always helpful to point out missing and non working things. If you test the trunk further, you will immediately see that components are not inherited properly. There is ongoing work on this, so you do not need to report that. Besides that, report everything that you find. Thanks for your interest. /Daniel
Re: Cleanup trunk directory structure
Antonio Gallardo wrote:
Reinhard Pötz wrote:
As we are at it to mavenize the missing blocks, we should also cleanup
trunk which is quite a mess. I propose following structure
cocoon/trunk
+- blocks
|+- cocoon-apples
|+- ...
+- core
|+- cocoon-core -- will finally go completly into blocks but
that needs
| more refactoring
|+- cocoon-blocks-fw
+- tools
|+- archetypes
|+- cocoon-deployer
|+- daisy-plugin
|+- sitemap-tags-2daisy
+- site
+- common (legal stuff, awards, graphics, ...)
WDOT?
+1.
Question: Why cocoon-apples? Should not be easy to use just apples?
This question was raised a couple of weeks ago and Jorg answered it, but I can't
find a pointer.
IIRC there are some reasons for it:
- naming of the artifact -- cocoon-apples-1.0.jar instead of apples-1.0.jar
- it is recommended by the M2 folks
- ... there was more, but can't remember, Jorg can you?
--
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: [Vote] Release plan for 2.1.9
Carsten Ziegeler skrev: Although we already agreed informaly on the release plan, we should do a formal vote. As I won't be able to do the release on the 31st of March, we have to delay it by one week (unless someone else volunteers to do it). So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes Carsten +1 /Daniel
Re: Cleanup trunk directory structure
Reinhard Poetz wrote: Antonio Gallardo wrote: Reinhard Pötz wrote: As we are at it to mavenize the missing blocks, we should also cleanup trunk which is quite a mess. I propose following structure cocoon/trunk +- blocks |+- cocoon-apples |+- ... +- core |+- cocoon-core -- will finally go completly into blocks but that needs | more refactoring |+- cocoon-blocks-fw +- tools |+- archetypes |+- cocoon-deployer |+- daisy-plugin |+- sitemap-tags-2daisy +- site +- common (legal stuff, awards, graphics, ...) WDOT? +1. Question: Why cocoon-apples? Should not be easy to use just apples? This question was raised a couple of weeks ago and Jorg answered it, but I can't find a pointer. IIRC there are some reasons for it: - naming of the artifact -- cocoon-apples-1.0.jar instead of apples-1.0.jar - it is recommended by the M2 folks - ... there was more, but can't remember, Jorg can you? I know, but IIRC Giacomo told the directory name is not important for jar generation since there is a directive in pom.xml to change the jar name. Looking at the current trunk the cocoon- prefix create a lot of noise. And this is why I am asking again if this is the best way we can go. ;-) WDYT? Best Regards, Antonio Gallardo.
error handling causes NPE? (was: error handling in aggregations)
Hi!
Err, guys, can it be that the sources aren't released correctly after a
ProcessingException during pipeline execution? I get the same NPE I did when I
didn't release a sitemap source correctly a while ago after I apply this patch
to 2.1.8...
Any ideas?
max
-Original Message-
From: Max Pfingsthorn
Sent: Tuesday, March 21, 2006 16:33
To: dev@cocoon.apache.org
Subject: RE: error handling in aggregations
Hi!
Yes, this works well. I've tested it and with
'when=external' on 'map:handle-errors', it does stop the
serializer from dumping the data before the error page. Also,
'when=internal' works wonderfully inside the aggregate!
I would be all for this change before 2.1.9 comes out. If
noone objects, I'll commit it within the hour.
max
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 19, 2006 14:33
To: dev@cocoon.apache.org
Subject: Re: error handling in aggregations
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest
possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml
logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard
name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching
name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProc
essingPipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not
Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px
20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid;
border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px
0px 0px;
border-style: solid; border-color: #336699; }span {color:
#336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color:
#336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be
found/ppspanSender:/
span
org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation :
sitecontent1//site
Then the generic error message.
If I now comment out the line parameter
name=outputBufferSize
value=32768/ from the map:pipe. then I only get the
error message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if
an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering
the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its
execution. This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
There's a little bit more to it though. In case of an error
the output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
which is much less then your
Re: Deployment into a monolithic Cocoon web app
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
I want to add some thoughts to Daniel's idea of writing some
Ant script for the build: trunk has been mavenized and split
up into many modules. The missing thing is some tool that
will create a web application out of a number of blocks. In
a world of real blocks that's the job of the deployer that
I wrote.
I will extend the deployer over the weekend. It probably won't
do all the things that we need, but as the interest in getting
it done is high ATM, I hope that sombody else picks up my work
and continues next week.
I worked on the deployer for monolithic Cocoon apps. I haven't
finished it yet but most of the work has already been done. If
somebody has some time over the next few days, don't hesistate
to jump in. Here some pointers to get started:
Do you mean deploying Cocoon built with Maven without the real
blocks?
No
If this is the case, how to test it, is there an « mvn
something » in some directory?
Or are you talking about cocoon-deployer-webapp-sample? This one
seems to be dealing with real blocks.
Thanks in advance for your answer,
The idea is that at packaging time, a M2 plugin scans an artifact (jar) whether
it is a Cocoon blocks if it is, some files (xconf, xlog, etc.) are extracted
into the right directory. e.g. all .xconf files go to WEB-INF/xconf.
The unit-tests are already working but I need some more time to provide a sample
based on cocoon-webapp. This will make it hopefully clearer.
--
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: error handling in aggregations
Jeremy Quinn wrote: Many thanks for the links Vadim !! You *are* welcome, you know. No need for double exclamation marks ;-P Vadim regards Jeremy On 20 Mar 2006, at 18:01, Vadim Gritsenko wrote: Jeremy Quinn wrote: On 20 Mar 2006, at 12:41, Bruno Dumon wrote: On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote: Lets say the aggregation part that is in error, is a cocoon:// pipeline, it is possible that the called pipeline has it's own local error-handler . if this is the case, it could be interesting to see if that one exception could run that one error-handler whose output would replace the output of that one aggregation part, instead of the whole pipeline. I can imagine this would be useful. Maybe it even works if the called pipeline has an error handler with when='internal' ? I had never seen this attribute before, or find any documentation all I can find is the code ... Vote Thread: http://marc.theaimsgroup.com/?t=11107614872r=1 Change Log (since changes.html is broken): http://marc.theaimsgroup.com/?l=xml-cocoon-devm=65425228965 Samples: http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/webapp/samples/errorhandling/ Vadim
[jira] Commented: (COCOON-1639) [patch] NekoHTMLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1639?page=comments#action_12371243 ] Jean-Baptiste Quenot commented on COCOON-1639: -- Hello, thank you for the updated patch. However: I was about to commit all of this when I noticed neko.properties containing URLs as property keys. The javadoc for java.util.Properties states that « The key contains all of the characters in the line starting with the first non-white space character and up to, but not including, the first unescaped '=', ':', or white space character other than a line terminator. ». Have you been able to test the settings in neko.properties successfully? If this is the case, why is the colon after http not interpreted as a key separator? Thanks in advance for your answer. [patch] NekoHTMLTransformer --- Key: COCOON-1639 URL: http://issues.apache.org/jira/browse/COCOON-1639 Project: Cocoon Type: Improvement Components: Blocks: HTML Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Andrew Stevens Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: NekoHTMLTransformer.java, NekoHTMLTransformer.java, cocoon.log, combined.diff, htmlblock.diff, neko.properties, samples.diff The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator and... hey, where's the NekoHTMLTransformer? So, just to complete the set, here's one I prepared earlier :-) I've also included an (empty) neko.properties configuration file, and updated the neko generator's setup bits to allow for setting parser features as well as properties. -- 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: [RT] a simple release plan
* Vadim Gritsenko: Carsten Ziegeler wrote: Reinhard Poetz schrieb: If a testcase gets broken *locally* by a developer, the developer should discuss the change on [EMAIL PROTECTED] and then people can decide together how to proceed. That should be the standard procedure in every development project, may it be opensource or commercial. Can we agree on these very basic rules? Some of our test cases are already broken for a long time; so it's hard to tell if for example my new changes broke something or if the test was already broken; currently I think our tests are not really used. http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b So IIUC you setup automated tests that were stopped since more than one year? I don't remember the decision to stop them. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [Vote] Release plan for 2.1.9
Carsten Ziegeler wrote: Although we already agreed informaly on the release plan, we should do a formal vote. As I won't be able to do the release on the 31st of March, we have to delay it by one week (unless someone else volunteers to do it). So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes Carsten +1 Best Regards, Antonio Gallardo
Re: [Vote] Release plan for 2.1.9
Carsten Ziegeler wrote: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) +1 Vadim
Re: Deployment into a monolithic Cocoon web app
* Reinhard Poetz: Reinhard Poetz wrote: Reinhard Poetz wrote: I want to add some thoughts to Daniel's idea of writing some Ant script for the build: trunk has been mavenized and split up into many modules. The missing thing is some tool that will create a web application out of a number of blocks. In a world of real blocks that's the job of the deployer that I wrote. I will extend the deployer over the weekend. It probably won't do all the things that we need, but as the interest in getting it done is high ATM, I hope that sombody else picks up my work and continues next week. I worked on the deployer for monolithic Cocoon apps. I haven't finished it yet but most of the work has already been done. If somebody has some time over the next few days, don't hesistate to jump in. Here some pointers to get started: Do you mean deploying Cocoon built with Maven without the real blocks? If this is the case, how to test it, is there an « mvn something » in some directory? Or are you talking about cocoon-deployer-webapp-sample? This one seems to be dealing with real blocks. Thanks in advance for your answer, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Cleanup trunk directory structure
Reinhard Pötz wrote: As we are at it to mavenize the missing blocks, we should also cleanup trunk which is quite a mess. I propose following structure cocoon/trunk +- blocks |+- cocoon-apples |+- ... +- core |+- cocoon-core -- will finally go completly into blocks but that needs | more refactoring |+- cocoon-blocks-fw +- tools |+- archetypes |+- cocoon-deployer |+- daisy-plugin |+- sitemap-tags-2daisy +- site +- common (legal stuff, awards, graphics, ...) WDOT? +1. Question: Why cocoon-apples? Should not be easy to use just apples? Best Regards, Antonio Gallardo.
Re: [Vote] Release plan for 2.1.9
Carsten Ziegeler wrote: Although we already agreed informaly on the release plan, we should do a formal vote. As I won't be able to do the release on the 31st of March, we have to delay it by one week (unless someone else volunteers to do it). So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes +1 Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: What is being suggested is not that we mirror the whole of ibiblio, we would only mirror the libraries that are currently hosted on cvs.a.o. ... You can point your pom to use the cvs.a.o directly. What do you mean here? - the dependency is not available on the central m2 repo (the number of these libs is slowly declining due to better m2 acceptance) If it is not on the central repo, it is a non-released version and questionable that anyone should depend on it. best practice #1 - the dependency is available, but has a dodgy pom making it difficult to benefit from m2 features (eg transitive dependencies). Since you will need to manually clean this up here, perhaps sending the file over to the Maven peeps is collectively a better idea. best practice #2, we will do this ofcourse. - we're using a snapshot dependency that is not hosted anywhere else (remember the central repo only allows _released_ versions) IMHO, a questionable practice. (see below) indeed it is. Remember that this mirror would become only a *temporary* solution for any dependend library that has not fully mavenized yet. Now think again; After you have done this, and decommissioned the temporary solution, you are in a position of a non-working slot in time for that source. This goes both for SNAPSHOTs (which are actively being removed from their temporary storage spaces) and temporary artifact hosts. I'll classify this as a worry about it later. We haven't even released anything so this is no time to worry about 100% reproducible builds. I just want to make the maven build to reliably work using the quickest way possible. Anything that involves send something to someone else and wait until... is just not working for us at the moment. Regards Jorg
Re: Cleanup trunk directory structure
Reinhard Poetz wrote: thanks for the hint. Where do we have our Continuum instance running? How can I get acces to it? I've created a link on the zone home page. Best way to experiment with this is to install continuum locally though. It really is just a matter of unzipping, starting, follow the initial configuration screen and adding the URL to our root pom as maven2 project. I've upgraded the instance to 1.0.3-SNAPSHOT over the weekend, it still needs a bit of work. Feel free to play around with it though, there is nothing you can break by clicking around. Regards Jorg
Re: Cleanup trunk directory structure
Antonio Gallardo wrote: I know, but IIRC Giacomo told the directory name is not important for jar generation since there is a directive in pom.xml to change the jar name. Looking at the current trunk the cocoon- prefix create a lot of noise. And this is why I am asking again if this is the best way we can go. ;-) Yes finalName/ allows you to control the artifact name. The reason why we've named these directories was that in continuum there is a mapping between the module name and the repository directory name. So if you declare in a top level module pom modules modulecocoon-apples/module /modules and scm connectionscm:svn:http://repo/trunk/connection /scm then continuum will resolve the checkout path for moduleA as http://repo/trunk/cocoon-apples. Now at the time i did not take the possibility of using finalName/ into account. Advice from the maven guys was module-name=module-location so that's what i went for. I suggest that before we decide to go for this approach, someone experiments with this layout and tests continuum and eclipse-plugin integration (they are the most picky with module poms) and reports back before we start another mass rename. Either way i'm not too bothered at all by a repo structure with noise. Maven is there to help you not having to look at the repo structure in it's totality. Regards Jorg
Re: [Vote] Release plan for 2.1.9
Carsten Ziegeler wrote: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) +1
Re: [Vote] Release plan for 2.1.9
* Carsten Ziegeler: Although we already agreed informaly on the release plan, we should do a formal vote. +0 I don't see the point of voting for such an obvious decision. Is there a rule requiring new releases to be first approved by a vote? I mean new releases should be automatic. IMHO it's not very useful to cast any vote for a maintenance release in a stable branch. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
[jira] Created: (COCOON-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: cocoon is not defined
Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError:
cocoon is not defined
---
Key: COCOON-1804
URL: http://issues.apache.org/jira/browse/COCOON-1804
Project: Cocoon
Type: Bug
Components: Blocks: Java Flow
Versions: 2.1.8
Reporter: Andrew Madu
Priority: Blocker
I have created a java flow class which does the following:
//Load in validation file
FormInstance form = new FormInstance(forms/login.xml);
My login map (snippet) is as follows:
Login.xml:
fd:validation
fd:javascript
var success = true;
var newUserReg = new Packages.test.User();
var username = widget.lookupWidget(username);
var password = widget.lookupWidget(password);
try {
var checkUserTest = newUserReg.getUser(username.value,
password.value);
if (checkUserTest != null) {
cocoon.session.setAttribute(user, checkUserTest);
success = true;
}else{
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(The password,
username combination does not exist. Please enter another one., false));
success = false;
}
} catch (e) {
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e., false));
success = false;
}
return success;
/fd:javascript
/fd:validation
I am getting an error message when the line
'cocoon.session.setAttribute(user, checkUserTest)' is hit.:
ReferenceError: cocoon is not defined
What is the issue here, can I create a session object from within form
validation/javascript in another way?
Andrew
--
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-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: cocoon is not defined
[
http://issues.apache.org/jira/browse/COCOON-1804?page=comments#action_12371268
]
Andrew Madu commented on COCOON-1804:
-
In addition to my earlier post the version of cocoon I am using is 2.1.7
Andrew
Javascript FOM_SCOPE issue when using Java as the flow engine -
ReferenceError: cocoon is not defined
---
Key: COCOON-1804
URL: http://issues.apache.org/jira/browse/COCOON-1804
Project: Cocoon
Type: Bug
Components: Blocks: Java Flow
Versions: 2.1.8
Reporter: Andrew Madu
Priority: Blocker
I have created a java flow class which does the following:
//Load in validation file
FormInstance form = new FormInstance(forms/login.xml);
My login map (snippet) is as follows:
Login.xml:
fd:validation
fd:javascript
var success = true;
var newUserReg = new Packages.test.User();
var username = widget.lookupWidget(username);
var password = widget.lookupWidget(password);
try {
var checkUserTest = newUserReg.getUser(username.value,
password.value);
if (checkUserTest != null) {
cocoon.session.setAttribute(user, checkUserTest);
success = true;
}else{
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(The password,
username combination does not exist. Please enter another one., false));
success = false;
}
} catch (e) {
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e., false));
success = false;
}
return success;
/fd:javascript
/fd:validation
I am getting an error message when the line
'cocoon.session.setAttribute(user, checkUserTest)' is hit.:
ReferenceError: cocoon is not defined
What is the issue here, can I create a session object from within form
validation/javascript in another way?
Andrew
--
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: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Pier Fumagalli wrote: On 20 Mar 2006, at 09:19, Andrew Savory wrote: Hi, Jorg Heymans wrote: If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) We (Luminas/SourceSense) are offering. Do you know what sort of requirements in terms of bandwidth and server space? We have capacity to spare, and are happy to donate it. Excuse me, but can someone refresh my memory on why we went down the Maven way? I thought it was to get rid of maintaining all those lib in our SVN, and now someone is telling me that we actually should maintain a full maven mirror, but tweaked because we don't like theirs? Pier http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110571714621160 Is something better now? I guess not. :-( /me looking for xerces-2.8.0 commons-io 1.2, et al in the maven2 repos. Best Regards, Antonio Gallardo.
[jira] Updated: (COCOON-1639) [patch] NekoHTMLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1639?page=all ] Jean-Baptiste Quenot updated COCOON-1639: - The patch applies OK, feedback received with success [patch] NekoHTMLTransformer --- Key: COCOON-1639 URL: http://issues.apache.org/jira/browse/COCOON-1639 Project: Cocoon Type: Improvement Components: Blocks: HTML Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Andrew Stevens Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: NekoHTMLTransformer.java, NekoHTMLTransformer.java, cocoon.log, combined.diff, htmlblock.diff, neko.properties, samples.diff The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator and... hey, where's the NekoHTMLTransformer? So, just to complete the set, here's one I prepared earlier :-) I've also included an (empty) neko.properties configuration file, and updated the neko generator's setup bits to allow for setting parser features as well as properties. -- 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: Cleanup trunk directory structure
Jorg Heymans wrote:
Antonio Gallardo wrote:
I know, but IIRC Giacomo told the directory name is not important for
jar generation since there is a directive in pom.xml to change the jar
name. Looking at the current trunk the cocoon- prefix create a lot of
noise. And this is why I am asking again if this is the best way we
can go. ;-)
Yes finalName/ allows you to control the artifact name.
The reason why we've named these directories was that in continuum there
is a mapping between the module name and the repository directory name.
So if you declare in a top level module pom
modules
modulecocoon-apples/module
/modules
and
scm
connectionscm:svn:http://repo/trunk/connection
/scm
then continuum will resolve the checkout path for moduleA as
http://repo/trunk/cocoon-apples.
Now at the time i did not take the possibility of using finalName/
into account. Advice from the maven guys was module-name=module-location
so that's what i went for.
I suggest that before we decide to go for this approach, someone
experiments with this layout and tests continuum and eclipse-plugin
integration (they are the most picky with module poms) and reports back
before we start another mass rename.
Either way i'm not too bothered at all by a repo structure with noise.
Maven is there to help you not having to look at the repo structure in
it's totality.
In one of my projects we had problems when artifactId and directory name were
different, now I remember.
I hesitate to change it as working against the system or recommendations can
be very frustrating and after daily using M2 for about 3 months I know that it's
best to follow every recommendation that you can get. Often when I tried
something different (e.g. not putting the Java sources into ./src/main/java but
somewhere else causes problems in some reporting plugins) I got problems.
Can somebody ask a M2 expert (IRC, [EMAIL PROTECTED], etc), if it is really save to use
the finalName/ element for JAR artifacts?
--
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: [Vote] Release plan for 2.1.9
On 21 Mar 2006, at 17:42, Jean-Baptiste Quenot wrote: * Carsten Ziegeler: Although we already agreed informaly on the release plan, we should do a formal vote. +0 I don't see the point of voting for such an obvious decision. Is there a rule requiring new releases to be first approved by a vote? I mean new releases should be automatic. IMHO it's not very useful to cast any vote for a maintenance release in a stable branch. http://cocoon.apache.org/devinfo/releasing.html Pier smime.p7s Description: S/MIME cryptographic signature
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: If SNAPSHOTs are totally unavoidable, consider putting these in the Svn alongside the source code. Inability to build from today's source in the future is a serious flaw in chosen strategy. This is exactly what we do internally. ;-) Best Regards, Antonio Gallardo. Cheers Niclas
Re: [Vote] Release plan for 2.1.9
Jean-Baptiste Quenot wrote:
* Carsten Ziegeler:
Although we already agreed informaly on the release plan, we
should do a formal vote.
+0 I don't see the point of voting for such an obvious decision.
Is there a rule requiring new releases to be first approved by a
vote? I mean new releases should be automatic. IMHO it's not
very useful to cast any vote for a maintenance release in a stable
branch.
The PMC has to vote about the actual software artifact but there is no rule that
we have to vote that we will do a release. After the many attempts to do a 2.1.9
release in the past, I think that Carsten wanted to be sure that this time
everybody is on board.
--
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: Cleanup trunk directory structure
Reinhard Poetz wrote: Jorg Heymans wrote: Antonio Gallardo wrote: I know, but IIRC Giacomo told the directory name is not important for jar generation since there is a directive in pom.xml to change the jar name. Looking at the current trunk the cocoon- prefix create a lot of noise. And this is why I am asking again if this is the best way we can go. ;-) Yes finalName/ allows you to control the artifact name. The reason why we've named these directories was that in continuum there is a mapping between the module name and the repository directory name. So if you declare in a top level module pom modules modulecocoon-apples/module /modules and scm connectionscm:svn:http://repo/trunk/connection /scm then continuum will resolve the checkout path for moduleA as http://repo/trunk/cocoon-apples. Now at the time i did not take the possibility of using finalName/ into account. Advice from the maven guys was module-name=module-location so that's what i went for. I suggest that before we decide to go for this approach, someone experiments with this layout and tests continuum and eclipse-plugin integration (they are the most picky with module poms) and reports back before we start another mass rename. Either way i'm not too bothered at all by a repo structure with noise. Maven is there to help you not having to look at the repo structure in it's totality. In one of my projects we had problems when artifactId and directory name were different, now I remember. I hesitate to change it as working against the system or recommendations can be very frustrating and after daily using M2 for about 3 months I know that it's best to follow every recommendation that you can get. Often when I tried something different (e.g. not putting the Java sources into ./src/main/java but somewhere else causes problems in some reporting plugins) I got problems. Can somebody ask a M2 expert (IRC, [EMAIL PROTECTED], etc), if it is really save to use the finalName/ element for JAR artifacts? Not necesary. Please keep the current hierachy with the cocoon- prefix. We have a lot of others things to do, hence keep moving. Later we can get back and improve this issue if we found it necesary at all. ;-) Best Regards, Antonio Gallardo.
[jira] Commented: (COCOON-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: cocoon is not defined
[
http://issues.apache.org/jira/browse/COCOON-1804?page=comments#action_12371271
]
Reinhard Poetz commented on COCOON-1804:
I had the same problem when I used cForms together with Apples. The problem is
that there is no Cocoon object unless you use Flowscript. As a workaround I
implemented the javascript validator as a Java class within the controller
IIRC. This should work for Javaflow too.
Javascript FOM_SCOPE issue when using Java as the flow engine -
ReferenceError: cocoon is not defined
---
Key: COCOON-1804
URL: http://issues.apache.org/jira/browse/COCOON-1804
Project: Cocoon
Type: Bug
Components: Blocks: Java Flow
Versions: 2.1.8
Reporter: Andrew Madu
Priority: Blocker
I have created a java flow class which does the following:
//Load in validation file
FormInstance form = new FormInstance(forms/login.xml);
My login map (snippet) is as follows:
Login.xml:
fd:validation
fd:javascript
var success = true;
var newUserReg = new Packages.test.User();
var username = widget.lookupWidget(username);
var password = widget.lookupWidget(password);
try {
var checkUserTest = newUserReg.getUser(username.value,
password.value);
if (checkUserTest != null) {
cocoon.session.setAttribute(user, checkUserTest);
success = true;
}else{
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(The password,
username combination does not exist. Please enter another one., false));
success = false;
}
} catch (e) {
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e., false));
success = false;
}
return success;
/fd:javascript
/fd:validation
I am getting an error message when the line
'cocoon.session.setAttribute(user, checkUserTest)' is hit.:
ReferenceError: cocoon is not defined
What is the issue here, can I create a session object from within form
validation/javascript in another way?
Andrew
--
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-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: cocoon is not defined
[
http://issues.apache.org/jira/browse/COCOON-1804?page=comments#action_12371273
]
Andrew Madu commented on COCOON-1804:
-
Reinhard,
how do I implement the javascript validator as a Java class within the
controller IIRC? Can you point me in the direction of any code?
Andrew
Javascript FOM_SCOPE issue when using Java as the flow engine -
ReferenceError: cocoon is not defined
---
Key: COCOON-1804
URL: http://issues.apache.org/jira/browse/COCOON-1804
Project: Cocoon
Type: Bug
Components: Blocks: Java Flow
Versions: 2.1.8
Reporter: Andrew Madu
Priority: Blocker
I have created a java flow class which does the following:
//Load in validation file
FormInstance form = new FormInstance(forms/login.xml);
My login map (snippet) is as follows:
Login.xml:
fd:validation
fd:javascript
var success = true;
var newUserReg = new Packages.test.User();
var username = widget.lookupWidget(username);
var password = widget.lookupWidget(password);
try {
var checkUserTest = newUserReg.getUser(username.value,
password.value);
if (checkUserTest != null) {
cocoon.session.setAttribute(user, checkUserTest);
success = true;
}else{
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(The password,
username combination does not exist. Please enter another one., false));
success = false;
}
} catch (e) {
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e., false));
success = false;
}
return success;
/fd:javascript
/fd:validation
I am getting an error message when the line
'cocoon.session.setAttribute(user, checkUserTest)' is hit.:
ReferenceError: cocoon is not defined
What is the issue here, can I create a session object from within form
validation/javascript in another way?
Andrew
--
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] Release plan for 2.1.9
* Pier Fumagalli: On 21 Mar 2006, at 17:42, Jean-Baptiste Quenot wrote: * Carsten Ziegeler: Although we already agreed informaly on the release plan, we should do a formal vote. +0 I don't see the point of voting for such an obvious decision. Is there a rule requiring new releases to be first approved by a vote? I mean new releases should be automatic. IMHO it's not very useful to cast any vote for a maintenance release in a stable branch. http://cocoon.apache.org/devinfo/releasing.html This document states that we have to vote once the new version is tagged, to be sure that there is no showstopper. So we are not applying the rule, right? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [Vote] Release plan for 2.1.9
* Reinhard Poetz: The PMC has to vote about the actual software artifact but there is no rule that we have to vote that we will do a release. After the many attempts to do a 2.1.9 release in the past, I think that Carsten wanted to be sure that this time everybody is on board. Just to be clear: I think Carsten is doing a valuable work as release manager. It's just that I feel this vote useless, I mean just go ahead. We might vote once the release is tagged. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [Vote] Release plan for 2.1.9
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
The PMC has to vote about the actual software artifact but there
is no rule that we have to vote that we will do a release. After
the many attempts to do a 2.1.9 release in the past, I think
that Carsten wanted to be sure that this time everybody is on
board.
Just to be clear: I think Carsten is doing a valuable work as
release manager. It's just that I feel this vote useless, I mean
just go ahead. We might vote once the release is tagged.
Then the PMC *has to* vote.
--
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
Voting on releases? (was: [Vote] Release plan for 2.1.9)
Le 21 mars 06 à 18:42, Jean-Baptiste Quenot a écrit : ...Is there a rule requiring new releases to be first approved by a vote?... Maybe not, but we've been doing it this way for about 25 years and it works ;-) Seriously, making sure we agree on release plans (code freeze dates etc.) is a Good Thing - I've seen several projects arguing or disagreeing on releases, so it's certainly good to be a bit careful and to make sure everyone is on the same page. It doesn't cost much and there are at least social benefits. So, +1 for voting on release plans ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (COCOON-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: cocoon is not defined
[
http://issues.apache.org/jira/browse/COCOON-1804?page=comments#action_12371283
]
Reinhard Poetz commented on COCOON-1804:
http://cocoon.apache.org/2.1/userdocs/widgetconcepts/validation.html should help
Javascript FOM_SCOPE issue when using Java as the flow engine -
ReferenceError: cocoon is not defined
---
Key: COCOON-1804
URL: http://issues.apache.org/jira/browse/COCOON-1804
Project: Cocoon
Type: Bug
Components: Blocks: Java Flow
Versions: 2.1.8
Reporter: Andrew Madu
Priority: Blocker
I have created a java flow class which does the following:
//Load in validation file
FormInstance form = new FormInstance(forms/login.xml);
My login map (snippet) is as follows:
Login.xml:
fd:validation
fd:javascript
var success = true;
var newUserReg = new Packages.test.User();
var username = widget.lookupWidget(username);
var password = widget.lookupWidget(password);
try {
var checkUserTest = newUserReg.getUser(username.value,
password.value);
if (checkUserTest != null) {
cocoon.session.setAttribute(user, checkUserTest);
success = true;
}else{
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(The password,
username combination does not exist. Please enter another one., false));
success = false;
}
} catch (e) {
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e., false));
success = false;
}
return success;
/fd:javascript
/fd:validation
I am getting an error message when the line
'cocoon.session.setAttribute(user, checkUserTest)' is hit.:
ReferenceError: cocoon is not defined
What is the issue here, can I create a session object from within form
validation/javascript in another way?
Andrew
--
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: Voting on releases?
Bertrand Delacretaz wrote: Le 21 mars 06 à 18:42, Jean-Baptiste Quenot a écrit : ...Is there a rule requiring new releases to be first approved by a vote?... Maybe not, but we've been doing it this way for about 25 years and it works ;-) Seriously, making sure we agree on release plans (code freeze dates etc.) is a Good Thing - I've seen several projects arguing or disagreeing on releases, so it's certainly good to be a bit careful and to make sure everyone is on the same page. It doesn't cost much and there are at least social benefits. So, +1 for voting on release plans ;-) A release is the primary output of a PMC on behalf of the ASF. You could say that producing releases is what a project exists for. So releases _can not_ be done without a vote, with PMC member's votes being the binding ones. And probably new releases, once done, should be noted to the board in a quarterly board report. There you go. That's the Bureaucracy of it. Regards, Upayavira
Re: Voting on releases?
Upayavira wrote: Bertrand Delacretaz wrote: Le 21 mars 06 à 18:42, Jean-Baptiste Quenot a écrit : ...Is there a rule requiring new releases to be first approved by a vote?... Maybe not, but we've been doing it this way for about 25 years and it works ;-) Seriously, making sure we agree on release plans (code freeze dates etc.) is a Good Thing - I've seen several projects arguing or disagreeing on releases, so it's certainly good to be a bit careful and to make sure everyone is on the same page. It doesn't cost much and there are at least social benefits. So, +1 for voting on release plans ;-) A release is the primary output of a PMC on behalf of the ASF. You could say that producing releases is what a project exists for. So releases _can not_ be done without a vote, with PMC member's votes being the binding ones. And probably new releases, once done, should be noted to the board in a quarterly board report. There you go. That's the Bureaucracy of it. Or in another way, requesting for a formal approval pings all committers. Maybe we oversaw an important issue and the vote will ring the bell for the person knowing that something is still missing. Also, doing the whole releasing process just to be stopped be an issue is a wasted effort after all. For this reason, the release manager (Carsten) prefers to do a formal vote before before starting the whole releasing process. I think it is a good practice. :-) Best Regards, Antonio Gallardo. Regards, Upayavira
Re: Voting on releases?
Bertrand Delacretaz wrote: Le 21 mars 06 à 18:42, Jean-Baptiste Quenot a écrit : ...Is there a rule requiring new releases to be first approved by a vote?... Maybe not, but we've been doing it this way for about 25 years and it works ;-) Seriously, making sure we agree on release plans (code freeze dates etc.) is a Good Thing - I've seen several projects arguing or disagreeing on releases, so it's certainly good to be a bit careful and to make sure everyone is on the same page. It doesn't cost much and there are at least social benefits. So, +1 for voting on release plans ;-) +0.5 :-P Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [Vote] Release plan for 2.1.9
On 21.03.2006 09:20, Carsten Ziegeler wrote: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) +1 Jörg
[jira] Commented: (COCOON-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: cocoon is not defined
[
http://issues.apache.org/jira/browse/COCOON-1804?page=comments#action_12371298
]
Simone Gianni commented on COCOON-1804:
---
Andrew, a validator is simply a java class, so you can create your own
validators writing a java class implementing
o.a.c.forms.validation.WidgetValidator . Once you have the class, you have to
write also another class implementing WidgetValidatorBuilder which acts as a
factory creating instances of your validator class, and register this builder
in cocoon.xconf so that cocoon forms can load, configure and use it thru the
avalon framework.
But Reinhard, AFAIK this does not solve (at least not directly) the problem of
accessing the session from inside this validator, if not with some
context/objectmodel static classes.
Could you tell us how to retrieve the current session (request, object model..
) from inside a java widget validator (so, eventually, translating it to
javascript it could be usable also inside the javascript validator)?
Javascript FOM_SCOPE issue when using Java as the flow engine -
ReferenceError: cocoon is not defined
---
Key: COCOON-1804
URL: http://issues.apache.org/jira/browse/COCOON-1804
Project: Cocoon
Type: Bug
Components: Blocks: Java Flow
Versions: 2.1.8
Reporter: Andrew Madu
Priority: Blocker
I have created a java flow class which does the following:
//Load in validation file
FormInstance form = new FormInstance(forms/login.xml);
My login map (snippet) is as follows:
Login.xml:
fd:validation
fd:javascript
var success = true;
var newUserReg = new Packages.test.User();
var username = widget.lookupWidget(username);
var password = widget.lookupWidget(password);
try {
var checkUserTest = newUserReg.getUser(username.value,
password.value);
if (checkUserTest != null) {
cocoon.session.setAttribute(user, checkUserTest);
success = true;
}else{
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(The password,
username combination does not exist. Please enter another one., false));
success = false;
}
} catch (e) {
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e., false));
success = false;
}
return success;
/fd:javascript
/fd:validation
I am getting an error message when the line
'cocoon.session.setAttribute(user, checkUserTest)' is hit.:
ReferenceError: cocoon is not defined
What is the issue here, can I create a session object from within form
validation/javascript in another way?
Andrew
--
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] Release plan for 2.1.9
Carsten Ziegeler wrote: Although we already agreed informaly on the release plan, we should do a formal vote. As I won't be able to do the release on the 31st of March, we have to delay it by one week (unless someone else volunteers to do it). So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes Carsten +1. Hopefully nothing bad will happen. Ralph
Re: Cleanup trunk directory structure
Antonio Gallardo wrote: Reinhard Poetz wrote: Jorg Heymans wrote: Antonio Gallardo wrote: I know, but IIRC Giacomo told the directory name is not important for jar generation since there is a directive in pom.xml to change the jar name. Looking at the current trunk the cocoon- prefix create a lot of noise. And this is why I am asking again if this is the best way we can go. ;-) Yes finalName/ allows you to control the artifact name. The reason why we've named these directories was that in continuum there is a mapping between the module name and the repository directory name. So if you declare in a top level module pom modules modulecocoon-apples/module /modules and scm connectionscm:svn:http://repo/trunk/connection /scm then continuum will resolve the checkout path for moduleA as http://repo/trunk/cocoon-apples. Now at the time i did not take the possibility of using finalName/ into account. Advice from the maven guys was module-name=module-location so that's what i went for. I suggest that before we decide to go for this approach, someone experiments with this layout and tests continuum and eclipse-plugin integration (they are the most picky with module poms) and reports back before we start another mass rename. Either way i'm not too bothered at all by a repo structure with noise. Maven is there to help you not having to look at the repo structure in it's totality. In one of my projects we had problems when artifactId and directory name were different, now I remember. I hesitate to change it as working against the system or recommendations can be very frustrating and after daily using M2 for about 3 months I know that it's best to follow every recommendation that you can get. Often when I tried something different (e.g. not putting the Java sources into ./src/main/java but somewhere else causes problems in some reporting plugins) I got problems. Can somebody ask a M2 expert (IRC, [EMAIL PROTECTED], etc), if it is really save to use the finalName/ element for JAR artifacts? Not necesary. Please keep the current hierachy with the cocoon- prefix. We have a lot of others things to do, hence keep moving. Later we can get back and improve this issue if we found it necesary at all. ;-) The reply seems to be no clear: I meant your suggested cleanup dir structure enhancement is ok. I am +1 for the change. :-) Best Regards, Antonio Gallardo.
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 22 March 12:22 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2006-03-22 12:02:10 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Fri Feb 24 09:07:16 GMT+00:00 2006 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Sat Feb 11 08:07:06 GMT+00:00 2006 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [echo] Looking in local plugins src... [echo] Unable to find plugin src in main plugins src dir. [echo] Looking in local whiteboard plugins src... [copy] Copying 24 files to /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [copy] Copied 10 empty directories to 1 empty directory under /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy final-check: fetchplugin: unpack-plugin: install-plugin: configure-plugin: configure-input-plugin: [echo] Mounting input plugin: org.apache.forrest.plugin.input.Daisy [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/input.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/input.xmap.new [xslt] Loading stylesheet
Re: [Vote] Release plan for 2.1.9
Carsten Ziegeler wrote: Although we already agreed informaly on the release plan, we should do a formal vote. As I won't be able to do the release on the 31st of March, we have to delay it by one week (unless someone else volunteers to do it). So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes +1 -David
[jira] Created: (COCOON-1805) [Link] Fingerprint Demo
[Link] Fingerprint Demo --- Key: COCOON-1805 URL: http://issues.apache.org/jira/browse/COCOON-1805 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8 Reporter: johnson hsu URL: http://www.erp.tw/cocoon/shb/portal/portal Title: Fingerprint authority in cocoon Cocoon version used: 2.1.8 Short summary of your site: A web site build by cocoon 2.1.8 portal with english chinese french japanese How can we verify this site is actually built with Cocoon? with the source of html html xmlns:i18n=http://apache.org/cocoon/i18n/2.1; How much time did it take to build the site from design to publication? one month. How many people were involved in the project? 2 What other information do you want to disclose (e.g. how does it work, how did you build it, what parts of Cocoon did you use)? there're two function in this demo site, using Fingerprint(U.are.U 4000) to be portal login and to be checking in/out for a group. contact: [EMAIL PROTECTED] -- 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: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On Wednesday 22 March 2006 01:00, Jorg Heymans wrote: Niclas Hedhman wrote: What is being suggested is not that we mirror the whole of ibiblio, we would only mirror the libraries that are currently hosted on cvs.a.o. ... You can point your pom to use the cvs.a.o directly. What do you mean here? You said; libraries that are currently hosted on cvs.a.o, meaning they exist on cvs.a.o, and can't you just tell Maven in your pom to use that repository as well?? Join the [EMAIL PROTECTED] mailing for discussion and more info. IIUIC, the http://cvs.apache.org/maven-snapshot-repository is meant for making snapshots available cross-ASF projects. I still maintain that checking in the libs to SVN are much more comfortable than a dependency on a temporary server. Cheers Niclas
Re: Voting on releases? (was: [Vote] Release plan for 2.1.9)
Bertrand Delacretaz wrote: Jean-Baptiste Quenot a ?crit : ...Is there a rule requiring new releases to be first approved by a vote?... Maybe not, but we've been doing it this way for about 25 years and it works ;-) I think that there is a requirement for PMCs to vote on all releases. Cocoon doesn't yet have its project guidelines, but other PMC guidelines are definite. Most say majority approval is required. Seriously, making sure we agree on release plans (code freeze dates etc.) is a Good Thing - I've seen several projects arguing or disagreeing on releases, so it's certainly good to be a bit careful and to make sure everyone is on the same page. It doesn't cost much and there are at least social benefits. So, +1 for voting on release plans ;-) +1, i agree that we should vote on the release plan as well. -David
[jira] Commented: (COCOON-1639) [patch] NekoHTMLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1639?page=comments#action_12371373 ] Andrew Stevens commented on COCOON-1639: I've no idea about the properties, I just copied it from the existing code in the generator. The only change I made was to differentiate between feature and property settings and call setFeature or setProperty as appropriate. If what you say is correct, then the generator has been broken for some time now... There's no open issues with the Neko generator, but I suppose that doesn't necessarily mean there isn't a problem. I'll take a look at it tomorrow if I have time; at worst it just needs the colons to be escaped. Or maybe we should ask the original author about it - I believe from the SVN logs that was upayavira? [patch] NekoHTMLTransformer --- Key: COCOON-1639 URL: http://issues.apache.org/jira/browse/COCOON-1639 Project: Cocoon Type: Improvement Components: Blocks: HTML Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Andrew Stevens Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: NekoHTMLTransformer.java, NekoHTMLTransformer.java, cocoon.log, combined.diff, htmlblock.diff, neko.properties, samples.diff The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator and... hey, where's the NekoHTMLTransformer? So, just to complete the set, here's one I prepared earlier :-) I've also included an (empty) neko.properties configuration file, and updated the neko generator's setup bits to allow for setting parser features as well as properties. -- 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: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: You said; libraries that are currently hosted on cvs.a.o, meaning they exist on cvs.a.o, and can't you just tell Maven in your pom to use that repository as well?? From what I can see the build is set up to do that. The builds fail because apparently that repository can't handle the load. That is why we need a mirrored server. Cheers Niclas
Re: Voting on releases?
My 2 cents. The paragraph below my signature is from http://www.apache.org/foundation/voting.html. I don't see anything here that indicates exactly when the vote should be taken. Common sense might tell you that you should only vote after the package has been built and tested. As long as I've been here votes seem to be taken to build the package and lazy consensus is used to approve the package - i.e. the formal release is delayed only if errors occur during testing. Our assumption is that you are frequently building and testing the current SVN so the formal release package shouldn't be a whole lot different. It would be rather pointless for the release manager to build a package and then start a vote only to then be told that a bunch of stuff needs to be fixed. Ralph Votes on Package Releases Votes on whether a package is ready to be released follow a format similar to majority approval http://www.apache.org/foundation/glossary.html#MajorityApproval -- except that the decision is officially determined solely by whether at least three +1 votes were registered. *Releases may not be vetoed.* Generally the community will table the vote to release if anyone identifies serious problems, but in most cases the ultimate decision, once three or more positive votes have been garnered, lies with the individual serving as release manager. The specifics of the process may vary from project to project, but the 'minimum of three +1 votes' rule is universal. David Crossley wrote: I think that there is a requirement for PMCs to vote on all releases. Cocoon doesn't yet have its project guidelines, but other PMC guidelines are definite. Most say majority approval is required. Seriously, making sure we agree on release plans (code freeze dates etc.) is a Good Thing - I've seen several projects arguing or disagreeing on releases, so it's certainly good to be a bit careful and to make sure everyone is on the same page. It doesn't cost much and there are at least social benefits. So, +1 for voting on release plans ;-) +1, i agree that we should vote on the release plan as well. -David
[jira] Commented: (COCOON-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: cocoon is not defined
[
http://issues.apache.org/jira/browse/COCOON-1804?page=comments#action_12371381
]
Andrew Madu commented on COCOON-1804:
-
Simone,could you point me in the direction of any exiting class code examples
for implementing both o.a.c.forms.validation.WidgetValidator,
WidgetValidatorBuilder,registering the builder with cocoon.xconf and final
usage of, my defined, WidgetValidator from within cforms?
Javascript FOM_SCOPE issue when using Java as the flow engine -
ReferenceError: cocoon is not defined
---
Key: COCOON-1804
URL: http://issues.apache.org/jira/browse/COCOON-1804
Project: Cocoon
Type: Bug
Components: Blocks: Java Flow
Versions: 2.1.8
Reporter: Andrew Madu
Priority: Blocker
I have created a java flow class which does the following:
//Load in validation file
FormInstance form = new FormInstance(forms/login.xml);
My login map (snippet) is as follows:
Login.xml:
fd:validation
fd:javascript
var success = true;
var newUserReg = new Packages.test.User();
var username = widget.lookupWidget(username);
var password = widget.lookupWidget(password);
try {
var checkUserTest = newUserReg.getUser(username.value,
password.value);
if (checkUserTest != null) {
cocoon.session.setAttribute(user, checkUserTest);
success = true;
}else{
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(The password,
username combination does not exist. Please enter another one., false));
success = false;
}
} catch (e) {
username.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
password.setValidationError(new
Packages.org.apache.cocoon.forms.validation.ValidationError(e., false));
success = false;
}
return success;
/fd:javascript
/fd:validation
I am getting an error message when the line
'cocoon.session.setAttribute(user, checkUserTest)' is hit.:
ReferenceError: cocoon is not defined
What is the issue here, can I create a session object from within form
validation/javascript in another way?
Andrew
--
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: Voting on releases?
Antonio Gallardo schrieb: Upayavira wrote: Bertrand Delacretaz wrote: Le 21 mars 06 à 18:42, Jean-Baptiste Quenot a écrit : ...Is there a rule requiring new releases to be first approved by a vote?... Maybe not, but we've been doing it this way for about 25 years and it works ;-) Seriously, making sure we agree on release plans (code freeze dates etc.) is a Good Thing - I've seen several projects arguing or disagreeing on releases, so it's certainly good to be a bit careful and to make sure everyone is on the same page. It doesn't cost much and there are at least social benefits. So, +1 for voting on release plans ;-) A release is the primary output of a PMC on behalf of the ASF. You could say that producing releases is what a project exists for. So releases _can not_ be done without a vote, with PMC member's votes being the binding ones. And probably new releases, once done, should be noted to the board in a quarterly board report. There you go. That's the Bureaucracy of it. Or in another way, requesting for a formal approval pings all committers. Maybe we oversaw an important issue and the vote will ring the bell for the person knowing that something is still missing. Also, doing the whole releasing process just to be stopped be an issue is a wasted effort after all. For this reason, the release manager (Carsten) prefers to do a formal vote before before starting the whole releasing process. I think it is a good practice. :-) Exactly, these are imho the important points for the pre release vote. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Voting on releases?
Ralph Goers wrote: My 2 cents. The paragraph below my signature is from http://www.apache.org/foundation/voting.html. I don't see anything here that indicates exactly when the vote should be taken. Common sense might tell you that you should only vote after the package has been built and tested. As long as I've been here votes seem to be taken to build the package and lazy consensus is used to approve the package - i.e. the formal release is delayed only if errors occur during testing. Our assumption is that you are frequently building and testing the current SVN so the formal release package shouldn't be a whole lot different. It would be rather pointless for the release manager to build a package and then start a vote only to then be told that a bunch of stuff needs to be fixed. Right :) Actually, we are performing two votes for a release: first one to set the release date. This gives every committer the chance to be on board for this release and makes sure that preparing the release is not a waste of time. Then the second vote will happen for the actual release - usually I start the vote one day before the release day and people vote then if the current revision will be the release. This ensures that the real vote is actually about the real release (code). And these votes do not take that much time for us committers; it's just kind of a ping and hopefully reveals who's supporting the release :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
