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
