You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/11/05 22:34:39 UTC
[PROPOSAL] An Avalon Component Repository
Okay gang,
enough with all those [RT]s for a bit! Here's something concrete.
Replies to the avalon development list only please.
Summary
-------
It has been said dozens of times now: we *badly* need a common
repository for Avalon components. The thought that immediately follows:
this repository should be part of Avalon. I strongly agree with the
first statement; I strongly disagree with the second.
In this email, I explain why, then I resurrect the best alternative:
*Avalonia*.
Explanation
-----------
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.
The rationale behind hosting such a repository here at Avalon is also
obvious: there's already a community here, there's already some
infrastructure here, and some components, and avalon is all about
component-oriented programming. Hosting components here will also likely
increase their visibility.
So why *should there not be an avalon-hosted component repository*?
1) Oversight. The Avalon PMC needs to be able to maintain (legal)
oversight of the community and of our entire codebase. The bigger the
codebase (especially: the bigger the number of small
effectively-one-or-two-man codebases most of the PMC is not very
familiar with), the more difficult this job is.
2) Brand dellution. Call everything "Avalon" and no-one will know what
it means. We've already seen this happen so often! "What is Avalon,
exactly? It seems to include <snip/>...BUT...<snip/>".
3) KISS. Do one thing, and do it well. Avalon is about a software
framework. Not about everything that could possibly be built using that
framework (avalon being a generic framework, you could implement half of
the java class libraries using it). As an analogy, your Do-It-Yourself
kit doesn't come with a house included, now does it?
4) Size. Already, since avalon is about lots of things, there are loads
and loads of messages on avalon-dev; our website is huge, and roughly a
third of all the binaries available on your average ASF mirror is
produced by Avalon. The sheer energy required to keep up is huge; this
is a big barrier to entry. The logical step in order to cope is to split
up mailing lists, partition cvs priviledges, etc; this is disastrous to
the community for various reasons (again, a lesson from experience), so
its not an option.
5) Barrier to entry. There is a substantial barrier to obtaining access
to an apache cvs, for various reasons (basically, its always a side
effect of being a committer on a project, which includes several
responsibilities and priviledges). We do not really need nor want such a
barrier for a component repository.
6) Scope. Apache has a few component repositories already:
jakarta-commons, apache-commons, xml-commons, ... It does not need
another, especially not one that is a subproject of a project that
previously had problems partially due to exceeding its original scope by
far. A component repository does not fit our intended project scope.
The Obvious Alternative
-----------------------
There should be a *seperate project* for hosting avalon components. This
removes objections 1-4. To remove objections 5 and 6, this project
should not be an ASF-hosted project.
Concrete
--------
So, what form would such an alternative take? Here's some basic ideas:
1) We create a sourceforge project
2) We name it:
Avalonia
--------
The one-stop shop for your Avalon component needs
3) All avalon committers, contributors and interested third parties can
get cvs access, without most of the barrier to entry that are intrinsic
to the ASF.
4) Avalonia is run loosely ASF-style (consensus, +1/-1/0 voting, ASL
license).
5) The Avalon PMC grants avalonia permission to use a slogan like the
one above.
6) Avalonia gets a link from the front page of the avalon website.
7) Discussion of the project is, at first, on the avalon mailing lists
(subjects prefixed with '[avalonia]'). When traffic ramps up, we create
seperate lists on sourceforge.
8) existing external avalon-related projects like jadetower, keel,
webtop, james, cocoon are all invited to participate (with an equal voice).
9) Avalonia forks avalon-components or gets a license grant;
avalon-components is discontinued.
10) Avalonia not only hosts components, it will also host a component
database linking to external components.
Proposal
--------
The proposal is as follows: we create Avalonia.
(We don't need to agree on all those bullet points above immediately,
but on the general idea.)
I'm willing to invest significant time, energy and computing resources
to get this thing underway, but only if there's broad support and other
people (both in the current avalon committer base and outside) who will
commit to doing the same.
Now is the time to volunteer!
cheers,
- Leo
PS: for those that are wondering...yes, I did start writing this e-mail
a month or two ago :D
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by peter royal <pr...@apache.org>.
On Nov 6, 2003, at 11:29 AM, Leo Simons wrote:
> also found the updated location:
> http://cvs.sourceforge.net/viewcvs.py/spice/spice/sandbox/repository/
>
> IIUC, that's a piece of software for building and managing component
> repositories. What I'm on about (as opposed to what Steve is on about
> :D) is an actual repository and supporting community.
>
> Maybe spice-repository would be a nice part of that infrastructure,
> maybe the project shaping up on the repository@apache.org mailing list
> would be, maybe the repository materials in avalon-sandbox would be.
> Figuring that out would be "stage 2" I guess.
its starting with infrastructure, a way to create a 'component library'
and go on from there.
step one is just having a place to find components, that's what is
being attacked first.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by Leo Simons <le...@apache.org>.
peter royal wrote:
> On Nov 5, 2003, at 4:34 PM, Leo Simons wrote:
>
>> I'm willing to invest significant time, energy and computing
>> resources to get this thing underway, but only if there's broad
>> support and other people (both in the current avalon committer base
>> and outside) who will commit to doing the same.
>
> take a peek at:
>
> <http://cvs.sourceforge.net/viewcvs.py/spice/spice/sandbox/
> component_repository/>
also found the updated location:
http://cvs.sourceforge.net/viewcvs.py/spice/spice/sandbox/repository/
IIUC, that's a piece of software for building and managing component
repositories. What I'm on about (as opposed to what Steve is on about
:D) is an actual repository and supporting community.
Maybe spice-repository would be a nice part of that infrastructure,
maybe the project shaping up on the repository@apache.org mailing list
would be, maybe the repository materials in avalon-sandbox would be.
Figuring that out would be "stage 2" I guess.
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by peter royal <pr...@apache.org>.
On Nov 5, 2003, at 4:34 PM, Leo Simons wrote:
> I'm willing to invest significant time, energy and computing resources
> to get this thing underway, but only if there's broad support and
> other people (both in the current avalon committer base and outside)
> who will commit to doing the same.
take a peek at:
<http://cvs.sourceforge.net/viewcvs.py/spice/spice/sandbox/
component_repository/>
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 06 November 2003 09:15, Stephen McConnell wrote:
> 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. 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.
This is not exclusive of Leo's well-intended push for getting a component
repository going. In fact, his proposal will partly be part of the use-cases
for such tools.
Also, an interesting aspect of Leo's proposal is that
1. It could facilitate differentiated quality levels, without shoveling around
from sandbox to some more permanent location, as is often the case in Apache
land.
2. Avalonia wouldn't have to have the requirement of not linking to LGPL code
and other similar licenses. In fact, Avalonia _could_ allow individual
licenses for individual components.
3. The "low entry" barrier is a plus. People like me don't necessary
gets/wants Apache committer access, as it, as you pointed out, comes both
with rights and _responsibilities_. Avalonia could be much more laxed, to
allow more codebases to enter.
As for the "single contract", I think that is a great notion, but people do
work in a hetereogenous environment _now_, not in an ideal homogeneous
environment in the future. So let's just accept that, and say;
"Hey, I want to share this great component, but it only works under Phoenix.
If you want to use it under Fortress, you got to help out."
And once the "standard contract" is in place, I could announce;
"Available NOW, works with all containers."
As for Copyright Assignment; I think that it is just easiest to let each
component author to maintain copyright with the following catch;
1. The contact email must be present in source code.
2. A blurb saying that if the email is no longer valid, the code belongs to
public domain.
3. Contributors add themselves to the list of copyright holders for each file
they modify.
Leo, I think your intention is all well and good. And although Stephen, the
sleep deprivated super-human, thinks otherwise, I think you would have a more
active community around component development, than can be achieved around
container development.
And let's face it; A container without components are useless.
Meanwhile Steve, we carry on all the container and tool goals at Avalon, and
keep us synchronized with Avalonia, and have a set of use-cases.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 07 November 2003 10:31, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> >IIUYC, avalon-playground would be more open to developers who are not full
> >Avalon comitters, and only access to that repo? And that the entry-level
> > for participation here would be much lower?
>
> Absolutely YES.
>
> I'm thinking of an entry level which is basically someone making a
> request within which they assert tat the recognise the rules. That it -
> period.k Its not about code repository - its about individual
> development, learning, experience, technology transfer - whaterver you
> want to call it. It not about creating a home for a component.
Ok, make it happen and I'm all game.
<snip content="how to make it happen and more" />
> >If you manage, I think Leo and I would agree it would be good, but in
> > absence of such break-through, do you still maintain that Avalon
> > components can ONLY be hosted at avalon.apache.org?
>
> Yes.
If I re-phrase the question, as I now realize that it is not unambigous;
Do you still maintain that Avalon-compatible components can ONLY be hosted at
avalon.apache.org? And that would then be in the dozens range, since we can't
maintain much more?
> What is nice about Pico is the ability to fudge the boundary
> between container space and component space. What is does is say that it
> is drop dead easy for any component to behave as a container.
I think your interpretation of what is nice may not be what other think is
"nice" about Pico. To me and a couple of my friends, it is "A LOT of
components exists already!!". The container is secondary, and perhaps a lot
of the Pico enthusiast will burn themselves later. That is technological
issue. My point is, and will remain, "A container without components is
useless.", no matter how good it is.
> Actually, I'm not too corcerned about the quality aspect - I figure we
> can automate avaluation of these things. What I do see is components
> within Apache juristiction having a loger life, greater attention to
> detail, a broader community, and at the end of the day - representing a
> greater value proposition to end users.
You almost sound like a MS marketing guy; "People only need great applications
from this great company." ;o)
I happen to believe otherwise. A successful COP project allows anyone to
expose a component easily, and for others to find equally easily.
Freshmeat.net comes to mind...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Friday 07 November 2003 08:28, Stephen McConnell wrote:
>
>
>
>>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.
>>
>>
>
>IIUYC, avalon-playground would be more open to developers who are not full
>Avalon comitters, and only access to that repo? And that the entry-level for
>participation here would be much lower?
>
Absolutely YES.
I'm thinking of an entry level which is basically someone making a
request within which they assert tat the recognise the rules. That it -
period.k Its not about code repository - its about individual
development, learning, experience, technology transfer - whaterver you
want to call it. It not about creating a home for a component.
>
>I doubt that will go through the ASF upper ranks. If there are legalities of
>copying an LGPL library to ASF infrastructue, I believe the above to be hard
>to get through.
>
I disagree - the board listens to the PMCs - the PMC are represented by
a Chair - the Chair expressed the interests and concerns of the PMC -
the PMC is here to resolve the issues and concerns of the community.
Things like LGPL are real concerns - but its a managable concern - if
the licensing conditions for a particular project cannot be resolved it
just means extra overhead for the the end-users - but in the process the
developer in the plaground gets to learn about legal implications of
open source development (along with all those other things like "what is
a component", "IOC", "SOC", community, process, etc.).
>
>If you manage, I think Leo and I would agree it would be good, but in absence
>of such break-through, do you still maintain that Avalon components can ONLY
>be hosted at avalon.apache.org?
>
Yes.
There is more to the license than a convinience factor.
>
>IMHO, the recent "success" (or at least hype) around Pico is directly related
>to "component availability" (more or less anything can be refactored in
>minutes).
>
I am probably going to regrat saying this but - honestly - it is largely
hype. What is nice about Pico is the ability to fudge the boundary
between container space and component space. What is does is say that it
is drop dead easy for any component to behave as a container. The
problem is that the Pico model is like 5-8% or the real issue - it just
one aspect of a rather complex concern.
>You may envision dozens of high-quality components. I envision thousands of
>various quality (comformant or not to the "single contract") components,
>where the high-quality ones are at Apache infrastructure, and the others are
>"easy to find" somewhere else.
>
Actually, I'm not too corcerned about the quality aspect - I figure we
can automate avaluation of these things. What I do see is components
within Apache juristiction having a loger life, greater attention to
detail, a broader community, and at the end of the day - representing a
greater value proposition to end users.
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] An Avalon Component Repository
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Friday 07 November 2003 08:28, Stephen McConnell wrote:
>
>
>>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.
>
>
> IIUYC, avalon-playground would be more open to developers who are not full
> Avalon comitters, and only access to that repo? And that the entry-level for
> participation here would be much lower?
>
> I doubt that will go through the ASF upper ranks. If there are legalities of
> copying an LGPL library to ASF infrastructue, I believe the above to be hard
> to get through.
The point of the proposal was to promote the idea of an external component
playground that would have much more relaxed requirements. The major drawback
is that you lose ASF protection and oversight. One of the benefits is that
you can allow the use of other projects that otherwise have an incompatible
license.
As long as we mandate that the component interfaces are licensed under the APL
or compatible license, and that the interfaces are encapsulated in a separate
JAR file from the implementations, we can use the components whose
implementations require an LGPL type of license. We just can't redistribute
them.
I've been thinking about this for a while and I think I have a sensible counter-
proposal. More on that later.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 07 November 2003 08:28, Stephen McConnell wrote:
> 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.
IIUYC, avalon-playground would be more open to developers who are not full
Avalon comitters, and only access to that repo? And that the entry-level for
participation here would be much lower?
I doubt that will go through the ASF upper ranks. If there are legalities of
copying an LGPL library to ASF infrastructue, I believe the above to be hard
to get through.
If you manage, I think Leo and I would agree it would be good, but in absence
of such break-through, do you still maintain that Avalon components can ONLY
be hosted at avalon.apache.org?
IMHO, the recent "success" (or at least hype) around Pico is directly related
to "component availability" (more or less anything can be refactored in
minutes).
You may envision dozens of high-quality components. I envision thousands of
various quality (comformant or not to the "single contract") components,
where the high-quality ones are at Apache infrastructure, and the others are
"easy to find" somewhere else.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> 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.
>
>
> <snip/>
>
>> 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.
>
>
> It seems you've nailed down the root of the difference in opinion --
> you want all these things to happen inside the scope of avalon (and
> under responsibility of the Avalon PMC), whereas I think that's not a
> good idea.
That's not exactly what I said.
Here is a consolidated statement of what I think ...
[1] I think that an Component Repository under Apache, possibly sponsored
by Avalon is much more interesting that a generic SourceForge project.
[2] I think that the development of tools and technologies supporting
component repositories is totally within the scope of Avalon and that
these tools and technologies will be a fundamental in enabling
manageable
repositories (see point [1]) that will ultimately be useful
resources to
end users.
[3] I think Avalon or an Apache Component Repository Project could
provide an
environment for COP/SOP learning and developer development (as
distinct
from code development) by providing the infrastructure and policy
framework
that facilitates coachingh and promotion of component and service
oriented
best-practices.
Cheers, Steve.
--
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] An Avalon Component Repository
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> 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.
<snip/>
> 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.
It seems you've nailed down the root of the difference in opinion -- you
want all these things to happen inside the scope of avalon (and under
responsibility of the Avalon PMC), whereas I think that's not a good idea.
The rest of the argument seems mostly about quantity (in its most
general sense), which is not very productive.
Perhaps we should just do a vote on avalon-playground. If it goes
through, no avalonia. If not, you'll have to recognize the next best
thing is something hosted at SF.
There's no point in doing this avalonia thing if the whole of avalon is
not on board. In fact, there may not be a point in doing this at all; I
just read my repository@apache.org backlog, and it seems there's half a
dozen similar efforts underway atm. I'm going to wait out what
spice-repository, repository@apache, avalon-sandbox/repository, ruper,
maven, etc, amounts to.
Just goes to show how badly a component repository really is needed :D
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by Leo Simons <le...@apache.org>.
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)?
>> 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
>> 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.
>> 6) Scope.
>
> Thats' a loaded argument.
I'd hope it wouldn't be. Let's try and be open.
> I agree with several of your points - and in particular aspects concerning
> focus.
This just reeks of potential for agreement :D
> 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.
>> 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.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[Merlin] Component startup sequence
Posted by Jim Alateras <ji...@comware.com.au>.
Folks,
I have a single component, which basically prints the name, version and
build date of my application and I want it to be the first component to
start. Is there anyway I can force a component to start in a particular
order without making it part of a dependency graph.
Currently I have a PlatfromVersion.java file, which is automatically
generated when I do a release. This is implemented as an Avalon
component and is configured in the block.xml file. The only thing this
file does is print something like "MyApp v0.1 [12 Sept, 2003 11:54]".
cheers
</jima>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] An Avalon Component Repository
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Okay gang,
>
> enough with all those [RT]s for a bit! Here's something concrete.
> Replies to the avalon development list only please.
>
>
> Summary
> -------
> It has been said dozens of times now: we *badly* need a common
> repository for Avalon components. The thought that immediately
> follows: this repository should be part of Avalon. I strongly agree
> with the first statement; I strongly disagree with the second.
One should qualify the term "repository".
Is a web page providing links to available components "a repository" -
no, its an index.
Should that page be maintained - developed - expanded - yes.
Moving on.
>
> In this email, I explain why, then I resurrect the best alternative:
> *Avalonia*.
>
>
> Explanation
> -----------
> 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. What that means is that we don't
have ECM component and Forress components and Phoenix components and
Merlin components. It means we have *one* Avalon component model backed
by a conformance test suite provided by Avalon.
>
>
> The rationale behind hosting such a repository here at Avalon is also
> obvious: there's already a community here, there's already some
> infrastructure here, and some components, and avalon is all about
> component-oriented programming. Hosting components here will also
> likely increase their visibility.
>
> So why *should there not be an avalon-hosted component repository*?
>
> 1) Oversight. The Avalon PMC needs to be able to maintain (legal)
> oversight of the community and of our entire codebase. The bigger the
> codebase (especially: the bigger the number of small
> effectively-one-or-two-man codebases most of the PMC is not very
> familiar with), the more difficult this job is.
Agreed.
>
>
> 2) Brand dellution. Call everything "Avalon" and no-one will know what
> it means. We've already seen this happen so often! "What is Avalon,
> exactly? It seems to include <snip/>...BUT...<snip/>".
Agreed.
>
>
> 3) KISS. Do one thing, and do it well. Avalon is about a software
> framework. Not about everything that could possibly be built using
> that framework (avalon being a generic framework, you could implement
> half of the java class libraries using it). As an analogy, your
> Do-It-Yourself kit doesn't come with a house included, now does it?
Agreed.
>
>
> 4) Size. Already, since avalon is about lots of things, there are
> loads and loads of messages on avalon-dev; our website is huge, and
> roughly a third of all the binaries available on your average ASF
> mirror is produced by Avalon. The sheer energy required to keep up is
> huge; this is a big barrier to entry. The logical step in order to
> cope is to split up mailing lists, partition cvs priviledges, etc;
> this is disastrous to the community for various reasons (again, a
> lesson from experience), so its not an option.
Disagree - well at least I think your exagerating. If we look at the
level of component related traffic - well - its small - really small.
>
> 5) Barrier to entry. There is a substantial barrier to obtaining
> access to an apache cvs, for various reasons (basically, its always a
> side effect of being a committer on a project, which includes several
> responsibilities and priviledges). We do not really need nor want such
> a barrier for a component repository.
Depends on your defintion of a component repository.
>
> 6) Scope. Apache has a few component repositories already:
> jakarta-commons, apache-commons, xml-commons, ... It does not need
> another, especially not one that is a subproject of a project that
> previously had problems partially due to exceeding its original scope
> by far. A component repository does not fit our intended project scope.
Thats' a loaded argument.
Lets go back to the real concerns. If components here in Avalon (such
as the cornerstone content) don't belong in Avalon - there is no reason
why that could not be promoted to an Apache component repository. I
agree with several of your points - and in particular aspects concerning
focus. 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.
>
>
>
> The Obvious Alternative
> -----------------------
> There should be a *seperate project* for hosting avalon components.
> This removes objections 1-4. To remove objections 5 and 6, this
> project should not be an ASF-hosted project.
Another obviouse conclusion - "there sould be a seperate directory
facilitating component discovery based on Avalon component management
technology".
>
>
>
> Concrete
> --------
> So, what form would such an alternative take? Here's some basic ideas:
>
> 1) We create a sourceforge project
> 2) We name it:
>
> Avalonia
> --------
> The one-stop shop for your Avalon component needs
>
> 3) All avalon committers, contributors and interested third parties
> can get cvs access, without most of the barrier to entry that are
> intrinsic to the ASF.
> 4) Avalonia is run loosely ASF-style (consensus, +1/-1/0 voting, ASL
> license).
> 5) The Avalon PMC grants avalonia permission to use a slogan like the
> one above.
> 6) Avalonia gets a link from the front page of the avalon website.
> 7) Discussion of the project is, at first, on the avalon mailing lists
> (subjects prefixed with '[avalonia]'). When traffic ramps up, we
> create seperate lists on sourceforge.
> 8) existing external avalon-related projects like jadetower, keel,
> webtop, james, cocoon are all invited to participate (with an equal
> voice).
> 9) Avalonia forks avalon-components or gets a license grant;
> avalon-components is discontinued.
> 10) Avalonia not only hosts components, it will also host a component
> database linking to external components.
>
>
> Proposal
> --------
> The proposal is as follows: we create Avalonia.
>
> (We don't need to agree on all those bullet points above immediately,
> but on the general idea.)
>
> I'm willing to invest significant time, energy and computing resources
> to get this thing underway, but only if there's broad support and
> other people (both in the current avalon committer base and outside)
> who will commit to doing the same.
>
> Now is the time to volunteer!
>
>
> cheers,
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. 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.
Cheers, Steve.
--
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