If that is the case, then why don't we add support to auto-generate
this for each build and stuff the required bits into the maven
repository?

--jason


On Thu, May 8, 2008 at 12:44 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:
> Donald Woods wrote:
>>
>> Seems that we need a unique plugin repo for each release, given how we now
>> build plugins based on the content in pom.xml instead of supplying a
>> separate plugin file....  Maybe there are some additional car-maven-plugin
>> enhancements needed, so you can define a range or that any sever release is
>> supported by the plugin/car being built.  Or maybe  as David Jencks has
>> suggested elsewhere, we need to setup the artifact_aliases.properties in
>> each server release to alias prior releases (like 2.1 and 2.1.1) to the
>> current release (which would be 2.1.2 for the next release.)
>
> Heh ... funny you should mention this now.  I came the same conclusion
> yesterday as well (ie. we need a catalog per release given our current
> process for creating the plugins).  I've decided that we need a catalog per
> release for those already out the door and we can think of getting more
> creative for future releases.
>
> Joe
>
>
>>
>>
>> -Donald
>>
>>
>> Joe Bohn wrote:
>>>
>>> I've got some questions (and possibly some issues) with the plugin
>>> repository for Geronimo 2.1.1.  I went out there attempting to update the
>>> plugin catalog after the release of 2.1.1 (as I had done after 2.1 was
>>> released).  However, I hit some issues and have some questions:
>>>
>>> 1) I learned too late that the download plugin repository list should
>>> have been changed before we cut the release if we wanted the unique catalog
>>> for 2.1.1 plugins to be the default (specified in
>>> framework/configs/plugin/pom.xml).  As it stands now, the default plugin
>>> catalog for Geronimo 2.1.1 is pointing to the catalog for Geronimo 2.1.
>>>
>>> 2) Perhaps sharing the plugin catalog is the correct thing. I'm really
>>> not sure if that is best (or even possible).  Can we have one catalog
>>> support multiple Geronimo releases?  ... I would presume we could.   Is that
>>> what people were assuming or is the assumption a catalog per release?
>>>
>>> 3) Assuming we should have our own catalog for G 2.1.1 .... I created one
>>> and put it under out there under
>>> geronimo/site/trunk/docs/plugins/geronimo-2.1.1/.  Naturally, you must
>>> manually add the catalog for 2.1.1 since the default wasn't updated prior to
>>> the release.
>>>
>>> 4) The catalog from #3 seems to work but I think I need to update some of
>>> the plugins (esp. samples) so that they are supported on Geronimo 2.1.1.  So
>>> it appears that regardless of if we have shared or unique catalogs among
>>> releases we will need to update the plugins to support the newer releases if
>>> they are shared.  Is that correct?  (I specifically attempted to install the
>>> 2.1-SNAPSHOT jsp sample which failed in 2.1.1 due to missing 2.1
>>> dependencies).
>>>
>>>
>>> I was a bit thrown off by all of this since we didn't have to make the
>>> same change for the download list when Geronimo 2.1 was released even though
>>> we did update the catalog.  This was because the version of the catalog was
>>> already specified as 2.1 even while the server itself was still
>>> 2.1-SNAPSHOT.  I wonder if it is wise to have the catalog listed as if
>>> released even when the dependent server (and plugins) are not. BTW, this is
>>> also the current case for Geronimo 2.2 and it's catalog. Thoughts?
>>>
>>> Joe
>>>
>>>
>>>
>>>
>
>

Reply via email to