So here's the thing with datasources. There just has to be one with a matching name. We don't attempt to validate what it points to. So you can have MyAppDataSource on dev, test, and prod servers, pointing to a different database on each box. Then if you deploy an application plugin that depends on MyAppDataSource, it will work on all 3 environments, pointing to the database you'd expect in each.
There's one subtlety. If you define the MyAppDataSource as a dependency, and it's not on the target server, the plugin installer will attempt to download and install that data source (which you may want if you normally clone from developer to developer). If you define the MyAppDataSource as a prerequisite instead, then it must be installed on the server before the plugin will attempt to install (which you may want if you're talking about installing the plugin to dev, test, and prod where it wouldn't be valid to copy a data source from anywhere else). As a side note, someone's also asked (I think at JavaOne) if we could add more options around data source validation, so they could say "depends on Oracle 9.x" as part of the data source dependency. I think he blew a lot of time debugging only to find that test had Oracle 9 and prod had Oracle 10, or something along those lines. I'm certainly open to adding more options around data source dependencies. Thanks, Aaron On 6/15/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
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 in 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 CAR 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 <[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 >> > >> > > >
