-Donald
Aaron Mulder wrote:
Sourceforge is kind of slow, which is my main objection. But perhaps we can use it as a start. What's Javaforge? Thanks, Aaron On 6/9/06, Donald Woods <[EMAIL PROTECTED]> wrote:Inline below. Aaron Mulder wrote: > On 6/8/06, Donald Woods <[EMAIL PROTECTED]> wrote: >>> BTW - How can we add new Plugins to the geronimoplugins website? Are we>> going to setup a Geronimo subproject (like Daytrader) with the site >> framework checked into svn, along with any scripts needed to build the >> plugins? It seems convoluted to have samples and plugin builds in the >> main Geronimo tree, which are not shipped with the server or >> automatically pushed to geronimoplugins. Wouldn't it be easier to >> maintain if we moved all the samples out to /trunk/samples/modules and>> all the equivalent plugin configs to /trunk/samples/plugins? That way,>> the Samples and plugins can be built, published and enhanced separate >> from the server development.... > > > Currently, to get a plugin added to the web site, you can mail it to > me. If you want to help out there, it would be great to have a script > that read the plugin.xml files and emitted the various PHP files with > all the plugin info! Currently it's a little more manual. :) > > We should definitely have a separate are in the SVN tree for the > samples. There's no reason they should be tied to the Geronimo > release schedule. > > We also need a non-Apache space where we can write the plugin wrappers > for various interesting LGPL projects. If you create a project on Sourceforge or Javaforge, I'll come and help. How about project=geronimoplugins to match the website name? -Donald > > Thanks, > Aaron > >> Aaron Mulder wrote: >> > On 6/7/06, Donald Woods <[EMAIL PROTECTED]> wrote: >> > >> >> Why shouldn't the Plugin support be as robust as module >> dependencies and >> >> allow the user providing the plugin to decide if they can support >> >> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only >> support>> >> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to >> >> me and doesn't follow previous email threads about not deviating from>> >> Maven2 versioning behavior... >> > >> > >> > But what you've said here is "why shouldn't the plugin support be as >> > robust as A and allow B" where A != B. Module dependencies let you>> > specify an exact version or no version. Plugin dependencies also let >> > you specify an exact version or no version. Neither of these support>> > 1.* or 1.1*. >> > >> >> Just as with the Tomcat JSP/Servlet Examples, you could easily >> provide a >> >> Plugin which should work on all 1.x releases.... >> > >> >>> > My preference it to opt-in supported version, not opt-out unsupported>> > versions. So I'd like the plugin developer to try a plugin on a>> > Geronimo version and if it works, list that version as supported. The >> > alternative will most likely lead to Geronimo being willing to install>> > a plugin but the plugin not working. If we get fancier version >> > dependencies we can consider things like "1.1.*" but I'm not sure I >> > like that. I'm willing to be convinced, but I'd want to hear from >> > more plugin developers/maintainers. >> > >> > Thanks, >> > Aaron >> > >> > >> >> >> > >
smime.p7s
Description: S/MIME Cryptographic Signature
