Hi Antonio,
It is fixed in the CVS.
Confirmed - thanks very much!
If you update jars, it would be good to test related stuff before and
after your changes, to make sure nothing weird happens.
-Bertrand
Antonio Gallardo wrote:
Do you agree with JSDK 1.4 as the lower Java version supported in Cocoon 2.2?
Here is my +1
-0.5
Even though 1.4 is available for most platforms, and I've been using it
exclusively for quite a long time, I still think there are many
environments where people are forced
It has been nice reading this month's SDMagazine.
On page 28, with *big* letters, it states: HERE BE PROFESSIONALS. Below it, a three
page article on Cocoon with a 4 out of 5 star rating. A big thank you from the author,
Rick Wayne, to the Cocoon community. Wow!
Arjé
Hippo
Le Dimanche, 29 fév 2004, à 18:53 Europe/Zurich, Carsten Ziegeler a
écrit :
As far as I know (from my weak memory :) ) there hasn't been a vote
at Cocoon about accepting this block...
Sorry, last I told the lenya-dev guys that IMO a vote was not needed to
create a new block in Cocoon (but I
Ugo Cei wrote:
Antonio Gallardo wrote:
Do you agree with JSDK 1.4 as the lower Java version supported in Cocoon 2.2?
Here is my +1
-0.5
Even though 1.4 is available for most platforms, and I've been using it
exclusively for quite a long time, I still think there are many
Hi,
I am new to cocoon internals and I really need some starting points at
least - please help.
I am making a kind of web-service(not standard) that works as a part of
corporate portal - provides dynamic content. Unfortunately most of the
things are out of my control - I can't get normal
It has been nice reading this month's SDMagazine.
On page 28, with *big* letters, it states: HERE BE
PROFESSIONALS. Below it, a three page article on Cocoon with a 4
out of 5 star rating. A big thank you from the author, Rick
Wayne, to the Cocoon community. Wow!
The article is online too:
Gregor, thanks!
Arje
the lenya community has developed a lightweight workflow
that we thought
would make more sense as a cocoon block, especially given
that other cms
built on cocoon have shown interest in using it (hi arje
:). i split out
the generic part and made it into a
Bertrand Delacretaz wrote:
Seeing how hard it is to retrofit tests and docs to existing
blocks, maybe we should require the following for any new
non-scratchpad block:
-samples
-automated tests
-documentation (in the block itself, I don't think our docs
structure makes it easy to
Carsten Ziegeler wrote:
As far as I know (from my weak memory :) ) there hasn't been a vote
at Cocoon about accepting this block.
you are right, there wasnt. in the thread on lenya-dev it was opined
that this would not be necessary.
So, can you please enlighten us (or only me?) about the use of
You're right, I'm also guilty of creating a few blocks without formally
asking.
Seeing how hard it is to retrofit tests and docs to existing blocks,
maybe we should require the following for any new non-scratchpad block:
-samples
-automated tests
-documentation (in the block itself, I don't
Thanks for the answer, Gregor.
Some comments inline:
Gregor J. Rothfuss wrote:
when we started this functionality, there was no workflow
engine around that specifically targeted the sane and common
80% of the requirements.
so we wrote our own :) recently, some cocooners showed
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Hartmann
Sent: Monday, March 01, 2004 10:41 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: workflow block commited
Currently there isn't really someone against this donation here at
Cocoon.
Jorg Heymans wrote:
I agree with this for core blocks.
Will there be a different central repository then for the
more exotic blocks that don't offer core functionality? Your
community rule might hold people back from creating blocks
for the fun of it.
Example: i've been thinking about
Andreas Hartmann wrote:
Gregor J. Rothfuss wrote:
hi,
the lenya community has developed a lightweight workflow that we
thought would make more sense as a cocoon block, especially
given that
other cms built on cocoon have shown interest in using it
(hi arje :).
i split out
Carsten Ziegeler wrote:
[...]
BTW, I think we should remove the o.a.l.xml sources and
instead add a lenya.jar library including this code.
You mean adding a lenya.jar to Cocoon? If so, I'm -1 on this
as I don't want circular dependencies!
Yes, this sounds reasonable. So we have to remove
the
Carsten Ziegeler wrote:
[...]
Currently there isn't really someone against this donation here at
Cocoon. Although the people that support it are very silent...
Anyways, as I just said, please ask the next time on the Cocoon list
before you submit a new block. Thanks.
OK.
If this block stays at
Le Lundi, 1 mars 2004, à 10:43 Europe/Zurich, Jorg Heymans a écrit :
...There was a discussion a few months ago about the need for a
blocks.cocoondev.org alike site, maybe this is relevant again now? By
default you would allow all blocks into an incubation phase and do a
vote on the ones to
Bertrand Delacretaz wrote:
I don't think it would be very hard to make the blocks system
more configurable, so that external blocks would need only an
XML descriptor to be integrated at compile-time. But someone
has to do it.
I always thought about simply adding all blocks that are in
Bertrand Delacretaz wrote:
[...]
Seeing how hard it is to retrofit tests and docs to existing blocks,
maybe we should require the following for any new non-scratchpad block:
-samples
-automated tests
-documentation (in the block itself, I don't think our docs structure
makes it easy to
Jorg Heymans wrote:
Example: i've been thinking about creating a text-to-speech block just
for the learning experience. Unlikely that more than 3 committers need
this, so where will it end up if i want to donate it?
I am no committer - but I might be interested in such a thing ;-)
Cheers,
Le Lundi, 1 mars 2004, à 11:13 Europe/Zurich, Andreas Hartmann a écrit :
Bertrand Delacretaz wrote:
[...]
Seeing how hard it is to retrofit tests and docs to existing blocks,
maybe we should require the following for any new non-scratchpad
block:
-samples
-automated tests
-documentation (in
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
I don't think it would be very hard to make the blocks system
more configurable, so that external blocks would need only an
XML descriptor to be integrated at compile-time. But someone
has to do it.
I always thought about simply
Great! :-DD
Best Regards,
Antonio Gallardo
Leo Sutic dijo:
The following Avalon packages have been released:
avalon-fortress-container-1.1
avalon-fortress-tools-1.1
excalibur-component-1.2
excalibur-event-1.1
excalibur-logger-1.1
excalibur-sourceresolve-1.1
Hi:
I think it is a good idea to talk about the protocol to add new blocks,
but currently there is no an avalanche or an invasion of new blocks. :-(
As suggested the solution can be that every block can have his own
build.xml and just integrate it by extending a main build.xml. I am not
sure if
Ok, it might be stupid to announce a GPL-software which uses
Apache-software in a apache-mailinglist. It is changed now.
Best Regards,
Simon
http://www.mieth-xml.de/openproject/cligui
Hi cocoon developers,
1st - Thank you for making cocoon. Cocoon is good stuff, but I guess you
know that already. ;)
2nd - I've been using cocoon in a little project for a search page
(returns multilingual results), however found some limitation while
using the CInclude transformer. I've posted a
Each block is more or a less a separate (sub) project. So there
definitly needs to be a community around it before it should end
up in our CVS. We failed at this point in the past. Take a
look at some blocks we have, there are quiet a lot that don't
have a community. So we should start considering
Arje Cahn wrote:
It has been nice reading this month's SDMagazine.
On page 28, with *big* letters, it states: HERE BE PROFESSIONALS. Below it, a three page article on Cocoon with a 4 out of 5 star rating. A big thank you from the author, Rick Wayne, to the Cocoon community. Wow!
Nice.
Just one
Jorg Heymans wrote:
You're right, I'm also guilty of creating a few blocks without
formally asking.
Seeing how hard it is to retrofit tests and docs to existing blocks,
maybe we should require the following for any new non-scratchpad block:
-samples
-automated tests
-documentation (in the
Reinhard Poetz wrote:
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
Reinhard Poetz wrote:
After using Cocoon for years I still think we are not very clear in
telling our users what is the right tool for their needs. Of course
this depends on their use cases and their skills.
I see three
On 29 Feb 2004, at 14:55, Carsten Ziegeler wrote:
Yes :) - No of course not, we can change everything back again.
It's the old problem (this is no offense against you, Vadim),
only a few people are interested in this
topic. It's been days since Dims informed us that we don't have
all licenses!
Just one of curiosity. What is the missing star for?
I'm afraid it's the following part:
...it's greatest strength is also it's greatest drawback: the
expressive power of XSL. That functional programming language comes
easily to neither procedurally trained programmers ('What do you mean, I
Bertrand Delacretaz wrote:
Le Mercredi, 25 fév 2004, à 16:49 Europe/Zurich, Daniel Fagerstrom a
écrit :
snip-plenty-of-good-stuff/
...But in many cases using SAX based XML as in pipelines is not enough
we need a data structure i.e. DOM. This leads to flowscript components
that reads some
Ralph Goers wrote:
It may not matter much, but I'd prefer to see examples of this without flow.
With flow you could just degenerate into a map:call for input and a map:call
for output, or perhaps a map:call that does both?
Take a look at my answer to Bertrands post. In that example you coul
Le Lundi, 1 mars 2004, à 15:48 Europe/Zurich, Daniel Fagerstrom a écrit
:
...I meant something a little bit more explicit:
map:generate type=request/
map:transform src=prepare-query-for-user-preferences/
map:transform type=sql/
map:store type=xml dest=xmodule:request-attr:foo/
map:call
Steven Noels wrote:
On 25 Feb 2004, at 22:53, Daniel Fagerstrom wrote:
CForms should use typed DOM as form model
---
I also believe that making CForms use typed XML as data storage is
important. This obviously require some changes, among other things the
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-03-01 13:37]:
Reinhard Poetz wrote:
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
Reinhard Poetz wrote:
I think it is a fairly complete picture.
So we need:
* SQL queries (inbeded in XML) - XML, this is handled by ESQL and
Geoff Howard [EMAIL PROTECTED] WRITES:
snip/
Two questions.
1. Is eventcache stable enough for me to use or will it be
undergoing
radical changes?
That's a good question. It's still marked alpha/stable/whatever but
that is more by inaction than purposeful decision (at least on my
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-03-01 14:54]:
Bertrand Delacretaz wrote:
Le Mercredi, 25 f?v 2004, ? 16:49 Europe/Zurich, Daniel Fagerstrom a
?crit :
snip-plenty-of-good-stuff/
...But in many cases using SAX based XML as in pipelines is not enough
we need a data structure
* Ralph Goers [EMAIL PROTECTED] [2004-02-25 18:18]:
Just trying to understand from a practical point of view, does this
mean something like
map:generate type=request/
map:transform src=prepare-query-for-user-preferences/
map:transform type=sql/
map:call function=myFlow() dom-input=domIn/
Steve Krulewitz [EMAIL PROTECTED] writes:
I agree that more sophisticated input handing would make general web
applications much easier to write in Cocoon... here are some
more random
thoughts on the subject:
Input can come from many sources:
- http query string
- http post stream
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27165.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I agree with this. As I said before, you can create an action (for example,
InputPipelineAction) which calls a pipeline to process and validate the
input. The end result could be something like what the FormValidatorAction
does, except the InputPiplelineAction would let you do whatever you want
* Hunsberger, Peter [EMAIL PROTECTED] [2004-03-01 16:17]:
Steve Krulewitz [EMAIL PROTECTED] writes:
1) in the flowscript the varible output has the complete contents of
this pipeline in it, it can be folded back into any handling you want
via flowscript variable passing (eg, as an XSLT
Antonio Gallardo [EMAIL PROTECTED] asks:
Do you agree with JSDK 1.4 as the lower Java version
supported in Cocoon 2.2?
Yes, please: +1
Carsten Ziegeler [EMAIL PROTECTED] writes:
Currently there isn't really someone against this donation
here at Cocoon. Although the people that support it are very
silent... Anyways, as I just said, please ask the next time
on the Cocoon list before you submit a new block. Thanks.
We'd
* Hunsberger, Peter [EMAIL PROTECTED] [2004-03-01 16:57]:
Antonio Gallardo [EMAIL PROTECTED] asks:
Do you agree with JSDK 1.4 as the lower Java version
supported in Cocoon 2.2?
Yes, please: +1
Does this mean we can use 1.4 regex in the sitemap?
--
Alan / [EMAIL PROTECTED] /
David Crossley wrote:
Ugo Cei wrote:
Antonio Gallardo wrote:
Do you agree with JSDK 1.4 as the lower Java version supported in Cocoon 2.2?
Here is my +1
-0.5
Even though 1.4 is available for most platforms, and I've been using it
exclusively for quite a long time, I still think
hi andy
it seems that xerces 2.6.2 removed ObjectFactory which broke nekopull if
i understand the exception correctly.
http://cvs.apache.org/viewcvs.cgi/xml-xerces/java/src/org/apache/xerces/util/Attic/ObjectFactory.java
i have posted a bug report with a stack trace at
Unico Hommes wrote:
I think that as a software product that is known for its innovative
nature it is *very* important in the interest of Cocoon to refuse being
impaired by the immobility of bureaucracratic organisations. We are
having a small crisis on our hands ATM regarding our persistent
Hunsberger, Peter wrote:
So, bottom line, I don't think Cocoon needs any new sitemap constructs
to do what is being discussed, unless what is needed is a way to do this
without flow? However, trying to do this without flow seems to me to
mean going back to regular actions, so I can't see any
Currently there isn't really someone against this donation
here at Cocoon. Although the people that support it are very
silent... Anyways, as I just said, please ask the next time
on the Cocoon list before you submit a new block. Thanks.
We'd be interested in taking a look at it.
Alan wrote:
* Hunsberger, Peter [EMAIL PROTECTED] [2004-03-01 16:17]:
Steve Krulewitz [EMAIL PROTECTED] writes:
1) in the flowscript the varible output has the complete contents of
this pipeline in it, it can be folded back into any handling you want
via flowscript variable passing (eg, as an
Ugo Cei wrote:
Unico Hommes wrote:
I think that as a software product that is known for its innovative
nature it is *very* important in the interest of Cocoon to refuse
being impaired by the immobility of bureaucracratic organisations. We
are having a small crisis on our hands ATM regarding
Arje Cahn wrote:
I'm interested in a workflow block as well. We currently have experience using OpenSymphony Workflow and would like to share this on the Cocoon list.
Please do. I'm really interested in that, I don't quite get what all
this workflow fuss is about, so it would be good to know
On Mon, 2004-03-01 at 16:09, Daniel Fagerstrom wrote:
Steven Noels wrote:
On 25 Feb 2004, at 22:53, Daniel Fagerstrom wrote:
CForms should use typed DOM as form model
---
I also believe that making CForms use typed XML as data storage is
Ugo Cei [EMAIL PROTECTED] asks:
Unico Hommes wrote:
I think that as a software product that is known for its innovative
nature it is *very* important in the interest of Cocoon to
refuse being
impaired by the immobility of bureaucracratic organisations. We are
having a small crisis
Stefano Mazzocchi [EMAIL PROTECTED] write:
Ugo Cei wrote:
Unico Hommes wrote:
I think that as a software product that is known for its innovative
nature it is *very* important in the interest of Cocoon to refuse
being impaired by the immobility of bureaucracratic
organisations.
On Mon, 2004-03-01 at 04:41, Antonio Gallardo wrote:
Hi:
Many was talked about this topic. I think it not need a large explanation:
The idea is to set JSDK 1.4 as the minimum supported JDK supported for the
next major release 2.2 of Cocoon. Currently we are supporting also 1.3 but
seems
* Stefano Mazzocchi [EMAIL PROTECTED] [2004-03-01 18:32]:
Alan wrote:
* Hunsberger, Peter [EMAIL PROTECTED] [2004-03-01 16:17]:
So, bottom line, I don't think Cocoon needs any new sitemap constructs
to do what is being discussed, unless what is needed is a way to do this
without flow?
On 26.02.2004 22:04, Alan wrote:
I would guess that Momento mainly would be accessed through the document
function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
transformerand the URLs in the document functions are resolved by using
an implementation of
Alan [EMAIL PROTECTED] writes:
snip/
Look, nobody prevents you from doing this already today:
StreamGenerator - ValidateTransformer - StoreTransformer -
but then what happens if the validation is not complete? how to you
manage that? what is the logic?
As I said, the logic of a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27147.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
* Joerg Heinicke [EMAIL PROTECTED] [2004-03-01 19:59]:
On 26.02.2004 22:04, Alan wrote:
I would guess that Momento mainly would be accessed through the document
function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
transformerand the URLs in the document functions are
On 01.03.2004 00:24, Antonio Gallardo wrote:
I was hit by that a few days ago on a different project, and it's an
endorsed problem, due to a wrong Xerces version. Now, don't ask me how
to fix that in eclipse, but if you can make ant use Cocoon's xerces you
should be fine.
This is a very weird
On 01.03.2004 19:37, Stefano Mazzocchi wrote:
I think that as a software product that is known for its innovative
nature it is *very* important in the interest of Cocoon to refuse
being impaired by the immobility of bureaucracratic organisations. We
are having a small crisis on our hands ATM
On 01.03.2004 12:28, Torsten Curdt wrote:
1) We more or less quietly dropped the scratchpad concept.
Everyone prefers to create a block because it's more pluggable.
Maybe we should emphasize the scratchpad's existence a bit more
again? ...or maybe have a block-scratchpad area instead of
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
But if someone provides a really useful 1.4 thing
like the mentioned NIO-based implementation of the persistent store
I'm for 1.4 of course.
I'm more of a user than a developer of Cocoon, but I'd say that
if someone can provide a reasonable
On 01.03.2004 07:02, Stefano Mazzocchi wrote:
What about just adding an element for licence location to jars.xml?
e.g.,
Gump descriptors now contain license information and gump is checking it
for you. I think we should use that.
I think gump would be a cool tool if we would use it correctly
Stefano Mazzocchi wrote:
Ugo Cei wrote:
Since we don't have a NIO-based implementation of the persistent
store, yet, why upgrade now? When we have it, I'll be more than
willing to vote +1.
Ugo,
this is chicken-egg problem: nobody is going to implement something on
1.4-only API if they
* Alan [EMAIL PROTECTED] [2004-03-01 20:36]:
* Joerg Heinicke [EMAIL PROTECTED] [2004-03-01 19:59]:
On 26.02.2004 22:04, Alan wrote:
I would guess that Momento mainly would be accessed through the document
function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
On 01.03.2004 23:36, Alan wrote:
I would guess that Momento mainly would be accessed through the document
function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
transformerand the URLs in the document functions are resolved by using
an implementation of
* Joerg Heinicke [EMAIL PROTECTED] [2004-03-01 22:48]:
On 01.03.2004 23:36, Alan wrote:
I would guess that Momento mainly would be accessed through the
document function in XSLT and XQuery. Saxon use JAXP 1.1 as external
API to the transformerand the URLs in the document functions are
David Crossley wrote:
Joerg Heinicke wrote:
Joerg Heinicke wrote:
I might be wrong but today I had the feeling that Eclipse just ignores
the default -kkv set in Eclipse itself and adds every file with unknown
file ending as binary. You maybe have to add your file endings at
Ugo Cei wrote:
Antonio Gallardo wrote:
Do you agree with JSDK 1.4 as the lower Java version supported in
Cocoon 2.2?
Here is my +1
-0.5
Even though 1.4 is available for most platforms, and I've been using
it exclusively for quite a long time, I still think there are many
environments
Hunsberger, Peter wrote:
Geoff Howard [EMAIL PROTECTED] WRITES:
snip/
Two questions.
1. Is eventcache stable enough for me to use or will it be
undergoing
radical changes?
That's a good question. It's still marked alpha/stable/whatever but
that is more by inaction than
Alan dijo:
* Hunsberger, Peter [EMAIL PROTECTED] [2004-03-01 16:57]:
Antonio Gallardo [EMAIL PROTECTED] asks:
Do you agree with JSDK 1.4 as the lower Java version
supported in Cocoon 2.2?
Yes, please: +1
Does this mean we can use 1.4 regex in the sitemap?
Hi Alan:
Yes. This is the
Joerg Heinicke wrote:
On 26.02.2004 22:04, Alan wrote:
I would guess that Momento mainly would be accessed through the
document function in XSLT and XQuery. Saxon use JAXP 1.1 as external
API to the transformerand the URLs in the document functions are
resolved by using an implementation of
Joerg Heinicke wrote:
On 01.03.2004 07:02, Stefano Mazzocchi wrote:
What about just adding an element for licence location to jars.xml?
e.g.,
Gump descriptors now contain license information and gump is checking
it for you. I think we should use that.
I think gump would be a cool tool if
Ugo Cei wrote:
Stefano Mazzocchi wrote:
Ugo Cei wrote:
Since we don't have a NIO-based implementation of the persistent
store, yet, why upgrade now? When we have it, I'll be more than
willing to vote +1.
Ugo,
this is chicken-egg problem: nobody is going to implement something on
1.4-only
* Stefano Mazzocchi [EMAIL PROTECTED] [2004-03-02 03:01]:
Joerg Heinicke wrote:
On 26.02.2004 22:04, Alan wrote:
I would guess that Momento mainly would be accessed through the
document function in XSLT and XQuery. Saxon use JAXP 1.1 as external
API to the transformerand the URLs in the
Hi:
Try to send any of these forms:
http://localhost:/samples/woody/form2xml.flow
http://localhost:/samples/woody/form2bean.flow
They don't show any error, but does not finish the processing (read the
instructions of the sample). I think there is still a bug.
Best Regards,
Antonio
Title: JCS Based Cache
Hi Guys,
I've seen quite a lot of talk about replacing the default persistent store with something other than JISP. I think this is a sound idea - I'm coming up against the various bugs everyone knows about with Jisp 2.51, and I understand the issues related to the
Corin Moss dijo:
Hi Guys,
I've seen quite a lot of talk about replacing the default persistent
store with something other than JISP. I think this is a sound idea -
I'm coming up against the various bugs everyone knows about with Jisp
2.51, and I understand the issues related to the JISP
Corin,
...Someone mentioned JCS as a good solution - and it strikes me as
being fairly simple to extend the JCS AbstractDiskCache
(http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/auxiliary/
disk/AbstractDiskCache.html.) I hope to start work on this in the
short term - today or
Hiya,
Thanks for the feedback - I'll get to work on this now. I guess conceptually this
really belongs within the Avalon-Excalibur-store framework, as it will sit along side
AbstractJispFilesystemStore rather than on top of it.
Do you agree, or do you feel that this should be implemented
-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 3:39 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: cocoon-2.1/src/blocks/html/lib
jtidy-04aug2000r7-dev.jar.license
Can we use a more standard extension? ie: .txt:
Le Mardi, 2 mars 2004, à 08:16 Europe/Zurich, Corin Moss a écrit :
... I guess conceptually this really belongs within the
Avalon-Excalibur-store framework, as it will sit along side
AbstractJispFilesystemStore rather than on top of it...
Makes sense but I don't think it prevents you from
Corin Moss wrote:
Hiya,
Thanks for the feedback - I'll get to work on this now.
Great!
I
guess conceptually this really belongs within the
Avalon-Excalibur-store framework, as it will sit along side
AbstractJispFilesystemStore rather than on top of it.
Yes, conceptually it should
Gregor J. Rothfuss dijo:
the lenya community has developed a lightweight workflow that we
thought would make more sense as a cocoon block, especially
given that
other cms built on cocoon have shown interest in using it
I see the following minimum todo list from the Cocoon POV:
- Use the
You have a good point there - I'm simply going to have to replace the
DefaultPersistentStore at my end (for testing only of course ;)
One thing that has occurred to me whilst hammering the JISP based store, and looking
at the code in a bit more depth, is that all of the perceived problems come
The following Avalon packages have been released:
avalon-fortress-container-1.1
avalon-fortress-tools-1.1
excalibur-component-1.2
excalibur-event-1.1
excalibur-logger-1.1
excalibur-sourceresolve-1.1
excalibur-store-1.0
excalibur-xmlutil-1.0
/LS
Woohoo
Thanks Leo for this great effort!
Carsten
-Original Message-
From: Leo Sutic [mailto:[EMAIL PROTECTED]
Sent: Monday, March 01, 2004 11:37 AM
To: 'Avalon Developers List'; [EMAIL PROTECTED]
Subject: [Avalon][PMC] Release!
The following Avalon packages have been
94 matches
Mail list logo
