geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Assemblies assemblies everywhere and which one to ship?
Date Fri, 12 Jan 2007 19:52:34 GMT
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.


On 1/12/07, 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.
> --jason
> On Jan 12, 2007, at 11:57 AM, Paul McMahan wrote:
> > On 1/12/07, Jason Dillon <> 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
> > 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

View raw message