I've been gone for a couple days, and 461 avalon messeges later I am a little overwhelmed. :-) I agree that the requirement that Apache hardware doesn't support resources using GPL or LGPL software is to me the biggest driver for another component repository. That, and I think the barrier to entry on Apache needs to remain high for new committers.
I wrote (with Preeme) an Avalon wrapper for Hibernate. Not knowing, I originally committed it to the Fulcrum project. It was pointed out the LGPL issues, whereupon it wandered homeless until it ended up in the HibernateExtensions project under Hibernate. Now, some may argue that components that integrate Avalon to something else should live with the "Something Else", but I think they should be aggregated together. I am a committer on the Hibernate project only because of this component, really I should be a committer on an Avalon Component Repo project, as my expertise isn't Hibernate development per se, but integrating Hibernate in an Avalon environment. But, I am not a Avalon committer b/c I don't have the expertise there (yet :-) ) either. What about leveraging the Fulcrum project for Apache compatible components? It already has 10 or so components, and is being brought inline with the latest and greatest thinking.. And, since I have lots of ideas for components that all have licensing issues, why not have a sf.net site? Maybe instead of Avalonia, just call it avalon-components.. Just like there is a maven-plugins site on sf.net.. A place with a lower bar to entry for components that for one reason or another can't make it into either the Avalon project or into Fulcrum or a parent project like Hibernate.. I have been thinking about playing around with implementing a custom lifecyle extension to map custom "start" methods to the "Startable" interface, and I need CVS etc to support me. Instead of demanding access to a sandbox/playground, or constantly working through patches, I think avalon-components would be a fine place to stick my code. (even though technically it isn't a compnent...) Then, if it finds favor, then talk about integrating it in.. there are other components that aren't ASF compatible that I would like to opensouce, but I need a home to put it in. We could also talk about the Xingu repo becoming better highlighted as a non-apache repo that people could ask if they would host their code as well.. I think multiple component repositories are already a reality, but having one that was blessed or pointed to first would be nice.. Eric > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > Sent: Friday, November 07, 2003 10:04 AM > To: Avalon Developers List > Subject: [Counter PROPOSAL] Avalon Component Index > > > The thread on the Avalon Component Repository has some merits > because it > highlights a couple fundamental problems with the ready > supply of shared > components. There are more than just the ones I am listing here: > > * Development in Scratchpad and moving to Components is > resource intensive > and does not encourage quick innovation. > > * We should be able to have a repository with components in > various stages > of maturity. > > * The Avalon community is just not set up to foster a > Component repository, > and the oversight requirements are beyond the scope of the > Avalon PMC as > it is defined right now. > > * Hosting the repository on ASF hardware means we can't > support components > that use GPL or LGPL software. > > All of these are legitimate issues. Throughout the > conversation, other > points came to light in regards to the lack of standards for > one component > definition, and the fact that some components are not made in > a container- > neutral manner. > > The solution I propose would allow and foster the creation of several > component repositories, but provide one index so that folks > know where to > look for components that they may want to use. Lets focus on the > infrastructure so that we don't have the issues associated > with central > management. We can leverage the concepts behind existing > technologies like > WSDL and the Web Services indexing service. > > As long as we know where an indexing service is, we can > verify if the component > in question will work for us. All we need to know is what > meta-data is needed > to ensure that the component will work, and what would be an > acceptable way to > programmatically access it. > > Such an index would have to be easily updatable, and > distributable. For > instance, we can have all the index services able to find > each other like > the peer-to-peer networks out there. The technology exists, > and it just > begs to be adapted for something more powerful than > downloading the latest > Britney Spears music (yech, I prefer people with real vocal chops). > > If we focus our energies down this route, we can help build > an infrastructure > that encourages mirroring and distributed component > repositories that can > focus on areas of expertise. Building many smaller > communities scales better > than trying to have one all encompassing community because > the signal to noise > ratio is much better. > > So whadaya think? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
