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 >