RE: Making tests suck less (was Re: ECM++)

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 selec

Re: Making tests suck less (was Re: ECM++)

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 in

Re: [VOTE] Remove excalibur instrumentation support from 2.2

Le 24 oct. 04, à 15:32, Carsten Ziegeler a écrit : ...So, please cast your votes on removing the support starting with 2.2: +1 Thanks for your work Carsten! -Bertrand smime.p7s Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 30971] - XSP compile failure when using Java 1.5 features

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [VOTE] Remove excalibur instrumentation support from 2.2

Il giorno 24/ott/04, alle 15:32, Carsten Ziegeler ha scritto: The ECM++ is now integrated in 2.2 and it seems that most things are running again - even simple XSP pages (haven't tested more yet). Thank you Carsten. You did an outstanding job. So, please cast your votes on removing the support start

DO NOT REPLY [Bug 30971] - XSP compile failure when using Java 1.5 features

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 31564] - [PATCH] XSP - JXPath logicsheet jxpath:for-each using relative contexts

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: New Test System

Ralph Goers wrote: > > Is SitemapComponentTestCase gone or does it simply use > ContainerTestcase now? > It's still there and yes inherits from ContainerTestCase now. Carsten

Re: [GT 2004] PGP key signing?

Carsten Ziegeler wrote: Carsten, Sylvain ...looks like you did not yet sign and/or update the keys on pgp.mit.edu? Yepp, that's true :( - I will try to do this next week... Same here. Thanks for the reminder. Same here also :-) Sylvain -- Sylvain Wallez

Re: [VOTE] Remove excalibur instrumentation support from 2.2

Carsten Ziegeler wrote: The ECM++ is now integrated in 2.2 and it seems that most things are running again - even simple XSP pages (haven't tested more yet). Now, as I mentioned earlier, one idea of ECM++ is to support only those interfaces/features that we really need. One candidate in this catego

Re: New Test System

Is SitemapComponentTestCase gone or does it simply use ContainerTestcase now? Ralph Carsten Ziegeler wrote: Ok, the title promises a little bit more than I did :) I removed the dependencies to excalibur-testcase from both 2.1.x and 2.2. We now have our own base class for component based junit tes

New Test System

Ok, the title promises a little bit more than I did :) I removed the dependencies to excalibur-testcase from both 2.1.x and 2.2. We now have our own base class for component based junit tests: ContainerTestCase - it provides similar functionality than the deprecated ExcaliburTestCase class. I remo

Re: [VOTE] Remove excalibur instrumentation support from 2.2

Carsten Ziegeler wrote: Stefano Mazzocchi wrote: +1 Carsten, one thing, when you remove a dependency, please update the gump.xml descriptor too! Sure, until now I only removed one jar (excalibur-testcase) and I updated gump.xml as well. Just curious, did I forget it somewhere or is this a gener

RE: [VOTE] Remove excalibur instrumentation support from 2.2

Carsten Ziegeler wrote: > So, please cast your votes on removing the support starting with 2.2: > +1 Carsten

RE: [VOTE] Remove excalibur instrumentation support from 2.2

Stefano Mazzocchi wrote: > > +1 > > Carsten, one thing, when you remove a dependency, please > update the gump.xml descriptor too! > Sure, until now I only removed one jar (excalibur-testcase) and I updated gump.xml as well. Just curious, did I forget it somewhere or is this a general reminder

Re: [VOTE] Remove excalibur instrumentation support from 2.2

Carsten Ziegeler wrote: The ECM++ is now integrated in 2.2 and it seems that most things are running again - even simple XSP pages (haven't tested more yet). Now, as I mentioned earlier, one idea of ECM++ is to support only those interfaces/features that we really need. One candidate in this catego

RE: [VOTE] Remove excalibur instrumentation support from 2.2

> -Original Message- > From: Giacomo Pati [mailto:[EMAIL PROTECTED] > Sent: 24 October 2004 15:45 > To: Cocoon-Dev > Subject: Re: [VOTE] Remove excalibur instrumentation support from 2.2 > > On Sun, 24 Oct 2004, Carsten Ziegeler wrote: > > > The ECM++ is now integrated in 2.2 and it see

Re: [VOTE] Remove excalibur instrumentation support from 2.2

On Oct 24, 2004, at 9:45 AM, Giacomo Pati wrote: In the end when we think of real blocks we need another solution anyways - this could be JMX or something else, but it's most likely that it won't be IIRC JMX isn't able to visualize behaviour over time (i.e. concurrent useage of a component over

Bug report for Cocoon 2 [2004/10/24]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Re: [VOTE] Remove excalibur instrumentation support from 2.2

On Sun, 24 Oct 2004, Carsten Ziegeler wrote: The ECM++ is now integrated in 2.2 and it seems that most things are running again - even simple XSP pages (haven't tested more yet). Now, as I mentioned earlier, one idea of ECM++ is to support only those interfaces/features that we really need. One can

[VOTE] Remove excalibur instrumentation support from 2.2

The ECM++ is now integrated in 2.2 and it seems that most things are running again - even simple XSP pages (haven't tested more yet). Now, as I mentioned earlier, one idea of ECM++ is to support only those interfaces/features that we really need. One candidate in this category is obviously the in

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

On 24-okt-04, at 1:38, Frédéric Glorieux wrote: Hello, Like explained in another thread, I'm trying to implement a PUT binaries in the webdav/davmap demo. I wrote a simple "RequestReader" like waited in the sitemap sample, it works well for httpRequest, because there is a getInputStream() metho

Re: webdav block, davmap, binaries PUT, request reader

Hi again, I thought that would have worked :-/ The problem may be that getInputStream is not defined on the Response interface but only on HttpResponse class. Hmm sorry, I guess a Reader is the best option ATM. -- Unico On 23-okt-04, at 20:30, Frédéric Glorieux wrote: Hello Unico, Back from fami

[Fwd: Re: changes to instrument packages break cocoon]

Hi cocooners, there's some backwards-incompatible changes being introduced in excalibur land (discussion on that is in ML archives for people interested). We're sorta planning to release soonish, so that will make it possible for y'all to upgrade (just some really small changes required; see be

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu