geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: Plugin Enhancements
Date Thu, 15 Jun 2006 13:18:16 GMT
I've had similar discussions about Maven with folks.  One other area that people were interested

about with plugins that I forgot about was configuration.  It's fine to develop an app that
has a 
datasource that's local but there is little likelyhood that the same datasource will be used
production.  They wanted a way to be able to edit those attributes. Really, more of a structured

list of attributes rather than looking in the console.  They wanted to know which ones the
depended on and a way to tweak them.

Aaron Mulder wrote:
> 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.
> Thanks,
>    Aaron
> 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