Niclas Hedhman wrote:
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations
are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and SourceResolver, Store,
XML
Niclas Hedhman wrote:
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and SourceResolver, Store, XML
utils,
SNIP/
I agree with most points from Stefano and we see it each time we do
Cocoon training that it's very hard for new users to start with Cocoon.
Imho that's a main difference between Cocoon and other projects: with
other projects it's very easy to start, but you might get stuck later on
in
Sorry Stefano, but I feel that you are somewhat biased. :-) I'm not
saying unit tests are the solution to all evil, and I certainly
understand that within the *current* Cocoon environment unit tests
might not help much. But this is because the current codebase isn't
test-friendly, so that it
Torsten Curdt wrote:
I think there is another explanation why there
are so little changes: We are way more concerned
about the stability of contracts. ...even for trunk!
Quite a few people now have live installations
and seem to go for the na, don't change it!
it ain't really broken. This seems
As someone who's walked into a cocoon project over the last few weeks,
I don't have a problem with the usage pattern as such (sitemap.xconf,
flowscripts, cforms etc). Most of the problems I've had have been to
do with some of the crack-induced choices made by other parties (I
wont go into
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=33603.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
IMO our huge community problem is what is most important. No, I'm
certainly not talking about our excelent existing community, I'm
talking about the fact that we only elected two new committers during
2004, compare that to around ten during
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-template has an issue affecting its community integration.
This
Hello,
It's bug (or limitation) in stylesheet caching. Make an entry in
Bugzilla,
http://issues.apache.org/bugzilla/show_bug.cgi?id=33603
and avoid using cocoon: urls in xsl:include. Alternatively,
you can try adding host into the cocoon: url itself:
xsl:stylesheet version=1.0
Torsten Curdt wrote:
Yepp ...yepp ...yepp
Guys, maybe we should get together
more often. I found this always
very helpful...
I'm up for it. And ask for some corporate sponsorship for those in far
and distant lands. A two day hackathon somewhere in Europe. I like the idea.
Regards, Upayavira
On Wednesday 16 February 2005 15:41, Reinhard Poetz wrote:
Niclas Hedhman wrote:
Why not use SVN's more exotic features of external linking, and plainly
include the Excalibur codebase (source that is) as part of Cocoon? You
all have commit access to it, and it is not likely that the
Upayavira wrote:
Torsten Curdt wrote:
Yepp ...yepp ...yepp
Guys, maybe we should get together
more often. I found this always
very helpful...
I'm up for it. And ask for some corporate sponsorship for those in far
and distant lands. A two day hackathon somewhere in Europe. I like the
idea.
If
Il giorno 16/feb/05, alle 13:01, Carsten Ziegeler ha scritto:
If we can't do it earlier, we could use the ApacheCon in Stuttgart
this year. We could meet the days before or after the conference, so
this would reduce travel costs.
+1
Ugo
--
Ugo Cei - http://agylen.com/blojsom/blog/
Niclas Hedhman wrote:
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and SourceResolver, Store, XML
utils,
Bart Molenkamp wrote:
Niclas Hedhman wrote:
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations
are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and
Reinhard Poetz wrote:
Why not use SVN's more exotic features of external linking, and
plainly include the Excalibur codebase (source that is) as part of
Cocoon? You all have commit access to it, and it is not likely that
the Excalibur community will make any big changes in the future, and
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 16, 2005 3:14 PM
To: dev@cocoon.apache.org
Subject: Re: [RT] How scripting made me hate java
Big -1
Not knowing where the code is is bad, having to versions that claim to
be the
One of the big challenges is to configure Cocoon when the same
application is used in different environments. For example when each
developer uses his own database.
With 2.2 things get easier: first, the big cocoon.xconf is split into
various little parts that can be handled more easily. But that
It seems that we all agree more or less on moving the blocks out of the
core, so which directory structure do we want to use in svn?
We recently had this suggestion:
/cocoon/trunk
/cocoon/blocks/core/
/cocoon/blocks/supported/
/cocoon/blocks/unsupported/
And then under core, supported,
Carsten Ziegeler wrote:
It seems that we all agree more or less on moving the blocks out of the
core, so which directory structure do we want to use in svn?
We recently had this suggestion:
/cocoon/trunk
/cocoon/blocks/core/
/cocoon/blocks/supported/
/cocoon/blocks/unsupported/
And then under
On Mar, 15 de Febrero de 2005, 3:58, Sylvain Wallez dijo:
Stefano Mazzocchi wrote:
latest checkout from 2.2, turn allow-reload true in web.xml and when
I hit a page with 'cocoon-reload=true' I get an IllegalStateException:
The cocoon-ehcache-4 Cache is not alive.
which goes away as soon
On Mar, 15 de Febrero de 2005, 4:26, Michael Wechner dijo:
Stefano Mazzocchi wrote:
latest checkout from 2.2, turn allow-reload true in web.xml and when
I hit a page with 'cocoon-reload=true' I get an IllegalStateException:
The cocoon-ehcache-4 Cache is not alive.
which goes away as soon
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=24391.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Antonio Gallardo wrote:
So far none of us has found a solution, except by suggesting to replace
the ehcache by something else
What else? JCS? AFAIK, 2.1.5 was shipped with JCS.
we are using https://whirlycache.dev.java.net/ in our cocoon project,
with good results.
--
Gregor J. Rothfuss
COO,
On Mie, 16 de Febrero de 2005, 12:51, Gregor J. Rothfuss dijo:
Antonio Gallardo wrote:
So far none of us has found a solution, except by suggesting to replace
the ehcache by something else
What else? JCS? AFAIK, 2.1.5 was shipped with JCS.
we are using https://whirlycache.dev.java.net/ in
Would it be worth considering adding either 'legacy' or 'deprecated' to
contain blocks that are going to disappear at some unspecified point in
the future (or maybe s/unsupported/deprecated/)? I'm just suggesting
that 'unsupported' may not be strongly worded enough for new users who
start
Antonio Gallardo wrote:
I wonder why every cache middleware claim to be the faster one. ;-)
one of the main things is a feature-performance tradeoff. less features
often means better performance.
from what i can tell, cocoon does not need all the advanced features of
some of these caches
--
This makes me a little uncomfortable. So blocks will now have a release
schedule that is independent from core? I'm just wondering if that is a
good thing or a bad thing at this time. And if that is so, why isn't
each block on its own release? (That is just rhetorical, as I don't
believe we
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
And then under core, supported, unsupported, come the different blocks
with a trunk, tags, releases directory each, right?
yes, e.g.
/cocoon/blocks/core/forms/trunk/ . the current forms block
/cocoon/blocks/core/forms/branches/
Ralph Goers wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
And then under core, supported, unsupported, come the different blocks
with a trunk, tags, releases directory each, right?
yes, e.g.
/cocoon/blocks/core/forms/trunk/ . the current forms block
On Mie, 16 de Febrero de 2005, 13:26, Gregor J. Rothfuss dijo:
Antonio Gallardo wrote:
I wonder why every cache middleware claim to be the faster one. ;-)
one of the main things is a feature-performance tradeoff. less features
often means better performance.
Agreed.
from what i can tell,
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy to
use deployment tool) it should be the goal to have independant blocks
with their own release cycles.
But I thought the proposal is to move blocks
Gianugo Rabellino wrote:
On Wed, 16 Feb 2005 11:42:06 -0800, Ralph Goers
[EMAIL PROTECTED] wrote:
Carsten Ziegeler wrote:
a) Use of properties in all xconf files. If you write ${my.property}
then this is replaced during loading of the xconf with the actual
value of the property. - for
Ralph Goers wrote:
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy to
use deployment tool) it should be the goal to have independant blocks
with their own release cycles.
But I thought the
Antonio Gallardo wrote:
Have you tried to run cocoon in tomcat and jetty using the same cache?
This is one of the problems I found using the current ehcache.
i'll give it a try sometime.
--
Gregor J. Rothfuss
COO, Wyona Content Management Solutionshttp://wyona.com
Apache Lenya
Reinhard Poetz wrote:
Ralph Goers wrote:
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy
to use deployment tool) it should be the goal to have independant
blocks with their own release cycles.
But
The problem with cocoon.xconf is that it is part of the war file.
This
makes it very difficult for our operations folks to change it since it
will get over-ridden each time the app is redeployed.
Doesn't have to be. The location of the .xconf is specified in web.xml
(now, if you ask me,
Gianugo Rabellino wrote:
The problem with cocoon.xconf is that it is part of the war file.
This
makes it very difficult for our operations folks to change it since it
will get over-ridden each time the app is redeployed.
Doesn't have to be. The location of the .xconf is specified in
This may be way off course, but have you thought about a Cocoon in
Squeak? That perhaps Java won't ever be able to give you the rapid
development experience (with easy manipulation of the core engine--the
damn virtual machine, if you're crazy) you're looking for?
Alan Kay came to this
Ralph Goers wrote:
Gianugo Rabellino wrote:
The problem with cocoon.xconf is that it is part of the war file. This
makes it very difficult for our operations folks to change it since it
will get over-ridden each time the app is redeployed.
Doesn't have to be. The location of the .xconf is
41 matches
Mail list logo
