[Webtest] Re: Canoo WebTest R_1104 Build Fixed

[Dierk Koenig]

Hi Paul,

Yes, I think this is going into the right direction.

There are more WT users with their private extensions that would
profit from build support for plugins.

A minor concern is with keeping the taskdef.xml as stable as
possible. Whenever upgrades to new WT versions make problems,
that's most often because of taskdef changes.

I see the potential value of supporting multiple classloaders 
and namespaces although I do not expect that the need will 
arise very soon.

Your latest commits are really cool. 
I very much like the support for testing RSS/REST/XML-RPC/SOAP.
We're gonna use that for testing the according GRAILS 
controllers (http://grails.codehaus.org).

Can you tell a bit about
the scenario that your client uses WT for?

cheers and a Happy New Year to everybody
Mittie

> -----Original Message-----
> From: webtest-admin@lists.canoo.com
> [mailto:webtest-admin@lists.canoo.com]On Behalf Of Paul King
> Sent: Montag, 2. Januar 2006 6:46
> To: webtest@gate2.canoo.com
> Subject: [Webtest] Re: Canoo WebTest R_1104 Build Fixed
> 
> 
> 
> [Mostly for developers]
> 
> I have started playing around with a 'plugins' directory structure.
> So far I have just moved the pdfsteps into a 'plugins/pdftest' folder
> and its necessary jars into 'lib/plugins/pdftest'.
> 
> At the moment, the classpath.xml just includes 'lib/plugins/**/*.jar'
> (as does the build file) so there is no immediate obvious difference.
> 
> The build does generate (strict and relaxed versions of)
> webtest_base.taskdef and webtest_<pluginname>.taskdef (for each
> directory in the plugins directory) as well as the current
> webtest.taskdef which includes all of the steps. Currently this
> is just for the pdf steps but we could move in applets, verifySchema,
> propertyTable (if we wanted) etc.
> 
> Things which this could allow in the future (with more!! work):
> 
> (1) compile plugin steps with base and <pluginname> jars (but not
>     jars for all the other plugins)
> 
> (2) provide plugin steps with their own classloader so that different
>     plugins could have different versions of 3rd party jars (probably
>     quite a lot of work)
> 
> (3) change classpath.xml and taskdef.xml to be aware of plugins
>     (e.g. so I could import taskdef_base and taskdef_applets but
>     not taskdef_pdftest if I wasn't interested in testing PDFs)
>     [this is just hyperthetical - applets is currently part of base]
> 
> (4) we could turn each plugin into an antlib so we could use namespaces
>     if we wanted to, so we could have both <wt:clickLink...> and
>     <pdf:clickLink...> if we chose without a name clash.
> 
> Let me know what you think. If there are serious objections I can back
> it out. My reason for wanting to go this way is that I have a customer
> who might want some extensions done and this structure will make it
> easier for me to add them in.
> 
> Cheers, Paul.
> _______________________________________________
> WebTest mailing list
> WebTest@lists.canoo.com
> http://lists.canoo.com/mailman/listinfo/webtest