geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Testsuite module, with basic/crude Selenium support
Date Thu, 07 Sep 2006 03:35:04 GMT
On Sep 6, 2006, at 8:03 PM, Prasad Kashyap wrote:
> Here are the use case scenarios I thought of  -
> UC #1 : use goal in testsuites. The modules for deployment in this
> execution typically comes from the testsupport project. For most
> testcases we can build the modules with the plans inside them. A few
> testcases that need to test a deployment with an external plan can
> specify the plan in the config.
> UC #2: use goal by others. The modules for deployment in this
> execution may come from a repository or be specified as a non-artifact
> archive. Even here, the plan, if need be, can be specified in the
> config along with the <modules>. However what I'd eventually like to
> do here is be able to deploy a list of modules.
> To be able to deploy a list of modules, the #plan param needs to get
> inside the #module param so that there can be a plan specified for
> every module config.

None of these cases require the moduleId and defaultModuleId bits,  
which was what I was hinting at.  A list of modules, with optional  
plan such be fine.

Sounds like that if you did want to do some selection, that it would  
be over one set of modules or another... but I still don't see the  
need for that.

>> Why do we have 'distribute' and 'undeploy'?  Why not 'deploy' and
>> 'undeploy'?
> "distribute" and "deploy" are some of the options passed to the deploy
> tool. The former option just "installs" the modules into G while the
> latter "installs" and starts it.  Now I went with distribute +  start
> sequence since that is what G had in the old itests. If we think we
> can get rid of it and just use deploy, then I'll be glad to change it.

I'd say, call the goal deploy, and add an optional startModule flag  
to indicate if distribute() or deploy() should be used.

>> In DistributeModuleMojo, why is #plan a String and not a File?  The
>> plexus container will perform the equiv of your getFile() for you.
> I thought about it. But eventually I wanted to move the #plan inside
> the #module. So I left it as String.

You can still have a File in a helper object and Plexus will inject  
it.  We should create a ModuleConfig, that extends from ArtifactItem  
(like AssemblyConfig) and add that field.

>> Any reason why we have explicitly set the TCL in getDeploymentManager
>> (), was the TCL that maven setup not correct?
> Hmm.. Not that I know of.  Must be from legacy code. But I'll reserve
> judgement on it until I investigate that further.

Well, if we don't need to set it... lets not.


View raw message