Giacomo Pati schrieb:
Now, with Spring I would suggest the following approach:
Cocoon uses an own application context which can be compared (by
simplifying) with a service manager. So we have an application context
for the core of Cocoon (again simplified). Now you can define a root
Spring
Ralph Goers wrote:
If that is the case then I'm -1 on this. We use our own logging framework
with Cocoon.
I knew this would happen :) Ok, anyway, I would like to get rid off
excalibur
logging and logkit. Which means, we only use the o.a.a.logging.Logger
abstraction which is passed to a component
Carsten Ziegeler wrote:
I knew this would happen :) Ok, anyway, I would like to get rid off
excalibur
logging and logkit. Which means, we only use the o.a.a.logging.Logger
abstraction which is passed to a component through LogEnabled. And we
configure a Log4J logger by default for this
of ECM++
Ralph Goers wrote:
If that is the case then I'm -1 on this. We use our own logging framework
with Cocoon.
I knew this would happen :) Ok, anyway, I would like to get rid off
excalibur
logging and logkit. Which means, we only use the o.a.a.logging.Logger
abstraction which is passed
Ok, I just committed the initial prototyp. The spring based container is
setup in the Cocoon class (in initialize). I think I've covered most of
the Avalon stuff including pooled components (but have not tested this).
The remaining part would be to use the spring based container instead of
ECM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
Once we use the Spring based container we can simplify the whole setup
process and clean up things like the CoreUtil and the Cocoon class.
While we are at discussing cleanups.
What about also getting
Giacomo Pati wrote:
On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
Once we use the Spring based container we can simplify the whole setup
process and clean up things like the CoreUtil and the Cocoon class.
While we are at discussing cleanups.
What about also getting rid of logkit and use
Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
Giacomo Pati wrote:
...What about also getting rid of logkit and use what we already have
in
our dependency lists (log4J, commons-logging, ...)?
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair)
Bertrand Delacretaz wrote:
Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
Giacomo Pati wrote:
...What about also getting rid of logkit and use what we already have in
our dependency lists (log4J, commons-logging, ...)?
Yes, please :) I would suggest log4j as commons-logging has
Upayavira wrote:
Bertrand Delacretaz wrote:
Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
Giacomo Pati wrote:
...What about also getting rid of logkit and use what we already have in
our dependency lists (log4J, commons-logging, ...)?
Yes, please :) I would suggest log4j as
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
Once we use the Spring based container we can simplify the whole setup
process and clean up things like the CoreUtil and the Cocoon class.
While we are at discussing cleanups.
Carsten Ziegeler wrote:
...
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair) and noone is using jdk14 logging.
Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a
facade for other logging frameworks but it doesn't suffer
Niklas Therning wrote:
Carsten Ziegeler wrote:
...
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair) and noone is using jdk14 logging.
Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a
facade for other logging
Niklas Therning wrote:
Carsten Ziegeler wrote:
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair) and noone is using jdk14 logging.
Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's
a facade for other logging frameworks but it
container instead of
ECM++ which requires changes in the Cocoon class and in the tree
processor. Changing the Cocoon class should be fairly easy while the
tree processor is more work. Now, this work can't be done without
possibly breaking Cocoon until the work is finished. So how do we proceed?
Once
Giacomo Pati wrote:
While we are at discussing cleanups.
What about also getting rid of logkit and use what we already have in
our dependency lists (log4J, commons-logging, ...)?
I think we definitively need to get a smaller footprint and also get
committed to fewer alternatives (of which
of ECM++
Niklas Therning wrote:
Carsten Ziegeler wrote:
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair) and noone is using jdk14 logging.
Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a
facade for other logging
instead of ECM++
Giacomo Pati wrote:
While we are at discussing cleanups.
What about also getting rid of logkit and use what we already have in our
dependency lists (log4J, commons-logging, ...)?
I think we definitively need to get a smaller footprint and also get
committed to fewer
Giacomo Pati wrote:
If the logger abstraction you mentioned is the Avalon LogEnabled one
than yes, we will still have to support that for backward compatability.
Of course we will support LogEnabled - with the only difference that you
always get a wrapper around a Log4J (or whatever we
Berin Loritsch wrote:
Niklas Therning wrote:
Carsten Ziegeler wrote:
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair) and noone is using jdk14 logging.
Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's
a facade for other
Daniel Fagerstrom wrote:
It depends on how long time you think that it will take. If you think
that it take a week or so I suggest that you branch cocoon-core, and
work on the branch until it works again and merge it back then. In the
meantime the rest of us try to avoid doing larger
Carsten Ziegeler said:
Daniel Fagerstrom wrote:
It depends on how long time you think that it will take. If you think
that it take a week or so I suggest that you branch cocoon-core, and
work on the branch until it works again and merge it back then. In the
meantime the rest of us try to
Ralph Goers wrote:
Carsten Ziegeler said:
Giacomo Pati wrote:
If the logger abstraction you mentioned is the Avalon LogEnabled one
than yes, we will still have to support that for backward compatability.
Of course we will support LogEnabled - with the only difference that you
always get a
: no, I'm not able to run
the portal or any other block right now and I don't have a clue how to
fix this. I meant that I need one or two days to replace ECM++ with
Spring and then Cocoon runs again in the same way it runs today. Getting
the blocks/samples run again is currently out of my scope
Carsten Ziegeler said:
Ralph Goers wrote:
Carsten Ziegeler said:
What do you mean by always? I thought that we switched the default
from
logkit to log4j a while ago? What more is needed?
This switch never happened - the idea behind this is to remove the
support for other logging
Carsten Ziegeler said:
Ah, sorry, again one of my too short sentences: no, I'm not able to run
the portal or any other block right now and I don't have a clue how to
fix this. I meant that I need one or two days to replace ECM++ with
Spring and then Cocoon runs again in the same way
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
It depends on how long time you think that it will take. If you think
that it take a week or so I suggest that you branch cocoon-core, and
work on the branch until it works again and merge it back then. In the
meantime the rest of us try to
of ECM++
Carsten Ziegeler said:
Ralph Goers wrote:
Carsten Ziegeler said:
What do you mean by always? I thought that we switched the default
from
logkit to log4j a while ago? What more is needed?
This switch never happened - the idea behind this is to remove the
support for other logging
short sentences: no, I'm not able to run
the portal or any other block right now and I don't have a clue how to
fix this. I meant that I need one or two days to replace ECM++ with
Spring and then Cocoon runs again in the same way it runs today. Getting
the blocks/samples run again is currently out
Giacomo Pati wrote:
-
Can you explain how you use your own under Cocoon? Separate LogEnabled
impls? CommonsLogging?
I implement org.apache.avalon.excalibur.logging.LoggerManager and
org.apache.avalon.excalibur.logging.Logger. These then interface with
my logging framework.
Ralph
On 14.02.2006, at 00:50, Carsten Ziegeler wrote:
Giacomo Pati wrote:
On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
Once we use the Spring based container we can simplify the whole
setup
process and clean up things like the CoreUtil and the Cocoon class.
While we are at discussing
Leszek Gawron wrote:
Carsten Ziegeler wrote:
So what do people think?
I haven't read any other replies yet but my small brain tells me to be
+100 on this one.
I don't have any objections either - especially since it is backward compatible
both from component and configuration POV.
Vadim
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
So what do people think?
I haven't read any other replies yet but my small brain tells me to be
+100 on this one.
I don't have any objections either - especially since it is backward
compatible
both from component and
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
So what do people think?
I haven't read any other replies yet but my small brain tells me to be
+100 on this one.
I don't have any objections either - especially since it is backward
compatible
Ralph Goers schrieb:
If you really can pull this off then a big +1. However
Can you post a sample configuration? I'd love to see what the mixture
of spring and avalon-style configuration looks like.
Oh, the avalon configuration is exactly the same as we have today in
trunk and the
Carsten Ziegeler wrote:
Ralph Goers schrieb:
And if we can ban poolables once and for all then this will greatly
simplify things. However, I'd love to see some performance comparisons
on some of the sample pages (including logging into the portal) before
buying off on this. I'd really
Carsten Ziegeler wrote:
If we want to go down this road I can commit the code to the scratchpad
in the next days.
Please add it to trunk so that integration with blocks-fw and deployer becomes
simpler. (Otherwise we have to run Maven twice in order to get all projects
updated.)
--
Carsten Ziegeler wrote:
What about replacing ECM++ with Spring? I've a prototype on my harddisk
which sets up a Spring BeanFactory based on our current Avalon
configuration files (roles and xconf with includes and property
replacements). This makes all of our components real spring beans while
What about replacing ECM++ with Spring? I've a prototype on my harddisk
which sets up a Spring BeanFactory based on our current Avalon
configuration files (roles and xconf with includes and property
replacements). This makes all of our components real spring beans while
allowing a smooth migration
Le 7 févr. 06, à 20:41, Carsten Ziegeler a écrit :
...So what do people think?
IIUC one would be able to recompile existing code, including
Avalon-based components, with no or minor changes?
Sounds like a dream come true: big +1 here.
-Bertrand
smime.p7s
Description: S/MIME cryptographic
On 07.02.2006 20:41, Carsten Ziegeler wrote:
So what do people think?
Sounds promising.
Jörg
Carsten Ziegeler skrev:
What about replacing ECM++ with Spring? I've a prototype on my harddisk
which sets up a Spring BeanFactory based on our current Avalon
configuration files (roles and xconf with includes and property
replacements). This makes all of our components real spring beans while
Carsten Ziegeler wrote:
What about replacing ECM++ with Spring? I've a prototype on my harddisk
which sets up a Spring BeanFactory based on our current Avalon
configuration files (roles and xconf with includes and property
replacements). This makes all of our components real spring beans while
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 7 Feb 2006, Carsten Ziegeler wrote:
Date: Tue, 07 Feb 2006 20:41:51 +0100
From: Carsten Ziegeler [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: Cocoon-Dev dev@cocoon.apache.org
Subject: [RT] Using Spring instead of ECM++
What about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 7 Feb 2006, Giacomo Pati wrote:
On Tue, 7 Feb 2006, Carsten Ziegeler wrote:
So what do people think?
If it is as easy and backward compatible as you say, sure +1 from here
- --
Giacomo Pati
Otego AG, Switzerland -
Il giorno 07/feb/06, alle ore 20:41, Carsten Ziegeler ha scritto:
What about replacing ECM++ with Spring?
I don't think I have to tell you how much I would love that. However,
I'm a bit confused, but it's really my fault, as I haven't been
following at all the recent realblocks/osgi/2.2
Giacomo Pati wrote:
Uh, what's a thread safe poolable??
If a thread safe component uses a poolable with ECM, you need to know
this when implementing the thread safe component. The implementation
will lookup/release the poolable whenever it needs one. Now this is of
course against
Ugo Cei wrote:
Il giorno 07/feb/06, alle ore 20:41, Carsten Ziegeler ha scritto:
What about replacing ECM++ with Spring?
I don't think I have to tell you how much I would love that. However,
I'm a bit confused, but it's really my fault, as I haven't been
following at all the recent
Giacomo Pati wrote
On Tue, 7 Feb 2006, Giacomo Pati wrote:
On Tue, 7 Feb 2006, Carsten Ziegeler wrote:
So what do people think?
If it is as easy and backward compatible as you say, sure +1 from here
I think it is - the only piece missing right now are Poolable's and the
tree processor
.
Ah yes. I forgot that we already had flattened selectors in ECM++ :-)
Sounds good!
Sylvain
--
Sylvain WallezAnyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Sylvain Wallez wrote:
You mean these are separate files each using their own format that are
merged in a single DOM for the ApplicationContext?
Yes, exactly (though technically I'm not using a DOM for this)
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
to see some performance comparisons
on some of the sample pages (including logging into the portal) before
buying off on this. I'd really like to make sure that our theory that
pooling doesn't buy much is really true.
Ralph
Carsten Ziegeler wrote:
What about replacing ECM++ with Spring? I've
Sylvain Wallez wrote:
Hi all,
I committed an initial ECM - OSGi bridge in
src/org/apache/cocoon/core/osgi.
Cool!
This code is untested and there are still some pending points, but I
wanted to share it ASAP so that we can discuss these issues.
What we have
Daniel Fagerstrom schrieb:
The ECM is given a LoggerManager that uses OSGi's LogService. We may
consider using an optional LoggerManager service if present, as
LogService has some limitations (no categories, and no isXxxEnabled
methods).
The OSGi LogService is obviously a little bit
Hi all,
I committed an initial ECM - OSGi bridge in
src/org/apache/cocoon/core/osgi.
This code is untested and there are still some pending points, but I
wanted to share it ASAP so that we can discuss these issues.
What we have there is a ServiceManagerActivator that will create an
ECM
Why a system property instead of an init-param?
Sylvain Wallez said:
Hi all,
I (once again) did some refactoring in ECM++ to implement a lazy-loading
strategy for components. Using this strategy, a component is loaded
(including it's class) only when looked up. This heavily reduces
Cool! One more reason for releasing 2.2 soon :)
/Daniel
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a lazy-loading
strategy for components. Using this strategy, a component is loaded
(including it's class) only when looked up. This heavily reduces
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a lazy-loading
strategy for components. Using this strategy, a component is loaded
(including it's class) only when looked up. This heavily reduces
Cocoon's initialization time.
Some quick measurement
Ralph Goers wrote:
Why a system property instead of an init-param?
Because it's experimental and I wanted a quick switch to compare lazy
and non-lazy modes!
Now if this is to become more mainstream (and I guess it will), that
will for sure be triggered by some init-param.
Sylvain
--
Sylvain
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when this is
the Cocoon Core Service Manager.
So what about using the CCSM acronym
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a
lazy-loading strategy for components. Using this strategy, a
component is loaded (including it's class) only when looked up. This
heavily reduces Cocoon's initialization time
On Mie, 5 de Enero de 2005, 15:01, Sylvain Wallez dijo:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when this is
the Cocoon Core
Antonio Gallardo wrote:
On Mie, 5 de Enero de 2005, 15:01, Sylvain Wallez dijo:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when
Antonio Gallardo wrote:
On Mie, 5 de Enero de 2005, 15:01, Sylvain Wallez dijo:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Also, CSM can be confused with CocoonServiceManager which is in
o.a.c.components.container (which is a subclass of CCSM).
howzabout CCM = Cocoon Component Manager... or is there a confusion hazard
vs. Avalon's
Mark Lundquist wrote:
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Also, CSM can be confused with CocoonServiceManager which is in
o.a.c.components.container (which is a subclass of CCSM).
howzabout CCM = Cocoon Component Manager... or is there a confusion
On Wed, 05 Jan 2005 22:42:57 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
Mark Lundquist wrote:
-Original Message-
howzabout CCM = Cocoon Component Manager... or is there a confusion hazard
vs. Avalon's ComponentManager?
Hey, read carefully, this is *Service* Manager. If
Sylvain Wallez said:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when this is
the Cocoon Core Service Manager.
So what about
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a lazy-loading
strategy for components. Using this strategy, a component is loaded
(including it's class) only when looked up. This heavily reduces
Cocoon's initialization time.
Cool!
What about
Sylvain Wallez wrote:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when this is
the Cocoon Core Service Manager.
So what about using
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a
lazy-loading strategy for components. Using this strategy, a
component is loaded (including it's class) only when looked up. This
heavily reduces Cocoon's initialization time.
Cool
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now
if we compare it to the original ECM. Lots and lots of things have
changed. Furthermore, ECM stands for Excalibur Component Manager
when this is the Cocoon Core Service
Ugo Cei wrote:
Il giorno 22/ott/04, alle 19:40, Reinhard Poetz ha scritto:
Have you considered using Easymock? IMHO its usage is more intuitive
than jMock.
(see BlockDeployer test cases)
After perusing the documentation and samples, I decided that I liked
jMock more, but I didn't try EasyMock
Ugo Cei wrote:
In the coming days, I plan to rewrite all tests depending on
ExcaliburTestCase so that we can forget about it. Stay tuned.
In addition, our tests test if it is possible to get a corresponding
selector (e.g. for transformers etc.) and then the component to test
from this
Il giorno 25/ott/04, alle 08:58, Carsten Ziegeler ha scritto:
Ugo Cei wrote:
In the coming days, I plan to rewrite all tests depending on
ExcaliburTestCase so that we can forget about it. Stay tuned.
In addition, our tests test if it is possible to get a corresponding
selector (e.g. for
Ugo Cei wrote:
Il giorno 25/ott/04, alle 08:58, Carsten Ziegeler ha scritto:
Ugo Cei wrote:
In the coming days, I plan to rewrite all tests depending on
ExcaliburTestCase so that we can forget about it. Stay tuned.
In addition, our tests test if it is possible to get a
Il giorno 25/ott/04, alle 08:17, Reinhard Poetz ha scritto:
Probably yes. IMO the advantages of Easymock are
- you directly call methods on the objects - so refactoring is
rather simple
because the TestMethods are updated too
Interesting. This merits some more consideration. I also don't
Ugo Cei wrote:
Il giorno 25/ott/04, alle 08:17, Reinhard Poetz ha scritto:
Probably yes. IMO the advantages of Easymock are
- you directly call methods on the objects - so refactoring is
rather simple
because the TestMethods are updated too
Interesting. This merits some more consideration.
Il giorno 25/ott/04, alle 09:39, Reinhard Poetz ha scritto:
But sometimes there are cases when you have to mock an object and not
an interface and Easymock can build proxy objects of them too.
Not true. You can mock classes with jMock too:
http://jmock.org/cglib.html :-)
Ugo
--
Ugo Cei
Ugo Cei wrote:
Il giorno 25/ott/04, alle 09:39, Reinhard Poetz ha scritto:
But sometimes there are cases when you have to mock an object and not
an interface and Easymock can build proxy objects of them too.
Not true. You can mock classes with jMock too:
http://jmock.org/cglib.html :-)
Ugo
On Mon, 25 Oct 2004, Ugo Cei wrote:
Il giorno 25/ott/04, alle 09:54, Reinhard Poetz ha scritto:
Anyway, I don't think we have to decide on one mock framework. Whoever
writes the test decides, which one he prefers.
Yes, that's a possibility. I am just thinking that it might be less confusing
for
of that dependency, but as a stopgap measure,
is there a class in ECM++ that can take its place just by substituting
the classname in its place?
Ugo
to get rid of that dependency, but as a stopgap measure,
is there a class in ECM++ that can take its place just by substituting
the classname in its place?
Well, after thinking about the issue some more, I decided to rewrite all
the sitemap components' testcases following a different approach. I
Ugo Cei wrote:
I wrote:
Using the jMock library, the test looks like this (slightly edited to
simplify):
Have you considered using Easymock? IMHO its usage is more intuitive than jMock.
--
Reinhard
Ugo Cei wrote:
I wrote:
Using the jMock library, the test looks like this (slightly edited to
simplify):
Have you considered using Easymock? IMHO its usage is more intuitive than jMock.
(see BlockDeployer test cases)
--
Reinhard
:42 PM
To: [EMAIL PROTECTED]
Subject: Re: ECM++
Currently, all the unit tests involving sitemap components
fail because the class
org.apache.cocoon.components.ExtendedComponentSelector, which
is referenced by *.xtest files, has been removed.
Now, those tests depend on the deprecated
Il giorno 22/ott/04, alle 19:40, Reinhard Poetz ha scritto:
Have you considered using Easymock? IMHO its usage is more intuitive
than jMock.
(see BlockDeployer test cases)
After perusing the documentation and samples, I decided that I liked
jMock more, but I didn't try EasyMock in practice. If
Stefano Mazzocchi wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work
anymore ...
Andreas, I *strongly* suggest that you keep off
disagree in part. B-)
I agree that there is no need of a separate jar in the distro.
I do think though that the compilation of ECM++ must be done
*before* the others, so that things remain properly layered.
Ah, ok, yepp, you're right - the first version that I will check
in has dependencies
Stefano Mazzocchi wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work
anymore ...
Andreas, I *strongly* suggest that you keep off
Andreas Hartmann wrote:
Just one more question for my understanding:
Lenya 1.4 will probably be released in spring or summer next year.
We're planning to do a major clean-up of the code base.
(See also thread Switch to Cocoon 2.2 for Lenya 1.4-dev on
lenya-dev (the archive seems to be
Carsten Ziegeler wrote:
Andreas Hartmann wrote:
[...]
Assumed we start development with Cocoon 2.1.* now, would
this mean that we will release against the 2.1 branch? It
looks like Cocoon 2.2 will really be quite different, so it
will probably be hard to upgrade Lenya. Will the 2.1 branch
This evening I'm going to integrate ECM++ into the current 2.2 codebase.
I've already done this locally and it seems to work very well, it even
seemed to be a little bit faster than with the old ECM - but this could
be some hallucination...
Anyway, I will move the code from the whiteboard
Il giorno 21/ott/04, alle 12:10, Carsten Ziegeler ha scritto:
This evening I'm going to integrate ECM++ into the current 2.2
codebase.
Go for it!
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
Andreas Hartmann wrote:
Stefano Mazzocchi wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work
anymore ...
Andreas, I *strongly*
On Thursday 21 October 2004 21:40, Stefano Mazzocchi wrote:
As for continous integration, Gump is your friend, so you should
not have to worry about that.
Provided we can get Gump all the way up and beyond Cocoon :o)
Soon there...
Cheers
Niclas
--
+--//---+
/
Niclas Hedhman wrote:
On Thursday 21 October 2004 21:40, Stefano Mazzocchi wrote:
As for continous integration, Gump is your friend, so you should
not have to worry about that.
Provided we can get Gump all the way up and beyond Cocoon :o)
Soon there...
you can bet your ass we will! :-)
--
Stefano
I already committed the first version of ECM++ into the whiteboard.
Now, the question is how do we want to continue?
I already integrated it into 2.2 on my computer. It requires only a few
changes in Cocoon.java and in some treeprocessor classes.
Should I switch 2.2 to use ECM++ now or do we
Il giorno 20/ott/04, alle 08:34, Carsten Ziegeler ha scritto:
Should I switch 2.2 to use ECM++ now or do we first want to write some
tests?
Is it stable enough? Stable in the sense that you aren't going to do
massive changes in the coming days, so that if I peek and poke around
in the code, we
PROTECTED]
Subject: Re: ECM++
Il giorno 20/ott/04, alle 08:34, Carsten Ziegeler ha scritto:
Should I switch 2.2 to use ECM++ now or do we first want to
write some
tests?
Is it stable enough? Stable in the sense that you aren't
going to do massive changes in the coming days, so that if I
1 - 100 of 189 matches
Mail list logo
