I like the idea of a component repository and I think that whether a component should be in the SM code repository would be due to the following factors (not a complete list - just what comes to mind ;) :
1. Is the component likely to have a wide audience of users? 2. Is the component from a standalone project? 3. Is the component large enough to be an SE? 4. Does the component leverage existing component convenience classes from SM? - i.e. is there a hard dependency that would make managing the component easier if it was integrated? As for what components we ship with the distribution, I would like to get some feedback from the users/developers since we don't want to go down the road of making the base distribution unreasonably hard to work with. Grant M. -----Original Message----- From: Guillaume Nodet [mailto:[EMAIL PROTECTED] Sent: Wednesday, 11 October 2006 2:18 PM To: servicemix-dev@geronimo.apache.org Subject: Location to host JBI components I'd like to start a thread about where JBI components that are contributed by users should be hosted. I see several choices: * host them at ASF in the ServiceMix svn tree * host them somewhere else * do not host them * provide a nice catalog of available components like http://geronimoplugincentral.org/ I think the last point is necessary as we at least need maybe not a full blown web site but a list of available JBI plugins. As for hosting components, I have pondered this a bit. There may be different cases: for example the ODE project has a JBI component that they host, and that's fine. I'd like tuscany to provide a SE, but they don't seem to have the bandwidth / will to work on that currently. For small components donated by non developers, I think we should try to host them at the ASF if there is no license problems and provide the authors will committer access if they maintain the component (should we put them in the sandbox first ?). It also leads to several somewhat related questions: * should all components have the same lifecycle than the container ? * if we restructure the svn source tree as stated in a previous discussion, we could easily split the component lifecycle from the container lifecycle (note that the container has had much less changes than the components) * which components should we ship in the distribution or should we ship any components at all ? if we split the container from the components, we could have separate downloads for components / examples. -- Cheers, Guillaume Nodet
