You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/11/07 10:04:16 UTC
[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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Counter PROPOSAL] Avalon Component Index
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 12 November 2003 18:26, Berin Loritsch wrote:
>
>>What the index needs is a way to identify the interface of the components
>>so that we can find what will work with our system.
>
>
> I was laying down for a second, and a thought struck me (hurt like hell)...
>
> What we are actually looking for already exist a spec for. It allows indexing
> and searching for resources of a known type with attributes set to certain
> values.
>
> I am thinking of RDF. Exactly what is required.
>
> 1. We need to define a RDF schema.
> 2. There should be RDF capable indexing engines.
> 3. RDF server shouldn't be too hard, right?
> 4. Abstract RDF concepts and features into an easy to use Client API.
> 5. Provide an implementation of RDF client.
> 6. Implement the Eclipse Plugin to use it.
> 7. Documentation of the whole shabang.
> 8. Get it all up and running.
>
> Piece of cake.
>
> Am I on track of your thought train now??
Yep!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Counter PROPOSAL] Avalon Component Index
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 12 November 2003 18:26, Berin Loritsch wrote:
> What the index needs is a way to identify the interface of the components
> so that we can find what will work with our system.
I was laying down for a second, and a thought struck me (hurt like hell)...
What we are actually looking for already exist a spec for. It allows indexing
and searching for resources of a known type with attributes set to certain
values.
I am thinking of RDF. Exactly what is required.
1. We need to define a RDF schema.
2. There should be RDF capable indexing engines.
3. RDF server shouldn't be too hard, right?
4. Abstract RDF concepts and features into an easy to use Client API.
5. Provide an implementation of RDF client.
6. Implement the Eclipse Plugin to use it.
7. Documentation of the whole shabang.
8. Get it all up and running.
Piece of cake.
Am I on track of your thought train now??
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Counter PROPOSAL] Avalon Component Index
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 12 November 2003 18:26, Berin Loritsch wrote:
> Niclas Hedhman wrote:
> > On Friday 07 November 2003 17:04, Berin Loritsch wrote:
> >>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.
> >
> > An index is not a repository. People can look up an index, interpret the
> > content, move on to N locations, interpret the "local language", figure
> > out which component can do what is needed, find the download area, and
> > manually insert them into a development effort.
> >
> > How about a tool doing this?? Not that easy...
>
> That is what I was getting at.
Sorry, it wasn't obvious, sounded more like a "web site with pointers"...
> And the fact that an index is not a repository was the exact point I wanted
> to make. I think having a one size fits all repository is destined to
> fail. Having an index to support the infrastructure of finding components
> that would be needed from multiple repositories would allow for several
> repositories that are *focused* on a particular problem space. That would
> facilitate islands of expertise which can be leveraged.
OK, you have a lot of work set out in front of you ;o) (or us...)
Since I am concentrate my efforts on the IDE use-case, my conclusion is
roughly like this;
The Eclipse plug-in can (and probably should be) completely
repository/directory agnostic. It only understand a fairly simple event-based
interface, and depend on implementations to connect to my "simple repo"
today, and to the hyper-duper searchable one tomorrow
So, now I just need to nail down the use-case.
> We would need to look at options for "self management". Have it all hosted
> as an Avalon project using Merlin to run the index server, and it would
> really rock.
Sure would, especially if Merlin is "componentized" down to the main() method
(or beyond), it can update itself ;o).
Does anyone know anything about the P2P model. Would that be feasible and
desirable?
Overall, I agree with you on the technical vision, just that I believe it is a
fairly large step to make (I like babysteps), and just freak out when I see
the amount of work required to make it a reality.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Counter PROPOSAL] Avalon Component Index
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Friday 07 November 2003 17:04, Berin Loritsch wrote:
>
>
>>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.
>
>
> An index is not a repository. People can look up an index, interpret the
> content, move on to N locations, interpret the "local language", figure out
> which component can do what is needed, find the download area, and manually
> insert them into a development effort.
>
> How about a tool doing this?? Not that easy...
That is what I was getting at.
Most of the hard work has been done. Look at the Web Services architecture.
They have WSDL to identify the interface of the web service, so that we can
look up compatible implementations. They have an index service (can't remember
the acronym right now) that provides a way to find the servers hosting the
component, and any meta-info that would help make a decision for it.
And the fact that an index is not a repository was the exact point I wanted
to make. I think having a one size fits all repository is destined to fail.
Having an index to support the infrastructure of finding components that would
be needed from multiple repositories would allow for several repositories that
are *focused* on a particular problem space. That would facilitate islands of
expertise which can be leveraged.
What the index needs is a way to identify the interface of the components so
that we can find what will work with our system. Next we need to have a bunch
of meta-info to allow for human intervention with the decision process. All
our interaction would be with the index, so the index itself would take care
of downloading (or proxying the request) for the component itself. Since we
are not *hosting* any of the components, but merely providing a lookup service,
we can have LGPL or GPL implementations mixed with our ASL implementations.
The major thing is that the interface has to be packaged separately and licensed
under the ASL or compatible license. Our contract is with the license, and our
code that uses the components would be using the interface directly--not the
implementation. The way our containers work, each component is essentially
isolated as much as possible from each other.
We start with the simple part--which is providing a lookup service for
components based on their interface. We can probably use the Manifest entries
that identify interface as the lookup key, and expand as necessary.
We would need to look at options for "self management". Have it all hosted as
an Avalon project using Merlin to run the index server, and it would really
rock.
It also means we don't have to answer the question of one contract for all
Avalon components. We have the containers the component was designed to be
compatible with, and filter out all the containers that won't work for our
project.
Of course we would seed it with our components, but I believe that this would
be the best way to get the message out there that we are serious about making
Avalon a force to be reconed with--and we don't have to ram it down anyone's
throat to do that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Counter PROPOSAL] Avalon Component Index
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Friday 07 November 2003 17:04, Berin Loritsch wrote:
>
>
>
>>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.
>>
>>
>
>An index is not a repository. People can look up an index, interpret the
>content, move on to N locations, interpret the "local language", figure out
>which component can do what is needed, find the download area, and manually
>insert them into a development effort.
>
>How about a tool doing this??
>
The component broker!
>Not that easy...
>
But feasible.
http://www.osm.net/doc/discovery
Stephen.
>
>
>Niclas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Counter PROPOSAL] Avalon Component Index
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 07 November 2003 17:04, Berin Loritsch wrote:
> 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.
An index is not a repository. People can look up an index, interpret the
content, move on to N locations, interpret the "local language", figure out
which component can do what is needed, find the download area, and manually
insert them into a development effort.
How about a tool doing this?? Not that easy...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Counter PROPOSAL] Avalon Component Index
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 11 November 2003 18:09, Berin Loritsch wrote:
> Yes, but what about my counter proposal to allow many such islands to
> exist, perhaps each with a common focus. As long as we can find them and
> verify that we downloaded what we wanted, then we can have one, two, or a
> hundred such repositories.
>
> Each with their own preferred licensing schemes.
I am in favour of "poolable" but not "transient" when it comes to
repositories... If we can make them survive and thrive in their own right,
SURE....
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Counter PROPOSAL] Avalon Component Index
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Tuesday 11 November 2003 19:48, Eric Pugh wrote:
>
>>I've been gone for a couple days, and 461 avalon messeges
>
>
> It is an idication that the "community is dead" to cite a famous Cocooner...
>
>
>
>>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..
>
>
> I, for one, agree... I think the only issue with the more hard core Apache
> guys (I'm not pointing a big finger at you Stephen) is the "endorsement",
> implied or otherwise, that Avalonia or avalon-components, is given.
>
> Nothing but the name can stop an SF site to get going (except lack of
> interest)...
>
> My personal opinion, ASF have deniability and can wash their hands, Avalon
> gets more components (albeit not all with top quality) and invdividual
> developers gets a lower entry barrier....
Yes, but what about my counter proposal to allow many such islands to exist,
perhaps each with a common focus. As long as we can find them and verify that
we downloaded what we wanted, then we can have one, two, or a hundred such
repositories.
Each with their own preferred licensing schemes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 12 November 2003 16:37, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> >On Tuesday 11 November 2003 19:48, Eric Pugh wrote:
> >>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..
> >
> >I, for one, agree... I think the only issue with the more hard core Apache
> >guys (I'm not pointing a big finger at you Stephen) is the "endorsement",
> >implied or otherwise, that Avalonia or avalon-components, is given.
>
> IM[HC]O, there are a number of different subjects
>
> (a) the barrier to entry
> (b) licensing
> (c) endorcement
Agree.
> The barrier to entry is a pure policy decision that can be made by the
> entity that is asserting oversite[sic!].
Ok... "Contribute a component -> Committer status" ?
> Equally components using non-ASF
> compatible resources should not impact a ASF/SF decision bacause this is
> simply a question of development time downloading (and seperate from
> deployment).
I think Cocoon have gone down that road and are a bit confused over what
constitutes "derived work" in the GPL license. To compile against GPLd code,
you need the JAR (or source), which you can't host/distribute. OTOH, if you
make dummy classes just for the compilation, and if needed at deployment, the
user have to pick up the GPLd elsewhere, then wouldn't the mock classes be
"derived work"? GPL is also a very "weird" license, and open to a lot of
interpretations, and I think that's the reason why ASF board decided to
exclude all (L)GPL code dependency from the codebases.
> Lastly - the question of endorcement - AFAICS, endorcement
> by Avalon requires oversite by Avalon which leads me to an alternative
> proposition.
That is arguable. Comparison, Tiger Woods endorse Nike products, but don't
oversee the product development ;o)
Or more closer to home, MySQL officially endorsed the JDBC driver from (forgot
who) long before it became an official driver.
It is a matter of "to which level"... But never mind.
> The proposal is a Avalon Component project here at Apache - seperate but
> aligned with Avalon. The project would establish policies that
> facilitated a lower barrier to entry of new component iniatives
> (typically micro-projects dealing with a specific component
> implementation) much in the same way that common manages new projects.
OK.
> In this scenario - the new project would establish a PMC responsible for
> oversite, content would be licensed under ASL, and the relationship
> between Avalon and the new project would include our focus on the tools
> and technologies dealing with aspects such as technical complicance,
> validation test suites, component repository tools, etc.
Ok.
Back to Eric's questions;
If we can make them "yes", I'm also in favour...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> The proposal is a Avalon Component project here at Apache - seperate
>> but aligned with Avalon.
>
<snip/>
> Seriously, I think a smart plan is to see what flows from the
> repository@apache.org discussion, see what kind of code we want to
> have in merlin based on that, and perhaps decouple a large part of
> that and combine it with other code efforts in a new project that
> starts off in the incubator.
>
> A possible destination for that would be under ant, under maven, under
> avalon, or TLP.
I don't see the repository@ iniative doing much more than defining a
protocol. After that there is the question of tools and services on
either end of the repository - and about the only thing that seems to be
clear is that there is very little interest in anything more than
plumbing. That means (IMVHO) that the smart stuff will be done here at
Avalon. Secondly - the management of a component repository project is
much more about people, community and focus - and honestly - that's not
going to come out of any of the things being discussed externally.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> The proposal is a Avalon Component project here at Apache - seperate but
> aligned with Avalon.
<snip/>
> In this scenario - the new project would establish a PMC responsible for
> oversite, content would be licensed under ASL, and the relationship
> between Avalon and the new project would include our focus on the tools
> and technologies dealing with aspects such as technical complicance,
> validation test suites, component repository tools, etc.
overhead! I've got no time for another PMC :D
Seriously, I think a smart plan is to see what flows from the
repository@apache.org discussion, see what kind of code we want to have
in merlin based on that, and perhaps decouple a large part of that and
combine it with other code efforts in a new project that starts off in
the incubator.
A possible destination for that would be under ant, under maven, under
avalon, or TLP.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Merlin Lookup versus ECM Lookup
Posted by Eric Pugh <ep...@upstate.com>.
Stephen (and other Avalon guru's)...
I have committed the merlin friendly (merlinized?) version of Configuation.
I ditched the api section as commons-configuration really provides that.
anyone want to review it and let me know?
http://cvs.apache.org/viewcvs/jakarta-turbine-fulcrum/configuration/
Ignore the configuration/src directory.. gotta figure out what I did..
Thought I deleted it, but apparently not..
Eric
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, November 12, 2003 10:49 AM
> To: Avalon Developers List
> Subject: Re: Merlin Lookup versus ECM Lookup
>
>
>
>
> Eric Pugh wrote:
>
> >I am looking at code that Stephen worked over from Fulcrum.
> In the past we
> >always had on the API a ROLE. So, like this:
> >
> > /** Avalon role - used to id the component within the manager */
> > String ROLE = Config.class.getName();
> >
>
> Confession - I have never liked the ROLE notion. It simply
> does not make
> sense to me. Other Avalon guys disagree with me on the
> grounds that ROLE
> can be changed to be something other than class.getName() and
> that this
> is somehow benefitial.
>
> >Is ROLE purely there for use in ECM/Fortress containers?
> Because in the
> >Merlin testcase, instead of a lookup using ROLE, we use:
> >
> >config = (Config) this.resolve( "conf" );
> >
>
> This is different. The abstract testcase has an embedded container
> within it. As such it has access to the appliance managing
> the component
> type. To do someting like the lookup of a component by
> interface name
> can be done in the abstruct unit test code (and I'm lazy so I
> just using
> the existing facilities on block to pull in a component ny name).
>
> However, getting a component relative to a service is
> something we need
> to provide where a component is acting as a component and container
> (whic is the case in the xmlrpc component). Towards that end
> I'm been
> doing so refactoring of the block implementation to make it easier to
> provide different styles of blocks:
>
> * compositional (the current approach)
> * factory
> * finder
>
> In the xmlrpc case and in the unit test case the finder style is the
> most appropriate.
>
> >Because we defined this:
> > <component name="conf"
> >
> class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
> >
> >We could have resolved it as FooBAR if we did this:
> >
> > <component name="FooBAR"
> >
> class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
> >
> >So, should we just leave ROLE on for old users? This code
> really hasn't
> >been 1.0 released yet, so I would rather ditch anything old.
> After all you
> >can look up in your code by anything, not just ROLE in ECM..
> >
>
> In the case of the conf sub-project I would dump the entire API. But
> this gets back to the question - is it actually needed if you run the
> compoent in ECM or Fortress - I don't know! Berin?
>
> >My other question is that in the block.xml we have:
> > <services>
> > <service type="org.apache.fulcrum.configuration.Config">
> > <source>config</source>
> > </service>
> > </services>
> >
> >Now, the only reason to have that is to declare that we export this
> >"service" so that others can use it without writing their
> own block.xml,
> >correct?
> >
>
> Yep.
>
> >So, as long as you lookup 'config/conf' you get back the right
> >object. So I can, in my code do either of these calls:
> >
> >config = (Config) this.resolve( "conf" );
> >
> >or
> >
> >config = (Config) this.resolve( "config/conf" );
> >
>
> Yes - but only if you code is container-side code.
>
> >
> >I just don't quite understand why I could do "conf" versus
> "config/conf", is
> >it because my default container was already called "config"?
> >
>
> Because the container established by the test case is is named as
> whatever the name of the block is named. In the stuff I did
> I typically
> named the containers with the same name as the project.
> Secondly, the
> unit test sets the default block for resolution of names to
> be the block
> that was loader to hold the test compoenents - that's just a
> convinience
> factor. What actually happens when you do a "/config/conf"
> is that the
> request is forwarded to the root container which forwards the
> request to
> the child config container which resolved the conf component.
>
> Stephen.
>
> >
> >
> >Eric Pugh
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> >For additional commands, e-mail: dev-help@avalon.apache.org
> >
> >
> >
> >
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merlin Lookup versus ECM Lookup
Posted by Stephen McConnell <mc...@apache.org>.
Eric Pugh wrote:
>I am looking at code that Stephen worked over from Fulcrum. In the past we
>always had on the API a ROLE. So, like this:
>
> /** Avalon role - used to id the component within the manager */
> String ROLE = Config.class.getName();
>
Confession - I have never liked the ROLE notion. It simply does not make
sense to me. Other Avalon guys disagree with me on the grounds that ROLE
can be changed to be something other than class.getName() and that this
is somehow benefitial.
>Is ROLE purely there for use in ECM/Fortress containers? Because in the
>Merlin testcase, instead of a lookup using ROLE, we use:
>
>config = (Config) this.resolve( "conf" );
>
This is different. The abstract testcase has an embedded container
within it. As such it has access to the appliance managing the component
type. To do someting like the lookup of a component by interface name
can be done in the abstruct unit test code (and I'm lazy so I just using
the existing facilities on block to pull in a component ny name).
However, getting a component relative to a service is something we need
to provide where a component is acting as a component and container
(whic is the case in the xmlrpc component). Towards that end I'm been
doing so refactoring of the block implementation to make it easier to
provide different styles of blocks:
* compositional (the current approach)
* factory
* finder
In the xmlrpc case and in the unit test case the finder style is the
most appropriate.
>Because we defined this:
> <component name="conf"
> class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
>
>We could have resolved it as FooBAR if we did this:
>
> <component name="FooBAR"
> class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
>
>So, should we just leave ROLE on for old users? This code really hasn't
>been 1.0 released yet, so I would rather ditch anything old. After all you
>can look up in your code by anything, not just ROLE in ECM..
>
In the case of the conf sub-project I would dump the entire API. But
this gets back to the question - is it actually needed if you run the
compoent in ECM or Fortress - I don't know! Berin?
>My other question is that in the block.xml we have:
> <services>
> <service type="org.apache.fulcrum.configuration.Config">
> <source>config</source>
> </service>
> </services>
>
>Now, the only reason to have that is to declare that we export this
>"service" so that others can use it without writing their own block.xml,
>correct?
>
Yep.
>So, as long as you lookup 'config/conf' you get back the right
>object. So I can, in my code do either of these calls:
>
>config = (Config) this.resolve( "conf" );
>
>or
>
>config = (Config) this.resolve( "config/conf" );
>
Yes - but only if you code is container-side code.
>
>I just don't quite understand why I could do "conf" versus "config/conf", is
>it because my default container was already called "config"?
>
Because the container established by the test case is is named as
whatever the name of the block is named. In the stuff I did I typically
named the containers with the same name as the project. Secondly, the
unit test sets the default block for resolution of names to be the block
that was loader to hold the test compoenents - that's just a convinience
factor. What actually happens when you do a "/config/conf" is that the
request is forwarded to the root container which forwards the request to
the child config container which resolved the conf component.
Stephen.
>
>
>Eric Pugh
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Merlin Lookup versus ECM Lookup
Posted by Eric Pugh <ep...@upstate.com>.
I am looking at code that Stephen worked over from Fulcrum. In the past we
always had on the API a ROLE. So, like this:
/** Avalon role - used to id the component within the manager */
String ROLE = Config.class.getName();
Is ROLE purely there for use in ECM/Fortress containers? Because in the
Merlin testcase, instead of a lookup using ROLE, we use:
config = (Config) this.resolve( "conf" );
Because we defined this:
<component name="conf"
class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
We could have resolved it as FooBAR if we did this:
<component name="FooBAR"
class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
So, should we just leave ROLE on for old users? This code really hasn't
been 1.0 released yet, so I would rather ditch anything old. After all you
can look up in your code by anything, not just ROLE in ECM..
My other question is that in the block.xml we have:
<services>
<service type="org.apache.fulcrum.configuration.Config">
<source>config</source>
</service>
</services>
Now, the only reason to have that is to declare that we export this
"service" so that others can use it without writing their own block.xml,
correct? So, as long as you lookup 'config/conf' you get back the right
object. So I can, in my code do either of these calls:
config = (Config) this.resolve( "conf" );
or
config = (Config) this.resolve( "config/conf" );
I just don't quite understand why I could do "conf" versus "config/conf", is
it because my default container was already called "config"?
Eric Pugh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 12 November 2003 17:32, Stephen McConnell wrote:
>
>>Niclas Hedhman wrote:
>
>
>>>LGPL is probably compatible with ASL, BUT ASF has said NO on being
>>>involved, I think largely due to unclarities of what the license actually
>>>demands from Apache _users_, more than ASF itself !!
>>
>>This is a point that I didn't think about earlier. Just to absolutely
>>clear - in the case of the Hibernate Component - at is using LGPL it is
>>subject to the LGPL by viral virtue - hense the requirement to license
>>the Hibernate Component under the LGPL and not under ASL. Therefore the
>>requirement is created for a place to put this LGPL Hibernate Component
>>outside of ASF space pending an explicit release of the viral
>>association by the licensor. However - this means that anything using
>>the LPGL Hibernate Component is by default pushed out as well. Ummm, I
>>starting to understand the religous impliciations and the reason for
>>zero-tolerance on LGPL.
>
>
> Confusing, isn't it??
>
> For us, I think it is just a matter of accepting the decision. Those guys have
> argued over this for months, I'm sure...
Since forever. THere is a lot of good software out there that we can't use
because of a stupid license. That sucks. With every new version of the (L)GPL
licenses someone tries to make an opening in their interpretation of the
legalese to allow us to use it...
No luck.
>
> Your conclusion is probably correct, the Hibernate component need to isolate
> itself from Apache source. The best would be that Hibernate published a set
> of interfaces under BSD-style, and we could compile/distribute against those
> interfaces, and the end-users download from Hibernate.
If the interface is ASL, and packaged separately, then we might could get around
some of the licensing issues. The problem is the implementation.
>
> If that is not acheivable, I don't see any other choice than an SF-based
> sidearm of the ASF-based one. I think it could be doable...
There is still the issue of each SF community being required to sort out its
licensing. All we are doing is saying "here, you worry about it".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Wednesday 12 November 2003 17:32, Stephen McConnell wrote:
>
>
>>Niclas Hedhman wrote:
>>
>>
>
>
>
>>>LGPL is probably compatible with ASL, BUT ASF has said NO on being
>>>involved, I think largely due to unclarities of what the license actually
>>>demands from Apache _users_, more than ASF itself !!
>>>
>>>
>>This is a point that I didn't think about earlier. Just to absolutely
>>clear - in the case of the Hibernate Component - at is using LGPL it is
>>subject to the LGPL by viral virtue - hense the requirement to license
>>the Hibernate Component under the LGPL and not under ASL. Therefore the
>>requirement is created for a place to put this LGPL Hibernate Component
>>outside of ASF space pending an explicit release of the viral
>>association by the licensor. However - this means that anything using
>>the LPGL Hibernate Component is by default pushed out as well. Ummm, I
>>starting to understand the religous impliciations and the reason for
>>zero-tolerance on LGPL.
>>
>>
>
>Confusing, isn't it??
>
>For us, I think it is just a matter of accepting the decision. Those guys have
>argued over this for months, I'm sure...
>
>Your conclusion is probably correct, the Hibernate component need to isolate
>itself from Apache source. The best would be that Hibernate published a set
>of interfaces under BSD-style, and we could compile/distribute against those
>interfaces, and the end-users download from Hibernate.
>
Going lateral .... if a ASL Hiberate component API was written together
with a block definition. Then, with the service based resolution via a
repository - the repository is doing the selection of an implementation
based on the requested service - and know implementations. I'm not a
lawyer - but I would imagine that it would be very difficult to show
viral rights on either the service broker or the consumer component.
Why - because neither are built against a viral product.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Wednesday 12 November 2003 17:32, Stephen McConnell wrote:
>
>
>>Niclas Hedhman wrote:
>>
>>
>
>
>
>>>LGPL is probably compatible with ASL, BUT ASF has said NO on being
>>>involved, I think largely due to unclarities of what the license actually
>>>demands from Apache _users_, more than ASF itself !!
>>>
>>>
>>This is a point that I didn't think about earlier. Just to absolutely
>>clear - in the case of the Hibernate Component - at is using LGPL it is
>>subject to the LGPL by viral virtue - hense the requirement to license
>>the Hibernate Component under the LGPL and not under ASL. Therefore the
>>requirement is created for a place to put this LGPL Hibernate Component
>>outside of ASF space pending an explicit release of the viral
>>association by the licensor. However - this means that anything using
>>the LPGL Hibernate Component is by default pushed out as well. Ummm,
>>I'm starting to understand the religous impliciations and the reason
>>for zero-tolerance on LGPL.
>>
>>
>
>Confusing, isn't it??
>
>For us, I think it is just a matter of accepting the decision. Those guys have
>argued over this for months, I'm sure...
>
>Your conclusion is probably correct, the Hibernate component need to isolate
>itself from Apache source. The best would be that Hibernate published a set
>of interfaces under BSD-style, and we could compile/distribute against those
>interfaces, and the end-users download from Hibernate.
>
>If that is not acheivable, I don't see any other choice than an SF-based
>sidearm of the ASF-based one. I think it could be doable...
>
Yep, its doable.
The question is - is it desirable? For the moment - I don't know.
Stephen.
>
>Niclas
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 12 November 2003 17:32, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> >LGPL is probably compatible with ASL, BUT ASF has said NO on being
> > involved, I think largely due to unclarities of what the license actually
> > demands from Apache _users_, more than ASF itself !!
>
> This is a point that I didn't think about earlier. Just to absolutely
> clear - in the case of the Hibernate Component - at is using LGPL it is
> subject to the LGPL by viral virtue - hense the requirement to license
> the Hibernate Component under the LGPL and not under ASL. Therefore the
> requirement is created for a place to put this LGPL Hibernate Component
> outside of ASF space pending an explicit release of the viral
> association by the licensor. However - this means that anything using
> the LPGL Hibernate Component is by default pushed out as well. Ummm, I
> starting to understand the religous impliciations and the reason for
> zero-tolerance on LGPL.
Confusing, isn't it??
For us, I think it is just a matter of accepting the decision. Those guys have
argued over this for months, I'm sure...
Your conclusion is probably correct, the Hibernate component need to isolate
itself from Apache source. The best would be that Hibernate published a set
of interfaces under BSD-style, and we could compile/distribute against those
interfaces, and the end-users download from Hibernate.
If that is not acheivable, I don't see any other choice than an SF-based
sidearm of the ASF-based one. I think it could be doable...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Wednesday 12 November 2003 16:49, Eric Pugh wrote:
>
>
>>Okay... But, can I transfer my Hibernate component over to this new
>>repository? Remember, Hibernate is LGPL, and I couldn't host it in
>>Fulcrum.
>>
>>
>
>I think there are problems...
>
>LGPL is probably compatible with ASL, BUT ASF has said NO on being involved, I
>think largely due to unclarities of what the license actually demands from
>Apache _users_, more than ASF itself !!
>
This is a point that I didn't think about earlier. Just to absolutely
clear - in the case of the Hibernate Component - at is using LGPL it is
subject to the LGPL by viral virtue - hense the requirement to license
the Hibernate Component under the LGPL and not under ASL. Therefore the
requirement is created for a place to put this LGPL Hibernate Component
outside of ASF space pending an explicit release of the viral
association by the licensor. However - this means that anything using
the LPGL Hibernate Component is by default pushed out as well. Ummm, I
starting to understand the religous impliciations and the reason for
zero-tolerance on LGPL.
>
>
>
>
>>Secondly, can I have committer access?
>>
>>
>
>I most certainly would assume so.
>Stephen was touching on the idea of micro-projects, but I would like to point
>out that "community is more important than code", all according to Apache
>itself, so I think it is counter-productive of letting each committer fool
>around in his own pond.
>
Sorry I should have been clearer - I didn't want to suggest seperate
sub-communites. ASAIAC is about one community - many components - joint
and several responsibility - the community is the important thing.
Stephen.
>
>
>
>>If either of those are no, then that points out the need for another site.
>>If both are yes, then I'm all for it as it solves my problem.
>>
>>
>
>Agree.
>
>Niclas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 12 November 2003 16:49, Eric Pugh wrote:
> Okay... But, can I transfer my Hibernate component over to this new
> repository? Remember, Hibernate is LGPL, and I couldn't host it in
> Fulcrum.
I think there are problems...
LGPL is probably compatible with ASL, BUT ASF has said NO on being involved, I
think largely due to unclarities of what the license actually demands from
Apache _users_, more than ASF itself !!
>Secondly, can I have committer access?
I most certainly would assume so.
Stephen was touching on the idea of micro-projects, but I would like to point
out that "community is more important than code", all according to Apache
itself, so I think it is counter-productive of letting each committer fool
around in his own pond.
> If either of those are no, then that points out the need for another site.
> If both are yes, then I'm all for it as it solves my problem.
Agree.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Eric Pugh wrote:
>Okay... But, can I transfer my Hibernate component over to this new
>repository? Remember, Hibernate is LGPL, and I couldn't host it in Fulcrum.
>Secondly, can I have committer access?
>
>If either of those are no, then that points out the need for another site.
>If both are yes, then I'm all for it as it solves my problem.
>
The Hibernate component could be transfered *if* the component code was
donated to the ASF. Remember that we are not talking about the Hibernate
sources - instead we are talking about code that is using Hibernate as
part of a component implementation. This is no different to the James
project using Javamail. As to yourself as a committer - absolutely yes!
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] Avalon Components project
Posted by Eric Pugh <ep...@upstate.com>.
Okay... But, can I transfer my Hibernate component over to this new
repository? Remember, Hibernate is LGPL, and I couldn't host it in Fulcrum.
Secondly, can I have committer access?
If either of those are no, then that points out the need for another site.
If both are yes, then I'm all for it as it solves my problem.
Eric
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, November 12, 2003 9:37 AM
> To: Avalon Developers List
> Subject: [PROPOSAL] Avalon Components project
>
>
>
>
> Niclas Hedhman wrote:
>
> >On Tuesday 11 November 2003 19:48, Eric Pugh wrote:
> >
> >
> >>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..
> >>
> >>
> >
> >I, for one, agree... I think the only issue with the more
> hard core Apache
> >guys (I'm not pointing a big finger at you Stephen) is the
> "endorsement",
> >implied or otherwise, that Avalonia or avalon-components, is given.
> >
>
> IM[HC]O, there are a number of different subjects
>
> (a) the barrier to entry
> (b) licensing
> (c) endorcement
>
> The barrier to entry is a pure policy decision that can be
> made by the
> entity that is asserting oversite - this should not be used as an
> argument for or against ASF versus SF. Equally components
> using non-ASF
> compatible resources should not impact a ASF/SF decision
> bacause this is
> simply a question of development time downloading (and seperate from
> deployment). Lastly - the question of endorcement - AFAICS,
> endorcement
> by Avalon requires oversite by Avalon which leads me to an
> alternative
> proposition.
>
> The proposal is a Avalon Component project here at Apache -
> seperate but
> aligned with Avalon. The project would establish policies that
> facilitated a lower barrier to entry of new component iniatives
> (typically micro-projects dealing with a specific component
> implementation) much in the same way that common manages new
> projects.
> We could bootstrap the thing by transfering the current
> avalon-components cvs to the new project and possibly well as
> incorporation of iniative such the FTP project.
>
> In this scenario - the new project would establish a PMC
> responsible for
> oversite, content would be licensed under ASL, and the relationship
> between Avalon and the new project would include our focus on
> the tools
> and technologies dealing with aspects such as technical complicance,
> validation test suites, component repository tools, etc.
>
> Stephen.
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Tuesday 11 November 2003 19:48, Eric Pugh wrote:
>
>
>>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..
>>
>>
>
>I, for one, agree... I think the only issue with the more hard core Apache
>guys (I'm not pointing a big finger at you Stephen) is the "endorsement",
>implied or otherwise, that Avalonia or avalon-components, is given.
>
IM[HC]O, there are a number of different subjects
(a) the barrier to entry
(b) licensing
(c) endorcement
The barrier to entry is a pure policy decision that can be made by the
entity that is asserting oversite - this should not be used as an
argument for or against ASF versus SF. Equally components using non-ASF
compatible resources should not impact a ASF/SF decision bacause this is
simply a question of development time downloading (and seperate from
deployment). Lastly - the question of endorcement - AFAICS, endorcement
by Avalon requires oversite by Avalon which leads me to an alternative
proposition.
The proposal is a Avalon Component project here at Apache - seperate but
aligned with Avalon. The project would establish policies that
facilitated a lower barrier to entry of new component iniatives
(typically micro-projects dealing with a specific component
implementation) much in the same way that common manages new projects.
We could bootstrap the thing by transfering the current
avalon-components cvs to the new project and possibly well as
incorporation of iniative such the FTP project.
In this scenario - the new project would establish a PMC responsible for
oversite, content would be licensed under ASL, and the relationship
between Avalon and the new project would include our focus on the tools
and technologies dealing with aspects such as technical complicance,
validation test suites, component repository tools, etc.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Counter PROPOSAL] Avalon Component Index
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 11 November 2003 19:48, Eric Pugh wrote:
> I've been gone for a couple days, and 461 avalon messeges
It is an idication that the "community is dead" to cite a famous Cocooner...
> 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..
I, for one, agree... I think the only issue with the more hard core Apache
guys (I'm not pointing a big finger at you Stephen) is the "endorsement",
implied or otherwise, that Avalonia or avalon-components, is given.
Nothing but the name can stop an SF site to get going (except lack of
interest)...
My personal opinion, ASF have deniability and can wash their hands, Avalon
gets more components (albeit not all with top quality) and invdividual
developers gets a lower entry barrier....
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Counter PROPOSAL] Avalon Component Index
Posted by Eric Pugh <ep...@upstate.com>.
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:bloritsch@apache.org]
> 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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org