geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <>
Subject Re: Testsuite module, with basic/crude Selenium support
Date Thu, 07 Sep 2006 21:56:08 GMT
Please review the latest patch at

I have worked on all but one of the issues we discussed here. The
remaning issue is the one of delegating stuff to a JMXProxy.

I have issues getting my geronimo server to start. So I shall go and
chase that problem for now.
Module 18/20 org.apache.geronimo.configs/webconsole-jetty/1.2-SNAPSHOT/car
      17:27:31,528 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
org.apache.geronimo.console.servlet.ContextForwardServlet in
classloader org.apache.geronimo.configs/webconsole-jetty_framework.war/1.2-SNAPSHOT/car
	at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(


On 9/6/06, Jason Dillon <> wrote:
> 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.
> --jason

View raw message