geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Plugin Enhancements
Date Thu, 15 Jun 2006 04:24:44 GMT
One of the folks at the Geronimo talk at the Enterprise Open Source
conference in NYC was from a university that uses Apt, RPM, and tools
like that to manage their patches and infrastructure.  They were
especially interested in find ways like that to distribute plugins.
He mentioned a feature in (or going into) Maven that would let it use
a different kind of repository back end (jpackage I think?  The
Java-on-Linux packaging effort).

It would be nice to figure out how to better leverage the Maven code
to populate and access the repositories, and make that layer more
pluggable (Brett or Jason, can we talk about this?).  It would
certainly also be nice to take advantage of tools like RPM and Apt to
install updates and plugins.  That might be a better way to distribute
plugins to a cluster, if the end user is on Linux.


On 6/15/06, Aaron Mulder <> wrote:
> (Changing subject to make thread more generic)
> So there are two ways to create a plugin.  One is to get the module
> running in Geronimo and then create the metadata file and export the
> CAR -- there's an API for this (which the console uses) and the
> Eclipse plugin could use too.  The other way is to use the Maven
> packaging plugin, copying in the plugin metadata file as part of the
> build (this is what the examples do).  I suppose you could also JAR up
> the module directory in the repository, though I wouldn't recommend
> that approach.  I assume the API approach would be best for Eclipse
> integration -- there's a call to get the default metadata (including
> dependencies gleaned from the module itself), a data structure for the
> metadata you can populate however you want, a call to update the saved
> metadata for the plugin, and a call to get a packaged plugin
> InputStream back out.
> As far as distributing to a cluster, that would require push and so
> far we've only implemented pull.  There's no reason it can't be done.
> I think it would make sense to start by defining a format that would
> hold a plugin and all its dependencies in a single file (ZIP/JAR) so
> the slaves don't need to separately download dependencies.  Then we
> can probably use the remote deploy application and the deploy tool/API
> (with perhaps minor enhancements) to send the plugin out to many
> servers.
> As far as sensitivity to releases, currently you can omit the Geronimo
> version entirely and it will run with any release.  You can also list
> many supported releases.  I don't think it's worth doing more until we
> have wider agreement on version wildcards or ranges, though perhaps we
> do with the 1.1.* approach.
> Thanks,
>     Aaron
> On 6/15/06, Matt Hogstrom <> wrote:
> > I was talking to a set of folks that are looking at Geronimo and one of the unique
things they are
> > interested in that Geronimo has and others do not is the plugin support.
> >
> > They're view of the world is that their developers use Eclipse as their IDE and
like the WTP work
> > that has been done so far (koodos Sachin).  What they would like the ability to
do is from Eclipse
> > be developing and testing and testing an application and when they get it right
is to export that
> > application in as a CAR (not from the Admin Console) directly out of Eclipse.
> >
> > There were several things that they asked about:
> >
> > One item was sensitivity to releases.  From their perspective this would be useful
if the CAR could
> > tolerate several versions of Geronimo.  If its only good for a specific version
that limits the
> > usefulness.
> >
> > Integration with Eclipse rather than having developers work the Geronimo console.
 It didn't seem as
> > compelling.
> >
> > They would like the Geronimo infrastructure to be able to distribute CARs throughout
a cluster.
> >
> > They had several other thoughts about G that would make it interesting as well but
they are Geronimo
> > server related so I'll post in another thread.
> >
> > Aaron, thoughts?
> >
> > Matt
> >

View raw message