You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Upayavira <uv...@upaya.co.uk> on 2003/11/07 10:23:30 UTC
Respecting the CLI
I often find myself fielding questions on the user list about why the
CLI doesn't work.
Sometimes this is down to my own stupidity. Other times, however, it is
down to people changing things in Cocoon, and assuming that the servlet
is the only environment in which Cocoon runs. This isn't the case. The
CLI does exist, and I hope there'll be other environments appearing too
(e.g. a mailet one for use with Doco).
How can we move to a point where changes that are made to Cocoon are
done in an environment agnostic way, rather than with an assumption that
the servlet is the only user?
Thoughts?
Regards, Upayavira
Re: Respecting the CLI
Posted by David Crossley <cr...@indexgeo.com.au>.
Upayavira wrote:
> I often find myself fielding questions on the user list about why the
> CLI doesn't work.
>
> Sometimes this is down to my own stupidity. Other times, however, it is
> down to people changing things in Cocoon, and assuming that the servlet
> is the only environment in which Cocoon runs. This isn't the case. The
> CLI does exist, and I hope there'll be other environments appearing too
> (e.g. a mailet one for use with Doco).
>
> How can we move to a point where changes that are made to Cocoon are
> done in an environment agnostic way, rather than with an assumption that
> the servlet is the only user?
Oh dear, i feel your pain. This is the exact same stuff that
i went through trying to get the Entity Resolver to work on
all platforms and in both command-line docs and the webapp.
It was agony and inefficiency.
I will help to get the Forrest Gump tests going, not that
i know anything about it.
--David
Re: Respecting the CLI
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
> Upayavira wrote:
> > Nicola Ken Barozzi wrote:
> ...
> >> Then add a test run target to the ant buildfile and make sure Gump
> >> runs it daily.
> >
> > That's the thing. Write a test target...
> > What shape would a CLI test target take?
>
> IMHO the first easy thing to do is to rely on Forrest, that uses Cocoon
> in a sufficiently complex way.
>
> What is needed is a test site that is complex enough, and have Forrest
> run on it. If the build fails, it may mean that it's Forrest's fault or
> Cocoon's, but the important thing is knowing that there is an error.
Yes, we have a 'forrest seed site' that is stable. We could add
a few other documents to it to exercise certain issues.
So i gather that we could be getting Gump to run that right now.
--David
Re: Respecting the CLI
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Upayavira wrote:
> Nicola Ken Barozzi wrote:
...
>> Then add a test run target to the ant buildfine and make sure Gump
>> runs it daily.
>
> That's the thing. Write a test target...
>
> What shape would a CLI test target take?
IMHO the first easy thing to do is to rely on Forrest, that uses Cocoon
in a sufficiently complex way.
What is needed is a test site that is complex enough, and have Forrest
run on it. If the build fails, it may mean that it's Forrest's fault or
Cocoon's, but the important thing is knowing that there is an error.
Then, if the Forrest build succedes, the ant build can do other checks
like the size of the files (>0), check that the files are actually there
and not more and not less than defined, etc.
This is the functional test part, which is only part of the picture, and
is to be done in Forrest. BTW, this makes it possible for us to gather
statistics about Cocoon speed.
Then we have the unit test part, that is about testing the functionality
of the CLI "unit", mainly of it's methods.
What I am doing now in my projects is to not try to devise clever tests
from the start. Most tests that people write are of no use, or at least
cost more to write than to fix the eventual bug later. IMHO writing
tests is like writing code, and as I now try to KISS code, I want to
KISS tests.
So actually I go the other way round current practice: I write only the
tests that I know I need, not more.
Since you don't know what tests to write, simply to set up a functional
test run, a simple CLI testcase, and check that they run on Gump. Then,
each time a problem occurs or each time you see that you are defining a
spec or contract that is not enforced in code, or that has to remain
enforced, write this down in the testcase that is already there.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Respecting the CLI
Posted by Upayavira <uv...@upaya.co.uk>.
Nicola Ken Barozzi wrote:
> Bertrand Delacretaz wrote:
>
>>> On Fri, 7 Nov 2003, Bertrand Delacretaz wrote:
>>>
>>>> The only thing that comes to mind is automated tests of both CLI and
>>>> servlet environments...at this point it is a lot of work to add, but I
>>>> doubt that any rules like "make sure you re-test the CLI" would work.
>>>
>>
>> Re-reading this I realize that it might give the wrong impression:
>> I'm not saying that the CLI is not important, but rather than asking
>> people to test their stuff in several environments usually doesn't
>> work, unless this testing is quick and automated.
>
>
> Gump. It already works.
>
> What we need is to make core Cocoon *not* need the servlet jar, as I
> had tried in he past but gt fed up with discussions.
I'm pretty sure it doesn't. I've just done a fresh checkout, and built
with no blocks, and it worked fine. I didn't need to add servlet.jar
anywhere.
But there are some blocks that need it.
> Take the servlet jar out, see what the dependencies are, make sure
> that the core doesn't need servlet.jar, and you are halfway there.
As I say, we're there already, AFAICS.
> Then add a test run target to the ant buildfine and make sure Gump
> runs it daily.
That's the thing. Write a test target...
What shape would a CLI test target take?
I know we need one, but I haven't yet really conceived it.
Regards, Upayavira
RE: Respecting the CLI
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
> Gump. It already works.
>
> What we need is to make core Cocoon *not* need the servlet jar, as I had
> tried in he past but gt fed up with discussions.
>
> Take the servlet jar out, see what the dependencies are, make sure that
> the core doesn't need servlet.jar, and you are halfway there.
>
> Then add a test run target to the ant buildfine and make sure Gump runs
> it daily.
>
> Problem solved.
>
The last time I tried it, Cocoon did compile without servlet.jar and did
also run. We lost this feature during the build restructuring as we
currently have some classes in the core that depend on the servlet.jar.
In the old build system these classes were excluded.
But afaik, we don't have dependencies to the servlet spec that are
required for the CLI (apart from those compilation problems and
the recently introduced context problem, that's fixed now).
Carsten
Re: Respecting the CLI
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bertrand Delacretaz wrote:
>> On Fri, 7 Nov 2003, Bertrand Delacretaz wrote:
>>
>>> The only thing that comes to mind is automated tests of both CLI and
>>> servlet environments...at this point it is a lot of work to add, but I
>>> doubt that any rules like "make sure you re-test the CLI" would work.
>
> Re-reading this I realize that it might give the wrong impression: I'm
> not saying that the CLI is not important, but rather than asking people
> to test their stuff in several environments usually doesn't work, unless
> this testing is quick and automated.
Gump. It already works.
What we need is to make core Cocoon *not* need the servlet jar, as I had
tried in he past but gt fed up with discussions.
Take the servlet jar out, see what the dependencies are, make sure that
the core doesn't need servlet.jar, and you are halfway there.
Then add a test run target to the ant buildfine and make sure Gump runs
it daily.
Problem solved.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Respecting the CLI
Posted by Upayavira <uv...@upaya.co.uk>.
Andrew Savory wrote:
>On Fri, 7 Nov 2003, Bertrand Delacretaz wrote:
>
>
>
>>The only thing that comes to mind is automated tests of both CLI and
>>servlet environments...at this point it is a lot of work to add, but I
>>doubt that any rules like "make sure you re-test the CLI" would work.
>>
>>
>
>Indeed - perhaps if we had something like CruiseControl running, we could
>get notified of these breakages before they hit the users?
>
>http://cruisecontrol.sourceforge.net/
>
>
>
Ah, but surely to use CruiseControl, you need to have tests to run :-(
I'm working on testing tools for pipelines, so maybe that would be
something we could use to set up some simple tests that could be used
with CruiseControl.
Actually, we could use it to detect build failures - but we usually find
those out quite quickly.
Hmm.
Regards, Upayavira
Re: Respecting the CLI
Posted by Vadim Gritsenko <va...@verizon.net>.
Andrew Savory wrote:
>On Fri, 7 Nov 2003, Bertrand Delacretaz wrote:
>
>
>
>>The only thing that comes to mind is automated tests of both CLI and
>>servlet environments...at this point it is a lot of work to add, but I
>>doubt that any rules like "make sure you re-test the CLI" would work.
>>
>>
>
>Indeed - perhaps if we had something like CruiseControl running, we could
>get notified of these breakages before they hit the users?
>
>
We already have gump, and it already can run unit tests. The only
missing piece right now is unit tests.
Vadim
Re: Respecting the CLI
Posted by Bertrand Delacretaz <bd...@apache.org>.
> On Fri, 7 Nov 2003, Bertrand Delacretaz wrote:
>
>> The only thing that comes to mind is automated tests of both CLI and
>> servlet environments...at this point it is a lot of work to add, but I
>> doubt that any rules like "make sure you re-test the CLI" would work.
Re-reading this I realize that it might give the wrong impression: I'm
not saying that the CLI is not important, but rather than asking people
to test their stuff in several environments usually doesn't work,
unless this testing is quick and automated.
-Bertrand
Re: Respecting the CLI
Posted by Andrew Savory <an...@luminas.co.uk>.
On Fri, 7 Nov 2003, Bertrand Delacretaz wrote:
> The only thing that comes to mind is automated tests of both CLI and
> servlet environments...at this point it is a lot of work to add, but I
> doubt that any rules like "make sure you re-test the CLI" would work.
Indeed - perhaps if we had something like CruiseControl running, we could
get notified of these breakages before they hit the users?
http://cruisecontrol.sourceforge.net/
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
Re: Respecting the CLI
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Vendredi, 7 nov 2003, à 10:23 Europe/Zurich, Upayavira a écrit :
> ...How can we move to a point where changes that are made to Cocoon
> are done in an environment agnostic way, rather than with an
> assumption that the servlet is the only user?...
The only thing that comes to mind is automated tests of both CLI and
servlet environments...at this point it is a lot of work to add, but I
doubt that any rules like "make sure you re-test the CLI" would work.
-Bertrand