Problem:
flow.js of blockA
--
function blockAFunc() {
return helper();
}
function helper() {
return A;
}
flow.js of blockB
-
function blockBFunc() {
return helper();
}
function helper() {
return B;
}
flow.js of blockC
-
function blockCFunc()
Automated Cocoon Unit tests failed!
Full log file if this unit test run is available here:
http://nagoya.apache.org/~vadim/cocoon-test-log-20050111.log
Last messages from the log file:
==
[foreach] reader-mime-type.xml:39
Torsten Curdt wrote:
Problem:
flow.js of blockA
--
function blockAFunc() {
return helper();
}
function helper() {
return A;
}
flow.js of blockB
-
function blockBFunc() {
return helper();
}
function helper() {
return B;
}
flow.js of blockC
-
that's the goal. But with imports in map:flow/ you will get into
trouble:
map:flow
map:script src=block:blockA/flow.js/
map:script src=block:blockB/flow.js/
map:script src=flow.js/
/map:flow
In this case print(blockBFunc()); will return A.
k ...then I did understand correctly.
the
Hi,
I am trying to build the released version of cocoon 2.1.6 from SVN but I
am not able to find the exact revision number.
On CVS there used to be symbolic names like RELEASE_2_1_5_1 or
RELEASE_2_1 so you could go back and build it. So build.sh was creating
a build/cocoon-2.1.5.1 directory
Torsten Curdt wrote:
that's the goal. But with imports in map:flow/ you will get into
trouble:
map:flow
map:script src=block:blockA/flow.js/
map:script src=block:blockB/flow.js/
map:script src=flow.js/
/map:flow
In this case print(blockBFunc()); will return A.
k ...then I did understand
Juan Jose Pablos wrote:
Hi,
I am trying to build the released version of cocoon 2.1.6 from SVN but
I am not able to find the exact revision number.
On CVS there used to be symbolic names like RELEASE_2_1_5_1 or
RELEASE_2_1 so you could go back and build it. So build.sh was
creating a
ok ...what version of javascript does
rhino implement? I could not find that
information...
http://www.mozilla.org/rhino/overview.html
(in trunk we use Rhino 1.6pre1)
bummer ...must have missed that one
ok ...so 1.5 it is
cheers
--
Torsten
On Mar, 11 de Enero de 2005, 4:07, Reinhard Poetz dijo:
http://www.mozilla.org/rhino/overview.html
(in trunk we use Rhino 1.6pre1)
Nope, we are using rhino 1.6R1:
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/lib/core/rhino-1.6R1.jar?rev=123652view=log
Anyway it is javascript 1.5.
Best
On Jan 11, 2005, at 3:57 AM, Torsten Curdt wrote:
k ...then I did understand correctly.
the callFunction proposal got me
a bit off the track ;)
I seem to be good at that. Since it was not something that I seriously
support, I will refrain from explaining. ;P
Glen Ezkovich
HardBop Consulting
glen
I am getting the same problem, but with :
BUILD FAILED
/Users/jerm/Development/Checkouts/Apache/Cocoon/trunk/tools/targets/
docs-build.xml:55: Sitemap component
org.apache.cocoon.generation.NekoHTMLGenerator does not implement a
sitemap component interface.
This was after a ./build.sh clean
Mark Lundquist wrote:
Thanks, Vadim! See below...
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Anyway, I'll wait a bit, and if nobody tells me I have my head
up my b*tt
I'll bugilla it. The bug, that is -- not my head (or my b*tt!)
Probably you are invoking this pipeline from a flowscript or
Jeremy Quinn wrote:
I am getting the same problem, but with :
BUILD FAILED
/Users/jerm/Development/Checkouts/Apache/Cocoon/trunk/tools/targets/
docs-build.xml:55: Sitemap component
org.apache.cocoon.generation.NekoHTMLGenerator does not implement a
sitemap component interface.
I may be at
Reinhard Poetz wrote:
Answer: It depends on the order of declaring your scripts in
map:flow/. The first helper() method declared will be found.
But there is only one helper() method per block!?
Yes. Therefore we need something more sohpisticated than imports.
I'm having a hard time following
I really hate to say anything about this but ...
On Jan 11, 2005, at 8:57 AM, Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Answer: It depends on the order of declaring your scripts in
map:flow/. The first helper() method declared will be found.
But there is only one helper() method per block!?
odd that this is breaking in different places for everyone. Do you
all have different sets of blocks enabled?
If not, I'm suspicious of out of memory error or something odd like
that. In that case, any chance that the docs build tasks could mask
some odd condition like that with such an error?
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Answer: It depends on the order of declaring your scripts in
map:flow/. The first helper() method declared will be found.
But there is only one helper() method per block!?
Yes. Therefore we need something more sohpisticated than imports.
I'm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33050.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Tue, 11 Jan 2005 15:47:30 +0100
Sylvain Wallez [EMAIL PROTECTED] wrote:
I had a quick look at the CocoonBean and associated classes, and it
turns out that precompile-only has been violently deleted when XSP was
moved to its own block.
Was it on purpose or just because of lazyness ? I
Simon Mieth wrote:
On Tue, 11 Jan 2005 15:47:30 +0100
Sylvain Wallez [EMAIL PROTECTED] wrote:
I had a quick look at the CocoonBean and associated classes, and it
turns out that precompile-only has been violently deleted when XSP was moved to its own block.
Was it on purpose or just because of
I have tried repeatedly to get the latest in svn to build but continue to
get the following:
Collecting sitemap components info
Listing all sitemap components to build/all-sitemap-components.txt
Generating documentation
Writing:
Hi:
Workaround: disable doc generation in local.build.properties.
Posible cause:
AFAIK, recently David is in process to integrate a new forrest version in
Cocoon and this could be the problem cause. ;-)
Best Regards,
Antonio Gallardo.
On Mar, 11 de Enero de 2005, 15:48, Ralph Goers dijo:
I
Antonio Gallardo wrote:
Workaround: disable doc generation in local.build.properties.
Posible cause:
AFAIK, recently David is in process to integrate a new forrest version in
Cocoon and this could be the problem cause. ;-)
No, not that. In fact, Forrest is now completely separated from the
Is this stuff working??? I built the latest and the portal looks
horrible. Is something not configured?
Ralph
[EMAIL PROTECTED] said:
Author: cziegeler
Date: Thu Jan 6 08:02:24 2005
New Revision: 124397
URL: http://svn.apache.org/viewcvs?view=revrev=124397
Log:
Add initial skin
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33004.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
1) If the problem has existed for ages why haven't I ever seen it before?
2) The Php block is disabled by default.
3) I don't see anything remarkable about PhpGenerator.java, but then I
have no idea what the qdox parser is trying to do to it. It is dying on
the end of file.
4) Telling folks that
Geoff Howard wrote:
odd that this is breaking in different places for everyone. Do you
all have different sets of blocks enabled?
I have all blocks enabled.
If not, I'm suspicious of out of memory error or something odd like
that. In that case, any chance that the docs build tasks could
On Mar, 11 de Enero de 2005, 17:35, Ralph Goers dijo:
1) If the problem has existed for ages why haven't I ever seen it before?
2) The Php block is disabled by default.
3) I don't see anything remarkable about PhpGenerator.java, but then I
have no idea what the qdox parser is trying to do to
David Crossley wrote:
Geoff Howard wrote:
odd that this is breaking in different places for everyone. Do you
all have different sets of blocks enabled?
I have all blocks enabled.
Mine is an unmodified checkout of SVN head.
Ross
--
No virus found in this outgoing message.
Checked by AVG
Antonio Gallardo wrote:
Ralph Goers dijo:
1) If the problem has existed for ages why haven't I ever seen it before?
The issue has been masked. See below.
2) The Php block is disabled by default.
3) I don't see anything remarkable about PhpGenerator.java, but then I
have no idea what the
On Mar, 11 de Enero de 2005, 10:55, Geoff Howard dijo:
odd that this is breaking in different places for everyone. Do you
all have different sets of blocks enabled?
Seems like have to do with diferent blocks enabled ;-)
In my case (a full build):
BUILD FAILED
Antonio Gallardo wrote:
The lastest changes of docs-build.xml (SVN 124702):
http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=110523951602586w=2
from:
sitemap-components docDir=${build.context}/xdocs/userdocs
source=${java}/
to:
sitemap-components
On Mar, 11 de Enero de 2005, 23:35, David Crossley dijo:
It is being done as part of the documentation effort.
http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html
It is not the cause, it just enables to bug to manifest.
OK.
Can you post where the problem is showed to you trying a full
Antonio Gallardo wrote:
David Crossley dijo:
It is not the cause, it just enables to bug to manifest.
OK.
Can you post where the problem is showed to you trying a full build? I am
trying to get an idea if the problem is truly random or just because users
have diferent blocks
On Mar, 11 de Enero de 2005, 23:57, David Crossley dijo:
I showed that a few messages ago in this thread.
Both Ross and i are doing a full build, javadocs and all,
with no blocks disabled. It breaks in different places
for each of us.
Then the problem is somewhere in the Ant task:
Ralph Goers wrote:
David Crossley wrote:
I showed that a few messages ago in this thread.
Both Ross and i are doing a full build, javadocs and all,
with no blocks disabled. It breaks in different places
for each of us.
Does it fail for you in BRANCH_2_1_X (before you disabled it) in the
On Mie, 12 de Enero de 2005, 1:27, David Crossley dijo:
Ralph Goers wrote:
David Crossley wrote:
I showed that a few messages ago in this thread.
Both Ross and i are doing a full build, javadocs and all,
with no blocks disabled. It breaks in different places
for each of us.
Does it fail
Hi Daniel:
In gump.xml there is:
depend project=cocoon-block-conversion/
What this means?
Can you review the changes Daniel? The trunk is broken.
Best Regards,
Antonio Gallardo
38 matches
Mail list logo
