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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
