Agree, but we really have two sets of plugins to host -
1) server CARs that we want to provide as plugins
2) samples and other ASF apps (like Jetspeed2) that should be delivered separately from the server releases


-Donald


Matt Hogstrom wrote:
See my other post. I hit send too quickly. I DO think we should host plugins at the ASF.



Aaron Mulder wrote:

I gather from what you're saying you don't think the Geronimo project
should host any plugins?  How do others feel?

Thanks,
   Aaron

On 6/12/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

As you say since plugins are not owned by the Geronimo project (ASF), not released by the Geronimo project and are not under the oversight of the porject perhaps the best thing to do is to put in an HTML link pointing to www.GeronimoPlugins.com and that way that project can manage the releases,
interdependncies, etc.  I think its a nice clean break.

When Geronimo hosts its own plugins then it would make sense for us to document them here.

I don't think we should host documentation as part of the Geronimo Project that is not under ASF
license.

The plugin framework is part of Geronimo...the content is not and is hosted externally. I think
this is the division.

Matt

Aaron Mulder wrote:
> On 6/12/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
>> As far as I can see, plugins are part of Geronimo and they should be
>> in the 1.1 documentation space.
>
> I diasgree.  Plugins will be versioned separately from Geronimo, and
> will not all be developed by the Geronimo team.  What will we do with
> the Geronimo 1.1 documentation if Plugin Foo is at version 1.0 when
> Geronimo 1.1 ships, but Plugin Foo goes through version 1.1, 1.2, and
> 1.3 before Geronimo 1.2 ships?  Will we constantly be updating the
> Geronimo 1.1 documentation?  I don't think that makes sense.
>
> I think there should be a Plugins space with the Plugin Foo
> documentation.  In the Geronimo 1.1 documentation we can include a
> list of known available plugins with references to their individual
> documentation pages, or we can actually repeat some common usage of
> popular plugins, but I don't think we should try to capture the
> current state of all plugins (and either have it get terribly outdated
> or need frequent changes to the "finished" parts of the 1.1
> documentation).
>
>> The plan is, as I proposed several times in earlier emails, to move
>> all the content from MoinMoin to
>> Confluence. Most of the content in the MoinMoin is outdated or
>> duplicated, the docs that are still
>> valid should be moved to a section within the new structure in
>> confluence. Those topics that don't
>> fit either the User's or Developer's guide should go into the Geronimo
>> SandBox space which is
>> version independent. This space should hold historical data like the
>> logo contest for example.
>
> OK.  Who's going to do that migration?  Also, I have to say, I don't
> think that putting documentation in a different Wiki is going to
> automatically keep it up to date.  It's a nice opportunity to clean
> up, but I imagine we'll need a regular cleaning process if we don't
> want our Wiki to get out of date.
>
> Thanks,
>    Aaron
>
>> Aaron Mulder wrote:
>> > I'd like to add some documentation for specific plugins to a Wiki. I
>> > don't know if the plan is to migrate pretty much everything to
>> > Confluence or only keep our main documentation there and use MoinMoin
>> > for the rest or what.
>> >
>> > Still, if we're documenting available plugins, that's probably more or >> > less project documentation, and should go in Confluence anyway. Could
>> > someone with admin access create an Apache Geronimo Plugins space?
>> > (The plugins will be on a separate release track from Geronimo so I
>> > don't think the plugin docs should necessarily go in the 1.1 docs.)
>> >
>> > Thanks,
>> >    Aaron
>> >
>>
>
>
>






Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to