I wonder if there is a way to eliminate the need of compatibility plugin for samples to install on multiple maintenance releases of geronimo (such as 2.1.2, 2.1.3, etc.).
I remember in the plugin catalog, there is a property called geronimoVersion. I wonder if we could allow users to specify a geronimo plugin to run on multiple maintenance releases of geronimo in this property, for example below means that the geronimo plugin can run on G server v2.1.2+. <geronimoVersion>[2.1.2,)</geronimoVersion> Since we know there are only minor changes in maintenance releases, when this property is set to allow the geronimo plugin to run on multiple G releases, maybe we could loose our plugin validation a bit to allow the installation to go through? I can see this function being useful for most of our samples which we don't change between maintenance releases (or even major releases). Lin On Tue, Aug 26, 2008 at 9:29 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: > We've had numerous discussions on how to facilitate plugins created for an > earlier release running on a later release. It seems that the only viable > alternative we keep coming back to is to create artifact alias entries to > map the older versions to the latest version. I'd like to have some > solution (even if imperfect) for Geronimo 2.1.3 so plugins we've released > for previous versions might have some hope of running on 2.1.3. My primary > concern is that samples that we hope to release for 2.1.2 will also install > on 2.1.3 using this mechanism. Perhaps even older plugins (like directory) > could be installed in 2.1.3. > > To that end, I've created 3 compatibility plugins (not yet checked in) under > the server /plugins. > > compat21 - includes alias mappings from 2.1 cars to 2.1.3 cars > comapt211 - includes alias mappings from 2.1.1 cars to 2.1.3 cars > compat212 - includes alias mappings from 2.1.2 cars to 2.1.3 cars > > I've already verified that I can install the 2.1.2 samples in a 2.1.3 server > image using the compat212 plugin. > > The structure is such that once we release a 2.1.3 version I anticipate that > we would create a compat213 for inclusion with the other compat* plugins in > 2.1.4. > > These aren't very sophisticated. They simply include all artifact alias > entries for all cars shipped in the specified lower level release and map > them to the equivalent 2.1.3 release car. There are no tomcat/jetty > specific versions of the plugins ... just one compat plugin per prior > release with entries for all of the cars shipped with that release. I don't > think the extraneous entries will cause any harm in the opposite server. > Also, I'm sure there are client cars included int he list that can be > removed (or perhaps moved to a client-artifact-aliases list). I hope you > will help me clean it up once I check it in. > > So now the questions: > 1) I'd like to check these into branches/2.1 ... should I? Just thought I'd > check in case there are strong objections to this approach. > 2) I'd like to include all 3 compat* plugins in all 2.1.3 assemblies that we > ship by including them in the boilerplate. This will provide "out of the > box" downward compatibility for plugins that have dependencies on the lower > level cars. Any concerns? > 3) Are there other entries that we should include beyond the cars included > in the javaee5 assemblies? > 4) Do we need to do something equivalent for client-artifact-aliases? What > should be included there? > > > Thanks, > Joe >
