You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/01/11 10:13:43 UTC
[PROPOSAL] Avalon Components
I propose that the Avalon Project creates a subproject called "Avalon
Components", where non-core Avalon committers can work on Avalon
components.
It would work conceptually like Jakarta Commons, and have its sandbox
open to all *Apache* committers. On the Avalon Components "proper", the
commit rights would be:
- all Avalon committers
- all committers that have been voted in by
Avalon+Avalon Component committers
When one is a committer on Avalon Components, he can commit on any part
of the repository, not just the components that originally interested him.
The main reason to make this here at Avalon is to have real contact with
the users of Avalon, and have them actively partecipate in the component
development. Avalon has had great benefit from the partecipation had in
the last month of outer-avalon developers of projects that use Avalon,
and we would like it to continue.
This subproject would help create a clear and longstanding relationship
with our users.
More practically, it would unite Excalibur and Cornerstone, and make it
possible for James developers to fix the Cornerstone components that are
driving them mad directly in the repository, and facilitate the usage
and fixing of our components by interested Turbine developers.
There were two issues brought up about this happening.
Leo Simmons correctly reminded that there is an Apache Commons project,
that could make a cool repository for all Avalon Components for all
Apache projects.
IMHO we are still far away from that possibility. I really don't think
that in the short-mid term Turbine or James developers would want to
move their stuff into that repo, because there is no real need. What
they would do, is to partecipate in the *generic* components, that we
would keep here, in Avalon Components.
Then Stephen McConnell wrote:
>
> It is my understanding that the notion of an avalon-components is out of
> scope of the Avalon Project.
>
> RESOLVED, that the Avalon PMC be and hereby is responsible
> for the creation and maintenance of software related to
> component and service management, based on software licensed
> to the Foundation;
But as you also correctly point out:
> Resolution of the conflict between this position and the existing
> Cornerstone and Apps CVS is addressed under the resolution:
>
> RESOLVED, that the initial Avalon PMC be and hereby is tasked
> with the migration and rationalization of the Jakarta PMC
> Avalon subproject;
That does not address the possibility of moving code outside of the
project, or keeping it ourselves.
I think that the creation of Avalon Components is part of the "
migration and rationalization" objective that the board has given us.
I have not yet recieved public answer from the question I gave to the
board about this. TO resolve this, I propose that we ask the board to
retify an addendum at the next meeting for our charter *if* they decide
that it's needed for this subproject creation:
RESOLVED, that the Avalon PMC be and hereby is responsible
for the creation and maintenance of software related to
component and service management, and components and services
themselves designed to operate in it, based on software licensed
to the Foundation;
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> I propose that the Avalon Project creates a subproject called "Avalon
> Components", where non-core Avalon committers can work on Avalon
> components.
It's something that has been on my nind for several weeks.
>
> It would work conceptually like Jakarta Commons, and have its sandbox
> open to all *Apache* committers. On the Avalon Components "proper",
> the commit rights would be:
> - all Avalon committers
> - all committers that have been voted in by
> Avalon+Avalon Component committers
>
> When one is a committer on Avalon Components, he can commit on any
> part of the repository, not just the components that originally
> interested him.
This sound much better that getting a per subproject scenario. It also
has a positive aspect of reducing the potential for private gardens.
>
> The main reason to make this here at Avalon is to have real contact with
> the users of Avalon, and have them actively partecipate in the component
> development. Avalon has had great benefit from the partecipation had in
> the last month of outer-avalon developers of projects that use Avalon,
> and we would like it to continue.
>
> This subproject would help create a clear and longstanding relationship
> with our users.
This is key point - putting in place somethig that supports the user
community.
>
> More practically, it would unite Excalibur and Cornerstone, and make
> it possible for James developers to fix the Cornerstone components
> that are driving them mad directly in the repository, and facilitate
> the usage and fixing of our components by interested Turbine developers.
+100.
>
> There were two issues brought up about this happening.
>
> Leo Simmons correctly reminded that there is an Apache Commons
> project, that could make a cool repository for all Avalon Components
> for all Apache projects.
>
> IMHO we are still far away from that possibility. I really don't think
> that in the short-mid term Turbine or James developers would want to
> move their stuff into that repo, because there is no real need. What
> they would do, is to partecipate in the *generic* components, that we
> would keep here, in Avalon Components.
>
> Then Stephen McConnell wrote:
>
>>
>> It is my understanding that the notion of an avalon-components is out
>> of scope of the Avalon Project.
>>
>> RESOLVED, that the Avalon PMC be and hereby is responsible
>> for the creation and maintenance of software related to
>> component and service management, based on software licensed
>> to the Foundation;
>
>
> But as you also correctly point out:
>
>> Resolution of the conflict between this position and the existing
>> Cornerstone and Apps CVS is addressed under the resolution:
>>
>> RESOLVED, that the initial Avalon PMC be and hereby is tasked
>> with the migration and rationalization of the Jakarta PMC
>> Avalon subproject;
>
>
> That does not address the possibility of moving code outside of the
> project, or keeping it ourselves.
Agreed.
The point I was raising is that relative tio our current scope - there
is an explicit action required by us to take a decision on this and that
decision has a implication on us to go though a board ratification
process becuase it touches on the questyion of Avalon scope.
>
> I think that the creation of Avalon Components is part of the "
> migration and rationalization" objective that the board has given us.
I agree that your proposal is within scope of rationalization.
>
>
> I have not yet recieved public answer from the question I gave to the
> board about this. TO resolve this, I propose that we ask the board to
> retify an addendum at the next meeting for our charter *if* they
> decide that it's needed for this subproject creation:
>
> RESOLVED, that the Avalon PMC be and hereby is responsible
> for the creation and maintenance of software related to
> component and service management, and components and services
> themselves designed to operate in it, based on software licensed
> to the Foundation;
I think we can enshance the wording a bit - but in pricipal - I think we
should do this as part of a process of facilitating Avalon user support.
I also think that this is more about evolving and supporting users than
establishing a component repository - but I must confess that the second
item has its benefits - but it also has its downside. Today - I'm +1 on
introducing something that enables and empowers our user community and I
think that it is the immediate priority. Perhaps the question of a
formal component repository is something to be addressed some time in
the future although I am not averse to discussing it now.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>The container module does not exist, there is only one "avalon" module.
>>There we will have framework and container. Yes, it will use Avalon
>>Components, and those would be in a single module, core and non-core.
>
>
> Right now you're dealing with a similar issue to what we're addressing in
> James. We have a sub-projected called the Mailet API. But the problem is
> that we didn't specify sufficient capabilities in the Mailet API domain, and
> so we have non-portable mailets that are not only tightly coupled with
> James, but are tightly coupled with Avalon components. So now we're in the
> process of revising the Mailet API.
You should be able to decide beforehand if you want mailets not to be
dependent on avalon, and have tests in the build process to check it.
Also compiling in phases (mailet api first, then mailet(s), then james,
then mailet(s)) can help a lot, with no need to split communities or
repositories.
> * Avalon Frameworks
> * Avalon Container
> * Avalon Components
>
> The Frameworks define the core contracts, the Container provides the overall
> environment, the Components are the building blocks. If someone had a
> motivation for building another Avalon Container, they ought to be able to
> cleanly take Frameworks and Components, and do it. Right? The container is
> just the implementation of the specification.
Correct.
One "avalon" module, with framework and container, that are built
*separately* one after the other. One project, two deliverables.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Avalon Components
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The container module does not exist, there is only one "avalon" module.
> There we will have framework and container. Yes, it will use Avalon
> Components, and those would be in a single module, core and non-core.
Right now you're dealing with a similar issue to what we're addressing in
James. We have a sub-projected called the Mailet API. But the problem is
that we didn't specify sufficient capabilities in the Mailet API domain, and
so we have non-portable mailets that are not only tightly coupled with
James, but are tightly coupled with Avalon components. So now we're in the
process of revising the Mailet API.
* Avalon Frameworks
* Avalon Container
* Avalon Components
The Frameworks define the core contracts, the Container provides the overall
environment, the Components are the building blocks. If someone had a
motivation for building another Avalon Container, they ought to be able to
cleanly take Frameworks and Components, and do it. Right? The container is
just the implementation of the specification.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>I'll work to reposition Avalon as
>> - Avalon Framework
>> - Avalon Container
>> - Avalon Components
>>AF and AC will be in a single repository, with same committers with same
>>access and voting rights. Core Avalon that is. Avalon Components with also
>>other committers and voters that use Avalon.
>
>
> Ok, this is where I see issues ... you see the architecture as layered, I
> don't. I think that the Avalon Container will, especially as it scales, be
> built by using Avalon Components. I do not think that it will be a three
> tier layer cake. Yes, there may be non-core Components, but also core
> Components. And if you decide that core Components would be moved into the
> Container module, well I would expect a ThreadPool implementation to be part
> of the core, and that is one of the components I'm trying to see fixed.
Interesting. Yes, this comment is very interesting.
Well, my opinion is that components must live in Avalon Components.
Core, non-core, all in a single component space.
If you have suffered from breakage of components made by us, why
wouldn't it be good to put us on the same level and potentially have
that happen with us? ;-)
Ok, it's put as a joke, but it isn't. Avalon Components has to be the
hook that binds together the Avalon community with the adopters'
communities. And it's a two way binding.
> The bottom line gets down to a bit of fish or cut bait: either make
> Committers out of related project developers, or not. The exception could
> be AF, but that is one where even you don't want to be making changes
> without very serious consideration, since those are core contracts.
The container module does not exist, there is only one "avalon" module.
There we will have framework and container. Yes, it will use Avalon
Components, and those would be in a single module, core and non-core.
Actually none are "core", because can be used also outside from Avalon.
James uses Xerces, but it still is not "core" for James.
> And you have to decide what are the kinds of components you want or not. I
> am very surprised that Peter is now saying that the entire store package
> should be pulled from Avalon and moved into James (or other client
> programs). What is the vision? Perhaps we need to take over the package,
> if the Avalon vision doesn't include a storage abstraction. On the other
> hand, I do view data stores as generically useful things, so perhaps we
> should be developing a better store for James that *is* part of the Avalon
> vision.
My view is very clear. There is no rule about which components to put.
The only real rule is that they should be maintained actively, and be of
a reasonable general use. Cocoon for example has many components that it
moves to excalibur at times. I would not like that to stop.
Also, your comments make it a bit clearer why we would want to have
Avalon Components here and not in Apache Commons, because in that case
we would have to differentiate between core and non-core components,
with all the problems it brings forward.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Avalon Components
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'll work to reposition Avalon as
> - Avalon Framework
> - Avalon Container
> - Avalon Components
> AF and AC will be in a single repository, with same committers with same
> access and voting rights. Core Avalon that is. Avalon Components with also
> other committers and voters that use Avalon.
Ok, this is where I see issues ... you see the architecture as layered, I
don't. I think that the Avalon Container will, especially as it scales, be
built by using Avalon Components. I do not think that it will be a three
tier layer cake. Yes, there may be non-core Components, but also core
Components. And if you decide that core Components would be moved into the
Container module, well I would expect a ThreadPool implementation to be part
of the core, and that is one of the components I'm trying to see fixed.
The bottom line gets down to a bit of fish or cut bait: either make
Committers out of related project developers, or not. The exception could
be AF, but that is one where even you don't want to be making changes
without very serious consideration, since those are core contracts.
And you have to decide what are the kinds of components you want or not. I
am very surprised that Peter is now saying that the entire store package
should be pulled from Avalon and moved into James (or other client
programs). What is the vision? Perhaps we need to take over the package,
if the Avalon vision doesn't include a storage abstraction. On the other
hand, I do view data stores as generically useful things, so perhaps we
should be developing a better store for James that *is* part of the Avalon
vision.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Leo,
>
> I don't think there is enough merit to a copy/symlink solution, on the
> basis that it is only a move not a real rationalisation.
IMHO it is. We are moving to a single container. A single Component
spec. We have united mailing lists. Now it's time to start with CVS
repositories.
The proposal of Avalon Components comprises a commit access *and* vote
possibility to committers of that project, that are not all from core
Avalon. Cocoon would want to partecipate in excalibur, James in
Cornerstone... let's just unite them and make that a single space to be.
> We will be left with some comps using ...
>
> org.apache.avalon.excalibur.*
> org.apache.excalibur.*
> org.apache.avalon.cornerstone.*
>
> ... packaging.
So? I don't think anybody really cares what the package names are. We
will be changing them with eventual backward-incompatible components or
new ones.
> Seems like we move depots forever......
I know, I know. We're always striving to find the best solution though.
When Fortress will be released, I'll work to reposition Avalon as
- Avalon Framework
- Avalon Container
- Avalon Components
AF and AC will be in a single repository, with same committers with same
access and voting rights. Core Avalon that is.
Avalon Components with also other committers and voters that use Avalon.
It will be our link to our user world.
I think it's a worthy goal.
> - Paul
>
>>> Ok, here is how I thought we could do Avalon Components:
>>>
>>> 1 - rename jakarta-avalon-excalibur CVS module to avalon-components
>>> 1-b - symlink so that you can checkout it as jakarta-avalon-excalibur
>>> for some time
>>> 2 - move the cornerstone component dirs under that repo (simple cp)
>>> 3 - add them in the "excalibur" build
>>>
>>> This would make us almost instantly have a common repo for all
>>> components that we can open to the James committers as you say.
>>>
>>> The only real work would be to add them to the build of "excalibur",
>>> which is not a big feat.
>>>
>>> This would be a first step; in the meantime we can still migrate
>>> package per package of non-Avalon stuff to JC, and decide about the
>>> others as we proceed. But in the meantime this would mean that we
>>> have taken a step towards a single component system, and towards a
>>> tighter relationship with our users.
>>>
>>> Deal?
>>
>>
>>
>> +0 (ie yes but I have different priorities :)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Avalon Components
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
> (except I don't think we should import all those projects into cvs as
> it'll make `cvs up` so painful, there's the licensing/copyright stuff
> popping up in my head immediately, etc etc)
I was pretty selective about my choices. The existing Avalon apps are
already here. Jesktop is Paul Hammant's, and BSD licensed. EOB is also
Paul's and is ASF Licensed.
Even so, these apps aren't to be included in A5, or released by the Avalon
PMC. They are to be used internally for A5 testing.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Leo Simons <le...@apache.org>.
+100. Totally agree with this. It's very important we _all_ agree on this.
(except I don't think we should import all those projects into cvs as
it'll make `cvs up` so painful, there's the licensing/copyright stuff
popping up in my head immediately, etc etc)
- Leo
Noel J. Bergman wrote:
> Paul,
>
>
>>I loved the multi container world. I have two (Jesktop and EOB) that
>>stand to be obsoleted in the stamepede towards uber. If it works
>>great, but I have my doubts.
>
>
> 1) You are a valued member of the Avalon Community. You
> have the ability to shape the scalable container to
> ensure that your existing Avalon applications work.
>
> 2) Stronger statement: you, and the rest of the Avalon
> community have the responsibility to ensure that no
> Avalon applications are left behind "in the stampede
> towards [the scalable container]."
>
> In other words, not only do you have the opportunity to make sure that
> Jesktop and EOB can work, but the entire Community has the responsibility to
> do so. It would be unconscionable for the Avalon Community to leave your
> projects behind. If anything, I might argue that Avalon should keep
> AvalonDB (and other existing Avalon apps) in a sandbox, and copy over
> Jesktop and EOB, for the specific purpose of using them as real-world
> validators for A5. A5 needs real-world apps to make sure that it provides
> migration through backwards compatibility, migration tools, and/or clearly
> documented changes for component/application authors.
>
>>We were having a great time with many containers and were only at
>>the start of the container landscape.
>
> I don't see that the scalable container idea changes that, Paul. The
> essential idea is simply to have lots of core code, and build the container
> from components, with optional features as desired.
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Avalon Components
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Our problem was that we blurred the name 'Avalon' We were inprecise
> about Avalon-Framework, AvalonX AvalonY etc.
That is one way of looking at it. But the flipside is that you have
multiple containers, each claiming to support Avalon, but not entirely
compatible. And no one able to say conclusively what it takes to be
compatible, and what the standards are for implementors or application
developers. As you noted:
> we've barely gathered a community for Avalon-Framework (our principal
art).
There is a nice list of projects that use Avalon-Framework, but that is
clearly not sufficient. More in necessary: excalibur, cornerstone, a
container ... and compatibility has come up as an issue.
The idea of the scalable container is that there appears to be a belief
amongst your peers that a container core can be built around which can be
attached services and containers that will build a scalable container.
Developing A5 doesn't mean throwing out A4, either concepts or code. You
may start with a clean slate, but then incorporate everything that has been
learned doing A4, and make use of what code can be incorporated from A4.
Yes, I think that there will be refactoring. I can't see how to do a
scalable, profilable, container without considerable refactoring of the
existing container code. But I don't think that the statement "diss their
predecessors work, and suggest complete rewrite" applies.
> I'm going to take a wild guess here that nobody other Stephen (who is
> in the joyous position of being paid to work on Open Source, for a
> company leveraging that for commercial gain - no 'tools boy' he) has the
> bandwidth to do the entire thing.
A constant problem in all Open Source communities.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>> I'm going to take a wild guess here that nobody other Stephen (who is
>> in the joyous position of being paid to work on Open Source, for a
>> company leveraging that for commercial gain - no 'tools boy' he) has
>> the bandwidth to do the entire thing.
>
>
> Paul:
>
> Just for your information - I am not paid to work on open-source.
My apologies.
I'll be less jealous in future!
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Paul Hammant wrote:
>
>> I'm going to take a wild guess here that nobody other Stephen (who is
>> in the joyous position of being paid to work on Open Source, for a
>> company leveraging that for commercial gain - no 'tools boy' he) has
>> the bandwidth to do the entire thing.
>
> Paul:
>
> Just for your information - I am not paid to work on open-source.
Does anybody *ever* get ever paid for OS? ;-P
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> I'm going to take a wild guess here that nobody other Stephen (who is
> in the joyous position of being paid to work on Open Source, for a
> company leveraging that for commercial gain - no 'tools boy' he) has
> the bandwidth to do the entire thing.
Paul:
Just for your information - I am not paid to work on open-source.
Cheeers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
>> We'd not seen the Tomcat team come to us and say "we love Avalon's
>> ideas but give us a container that we can work with".
>
>
> IMHO having multiple containers is one of the reasons that stamps us
> as a "research" project, not ready for real-life usage (not true, of
> course, but happens to be percieved). The reasonong is that having
> multiple implementation is the proof that none of them is good enough.
>
I'll continue in the devils advocate mode a while longer ...
Our problem was that we blurred the name 'Avalon' We were inprecise
about Avalon-Framework, AvalonX AvalonY etc.
We have no proven need for an UberContainer (as per Agile definitions -
simplest thing et al). We will shortly be back in the big-plan,
mega-design, architecture purgatory. Currently we are attacking the CVS
depots. It's not the first time it has happend twice now in my time.
I'm going to take a wild guess here that nobody other Stephen (who is
in the joyous position of being paid to work on Open Source, for a
company leveraging that for commercial gain - no 'tools boy' he) has the
bandwidth to do the entire thing. I;ve already see a cuple of the newer
enthusiasts post tentative "great idea, but I am not sure I have the
time" mails.
A worse sin, not yet quite prevalent here is typical of companies where
some team of new brooms comes in (with lofty architect titles), and take
ten seconds to diss their predecessors work, and suggest complete
rewrite. I used to be one of them. Nowadays, I hold this (
http://www.joelonsoftware.com/articles/fog0000000069.html ) to be a
guiding lesson. We're not quite the same here, but I feel it was wrong
for us to propose, vote, accept the need for rewrite when we've barely
gathered a community for Avalon-Framework (our principal art). I
appreciate that we have accpeted that it will happen though.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> We'd not seen the Tomcat team come to us
> and say "we love Avalon's ideas but give us a container that we can work
> with".
IMHO having multiple containers is one of the reasons that stamps us as
a "research" project, not ready for real-life usage (not true, of
course, but happens to be percieved). The reasonong is that having
multiple implementation is the proof that none of them is good enough.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> Paul,
>
>
>>I loved the multi container world. I have two (Jesktop and EOB) that
>>stand to be obsoleted in the stamepede towards uber. If it works
>>great, but I have my doubts.
>
>
> 1) You are a valued member of the Avalon Community. You
> have the ability to shape the scalable container to
> ensure that your existing Avalon applications work.
>
> 2) Stronger statement: you, and the rest of the Avalon
> community have the responsibility to ensure that no
> Avalon applications are left behind "in the stampede
> towards [the scalable container]."
I totally agree.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Avalon Components
Posted by "Noel J. Bergman" <no...@devtech.com>.
Paul,
> I loved the multi container world. I have two (Jesktop and EOB) that
> stand to be obsoleted in the stamepede towards uber. If it works
> great, but I have my doubts.
1) You are a valued member of the Avalon Community. You
have the ability to shape the scalable container to
ensure that your existing Avalon applications work.
2) Stronger statement: you, and the rest of the Avalon
community have the responsibility to ensure that no
Avalon applications are left behind "in the stampede
towards [the scalable container]."
In other words, not only do you have the opportunity to make sure that
Jesktop and EOB can work, but the entire Community has the responsibility to
do so. It would be unconscionable for the Avalon Community to leave your
projects behind. If anything, I might argue that Avalon should keep
AvalonDB (and other existing Avalon apps) in a sandbox, and copy over
Jesktop and EOB, for the specific purpose of using them as real-world
validators for A5. A5 needs real-world apps to make sure that it provides
migration through backwards compatibility, migration tools, and/or clearly
documented changes for component/application authors.
> We were having a great time with many containers and were only at
> the start of the container landscape.
I don't see that the scalable container idea changes that, Paul. The
essential idea is simply to have lots of core code, and build the container
from components, with optional features as desired.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
>> I do not share you vision, however it is felt that this is best, so
>> be it.
>
>
> I'd like to hear yours, or at least why you don't like the above!
There is not much point to opening the wound again. In some way shape
or form Uber is coming. I do not believe the merit need was there. I
loved the multi container world. I have two (Jesktop and EOB) that
stand to be obsoleted in the stamepede towards uber. If it works
bgreat, but I have my doubts.
Also as I work for an agile consultancy, I belive in the refactor (big
design) from working, live and deployed (small design) projects.
Phoenix and Fortress and ECM and Merlin were that. EOB and Jesktop
too. We were having a great time with many containers and were only at
the start of the container landscape. We'd not seen the Tomcat team
come to us and say "we love Avalon's ideas but give us a container that
we can work with". The mandate, based on merit, is completely missing.
We'd barely convinced anyone to make non static components to sit in an
IoC container.
As I say, I only wanted to remind people that though I am helping with
the Uber effort and the big depot changes, I do not agree with them.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
> Leo,
>
>> Somewhere in the future, I would like avalon.apache.org to only be about
>>
>> org.apache.avalon.framework
>> org.apache.avalon.framework.impl
>> org.apache.avalon.container
>> org.apache.avalon.container.impl
>> org.apache.avalon.util (*)
>>
> I do not share you vision, however it is felt that this is best, so be it.
I'd like to hear yours, or at least why you don't like the above!
cheers,
- Leo
(clarification: I would _like_ to be able to have only
org.apache.avalon.container
org.apache.avalon.container.impl
But I'm not convinced just yet that it is also _possible_.)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
> Somewhere in the future, I would like avalon.apache.org to only be about
>
> org.apache.avalon.framework
> org.apache.avalon.framework.impl
> org.apache.avalon.container
> org.apache.avalon.container.impl
> org.apache.avalon.util (*)
>
I do not share you vision, however it is felt that this is best, so be it.
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
[...]
> This move Nicola's proposing is a baby step closer to that, and has
> added advantage of him and others doing the move splitting up
> cornerstone into new jars, getting the james people in closer, etc etc.
Good summary. Yes, this is the idea.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
> Leo,
hey Paul!
> I don't think there is enough merit to a copy/symlink solution, on the
> basis that it is only a move not a real rationalisation.
>
> We will be left with some comps using ...
>
> org.apache.avalon.excalibur.*
> org.apache.excalibur.*
> org.apache.avalon.cornerstone.*
>
> ... packaging.
>
> Seems like we move depots forever......
my feeling too.
For clarity, here's my reasoning:
Somewhere in the future, I would like avalon.apache.org to only be about
org.apache.avalon.framework
org.apache.avalon.framework.impl
org.apache.avalon.container
org.apache.avalon.container.impl
org.apache.avalon.util (*)
* stuff like ContainerUtil, ConfigurationUtil, SaxConfigurationBuilder.
Not stuff like logkit.
with everything else we have at avalon currently moving to either
org.apache.commons.*
or
org.apache.*
or
org.somewhere.else.if.the.maintainers.want.it.that.way
and corresponding cvs module structure. Been saying that for a long time
now. This move Nicola's proposing is a baby step closer to that, and has
added advantage of him and others doing the move splitting up
cornerstone into new jars, getting the james people in closer, etc etc.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
I don't think there is enough merit to a copy/symlink solution, on the
basis that it is only a move not a real rationalisation.
We will be left with some comps using ...
org.apache.avalon.excalibur.*
org.apache.excalibur.*
org.apache.avalon.cornerstone.*
... packaging.
Seems like we move depots forever......
- Paul
>> Ok, here is how I thought we could do Avalon Components:
>>
>> 1 - rename jakarta-avalon-excalibur CVS module to avalon-components
>> 1-b - symlink so that you can checkout it as jakarta-avalon-excalibur
>> for some time
>> 2 - move the cornerstone component dirs under that repo (simple cp)
>> 3 - add them in the "excalibur" build
>>
>> This would make us almost instantly have a common repo for all
>> components that we can open to the James committers as you say.
>>
>> The only real work would be to add them to the build of "excalibur",
>> which is not a big feat.
>>
>> This would be a first step; in the meantime we can still migrate
>> package per package of non-Avalon stuff to JC, and decide about the
>> others as we proceed. But in the meantime this would mean that we
>> have taken a step towards a single component system, and towards a
>> tighter relationship with our users.
>>
>> Deal?
>
>
> +0 (ie yes but I have different priorities :)
>
> cheers,
>
> - Leo
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Leo Simons <le...@apache.org>.
> Ok, here is how I thought we could do Avalon Components:
>
> 1 - rename jakarta-avalon-excalibur CVS module to avalon-components
> 1-b - symlink so that you can checkout it as jakarta-avalon-excalibur
> for some time
> 2 - move the cornerstone component dirs under that repo (simple cp)
> 3 - add them in the "excalibur" build
>
> This would make us almost instantly have a common repo for all
> components that we can open to the James committers as you say.
>
> The only real work would be to add them to the build of "excalibur",
> which is not a big feat.
>
> This would be a first step; in the meantime we can still migrate package
> per package of non-Avalon stuff to JC, and decide about the others as we
> proceed. But in the meantime this would mean that we have taken a step
> towards a single component system, and towards a tighter relationship
> with our users.
>
> Deal?
+0 (ie yes but I have different priorities :)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Nicola Ken Barozzi wrote:
>
>>>> More practically, it would unite Excalibur and Cornerstone, and make
>>>> it possible for James developers to fix the Cornerstone components
>>>> that are driving them mad directly in the repository, and facilitate
>>>> the usage and fixing of our components by interested Turbine
>>>> developers.
>>>
>>> big advantage!
>>
>> Ok, let's see then how to make it happen. :-)
>
> yep.
>
[...]
>> MHO is that it still doesn't make sense to have a completely common
>> component repository.
>
>
> also agreed. I think we should make a distinction between component and
> component. I think we should seperate based on usage space:
>
> - framework development (1)
> - container development (2)
> - application framework development (3)
> - application development (4)
>
> (1),(2) ==> in avalon
> (3) ==> okay in avalon, but preferably elsewhere in the future
> (4) ==> elsewhere
>
>>> On my agenda is asking: "Guys, can we move components X, Y, Z
>>> currently in cvs module A, B, C over to Commons?"
>>>
>>> And then doing it. Until I see a definitive "no" answer I'm not
>>> liking "Avalon Components".
>>
>>
>> no, then.
>>
>> I'm (vote) -1 towards moving them into Commons now. In the future,
>> yes, but not now. Moving them there would refragment our community
>> with what benefits?
>
> removing fragmentation of the apache community of course!
+1
>> I only see negative things of doing this /now/.
>>
>> I repeat that I like the concept of a common repository, but I
>> question the benefits of doing it /now/.
>
> ok.
>
[...]
>> I'm talking about *Avalon" Components, ie those that had the
>> "Component" interface, to be clear. Anything that is not *strictly* an
>> Avalon Component-Service should (or I'd even say must) go elswhere,
>> and my favourite place for it is in Jakarta Commons, as has been done
>> till now.
>
> note that the difference between an "*Avalon* Component" and another
> component is often just a compile-time and runtime dependency on
> avalon-framework.jar, as well as sometimes some renaming of methods. You
> shouldn't make a distinction based on that.
Of course, having a couple of Avalon methods would just be fooling, I agree.
> I think we should strive to move components in (3) or (4) (which are not
> used in building other parts of avalon (ie user space code)) elsewhere
> as well. KISS.
>
>> As for utility code for making containers, it should all go in the
>> container that uses them, because we will be making a single container.
>
> not against it (ie I find all that stuff takes a lot of work and there
> must be another reason than "it is clean" for me to do that work).
Agreed. As we agree on the principle, when we will start uniting
containers you will see that other things will follow. I'm also against
doing it just for the sake of it.
>> _framework_
>>
>>
>> Avalon4 ----------------------------------- AvalonFive-F
>
>
> note that perhaps:
> 2001 ----------------------------------- 2022
Could be. I'm with you in stressing that A4 is something we should build
upon. Anyway, it's the container evolution that presses me, not the
framework.
>> _container_
>>
>> ECM ---- Fortress ---- Merlin's Fortress-----AvalonFive-C
>> ^ ^
>> | |
>> Merlin (unreleased)-' |
>> |
>> |
>> Phoenix ----------------------------------'
>
>
> I think your AvalonFive-C should actually just be an Avalon4 container,
> and that "Merlin's Fortress" shouldn't be removed as a step...Other than
> that, yep! so:
>
> ECM ---- Fortress --------- SuperAvalonC ---------AvalonFive-C
> ^
> |
> Merlin (unreleased)-'
> All other dev code -'
> (like containerkit)-|
> |
> Phoenix ------------/---------maintaince-only----retire
>
> but this should go under the roadmap thread....
Yes, these two threads have some overlap.
My roadmap was based on what I read on this list, but I also had
concerns about it being too baby-stepped.
Yes, I like yours better.
>> _components_
>>
>> Jakarta Commons
>> ^
>> |
>> (utils)
>> |
>> Excalibur ------------ Avalon Components --(*)-- Apache Commons
>> ^ ^ ^
>> Cornerstone -----' | |
>> | |
>> Cocoon Components ---' |
>> |
>> Turbine Fulcrum ---(*)------------------------'
>
>
> ehm...ok...But I really have absolutely no desire to go through all the
> work to do lots of cvs and package migration.
Hold it! Who said that? No package will change. I see now why you may
think I'm nuts! ;-)
> I have some different
> priorities.
>
> And I have lots of demands about how to do it if others are to do this
> work (like it has to be started and _finished_ within a reasonable time
> frame (ie not like the previous refactoring attempts), it needs to work
> with gump, it needs to be easily maintainable by peopl as dumb as me, it
> should be backwards-compatible, it needs to satisfy actual need, it
> needs clear documentation, ......)
Yes, Yes, Yes. See below.
>>> Nor do I think it is of interest to the james or turbine developers
>>> to work on _those_ components.
>>
>>
>> It is. James uses Cornerstone components that are now bugged. They
>> want to fix them. I think it's in the best interest of both of us
>> projects to make it happen.
>
>
> Cool.
>
> way easier: I'm supportive of granting all james committers voting &
> commit privelidges wrt the cornerstone repo. It's a lot less work than
> doing lots of confusing cvs/package/whatever migration!
Ok, here is how I thought we could do Avalon Components:
1 - rename jakarta-avalon-excalibur CVS module to avalon-components
1-b - symlink so that you can checkout it as jakarta-avalon-excalibur
for some time
2 - move the cornerstone component dirs under that repo (simple cp)
3 - add them in the "excalibur" build
This would make us almost instantly have a common repo for all
components that we can open to the James committers as you say.
The only real work would be to add them to the build of "excalibur",
which is not a big feat.
This would be a first step; in the meantime we can still migrate package
per package of non-Avalon stuff to JC, and decide about the others as we
proceed. But in the meantime this would mean that we have taken a step
towards a single component system, and towards a tighter relationship
with our users.
Deal?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
>>> More practically, it would unite Excalibur and Cornerstone, and make
>>> it possible for James developers to fix the Cornerstone components
>>> that are driving them mad directly in the repository, and facilitate
>>> the usage and fixing of our components by interested Turbine developers.
>>
>> big advantage!
>
> Ok, let's see then how to make it happen. :-)
yep.
>>> There were two issues brought up about this happening.
>>>
>>> Leo Simmons correctly reminded that there is an Apache Commons
>>> project, that could make a cool repository for all Avalon Components
>>> for all Apache projects.
>>>
>>> IMHO we are still far away from that possibility. I really don't
>>> think that in the short-mid term Turbine or James developers would
>>> want to move their stuff into that repo, because there is no real
>>> need. What they would do, is to partecipate in the *generic*
>>> components, that we would keep here, in Avalon Components.
>>
>> IMO all it takes is someone 'just doing it'. Apache Commons is just
>> about ready for some components. I'm not saying the turbine or james
>> developers would need to move their components, but if we move ours
>> they can still get access as well....
>
> This is not a reason for moving to Apache Commons though.
yep. The reason for moving to Apache Commons is that that is a location
for 'common' components, whereas Apache Avalon is not.
> MHO is that it still doesn't make sense to have a completely common
> component repository.
also agreed. I think we should make a distinction between component and
component. I think we should seperate based on usage space:
- framework development (1)
- container development (2)
- application framework development (3)
- application development (4)
(1),(2) ==> in avalon
(3) ==> okay in avalon, but preferably elsewhere in the future
(4) ==> elsewhere
>> On my agenda is asking: "Guys, can we move components X, Y, Z
>> currently in cvs module A, B, C over to Commons?"
>>
>> And then doing it. Until I see a definitive "no" answer I'm not liking
>> "Avalon Components".
>
> no, then.
>
> I'm (vote) -1 towards moving them into Commons now. In the future, yes,
> but not now. Moving them there would refragment our community with what
> benefits?
removing fragmentation of the apache community of course!
> I only see negative things of doing this /now/.
>
> I repeat that I like the concept of a common repository, but I question
> the benefits of doing it /now/.
ok.
>> I'm so very much against "Yet Another Commons" . . . . Jakarta
>> Commons, XML Commons, Apache Commons, Avalon Commons, James Commons,
>> Cocoon Commons.......it's simply doesn't make sense. And I'm not even
>> talking about the negative vibes it'll send through the wider
>> community (based on experience from the reorg@apache list).
>
> Ok, then, your point is valid, let's remove the Component "Sandbox"
> part. I think your observation on this is correct. We have our Avalon
> Sandbox for the Avalon core committers stuff. For Avalon Components
> there would be no sandbox then, ok.
good.
>> We've got two kinds of components:
>>
>> - those useful in a very wide scope, like Zip or Datasource
>> - those useful only (mostly) in developing avalon containers or
>> infrastructure on top of avalon, like instrument, extension,
>> containerkit....
>>
>> for the first one, that should go to a _common_ commons. For the
>> second one, if it makes sense to have those seperated out into a
>> different cvs, okay.
>
> Leo, I think we had already decided this, sorry if I was not clear.
>
> I'm talking about *Avalon" Components, ie those that had the "Component"
> interface, to be clear. Anything that is not *strictly* an Avalon
> Component-Service should (or I'd even say must) go elswhere, and my
> favourite place for it is in Jakarta Commons, as has been done till now.
note that the difference between an "*Avalon* Component" and another
component is often just a compile-time and runtime dependency on
avalon-framework.jar, as well as sometimes some renaming of methods. You
shouldn't make a distinction based on that.
I think we should strive to move components in (3) or (4) (which are not
used in building other parts of avalon (ie user space code)) elsewhere
as well. KISS.
> As for utility code for making containers, it should all go in the
> container that uses them, because we will be making a single container.
not against it (ie I find all that stuff takes a lot of work and there
must be another reason than "it is clean" for me to do that work).
> _framework_
>
>
> Avalon4 ----------------------------------- AvalonFive-F
note that perhaps:
2001 ----------------------------------- 2022
> _container_
>
> ECM ---- Fortress ---- Merlin's Fortress-----AvalonFive-C
> ^ ^
> | |
> Merlin (unreleased)-' |
> |
> |
> Phoenix ----------------------------------'
I think your AvalonFive-C should actually just be an Avalon4 container,
and that "Merlin's Fortress" shouldn't be removed as a step...Other than
that, yep! so:
ECM ---- Fortress --------- SuperAvalonC ---------AvalonFive-C
^
|
Merlin (unreleased)-'
All other dev code -'
(like containerkit)-|
|
Phoenix ------------/---------maintaince-only----retire
but this should go under the roadmap thread....
> _components_
>
> Jakarta Commons
> ^
> |
> (utils)
> |
> Excalibur ------------ Avalon Components --(*)-- Apache Commons
> ^ ^ ^
> Cornerstone -----' | |
> | |
> Cocoon Components ---' |
> |
> Turbine Fulcrum ---(*)------------------------'
ehm...ok...But I really have absolutely no desire to go through all the
work to do lots of cvs and package migration. I have some different
priorities.
And I have lots of demands about how to do it if others are to do this
work (like it has to be started and _finished_ within a reasonable time
frame (ie not like the previous refactoring attempts), it needs to work
with gump, it needs to be easily maintainable by peopl as dumb as me, it
should be backwards-compatible, it needs to satisfy actual need, it
needs clear documentation, ......)
>> Nor do I think it is of interest to the james or turbine developers to
>> work on _those_ components.
>
> It is. James uses Cornerstone components that are now bugged. They want
> to fix them. I think it's in the best interest of both of us projects to
> make it happen.
Cool.
way easier: I'm supportive of granting all james committers voting &
commit privelidges wrt the cornerstone repo. It's a lot less work than
doing lots of confusing cvs/package/whatever migration!
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Folks,
>
> Procs and Cons... Greater participation from others and our user
> comminity et al versus receipt of patches.
Very well said.
> Clearly we differ to other commons places, in that there is some
> dependance on Avalon Framework interfaces.
Yes. Some times I ask myself if it's really necessary...
> One thing we have to solve is the logging issue (prevalent static
> loggers beating IoC loggers in terms of server-side usage counts). I've
> been thinking about it a lot, and it is the final barrier to being able
> to create a component view world that includes a component based
> repository.
Hope you find a workable solution, I see its importance too.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
Procs and Cons... Greater participation from others and our user
comminity et al versus receipt of patches.
Clearly we differ to other commons places, in that there is some
dependance on Avalon Framework interfaces.
One thing we have to solve is the logging issue (prevalent static
loggers beating IoC loggers in terms of server-side usage counts). I've
been thinking about it a lot, and it is the final barrier to being able
to create a component view world that includes a component based repository.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Hi Nicola,
>
> Nicola Ken Barozzi wrote:
> <snipping lots of stuff/>
>
>> The main reason to make this here at Avalon is to have real contact with
>> the users of Avalon, and have them actively partecipate in the component
>> development. Avalon has had great benefit from the partecipation had in
>> the last month of outer-avalon developers of projects that use Avalon,
>> and we would like it to continue.
>
> +1.
>
>> More practically, it would unite Excalibur and Cornerstone, and make
>> it possible for James developers to fix the Cornerstone components
>> that are driving them mad directly in the repository, and facilitate
>> the usage and fixing of our components by interested Turbine developers.
>
> big advantage!
Ok, let's see then how to make it happen. :-)
>> There were two issues brought up about this happening.
>>
>> Leo Simmons correctly reminded that there is an Apache Commons
>> project, that could make a cool repository for all Avalon Components
>> for all Apache projects.
>>
>> IMHO we are still far away from that possibility. I really don't think
>> that in the short-mid term Turbine or James developers would want to
>> move their stuff into that repo, because there is no real need. What
>> they would do, is to partecipate in the *generic* components, that we
>> would keep here, in Avalon Components.
>
>
> IMO all it takes is someone 'just doing it'. Apache Commons is just
> about ready for some components. I'm not saying the turbine or james
> developers would need to move their components, but if we move ours they
> can still get access as well....
This is not a reason for moving to Apache Commons though. We can still
make them partecipate in "our" components.
MHO is that it still doesn't make sense to have a completely common
component repository.
> On my agenda is asking: "Guys, can we move components X, Y, Z currently
> in cvs module A, B, C over to Commons?"
>
> And then doing it. Until I see a definitive "no" answer I'm not liking
> "Avalon Components".
no, then.
I'm (vote) -1 towards moving them into Commons now. In the future, yes,
but not now. Moving them there would refragment our community with what
benefits? Move things that we count on and are stable under SVN that we
decided not to use for container stuff yet, and move the community out?
I only see negative things of doing this /now/.
I repeat that I like the concept of a common repository, but I question
the benefits of doing it /now/.
>> I have not yet recieved public answer from the question I gave to the
>> board about this. TO resolve this, I propose that we ask the board to
>> retify an addendum at the next meeting for our charter *if* they
>> decide that it's needed for this subproject creation:
>>
>> RESOLVED, that the Avalon PMC be and hereby is responsible
>> for the creation and maintenance of software related to
>> component and service management, and components and services
>> themselves designed to operate in it, based on software licensed
>> to the Foundation;
>
>
> I'm so very much against "Yet Another Commons" . . . . Jakarta Commons,
> XML Commons, Apache Commons, Avalon Commons, James Commons, Cocoon
> Commons.......it's simply doesn't make sense. And I'm not even talking
> about the negative vibes it'll send through the wider community (based
> on experience from the reorg@apache list).
Ok, then, your point is valid, let's remove the Component "Sandbox"
part. I think your observation on this is correct. We have our Avalon
Sandbox for the Avalon core committers stuff. For Avalon Components
there would be no sandbox then, ok.
But Stephen is talking about an Avalon "playground", a slightly
different notion, let's then remove this notion from this porposal and
focus on the Components repo.
Avalon Components is *not* a Avalon Commons. It's about the Components
*we* make. I'd never ever ask Turbine and James to move their Components
here, unless they have a compelling reason to, like Cocoon does with
excalibur components.
We are still making the container that will make Components completely
compatible. Until then, I don't see a compelling reason to switch to a
new repository in a new project with a new VCS system.
> We've got two kinds of components:
>
> - those useful in a very wide scope, like Zip or Datasource
> - those useful only (mostly) in developing avalon containers or
> infrastructure on top of avalon, like instrument, extension,
> containerkit....
>
> for the first one, that should go to a _common_ commons. For the second
> one, if it makes sense to have those seperated out into a different cvs,
> okay.
Leo, I think we had already decided this, sorry if I was not clear.
I'm talking about *Avalon" Components, ie those that had the "Component"
interface, to be clear. Anything that is not *strictly* an Avalon
Component-Service should (or I'd even say must) go elswhere, and my
favourite place for it is in Jakarta Commons, as has been done till now.
As for utility code for making containers, it should all go in the
container that uses them, because we will be making a single container.
[()*=eventually]
_framework_
Avalon4 ----------------------------------- AvalonFive-F
_container_
ECM ---- Fortress ---- Merlin's Fortress-----AvalonFive-C
^ ^
| |
Merlin (unreleased)-' |
|
|
Phoenix ----------------------------------'
_components_
Jakarta Commons
^
|
(utils)
|
Excalibur ------------ Avalon Components --(*)-- Apache Commons
^ ^ ^
| | |
Cornerstone -----' | |
| |
| |
Cocoon Components ---' |
|
|
Turbine Fulcrum ---(*)------------------------'
> But that certainly doesn't require amendment of the board
> resolution.
Based on Stephen's comments, it could be. I think it doesn't, I was
trying to consider his concerns.
> Nor do I think it is of interest to the james or turbine
> developers to work on _those_ components.
It is. James uses Cornerstone components that are now bugged. They want
to fix them. I think it's in the best interest of both of us projects to
make it happen.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Avalon Components
Posted by Berin Loritsch <bl...@citi-us.com>.
> This is same concern that is underling my last message. I'm
> bothered by
> the notion of a Avalon Commons as another repository
> (although I can see
> benefits), but I think Leo's comments on subject are on the button.
> However - ther is something missing - a playground for user to
> experiment with Avalon and get our feedback on apprach, best
> practices,
> etc. The sort of place that supports and supports the
> adoption hurdle.
> It's not the sandbox - it something like:
>
> ${avalon-playgound}
AKA avalon-sandbox?
A completely uncontrolled CVS archive is not good.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> I'm so very much against "Yet Another Commons" . . . . Jakarta
> Commons, XML Commons, Apache Commons, Avalon Commons, James Commons,
> Cocoon Commons.......it's simply doesn't make sense. And I'm not even
> talking about the negative vibes it'll send through the wider
> community (based on experience from the reorg@apache list).
>
> We've got two kinds of components:
>
> - those useful in a very wide scope, like Zip or Datasource
> - those useful only (mostly) in developing avalon containers or
> infrastructure on top of avalon, like instrument, extension,
> containerkit....
>
> for the first one, that should go to a _common_ commons. For the
> second one, if it makes sense to have those seperated out into a
> different cvs, okay. But that certainly doesn't require amendment of
> the board resolution. Nor do I think it is of interest to the james or
> turbine developers to work on _those_ components.
This is same concern that is underling my last message. I'm bothered by
the notion of a Avalon Commons as another repository (although I can see
benefits), but I think Leo's comments on subject are on the button.
However - ther is something missing - a playground for user to
experiment with Avalon and get our feedback on apprach, best practices,
etc. The sort of place that supports and supports the adoption hurdle.
It's not the sandbox - it something like:
${avalon-playgound}
Image multiple project in avalon playground - with the conditions that
content in playground is just that - somewhere to play - to learn - not
a platform for building a private party - an environment for learing,
evolving and moving on.
Thoughts?
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Avalon Components
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm so very much against "Yet Another Commons"
For any "commons", I do think that you need to understand the context. It
isn't as if they are common out of context. To be truely common, something
would need to be dependent upon nothing (or at least a universal context).
In the case of Avalon Commons, it would be for components that require the
Avalon frameworks. For the sake of argument, if we had a "commons" for
James, it would be for modules that could plug into James.
That is the semantic argument for contextual commons.
The CVS rights argument is that CVS assigns rights on module boundaries. If
you have one Commons, then anyone allowed to work on one part can work on
all parts. True, Commons is using Subversion, but that just raises other
issues for anyone wanting to work on that code, and adds additional
complications for building Avalon and related projects, e.g., having to get
some out of CVS and some out of Subversion.
Be that as it may, I don't know that there is any point to an Avalon
Components module for the reasons Nicola states:
> It is. James uses Cornerstone components that are now bugged. They want
> to fix them. I think it's in the best interest of both of us projects to
> make it happen.
If that is the reason, then the solutions are to (a) have someone already in
Avalon make fixes and/or (b) just make one or more of us Committers on the
relevant Avalon module(s), which is the same as what the Avalon Components
proposal basically amounts does.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Avalon Components
Posted by Leo Simons <le...@apache.org>.
Hi Nicola,
Nicola Ken Barozzi wrote:
<snipping lots of stuff/>
> The main reason to make this here at Avalon is to have real contact with
> the users of Avalon, and have them actively partecipate in the component
> development. Avalon has had great benefit from the partecipation had in
> the last month of outer-avalon developers of projects that use Avalon,
> and we would like it to continue.
+1.
> More practically, it would unite Excalibur and Cornerstone, and make it
> possible for James developers to fix the Cornerstone components that are
> driving them mad directly in the repository, and facilitate the usage
> and fixing of our components by interested Turbine developers.
big advantage!
> There were two issues brought up about this happening.
>
> Leo Simmons correctly reminded that there is an Apache Commons project,
> that could make a cool repository for all Avalon Components for all
> Apache projects.
>
> IMHO we are still far away from that possibility. I really don't think
> that in the short-mid term Turbine or James developers would want to
> move their stuff into that repo, because there is no real need. What
> they would do, is to partecipate in the *generic* components, that we
> would keep here, in Avalon Components.
IMO all it takes is someone 'just doing it'. Apache Commons is just
about ready for some components. I'm not saying the turbine or james
developers would need to move their components, but if we move ours they
can still get access as well....
On my agenda is asking: "Guys, can we move components X, Y, Z currently
in cvs module A, B, C over to Commons?"
And then doing it. Until I see a definitive "no" answer I'm not liking
"Avalon Components".
> I have not yet recieved public answer from the question I gave to the
> board about this. TO resolve this, I propose that we ask the board to
> retify an addendum at the next meeting for our charter *if* they decide
> that it's needed for this subproject creation:
>
> RESOLVED, that the Avalon PMC be and hereby is responsible
> for the creation and maintenance of software related to
> component and service management, and components and services
> themselves designed to operate in it, based on software licensed
> to the Foundation;
I'm so very much against "Yet Another Commons" . . . . Jakarta Commons,
XML Commons, Apache Commons, Avalon Commons, James Commons, Cocoon
Commons.......it's simply doesn't make sense. And I'm not even talking
about the negative vibes it'll send through the wider community (based
on experience from the reorg@apache list).
We've got two kinds of components:
- those useful in a very wide scope, like Zip or Datasource
- those useful only (mostly) in developing avalon containers or
infrastructure on top of avalon, like instrument, extension,
containerkit....
for the first one, that should go to a _common_ commons. For the second
one, if it makes sense to have those seperated out into a different cvs,
okay. But that certainly doesn't require amendment of the board
resolution. Nor do I think it is of interest to the james or turbine
developers to work on _those_ components.
regards,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>