You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/04/10 10:10:51 UTC
Future of Fortress
Gang,
I have just read through all of the Fortress discussion mails. There seems to
be 2 major consensus (we can agree on) in there;
1. ECM/Fortress should stay with Apache.
2. ECM/Fortress users should not be abondoned.
I also get the feeling that there are many proponents of Fortress to 'live
on', and if that true, we not do that...
I think I am more and more in favour of;
1. Apache Avalon = Component contracts.
2. Place Merlin & Fortress into subprojects of Avalon.
3. The Fortress gang rally a community around it to show that it is really
live and well, and not just "hot air".
WDYT?
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Shash Chatterjee <sh...@badfw.org>.
Niclas,
> Gang,
>
> I have just read through all of the Fortress discussion mails. There seems to
> be 2 major consensus (we can agree on) in there;
>
> 1. ECM/Fortress should stay with Apache.
> 2. ECM/Fortress users should not be abondoned.
>
> I also get the feeling that there are many proponents of Fortress to 'live
> on', and if that true, we not do that...
>
> I think I am more and more in favour of;
>
> 1. Apache Avalon = Component contracts.
> 2. Place Merlin & Fortress into subprojects of Avalon.
> 3. The Fortress gang rally a community around it to show that it is really
> live and well, and not just "hot air".
Yes, yes, yes...please, please, please! I cannot agree more!
I'll tell you one thing that I and many others have learnt while using
Avalon and developing services for Keel. Every time we add a second and
third implementation of a service, we find the need to change the
service interfaces we created the first time around. It takes the
sometimes opposing needs of different implementations, and the sometimes
opposing views of the different developers, for the generic interface to
materialize properly.
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Shash Chatterjee <sh...@badfw.org>.
>
> Now you are touching on the "Essence of Dispute" :o)
>
Essence of Debate? :-) Think positively!
> Is Avalon about Containers or about Components ?
>
I am no expert....I think it is about both, as it stands now. The
ServiceManager parts of the framework are about containers, "how do I
get my component". The life-cycle interfaces (and to a lesser degree,
the meta-data) is about components.
> If it is about containers, then I am banging my head in vain, that is fairly
> clear.
>
> IMHO, there are NO components out there worth the name, and IMHO Avalon should
> take the charge and get a proper component specification in place that should
> be as important to the Java community as the IC and "printed circuit board"
> was to the electronics industry.
I have to agree with you. This has long been a dream. I think we can
get to that eventually and strive for it. But, we need to be pragmatic
because of what the reality is. Even though we are far from perfection
in completely well-defined and portable components, we have to be able
to use the best of what is there, from Avalon and other containers. In
other words, I'd love to be get to 100% interchangeable components. In
the meantime, I'd be grateful to be able to save 99% of the work in
reusing a "less than perfect" component, for the price of changing a bit
of configuration or meta-data.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 11 April 2004 21:11, Shash Chatterjee wrote:
> We need to define ways to make the containers more flexible,
> not tied to a rigid spec.
Now you are touching on the "Essence of Dispute" :o)
Is Avalon about Containers or about Components ?
If it is about containers, then I am banging my head in vain, that is fairly
clear.
IMHO, there are NO components out there worth the name, and IMHO Avalon should
take the charge and get a proper component specification in place that should
be as important to the Java community as the IC and "printed circuit board"
was to the electronics industry.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Future of Fortress
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>> Is it only I who think that Avalon can step up and create this (a.k.a
>>> AvalonPlanet)??
>> Almost every single member of the PMC.
> *cough*consensus-via-attrition*cough*
Yes, I was thinking the same thing. And I don't believe that people really
understand the differences between developing a platform and an application.
I'm getting the terribly uncomfortable feeling that we cannot be entrusted
with the future of client projects. Would anyone other than those promoting
PlanetAvalon base their company's, or project's, future on Avalon today?
I think that the "PlanetAvalon" dream has a lot of potential. I would like
to see it given a chance. What I think has everyone tense is that the
current community may be disenfrancised in the process of building an all
new one.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by peter royal <pr...@apache.org>.
On Apr 11, 2004, at 6:35 AM, Stephen McConnell wrote:
> Niclas Hedhman wrote:
>> On Sunday 11 April 2004 12:22, hammett wrote:
>>> May be you concerns, but who shares it? Keep it simple.
>> Ok. Fair question.
>> Who does share my dream?
>> * A component developed against a set of (one or more)
>> specifications WILL work unmodified in all applications that
>> understand/"complies with" suc specification(s).
>> * Once components can be "managed" inside and outside applications,
>> it will drive applications in many directions, where containers are
>> only one such branch of development. The better the tools, the faster
>> components can be created, leading to more tool support and so on.
>> Is it only I who think that Avalon can step up and create this (a.k.a
>> AvalonPlanet)??
>
>
> Almost every single member of the PMC.
*cough*consensus-via-attrition*cough*
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: choices (was Re: Future of Fortress)
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
> It was your choice to leave that PMC and in doing so your choice to
> separate yourself from the body the takes responsibility for what is is
> that Avalon is and what it is that Avalon will be.
Yes, it was, dad. I won't regret that.
So you're free to lead Avalon to your personal goals, nobody will stand in
your path.
Now excuse me, I have better things to do than involve myself in such
pointless discussions >:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
choices (was Re: Future of Fortress)
Posted by Stephen McConnell <mc...@apache.org>.
hammett wrote:
> ----- Original Message -----
> From: "Stephen McConnell" <mc...@apache.org>
>
>>>Is it only I who think that Avalon can step up and create this (a.k.a
>>>AvalonPlanet)??
>>
>>Almost every single member of the PMC.
>
>
> Every single member that last of the PMC.
It was your choice to leave that PMC and in doing so your choice to
separate yourself from the body the takes responsibility for what is is
that Avalon is and what it is that Avalon will be.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
> > Is it only I who think that Avalon can step up and create this (a.k.a
> > AvalonPlanet)??
>
> Almost every single member of the PMC.
Every single member that last of the PMC.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> On Sunday 11 April 2004 12:22, hammett wrote:
>
>
>>May be you concerns, but who shares it? Keep it simple.
>
>
> Ok. Fair question.
>
> Who does share my dream?
>
> * A component developed against a set of (one or more) specifications WILL
> work unmodified in all applications that understand/"complies with" suc
> specification(s).
>
> * Once components can be "managed" inside and outside applications, it will
> drive applications in many directions, where containers are only one such
> branch of development. The better the tools, the faster components can be
> created, leading to more tool support and so on.
>
>
> Is it only I who think that Avalon can step up and create this (a.k.a
> AvalonPlanet)??
Almost every single member of the PMC.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Shash Chatterjee <sh...@badfw.org>.
Niclas,
> Who does share my dream?
>
> * A component developed against a set of (one or more) specifications WILL
> work unmodified in all applications that understand/"complies with" suc
> specification(s).
>
> * Once components can be "managed" inside and outside applications, it will
> drive applications in many directions, where containers are only one such
> branch of development. The better the tools, the faster components can be
> created, leading to more tool support and so on.
>
>
> Is it only I who think that Avalon can step up and create this (a.k.a
> AvalonPlanet)??
I think you will find very few people who will disagree with you.
However, the difference between the dream and reality today is quite
large, and constant work is needed in this area. But, tightening the
spec in Avalon may not be the answer. I, for one, don't want to just
use Avalon components. I want to use Jicarilla components, Pico
components, Spring components, HiveMind components.....bring them on.
No matter what we do in Avalon, there will always be innovation
elsewhere. We need to define ways to make the containers more flexible,
not tied to a rigid spec.
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Timothy Bennett <ex...@comcast.net>.
Niclas Hedhman wrote:
> On Sunday 11 April 2004 12:22, hammett wrote:
>
>
>>May be you concerns, but who shares it? Keep it simple.
>
>
> Ok. Fair question.
>
> Who does share my dream?
>
> * A component developed against a set of (one or more) specifications WILL
> work unmodified in all applications that understand/"complies with" suc
> specification(s).
>
> * Once components can be "managed" inside and outside applications, it will
> drive applications in many directions, where containers are only one such
> branch of development. The better the tools, the faster components can be
> created, leading to more tool support and so on.
>
>
> Is it only I who think that Avalon can step up and create this (a.k.a
> AvalonPlanet)??
>
>
> Cheers
> Niclas
+1
This is also my dream, Niclas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Future of Fortress
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > I keep thinking that this is a representation issue, and multiple forms
> > could be supported. A container could detect which, if any,
> > representations that it understands is present, and act accordingly.
> Agree. Unfortunately, the more such 'representations' that one introduces,
> the harder it is for both the container and the component authors, to
> support 'all'.
Also agreed. But I do not believe that we are dealing with an infinite, or
even large, number. We don't have even a handful. I think it is a totally
managable situation. But I'd like to see what folks like Berin, Carsten,
Leif, and Leo think.
> I am trying to break out of the stalemate around here, and forget about
> what we disagree about and try to concentrate on what we DO agree on
I recognize that, Niclas, and said as much to Hammett just a few minutes ago
in a message. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 13 April 2004 12:12, Noel J. Bergman wrote:
> I think you need to elaborate, but all in all, I think your ideas seem
> reasonable.
I will as soon as I get anywhere forward... Stay tuned.
> > Here the problems of consensus would start big time. Some would be
> > in favour of sticking to a Java only solution, others to files in
> > JAR or entries in Manifest, and perhaps another group would like to
> > see an RDF solution. Are they mutually exclusive? No, but the more
> > schemes the harder for everyone.
>
> I keep thinking that this is a representation issue, and multiple forms
> could be supported. A container could detect which, if any,
> representations that it understands is present, and act accordingly. If it
> did not find any, that would mean, in your words, that "the component
> doesn't work with that container."
Agree. Unfortunately, the more such 'representations' that one introduces, the
harder it is for both the container and the component authors, to support
'all'.
> However, with respect to consensus, it seems to me that although we
> sometimes get a reasonable and workable message like yours, from which
> people could try to build a consensus, we are increasingly seeing dug in
> positions of absolutes that leave no room.
I am trying to break out of the stalemate around here, and forget about what
we disagree about and try to concentrate on what we DO agree on - yes there
are such things :o)
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Future of Fortress
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niclas Hedhman wrote:
> Noel J. Bergman wrote:
> > > A component developed against a set of (one or more) specifications
> > > WILL work unmodified in all applications that understand/"complies
> > > with" suc specification(s).
> >
> > That is like saying that a J2EE component will run on every J2EE app
> > server. Very nice, but doesn't do much for J2SE or J2ME. Essentially,
> > you are saying that only an Avalon "J2EE" can/should exist.
> Not at all. I have probably not been good at communicating my findings.
I did not mean J2EE in the sense that it is necessarily heavyweight. J2EE
is a superset of the other platform specifications, and you are raising the
bar for the minimum platform specification.
That isn't necessarily a bad thing. I thought that your comments in this
most recent message were fairly measured and balanced. It would be
interesting to see how people in the Fortress community feel about them. I
thought I saw some earlier comments that were positive about the general
idea, so long as it doesn't break compatibility with existing code, but
responses from Stephen indicated that developing Fortress to support such
things is out of the question, because Merlin shall be the only Avalon
container. This appears to conflict with what others want, and does not
appear to be required by your desire to ...
> [establish] the existing formal contracts (pluralis) that do exist
> (by implementation coincidence) in ECM, Fortress and Merlin. Each
> container being developed then has a fairly straight forward task
> when encountering a component [...]
> that brings me to a much tougher nut to crack, since noone think
> it is an issue; How do you "Identify" a component? Or a service
> for that matter? I have no definate answers here yet, but I am
> actually leaning towards using a URN
I think you need to elaborate, but all in all, I think your ideas seem
reasonable.
> Here the problems of consensus would start big time. Some would be
> in favour of sticking to a Java only solution, others to files in
> JAR or entries in Manifest, and perhaps another group would like to
> see an RDF solution. Are they mutually exclusive? No, but the more
> schemes the harder for everyone.
I keep thinking that this is a representation issue, and multiple forms
could be supported. A container could detect which, if any, representations
that it understands is present, and act accordingly. If it did not find
any, that would mean, in your words, that "the component doesn't work with
that container."
However, with respect to consensus, it seems to me that although we
sometimes get a reasonable and workable message like yours, from which
people could try to build a consensus, we are increasingly seeing dug in
positions of absolutes that leave no room.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 13 April 2004 03:37, Noel J. Bergman wrote:
> > A component developed against a set of (one or more) specifications
> > WILL work unmodified in all applications that understand/"complies
> > with" suc specification(s).
>
> That is like saying that a J2EE component will run on every J2EE app
> server. Very nice, but doesn't do much for J2SE or J2ME. Essentially, you
> are saying that only an Avalon "J2EE" can/should exist.
Not at all. I have probably not been good at communicating my findings.
1. Specification declaration. If I provide a piece of code today, let's say a
JAR file, there is no way to know which specifications (pluralis) it
"complies with", "requires" and "requests". I am convinced that ALL
components would benefit from this.
2. Specifications should be kept very small, allowing components to "comply
with", "require" and/or "request" any subset of all or mutually exclusive
specifications.
3. By keeping Specifications small, they can evolve fairly easily.
After this has been established, it is a matter of establishing the existing
formal contracts (pluralis) that do exist (by implementation coincidence) in
ECM, Fortress and Merlin.
Each container being developed then has a fairly straight forward task when
encountering a component;
1. Does it "comply with" my own "required" contracts? Does it have same or a
higher 'minor' version and the same 'major' that I can work with?
2. Do I "comply with" its "required" contracts? Do I comply with the same or a
higher 'minor' version of the same 'major' that it requires?
If NOT, the component doesn't work with that container.
If the containers themselves could expose the same Specification "complies
with", "requires" and "requests", other applications can 'know' what will
work with what, and so on.
To call this a J2EE attempt is IMHO an over-statement.
Would it be possible to define J2EE under this? Yes, it is of course possible.
Would it be possible to define PicoComponents under this? Yes, equally true.
The challenge I am trying to figure out now is how should these declarations
be made. And that brings me to a much tougher nut to crack, since noone think
it is an issue; How do you "Identify" a component? Or a service for that
matter?
I have no definate answers here yet, but I am actually leaning towards using a
URN based on package+interface/class, since they are supposedly unique.
And if that is solved "Where does the Specification Declaration go?" is next.
Here the problems of consensus would start big time. Some would be in favour
of sticking to a Java only solution, others to files in JAR or entries in
Manifest, and perhaps another group would like to see an RDF solution.
Are they mutually exclusive? No, but the more schemes the harder for everyone.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Future of Fortress
Posted by "Noel J. Bergman" <no...@devtech.com>.
> A component developed against a set of (one or more) specifications
> WILL work unmodified in all applications that understand/"complies
> with" suc specification(s).
That is like saying that a J2EE component will run on every J2EE app server.
Very nice, but doesn't do much for J2SE or J2ME. Essentially, you are
saying that only an Avalon "J2EE" can/should exist.
> Once components can be "managed" inside and outside applications, it
> will drive applications in many directions, where containers are only
> one such branch of development. The better the tools, the faster
> components can be created, leading to more tool support and so on.
Perhaps, but entire application domains are removed from being able to use
Avalon, which eliminates their communities, and anyone who is aware of the
politics within this project would be increasing loathe to build using its
technology. Existing projects are starting to look at exit strategies.
I think that Alex had the right idea at a time before the Directory code was
encumbered. James is too dependent on Avalon for safety. We are going to
have to decouple it, using an approach similar to what Alex has done, in
order to ensure that James has options.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 11 April 2004 12:22, hammett wrote:
> May be you concerns, but who shares it? Keep it simple.
Ok. Fair question.
Who does share my dream?
* A component developed against a set of (one or more) specifications WILL
work unmodified in all applications that understand/"complies with" suc
specification(s).
* Once components can be "managed" inside and outside applications, it will
drive applications in many directions, where containers are only one such
branch of development. The better the tools, the faster components can be
created, leading to more tool support and so on.
Is it only I who think that Avalon can step up and create this (a.k.a
AvalonPlanet)??
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Niclas Hedhman" <ni...@hedhman.org>
> It is all about Component Interoperability, at container-level, at IDE
level,
> at search tools level, and every other conceivable application that may be
> interested in looking at the component.
So you'd like to get everything right at once in the first shot. Hmmm.
Thanks God I'm not part of this _dream_ anymore.
You're trying to make Avalon a thing that its not. Avalon is just a simple -
very simple - framework and some well-known semantics. IDE, search tools are
fluffy. May be you concerns, but who shares it? Keep it simple.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 11 April 2004 11:25, hammett wrote:
> No problem with that if these specs only describes container semantics -
> instead of merlin's contracts and inner-workings.
It is all about Component Interoperability, at container-level, at IDE level,
at search tools level, and every other conceivable application that may be
interested in looking at the component.
Today, we are very far from this, I would say the journey have just about
started.
I won't give up until this is achieved, as without it, COP is just another
'what could have been'...
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by peter royal <pr...@apache.org>.
On Apr 11, 2004, at 10:07 AM, Stephen McConnell wrote:
> Frankly guys, I'm not interested in discussing anything related to a
> multi-container avalon. That's history.
>
> Get on with the present.
How about making the "Single Avalon Platform" based around Fortress?
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Stephen McConnell <mc...@apache.org>.
Shash Chatterjee wrote:
> Stephen,
>
>>
>> So get active on the codebase - get voted in as a committer after
>> demonstrating commitment and ability to work with the community - and
>> get yourself onto the PMC - and from there influence the decisions
>> that are made. In the meantime - decisions have been made and Avalon
>> is moving forward. The question is not if we moving forward - the
>> question is how to deal with the pragmatics of migration and user
>> transitioning.
>
>
> I have sent in Fortress patches previously, I will continue to do so; I
> am certainly very active in and committed to creating Avalon components
> that the entire community can use. Having said that, given that very
> capable developers (no, let me state it, the *ORIGINAL AUTHORS OF AVALON
> AND MOST OF THE CONTAINERS*) who are already committers cannot do this
> because of the veto that you would give to everything that is
> non-Merlin, there is hardly a chance that little, old me could do
> anything to influence decisions.
Yep - heard this one before!
Frankly guys, I'm not interested in discussing anything related to a
multi-container avalon. That's history.
Get on with the present.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Shash Chatterjee <sh...@badfw.org>.
Stephen,
>
> So get active on the codebase - get voted in as a committer after
> demonstrating commitment and ability to work with the community - and
> get yourself onto the PMC - and from there influence the decisions that
> are made. In the meantime - decisions have been made and Avalon is
> moving forward. The question is not if we moving forward - the question
> is how to deal with the pragmatics of migration and user transitioning.
I have sent in Fortress patches previously, I will continue to do so; I
am certainly very active in and committed to creating Avalon components
that the entire community can use. Having said that, given that very
capable developers (no, let me state it, the *ORIGINAL AUTHORS OF AVALON
AND MOST OF THE CONTAINERS*) who are already committers cannot do this
because of the veto that you would give to everything that is
non-Merlin, there is hardly a chance that little, old me could do
anything to influence decisions.
I love the words "ability to work with the community"! Indeed!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Stephen McConnell <mc...@apache.org>.
Shash Chatterjee wrote:
> Niclas,
>
>> But it WOULD mean that since Avalon specs must be tightenend, Fortress
>> would have to comply with these for component interoperability
>> according to such new component specifications required to reach
>> there. That would not be optional.
>>
>
> Exactly. That is what I have been saying, that you cannot simply put
> Fortress in maintenance mode and forget about it. Fortress needs to
> support a common set of meta tags to allow even more component reuse,
> for new components that'll be written to the new specs. But, the fact
> remains, that for backwards compatibility Fortress will always need to
> support the current set of tags (and, therefore, the associated
> semantics) it supports.
>
> But I think you guys need to get off the high horse that says "once we
> have voted, that's it, we can never go back". There's too much
> dependence on the vote about the current meta package, the current
> repository, and the one container strategy. Please do not ignore the
> original authors of framework, ECM, Phoenix, Fortress: almost to a
> person they seem to say they would like something different. It is time
> to revisit all of those in the context of one framework and multiple
> containers.
So get active on the codebase - get voted in as a committer after
demonstrating commitment and ability to work with the community - and
get yourself onto the PMC - and from there influence the decisions that
are made. In the meantime - decisions have been made and Avalon is
moving forward. The question is not if we moving forward - the question
is how to deal with the pragmatics of migration and user transitioning.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Shash Chatterjee <sh...@badfw.org>.
Niclas,
> But it WOULD mean that since Avalon specs must be tightenend, Fortress would
> have to comply with these for component interoperability according to such
> new component specifications required to reach there. That would not be
> optional.
>
Exactly. That is what I have been saying, that you cannot simply put
Fortress in maintenance mode and forget about it. Fortress needs to
support a common set of meta tags to allow even more component reuse,
for new components that'll be written to the new specs. But, the fact
remains, that for backwards compatibility Fortress will always need to
support the current set of tags (and, therefore, the associated
semantics) it supports.
But I think you guys need to get off the high horse that says "once we
have voted, that's it, we can never go back". There's too much
dependence on the vote about the current meta package, the current
repository, and the one container strategy. Please do not ignore the
original authors of framework, ECM, Phoenix, Fortress: almost to a
person they seem to say they would like something different. It is time
to revisit all of those in the context of one framework and multiple
containers.
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by peter royal <pr...@apache.org>.
On Apr 10, 2004, at 10:40 PM, Niclas Hedhman wrote:
> On Sunday 11 April 2004 07:16, peter royal wrote:
>> I am not in favor
>> of forcing all containers to implement Merlin semantics.
>
> But it WOULD mean that since Avalon specs must be tightenend, Fortress
> would
> have to comply with these for component interoperability according to
> such
> new component specifications required to reach there. That would not be
> optional.
>
> My fear is that the light-weight gang are strong on opinion and weak on
> action.
The light-weight gang had solutions that worked that have been pushed
aside by the "heavy-weight" gang (just to create an opposite).
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Niclas Hedhman" <ni...@hedhman.org>
> But it WOULD mean that since Avalon specs must be tightenend, Fortress
would
> have to comply with these for component interoperability according to such
> new component specifications required to reach there. That would not be
> optional.
No problem with that if these specs only describes container semantics -
instead of merlin's contracts and inner-workings.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 11 April 2004 07:16, peter royal wrote:
> I am not in favor
> of forcing all containers to implement Merlin semantics.
But it WOULD mean that since Avalon specs must be tightenend, Fortress would
have to comply with these for component interoperability according to such
new component specifications required to reach there. That would not be
optional.
My fear is that the light-weight gang are strong on opinion and weak on
action.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by peter royal <pr...@apache.org>.
On Apr 10, 2004, at 4:10 AM, Niclas Hedhman wrote:
> I think I am more and more in favour of;
>
> 1. Apache Avalon = Component contracts.
> 2. Place Merlin & Fortress into subprojects of Avalon.
> 3. The Fortress gang rally a community around it to show that it is
> really
> live and well, and not just "hot air".
This is just about the Lowest Common Denominator approach that Paul
Hammant was a proponent of. I am in favor of that. I am not in favor
of forcing all containers to implement Merlin semantics.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Niclas Hedhman" <ni...@hedhman.org>
> 1. Apache Avalon = Component contracts.
> 2. Place Merlin & Fortress into subprojects of Avalon.
> 3. The Fortress gang rally a community around it to show that it is really
> live and well, and not just "hot air".
Finally I second something you said :-D
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Future of Fortress
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> Gang,
>
> I have just read through all of the Fortress discussion mails. There seems to
> be 2 major consensus (we can agree on) in there;
>
> 1. ECM/Fortress should stay with Apache.
> 2. ECM/Fortress users should not be abondoned.
>
> I also get the feeling that there are many proponents of Fortress to 'live
> on', and if that true, we not do that...
>
> I think I am more and more in favour of;
>
> 1. Apache Avalon = Component contracts.
> 2. Place Merlin & Fortress into subprojects of Avalon.
-1
One platform, one specification, one container. Avalon made the two
state decision years ago with Phoenix and ECM - and that's not role
model for the future. What is clearly desired is:
* transition solutions
* migration tools
> 3. The Fortress gang rally a community around it to show that it is really
> live and well, and not just "hot air".
Then said community should fork.
Cheers, Stephen.
>
> WDYT?
>
> Niclas
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org