Il giorno 30/ott/04, alle 02:32, Mark Lundquist ha scritto:
I just built a fresh Cocoon from SVN, and then followed the
instructions on http://new.cocoondev.org/main/g1/43 for building the
Spring + Hibernate stuff. I get compile errors that look like the
build is not seeing the jars in
Giacomo Pati wrote:
And eliminating ALL spawing of new Threads in the code will
eventually allow us to be more J2EE spec conformant (I do
know of prominent J2EE app servers Cocoon isn't able to run
in just because of spawning own sub threads).
Yepp.
I think this is on of our core
Hi all,
Maybe it's an avalon issue and maybe I should post it to user
list, but I think it may be a problem with ECM which is deprecated in
avalon (or excalibur) and used by cocoon.
I developed and declared two components CompA and CompB in
cocoon.xconf. Both are Serviceable and in the
On 28 Oct 2004, at 16:04, Torsten Curdt wrote:
Folks please cast your votes for:
[ X ] Leszek
[ X ] Ralph
as Apache Cocoon committers.
My belated +1
Well done guys, and Welcome !!!
regards Jeremy
If email from this address
Giacomo Pati wrote:
I suppose in the trunk only (not in 2.1) or did you strip off
ALL event package references?
I didn't change anything in 2.1 - but I guess that the event package
is only used in the continuations manager in 2.1 as well. if that is
the case, change 2.1 as well and we are
On Sat, 30 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
I suppose in the trunk only (not in 2.1) or did you strip off
ALL event package references?
I didn't change anything in 2.1 - but I guess that the event package
is only used in the continuations manager in 2.1 as well. if that is
the
Reinhard wrote:
...
Stefano and others, What do you think, should I
continue with the new block build system?
You are doing the work, the work is well done, what can I say... go
ahead :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier [1].
In order to do so I have extended the gump descriptor with additional
information that allows the build system to locate one or more
dependency jars per depend project
Il giorno 30/ott/04, alle 10:00, Ugo Cei ha scritto:
I will test it again and update the docs ASAP. Thanks for letting me
know.
Done.
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
Ugo Cei wrote:
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier [1].
In order to do so I have extended the gump descriptor with additional
information that allows the build system to locate one or more
dependency jars per
On Oct 30, 2004, at 6:17 AM, Giacomo Pati wrote:
On Sat, 30 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
I suppose in the trunk only (not in 2.1) or did you strip off
ALL event package references?
I didn't change anything in 2.1 - but I guess that the event package
is only used in the
Vadim, Thank you for your advice!
But, don't you think if the circular-dependency is supported in
component container, we can avoid this problem downright? And the
implementation is not quite difficult. Simply put some signal to tell
the container not to create an already created component which
On Sat, 30 Oct 2004, Steven Gong wrote:
Vadim, Thank you for your advice!
But, don't you think if the circular-dependency is supported in
component container, we can avoid this problem downright? And the
implementation is not quite difficult. Simply put some signal to tell
the container not to
Peter Royal wrote:
Why Quartz vs Event?
Given the requirements that Vadim laid out:
* Continuation manager.
Need to execute single task periodically.
* Store janitor.
Need to execute single task periodically.
* DefaultIncludeCacheManager.
Need to execute single
Il giorno 30/ott/04, alle 15:49, Vadim Gritsenko ha scritto:
It was required for libs dependencies cleanup. Before, you either had
to duplicate the lib, or put fake dependency between blocks. Now we
can cleanup these unnecessary dependencies, and build will find
required libs for the blocks.
I
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the implementation,
but not as the interface. Now we already have the quartz block with
the required implementation, so it's easy to use that.
The first step is to do this move. If then someone things that an
own
Vadim Gritsenko wrote:
Ugo Cei wrote:
Looks like this is not a backward-compatible change. Blocks which are
distributed outside of Cocoon (like Fins or my Spring Petstore) must
change their deployment instructions to add all those depend
elements (and put dependencies in gump too, which wasn't
Ralph Goers wrote:
I believe the policy says that these sort of changes (like deprecating
something) require that they be announced in one maintenance
release and then they can be put in the next. So this change
can only happen in 2.1.7, if I have it right.
No :) our policy says that no
Ralph Goers wrote:
I'm not saying don't do this, but I am asking if this is
really what you want. After briefly looking at the Event
interface and the Cron block, they appear to be very
different. The Cron block appears to be about job
scheduling, which is fine if that is really what
Ugo Cei wrote:
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier [1].
In order to do so I have extended the gump descriptor with additional
information that allows the build system to locate one or more
dependency jars per
On 30-okt-04, at 18:46, Ralph Goers wrote:
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the
implementation,
but not as the interface. Now we already have the quartz block with
the required implementation, so it's easy to use that.
The first step is to do this move.
On 30-okt-04, at 19:29, Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier
[1]. In order to do so I have extended the gump descriptor with
additional information that allows the build
Ralph Goers wrote:
No :) our policy says that no incompatible changes should
occur between
maintenance releases. They might happen between minor
version changes.
Now of course these rules are not fixed which means we can
decide on a
case by case basis.
Carsten
So you are
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=31985.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=31985.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Sat, 30 Oct 2004, Unico Hommes wrote:
On 30-okt-04, at 18:46, Ralph Goers wrote:
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the
implementation,
but not as the interface. Now we already have the quartz block with
the required implementation, so it's easy to use
On Sat, 30 Oct 2004, Ralph Goers wrote:
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the implementation,
but not as the interface. Now we already have the quartz block with
the required implementation, so it's easy to use that.
The first step is to do this move. If
On 30-okt-04, at 20:05, Unico Hommes wrote:
On 30-okt-04, at 19:29, Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier
[1]. In order to do so I have extended the gump descriptor with
On 30-okt-04, at 21:02, Giacomo Pati wrote:
On Sat, 30 Oct 2004, Unico Hommes wrote:
On 30-okt-04, at 18:46, Ralph Goers wrote:
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the
implementation,
but not as the interface. Now we already have the quartz block with
the
Hi,
if I use this code in sitemap:
map:matchers default=wildcard
map:matcher name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcherFactory/
/map:matchers
the browser displays this error:
org.apache.cocoon.ProcessingException: Failed to load sitemap .
Hi Sylvain:
I am sorry for being late. I am trying to keep up to date, but it is hard
to me now. :-(
I think, I found a problem with the current implementation of this feature.
As all you already know, Jeremy requested me to help in a interesing
sample using Lucene and OJB, aka. ORO or OBJ ;-)
Jorg Heymans dijo:
Vadim Gritsenko wrote:
Jorg Heymans wrote:
First of all, thanks Luigi for bringing up something that has been on
my mind for a long time! Cocoon's patch queue is nothing to be proud
of to be honest, both in size and age.
The only way to get an overworked committer off
Unico Hommes dijo:
Not that I no longer care what you guys think ;-) but I went ahead and
made the proposed changes. It should be compatible now.
:-D
Best Regards,
Antonio Gallardo
33 matches
Mail list logo
