This convo is heavy and I've tried to follow but I want to start building out the ideas to play with in the sandbox. Part of it is to just embellish the artifact repo with attributes and be able to query this database of sorts. I will talk about this in a new email track.
However as far as these discussions are concerned regarding avalon components we can use marker attributes to describe the contents of jar artifacts in avalon terms for the sake of build time, configuration time and runtime aspects. There are no limits once the maven repository as we know it today is transformed into a repository with a database. Alex > > From: Stephen McConnell <[EMAIL PROTECTED]> > Date: 2003/11/06 Thu PM 07:28:17 EST > To: Avalon Developers List <[EMAIL PROTECTED]> > Subject: Re: [PROPOSAL] An Avalon Component Repository > > > > Leo Simons wrote: > > > Stephen McConnell wrote: > > > >>> The rationale behind a common component repository is obvious: there > >>> are lots of (open source) avalon(-compatible) components out there, > >>> and a single place for hosting/finding all of those means less > >>> infrastructure overhead, less googling, in other words, we get all > >>> the benefits of one-stop-shopping. It also means that a single > >>> community can be built around multiple components (much like jakarta > >>> commons) that would otherwise likely be single-man projects. > >> > >> > >> I'm not convinced. Before such a vision is realistic we need to have > >> a *single* avalon component contract. > > > > > > why? There is a need for sharing. Why should we wait until we have a > > single component contract (which is imnsho quite a few months if not > > years from being 'fully' realized)? > > > Simply because your branding the repository as an Avalon repository. > What does that mean? What is means is a bunch of components that have > computational dependencies on avalon apis and implementations together > with grand claims of support. In reality its just plain missleading. > This isn't so much a thing about a single component contract - its much > more about understanding the differences in the component contract > interpritations. Keep in mind that those differences are sufficient to > break the component contract. Take for example the recent post > concerning using a parent container service manager in Fortress - what > relalevance has this to the Avalon component contract - absolutely > none! Any yet that guy is going to go ahead an invest his time in > coding something up that is specific to Fortress. That's a > dissapointment - why - because you talking about a common repository for > wanabe-components and you want to align it with Avalon. > > As to the timeframe - months or years? That is in part a function of > the market, this community, and key individuals. Getting down and dirty > is part of the process - do we (Avalon) consider ECM semantics as part > of the core framework? I don't because the specification just isn't > sufficient. Are phoenix semantics part of the core framework - yes - > but depricated relative to a common set of context entries. Are > Fortress semantics (which are largely related to ECM semantics) part of > the framework - no - simply because we have not identified and > documented the semantics distinctions and implications of those > distinctions. > > The fast track to a single component contract is: > > * elimination of selectors > * elimination of pooled and per-thread lifestyle strategies > * elimination of framework marker interfaces > > Validation of any component against this senario and you have the > context for establishing a component repository of value. > > > > >>> So why *should there not be an avalon-hosted component repository*? > >>> > >>> 1) Oversight. > >> > >> Agreed. > >> > >>> > >>> 2) Brand dellution. > >> > >> Agreed. > >> > >>> 3) KISS. > >> > >> Agreed. > >> > >>> 4) Size. > >> > >> Disagree - well at least I think your exagerating. If we look at the > >> level of component related traffic - well - its small - really small. > > > > > > which might just be because all the available traffic space is taken > > up by container-related traffic :D > > > Nope. > We have lots of scope for expansion. Last months was 614 messages and > there have more than a few months where Avalon trafic has been up and > over 1000 per month. Container-related is not the issue -- but it is > perhaps a stimulus in terms of what is and is not an Avalon component. > > > > > > >>> 5) Barrier to entry. > >> > >> > >> Depends on your defintion of a component repository. > > > > > > sure does! Lets define it as vaguely as "something maintained using > > CVS" and there's your barrier. > > > No. > > The barrier is the policy and procedures that are put in place. > I've mentioned before (on the PMC list) that I would like to see a soft > zone here in Avalon supporting and facililitating component development > and experimentation. Unfortunately I have not managed to get the value > of that across - but I'm still keen to see this happening - becuase here > is where the skills are - and here is where *we* can be constructive in > terms of other people learning about this stuff. > > > > > > >>> 6) Scope. > >> > >> > >> Thats' a loaded argument. > > > > > > I'd hope it wouldn't be. Let's try and be open. > > > Being open - as far as I am concerned the notion of an SF base is not an > option. The question is "do we setup an Apache repository or not". If > its here at Apache - count me in. > > > >> I agree with several of your points - and in particular aspects > >> concerning focus. > > > > > > This just reeks of potential for agreement :D > > > You know me - I'm a reasonable guy!! > > > > >> But I don't agree with the conclusions. Instead I think we should be > >> going beyond the question of "where is the repository" and instead > >> enable repositories using Avalon tools and technologies that > >> facilitate better conformance, easier discovery, and automation of > >> usage. > > > > > > that should happen too. I think there can be a positive spiral between > > the development of such technology, and the existence of open source > > material actually using it. > > > I agree. I'm thinking right now about the FTP project and how something > like that needs an Avalon Component Repository. But lets be up-front - > if the FTP project came in as a component I would getting in there and > bringing it into conformance - and doing this in the context of a > policies that ensured that I could do this if needed. And if > conformance was not possible - then those same policies would let me > kick-it-out. But to that I need a conformance criteria before I need a > playground. > > > > >>> The Obvious Alternative > >>> ----------------------- > >>> There should be a *seperate project* for hosting avalon components. > >> > >> > >> Another obviouse conclusion - "there sould be a seperate directory > >> facilitating component discovery based on Avalon component management > >> technology". > > > > > > yep. > > > >> Another proposal > >> ---------------- > >> No need for another shakeup. Instead, we continue the stready > >> improvement and development of the Avalon content, migrating stuff to > >> commons when appropriate, improving quality of existing components > >> when appropriate, keeping links to other activities active and alive. > > > > > > That is an approach which has consistently failed to work over the > > last few years. Over the past few months, I've seen about 3 dozen > > posts in this community about the addition of cool new components to > > the avalon codebase, but what happens is that people run out of steam > > developing their component on their own, never bother to submit a > > website patch, and lots of reuse potential is lost. > > > However, Avalon continuues to grow and develop. Out components in > cornerstone have taken a big jump forward in quality. Or web site is > better than it has ever been. Our focus and activities have never been > as united as it is today. We still have more to do with respect to > Excalibur - but the bottom line is core community and the core product > line is better today then it has been in the history of Avalon. I agree > that this does not deliver a concrete solution to developers of new > components - but it does raise a relevant subject - "what is the role of > the PMC and the community relative to facilitating new component iniatives"? > > My own opinion is that we need a new CVS repository - avalon-playground. > > What's the difference between avalon-playground and avalon-sandbox - > simple - things in playground are not destined for Avalon - its simply > an infrastructure to support and enable people who want to do new > things. What is the exit criteria for playground content? Its the > development of the individuals who come to play. > > I.e. Avalonia - the center for component developer development. > > > > >> And at the same time - build the tools supporting component and > >> service management that facilite component based development and > >> enable automated component validation, discovery, deployment, > >> execution and management. > > > > > > +1. > > > > - LSD > > > Stephen. > > -- > > Stephen J. McConnell > mailto:[EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > 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]
