You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/08/05 15:00:34 UTC
[Proposal] Lowest Common Denominator From Paul Hammant (was Re: urban
legend ...)
Paul Hammant wrote:
>
> At some risk, I'd like to reopen this then. Proposal :
>
> 1) We strive for a lowest common denominator (LCD) approach with
> embracing of multiple value-added implementation, which may end up
> divergent without that being considered a failure. Thus A-F's Java
> interfaces are our point of unification. There is no single container.
> There is no unified assembly or configuration meta info specification at
> the application level. XML and other.
>
> 2) We drop a unified component-level meta info dependancy and
> configuration design. XML and other.
>
> This has been discussed to the tune of a million characters. Let us just
> see which of the two above committers have moved on (or not).
With all do respect, Paul, if we do this, then our job is done. THe
Avalon CVS is all that we should keep and everything else goes by-by.
The fun stuff would all be done elsewhere.
I fail to get excited about this proposal. Maybe it's just me. I gave
your proposal some more visibility to see if it is just me.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Lowest Common Denominator From Paul Hammant (was Re:
urban legend ...)
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Berin,
>>
>> 1) We strive for a lowest common denominator (LCD) approach with
>> embracing of multiple value-added implementation, which may end up
>> divergent without that being considered a failure. Thus A-F's Java
>> interfaces are our point of unification. There is no single
>> container. There is no unified assembly or configuration meta info
>> specification at the application level. XML and other.
>>
>> 2) We drop a unified component-level meta info dependancy and
>> configuration design. XML and other.
>>
>> This has been discussed to the tune of a million characters. Let us
>> just see which of the two above committers have moved on (or not).
>
> At some risk, I'd like to reopen this then. Proposal :
>
> With all do respect, Paul, if we do this, then our job is done. THe
> Avalon CVS is all that we should keep and everything else goes by-by.
>
> The fun stuff would all be done elsewhere.
Merlin, Fortress and others are still here. There is still work to make
components (seems to heve been forgotten). I am a late arriver to XP.
Though I am lucky enough to work for one of the worlds most practiced XP
shops. More than ever I believe that we Avaloners are too
design-ahead-of-need focussed. Woods for trees - declare A-F complete
at the Java level and stop talking about Avalon 5 etc. Embrace the
multi container view and start componentizing the rest of Apache.
OSS is not awlays about fun. We often miss off the point at which we
should be claiming we are finished at API level and merely work on
improved and alternate implementations.
> I fail to get excited about this proposal. Maybe it's just me. I gave
> your proposal some more visibility to see if it is just me.
Grand. I firmly in what I said as the best way for peace to break out here.
- Paul
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Proposal] Lowest Common Denominator From Paul Hammant (was Re: urban legend ...)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Paul Hammant wrote:
> 1) We strive for a lowest common denominator (LCD)
This assumes that A-F either:
1) can be evolved
2) has reached its final form
(1) is false, because it is evident that we can't cooperate. (2)
is false, because, well, do I really need to explain this?
So let's seek a much lower common denominator:
Let's just everyone fuck off to their own little projects
at SourceForge or wherever, and we can save the Apache board
some administration.
Enough "provocation". Sorry for picking your email Paul, and the
above isn't intended as an insult or something you should even
consider responding to.
It is however intended to be the logical conclusion of making
"let's agree to disagree" the first, last and only way of solving
any disagreement, which I think you are.
So what I am asking you is this:
1) How will A-F be evolved, given the problems we have?
2) What are the preconditions for (1) in terms of community
coding and social skill?
3) Are those preconditions fulfilled now?
4) If they were, would we still need this LCD approach?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Lowest Common Denominator From Paul Hammant (was Re:
urban legend ...)
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> Berin wrote;
>
>>Paul Hammant wrote:
>>
>>>At some risk, I'd like to reopen this then. Proposal :
>>>
>>>1) We strive for a lowest common denominator (LCD) approach with
>>>embracing of multiple value-added implementation, which may end up
>>>divergent without that being considered a failure. Thus A-F's Java
>>>interfaces are our point of unification. There is no single
>>>container. There is no unified assembly or configuration meta info
>>>specification at the application level. XML and other.
>>>
>>>2) We drop a unified component-level meta info dependancy and
>>>configuration design. XML and other.
>>>
>>>This has been discussed to the tune of a million characters. Let us
>>>just see which of the two above committers have moved on (or not).
>>
>>With all do respect, Paul, if we do this, then our job is done. THe
>>Avalon CVS is all that we should keep and everything else goes by-by.
>>
>>The fun stuff would all be done elsewhere.
>>
>>I fail to get excited about this proposal. Maybe it's just me. I gave
>>your proposal some more visibility to see if it is just me.
>
>
> Isn't this very fatalistic?
> 1. Meta-info model of components are required in the long run. Take the
> evolutionary approach and let the container development dictate the
> outcome. Stephen's work on the meta-info "break-out" is "Merlin's
> requirement", and is probably a good base to start at. At some point you
> declare this as "standard of Avalon 4.5", and the containers that wants to
> be compliant follow suit.
The proposal as I understood it means that we live with Avalon Framework
and that is it. SO it doesn't change. I have no problems with that.
>
> 2. Component packaging is IMVHO a completely missed area of Avalon focus.
> AT the present, there is no standardized way to package them, and expose
> them through some kind of repository system (perhaps only the through the
> Filesystem).
I can't seem to get enough interested people to attack this area.
>
> 3. Better tools to "wire" components, preferably as far as direct IDE
> support of Netbeans and/or Eclipse.
and IDEA. It would be great, but we only have so many developers.
>
> 4. Dynamic Components, that are added/removed on the fly, is another
> interesting area, where framework level specifications are required.
>
> I am sure there are many more, when the containers are "gathering
> experience" and bringing it to the table;
> "In Merlin we have found that ...."
That would be nice to hear.
> "Couldn't we consolidate around..."
I attempted that and got called a control freak.
> "Ok let's test that first... Yeah, easy to do that way in Merlin... Wow,
> in Fortress too..."
It was partly done with the extensions interfaces. It fell apart when
talking about the meta info.
>
> Healthy, evolutionary progress....
Its great on paper, but every time we try to merge on ideas it falls
apart. I need evidence that this is going to change before I can
get behind this.
>
> And as Paul said, it is not bad that a particular API doesn't evolve
> further. Some shark spieces doesn't either!
> New APIs to address newly encountered areas of interest.
>
Yes, but those APIs would be outside the realm of Avalon because we would
have stopped with Framework.
> Positive attitudes, strive forward and not bickering about current states.
> Get back to "Release Early, Release Often" and "Develop for Change"
> without being tied in with huge chunks of deprecated code.
We have to undo what was done in the past--we have huge chunks of deprecated
code. So what to do now.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Lowest Common Denominator From Paul Hammant (was Re: urban legend ...)
Posted by Niclas Hedhman <ni...@hedhman.org>.
Niclas wrote;
> 1. Meta-info model of components are required in the long run. Take the
> 2. Component packaging is IMVHO a completely missed area of Avalon
> 3. Better tools to "wire" components, preferably as far as direct IDE
> 4. Dynamic Components, that are added/removed on the fly, is another
Forgot one...
5. Component-assembly-into-components. Why can't a wire together a set of
components today and have that packaged as a single super-component, with
a large of hazzle??
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Lowest Common Denominator From Paul Hammant (was Re: urban legend ...)
Posted by Niclas Hedhman <ni...@hedhman.org>.
Berin wrote;
> Paul Hammant wrote:
>>
>> At some risk, I'd like to reopen this then. Proposal :
>>
>> 1) We strive for a lowest common denominator (LCD) approach with
>> embracing of multiple value-added implementation, which may end up
>> divergent without that being considered a failure. Thus A-F's Java
>> interfaces are our point of unification. There is no single
>> container. There is no unified assembly or configuration meta info
>> specification at the application level. XML and other.
>>
>> 2) We drop a unified component-level meta info dependancy and
>> configuration design. XML and other.
>>
>> This has been discussed to the tune of a million characters. Let us
>> just see which of the two above committers have moved on (or not).
>
> With all do respect, Paul, if we do this, then our job is done. THe
> Avalon CVS is all that we should keep and everything else goes by-by.
>
> The fun stuff would all be done elsewhere.
>
> I fail to get excited about this proposal. Maybe it's just me. I gave
> your proposal some more visibility to see if it is just me.
Isn't this very fatalistic?
1. Meta-info model of components are required in the long run. Take the
evolutionary approach and let the container development dictate the
outcome. Stephen's work on the meta-info "break-out" is "Merlin's
requirement", and is probably a good base to start at. At some point you
declare this as "standard of Avalon 4.5", and the containers that wants to
be compliant follow suit.
2. Component packaging is IMVHO a completely missed area of Avalon focus.
AT the present, there is no standardized way to package them, and expose
them through some kind of repository system (perhaps only the through the
Filesystem).
3. Better tools to "wire" components, preferably as far as direct IDE
support of Netbeans and/or Eclipse.
4. Dynamic Components, that are added/removed on the fly, is another
interesting area, where framework level specifications are required.
I am sure there are many more, when the containers are "gathering
experience" and bringing it to the table;
"In Merlin we have found that ...."
"Interesting, but in Fortress we are inclined to look at that problem
like..."
"Couldn't we consolidate around..."
"Ok let's test that first... Yeah, easy to do that way in Merlin... Wow,
in Fortress too..."
Healthy, evolutionary progress....
And as Paul said, it is not bad that a particular API doesn't evolve
further. Some shark spieces doesn't either!
New APIs to address newly encountered areas of interest.
Positive attitudes, strive forward and not bickering about current states.
Get back to "Release Early, Release Often" and "Develop for Change"
without being tied in with huge chunks of deprecated code.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org