You can install a plugin from the command line deploy tool -- just use
the "install-plugin" command point it to the CAR file. The down side
is that if that plugin has dependencies, they will be resolved against
a remote repository (as listed in the plugin metadata). So you'd
presently have to pluginize all the dependencies and install them in
"just the right order" to avoid hitting a remote repo. One of the
items on the plugin todo list is to support something like a ZIP file
where everything attempts to resolve against the contents of the ZIP
before going to remote repositories.
For purposes of an installer, you could extract all the "source JARs"
to a directory formatted like a Maven 2 repo, and then use a file:///
URL as the remote repository. I think the problem there is that the
remote repository listed in the plugin metadata presently overrides
the location the plugin was actually loaded from. It should be easy
enough to add some kind of flag to reverse that so the "current"
repository gets priority during an install.
Thanks,
Aaron
On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> 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.
--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
