You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Donald Woods <dw...@apache.org> on 2008/05/07 19:21:12 UTC
Re: plugin repository for 2.1.1
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.)
-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
>
>
>
>
Re: plugin repository for 2.1.1
Posted by Joe Bohn <jo...@earthlink.net>.
We have somewhat of a fairly complete geronimo-plugins.xml generated now
as a result of a Geronimo build or building other plugins. It just
requires some minor edits afterward before we can publish it. The
geronimo-plugins.xml is created (or updated) as a peer to the maven
repository (under .m2). It's difficult to tie this directly to just one
build since the catalog of plugins is typically created from building
several projects (Geronimo server, samples, components, or whatever).
Joe
Jason Dillon wrote:
> 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 <jo...@earthlink.net> 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
>>>>
>>>>
>>>>
>>>>
>>
>
Re: plugin repository for 2.1.1
Posted by Jason Dillon <ja...@planet57.com>.
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 <jo...@earthlink.net> 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
>>>
>>>
>>>
>>>
>
>
Re: plugin repository for 2.1.1
Posted by Joe Bohn <jo...@earthlink.net>.
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
>>
>>
>>
>>