On Jan 12, 2007, at 10:43 AM, Jason Dillon wrote:
How easy is it to install a set of plugins from the command-line?
And don't plugins require a remote repository to hold the
archives? While I think that this is good to allow installation of
custom plugins, I don't think its good to use a remote repo to
install system components. I'd rather ship everything in one
assembly, and then have a simple command-line tool to allow
customization of what is installed.
I'm no expert on how plugins currently work, but it is my
understanding that it is not that easy to configure a server to use
a set of plugins from he command-line (or driven off of a
configuration file). For build automation and TCK testing it would
be a PITA to require the console and then need to automate clicks
to setup the right configuration for testing.
Eventually... I think that everything (except the core kernel and
deployment system) should be in some self-contained plugin, which
could be zipped up in an archive, or as a set of xmls and jars
which could be deployed into the server.
My understanding is that we are not really to that point yet,
hopefully once 2.0 is out we can focus on some of these usability
and configuration issues.
Can't one of the maven plugins install geronimo plugins? e.g. the
car-maven-plugin? I think its the same as installing a config/module
into a server under construction like we do in the assemblies.
I think there's a command line deployer option to install a plugin
but I'm not sure I've used it.
My idea with the abandoned installer project was to start with a
basic server (what joe has as "framework" I think) and add configs/
plugins from a maven repo inside the installer jar. I still think
this is the way to build an installer.
Another possibility for something you can download is one server with
all the configs/plugins in it and a lot of different config.xmls for
different purposes. A script could copy the appropriate config.xml
in place and then prune the server's repo so only the stuff used in
the config.xml is left. A slight variation on this would start with
a basic framework config.xml and scripts would enable various configs/
plugins, followed by pruning.
Lots of promising ideas, so little time.
thanks
david jencks
--jason
On Jan 12, 2007, at 11:57 AM, Paul McMahan wrote:
On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
If we do start shipping 8 (or more) different assemblies... which
I think is
crazy, then we probably don't want to hook them all up to the
default build,
as it will just cause it take longer and longer to run.
We really need to get plugins functional so that we can build one
assembly.
Please... :-)
AFAIK the plugin functionality already works sufficiently well to
support this approach. And the infrastructure should already be in
place as well since the plugin repository catalogs at
geronimo.apache.org point to maven repos where the Geronimo CARs get
published.
Granted we've only used plugins for installing applications so far
and
really haven't tried using plugins to install or replace core jee5
services, so there may be missing functionality that needs our
attention. Only way to know for sure is to identify each config that
should be provided as plugin, map out its dependencies, and add a
geronimo-plugin.xml to the CAR file that maven builds. Then update
the plugin catalog so when that CAR gets published to the maven repo
it will be installable as a plugin. There are several examples in
trunk/configs.
Best wishes,
Paul
