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/07/28 15:48:28 UTC
[VOTE] Lifecycle Extension Tags
It appears that both Stephen and I have opposing views on this particular point,
so the best solution is to get some consensus. We will go with the solution
that the Avalon team chooses.
The question comes from the @avalon.extension and @avalon.stage tags. They were
introduced to allow Merlin to use meta-info to declare a dependency on the
lifecycle extensions. Below is the proposal and objection:
Proposal:
Move these two tags to a neutral namespace like @lifecycle.* so that their use
can be fine tuned without affecting the rest of the Avalon Meta Tags proposal.
I beleive that putting them in a separate namespace helps enforce the idea that
they are not essential to pure Avalon components, and their use should be done
by people who understand the implication.
Objection:
They may not be core, but it is essential that a container recognize that the
extension is required. Merlin has been using them for a while and Merlin users
have not had a problem with them. (I am probably missing something here, but
you can find the full set of objections in the "[Proposal] AMTAGS pt. 3 (Stage
and Extension)" thread.)
Please be certain that whatever namespace we choose, it does not mean that we
have to come up with a "container extension" plan at this time. We can cross
that bridge when we come to it.
[VOTE]
Place the extension tags (.extension and .stage) in the @lifecycle namespace.
[ ] +1 I like the proposal
[ ] -1 I am fine with them in the @avalon namespace
[ ] 0 I don't really care (I'll go with the majority)
+1 from 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: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> I can only conclude that through your call for vote
> that you do not understand the problem or implication of the
> solution your are proposing.
What are the implications of having the stuff under "lifecycle"
instead of under "avalon"? There are no functional implications:
You still have the functionality there but under another name.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> Calling for a vote is about the least productive thing you could do
>> to get consensus. If you want consensus then address the real issue.
>> That means addressing the real problems of a container understanding
>> the full implication of component deployment.
>>
>> I am not even going to bother voting on this vote. This is simply a
>> mistake. I will consider it totally invalid and I certainly will not
>> feel bound by any outcome. Until we recognize and address and
>> solution to the problem of full and complete description of a
>> components requirements to a container – we are simply not addressing
>> the real problem. Either abstract the problem or solve the problem.
>> Calling a vote is a waste of everyone’s time.
>
>
> Stephen, it is this anti cooperative spirit that is causing most of the
> problems.
No Berin!
Your idea of forcing consensus through a vote without addressing
the real issues is causing this problem. I cannot support your
proposal because does not address a solution the problem.
I can only conclude that through your call for vote that you do not
understand the problem or implication of the solution your are
proposing. How can I endorse an action if I fundamentally disagree
with the logic behind the action?
> We can continue the discussion of you refusing to cooperate
> on the PMC list.
You could continue this discussion here. The subject is the
relevance of your proposal to the problem and the implications of
your proposal to the problem. You can try to shift this to a
Steve versus Avalon PMC adventure if you like. But its a waste of
time. If you have something to say - say it here because its
something that concerns everyone here.
> For now, the vote stands, and any publicly released
> Avalon technology *will* be bound by its outcome. I advise
> you to vote.
I regret to inform you that your advice on this occasion will
not be respected. If you don't like that then I would respectfully
suggest that you go back to the real problem, understand the issue,
understand my objection (which was incorrectly presented in your
email), and work towards something that would address the concerns
and issues that I have raised.
> If you refuse to abide by the decisions of the Avalon team,
> then I highly recommend you reevaluate that position.
I can abide by decisions when they are decisions that make sense.
This scenario does not make sense because you are proposing
something that will ultimately be detrimental to the Avalon
community. I know you don't see this nor understand the
implications - but you could at least spend the time and get to the
point where you do understand and appreciate these points.
I am saying that this vote is premature. The issues and solutions
are not resolved. Your actions will result in division. Is that
what you really want?
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Calling for a vote is about the least productive thing you could do to
> get consensus. If you want consensus then address the real issue. That
> means addressing the real problems of a container understanding the full
> implication of component deployment.
>
> I am not even going to bother voting on this vote. This is simply a
> mistake. I will consider it totally invalid and I certainly will not
> feel bound by any outcome. Until we recognize and address and solution
> to the problem of full and complete description of a components
> requirements to a container – we are simply not addressing the real
> problem. Either abstract the problem or solve the problem. Calling a
> vote is a waste of everyone’s time.
Stephen, it is this anti cooperative spirit that is causing most of the
problems. We can continue the discussion of you refusing to cooperate
on the PMC list. For now, the vote stands, and any publicly released
Avalon technology *will* be bound by its outcome. I advise you to vote.
If you refuse to abide by the decisions of the Avalon team, then I highly
recommend you reevaluate that position.
--
"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: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Calling for a vote is about the least productive thing you could do to
> get consensus.
I agree. Calling a vote is smart though when there you come to the
understanding that it might be best to agree to disagree. That seems to
be the case. Getting *a* decision rather than *the best* decision is
often a good idea in order to move forward. We don't need consensus on
everything. Especially on hairsplitting issues like this.
> I am not even going to bother voting on this vote. This is simply a
> mistake. I will consider it totally invalid and I certainly will not
> feel bound by any outcome.
oh, get a grip already! If you don't feel bound by the outcome of votes,
you don't belong at apache. Stop the confrontational stuff please.
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
> Social stuff
> ------------
>
>> The social implications is:
>>
>> * "it's not I the avalon namespace I don't have to worry about it"
>
>
> you cannot battle negative social implications with code or
> specifications. That's plain dumb.
Another way of looking at it is that we can ignore the implications of
our actions. Social implications play an important role in the
development of systems, their usage, adoption, and value they deliver.
To ignore that dimension is to ignore the damage that this vote is
doing. Instead of dealing with the pain of reaching consensus - a vote
is forced upon us. It is the cheap and easy option - the easy way out.
>
>
> Here's the important social implication: the fact that you think it
> appropriate to state "I will ignore this group decision made by the
> accepted decision-making process we have put in place as a group
> because I may disagree with the result" over something as silly as a
> naming convention, dragging us all back into long e-mails full of
> debate about bike sheds has hereby led to the end of my involvement in
> talks about and work on implementing a common avalon metadata system.
> This is not how I want to develop stuff.
There are a couple of misconceptions you have.
Firstly you categorization of this issues as "something as silly as a
naming convention" is completely missing the point. Its not about "do we
name it this or do we name it that" - its about the thing we name and
having at least some degree of integrity about that thing. I.e. assume
for a moment that this is all about packaging something under the
namespace of "component". E.g. @component.depedency, @component.entry,
@component.stage. The model named by a namespace. The namespace
presents a specific solution space. To propose @component under the
guise of something to foster reliable component deployment would be out
and out misleading because it is technically incomplete. If we refocus
this scenario by substituting @component with @avalon, we compound the
error.
> Have fun writing it on your own.
Happily, I'm not on my own.
>
> Contractual stuff
> -----------------
>
>> This is complicated by a contractual limitations:
>>
>> * "the avalon namespace model does not support model extension"
>
>
> avalon does not need a formal namespace model with extension
> capability. Look at how much trouble the XDoclet people have managing
> their dozens of tags (namely: none). We're certainly not likely to
> have more than them.
Leo - again your missing the point. The objective is a framework
whereby we can declare meta data once (irrespective of the containment
environment) and from that achieve reliable component deployment.
Nobody has presented anything of substance to discount the objections I
raised concerning the implications of Berin's vote. Give me a solution
that maintains integrity of the objective! Don't give me arguments that
have nothing to do with the subject we are discussing.
>
> Sigh.
>
> You know how much work it is to replace @lifecycle with
> @avalon.lifecycle? It goes a little something like
>
> s/@lifecycle/@avalon\.lifecycle/
>
> in perl. Which is something just about every reasonable editor on this
> planet can do with a few keystrokes or a few mouseclicks. In fact, I
> can do that ASF-wide to all sourcecode in less time than it takes you
> to reply to this e-mail.
I'm assuming this said with a somewhat tongue-in-cheek posture. Just in
case anyone were to take this comment seriously, I should put out that
this has nothing to do with substitution of text strings. It has
everything to do with responsibility.
>
> Some pointless bickering
> ------------------------
My turn to sigh?
:-)
>
> just for fun, I'll point out some things that are plain wrong:
OK. Lets find out how stupid I really am.
>
>
>> if something is not inside Avalon namespace - well - it just does not
>> exist in terms of something standard and recognized.
>
>
> wrong. java.lang for example is standard and recognized. So is log4j.
> Standards don't need a namespace.
Your misunderstanding my comment. Perhaps I did not write it clearly so
I'll have a go a re-stating this more clearly. Firstly, I am discussing
these things with an Avalon context - I am not discussing global
concerns, java concerns, or Apache concerns. I think it is reasonable
that anyone reading my comments on this subject would have equated my
concerns with what "Avalon" establishes as a standard. Clearly you
appear to have been confused on this point and as such, I can only offer
my apologies together with a promise to be a touch more verbose in the
future.
>
>> The @avalon.stage tag does not dictate a mechanisms to a container
>
>
> the way you're putting it it does: you are stating that all containers
> must have a mechanism in place to parse some kind of data about
> lifecycle extensions and then kick out a component.
Let me clarify. In order for Avalon to provide a common and consistent
model for the declaration of container responsibilities towards a
container we have developed a set of tags. These tags can be used to
generate an information model - common referred to as a meta-info model
. Today we have three containers. Each container employs a different
meta-info model. In your absence a lot of work has gone into putting in
place a complete a meta-info model and a set of supporting tags that
will ensure a migration path from the current approach towards a unified
approach. The unified approach is what will enable any container to
verify, prior to deployment, if a component is supportable or not.
There is a proposal (and unfortunately a vote) that if successful will
fragment this community and initiate divergence. One must ask why are
we not uniting and embracing everyone's needs (i.e. Phoenix, Fortress
and Merlin). One must question why a solution proposed that does not
even meet the objective.
>
>> If we retract the @avalon.stage (and the corresponding
>> @avalon.extension) tags from the Avalon namespace, we are stating
>> that the notions of deployment phase (versus classic runtime phase)
>> notions are concepts that can be ignored.
>
>
> wrong. We are seperating concerns.
I agree that *we* are separate concerns, however, I was not referring to
you or I. I was in fact referring to the semi-royal we a.k.a. Avalon
Community. If by chance you were not referring to you and I, then I
would suggest that your taking a very technical view and in doing so,
you risk ignoring the big picture and missing the basic objective of the
@avalon process.
>
>> If you remove @avalon.stage from core Avalon - then any component
>> that leverages deployment phase dependencies (i.e. components that
>> fulfill stage execution) will no longer be a valid Avalon components.
>
>
> wrong. "valid avalon component" is defined by providing a no argument
> constructor, a work interface and following IoC. That won't change.
Should I assume that Avalon is already dead and buried? Avalon was (at
least in my simplistic view of the world) an evolving environment - if I
remember correctly, Marcus Crafter announced the availability of
lifecycle extensions under Fortress back in September last year. Not
long afterwards the same concept (based on the original work from
Marcus) was introduced to the Merlin platform. It took something like
nine months to release a package with less than half-a-dozen classes,
but that release signaled the establishment of a formal Avalon
abstraction. The notion that a component can be deployed with a
variable set of lifecycle stages. That abstraction (as you are well
aware) has provided highly valuable in a number of areas and application
scenarios. It is that same abstraction that that introduced that the
notion of a stage as a computational dependency exposed by a component
towards a container.
While I'm not into lecturing on history - I do think that we should
recognize the past and be responsible for what we have released and the
semantics they imply.
>
>> The implication of this is that a container could be asked to deploy
>> such a component, and unless the component does its own error
>> checking to validate that in fact its lifecycle stages have been
>> executed, we enter the gray zone of unpredictable components. This
>> gray zone is components executing on the assumption that they have
>> been fully deployed. This potential false assumption can lead to
>> failures in security, inconsistency in service delivery behavior, and
>> potential damage by a component simply because it is acting under
>> incorrect assumptions.
>
>
> indeed. Someone who deploys an application into a container and uses
> advanced features better check they're supported. Just like you should
> deploy a component that uses javax.logging on jdk 1.3.
We are not talking about advanced feature - we are talking about
released features. As to your point "[they] better check they're
supported" - that something central to this entire discussion. If your
deploying a component using JNLP (as an example), and you don't have a
developer babysitting the process - what happens with the scenario that
Berin is proposing is that the solution (a) runs because your lucky, (b)
fails with a stack trace because sort of lucky, (c) does something it
was not intended to do because we (Avalon) decided to ignore the
contracts that we (Avalon) established and released.
Do you feel comfortable endorcing this position?
>
>
>> Containers outside (and quite probably inside) Avalon will ignore
>> @lifecycle because its not part of a "core" @avalon contract.
>
>
> containers inside and outside avalon ignore some parts of
> avalon-framework that have been in place since version 4.0. I would
> argue that ComponentSelector is at the very core of the core of avalon.
We are not defining an interface - we are defining the information that
a component communicates to a container concerning constraints it
imposes on its deployment and runtime life. These are very different
subjects.
>
>
>> One cannot simply retract this tag from the Avalon namespace without
>> providing a solution.
>
>
> wrong. No application I have ever written will suffer. No application
> deployed on released avalon code will suffer. No application to
> deployed on to-be-released avalon code will suffer more than a
> search-and-replace incovenience.
I would categorize your conclusion as a naive generalization. Avalon
will suffer significantly because we will have failed miserably at
delivering what we have been promising. We will have failed to back up
what we have released and we will be promoting an incomplete model of
what we are about. Avalon looses credibility. Avalon utility is
decreased. All of that is put at stake because one individual wants to
force a vote on a half-baked solution.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
Social stuff
------------
> The social implications is:
>
> * "it's not I the avalon namespace I don't have to worry about it"
you cannot battle negative social implications with code or
specifications. That's plain dumb.
Here's the important social implication: the fact that you think it
appropriate to state "I will ignore this group decision made by the
accepted decision-making process we have put in place as a group because
I may disagree with the result" over something as silly as a naming
convention, dragging us all back into long e-mails full of debate about
bike sheds has hereby led to the end of my involvement in talks about
and work on implementing a common avalon metadata system. This is not
how I want to develop stuff.
Have fun writing it on your own.
Contractual stuff
-----------------
> This is complicated by a contractual limitations:
>
> * "the avalon namespace model does not support model extension"
avalon does not need a formal namespace model with extension capability.
Look at how much trouble the XDoclet people have managing their dozens
of tags (namely: none). We're certainly not likely to have more than them.
Sigh.
You know how much work it is to replace @lifecycle with
@avalon.lifecycle? It goes a little something like
s/@lifecycle/@avalon\.lifecycle/
in perl. Which is something just about every reasonable editor on this
planet can do with a few keystrokes or a few mouseclicks. In fact, I can
do that ASF-wide to all sourcecode in less time than it takes you to
reply to this e-mail.
Some pointless bickering
------------------------
just for fun, I'll point out some things that are plain wrong:
> if something is not inside Avalon namespace - well - it just does not exist
> in terms of something standard and recognized.
wrong. java.lang for example is standard and recognized. So is log4j.
Standards don't need a namespace.
> The @avalon.stage tag does not dictate a mechanisms to a container
the way you're putting it it does: you are stating that all containers
must have a mechanism in place to parse some kind of data about
lifecycle extensions and then kick out a component.
> If we retract the @avalon.stage (and the corresponding
> @avalon.extension) tags from the Avalon namespace, we are stating that
> the notions of deployment phase (versus classic runtime phase) notions
> are concepts that can be ignored.
wrong. We are seperating concerns.
> If you remove
> @avalon.stage from core Avalon - then any component that leverages
> deployment phase dependencies (i.e. components that fulfill stage
> execution) will no longer be a valid Avalon components.
wrong. "valid avalon component" is defined by providing a no argument
constructor, a work interface and following IoC. That won't change.
> The implication
> of this is that a container could be asked to deploy such a component,
> and unless the component does its own error checking to validate that in
> fact its lifecycle stages have been executed, we enter the gray zone of
> unpredictable components. This gray zone is components executing on the
> assumption that they have been fully deployed. This potential false
> assumption can lead to failures in security, inconsistency in service
> delivery behavior, and potential damage by a component simply because it
> is acting under incorrect assumptions.
indeed. Someone who deploys an application into a container and uses
advanced features better check they're supported. Just like you should
deploy a component that uses javax.logging on jdk 1.3.
> Containers outside (and quite probably inside) Avalon will
> ignore @lifecycle because its not part of a "core" @avalon contract.
containers inside and outside avalon ignore some parts of
avalon-framework that have been in place since version 4.0. I would
argue that ComponentSelector is at the very core of the core of avalon.
> One cannot
> simply retract this tag from the Avalon namespace without providing a
> solution.
wrong. No application I have ever written will suffer. No application
deployed on released avalon code will suffer. No application to deployed
on to-be-released avalon code will suffer more than a search-and-replace
incovenience.
> * moving out of core means death to the idea of reliable deployment
> across containers
FUD.
> * an absence of an extension mechanism in @avalon core makes the
> proposal technically invalid
wrong.
> Now is not the time for another divergent split in Avalon
very right. Maybe you should dim your tone in order to avoid such
divergence.
> containers that recognize the full criteria and containers that claim
> Avalon compliance but ignore the reality of what developers are doing
> using release Avalon product).
FUD.
g'night!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Royal wrote:
>
>> On Monday, July 28, 2003, at 11:04 AM, Stephen McConnell wrote:
>>
>>> Do they understand what they are voting for? My guess is that they
>>> will assume the very simplistic line from Berin that this is about a
>>> namespace. They will not take into account the ramifications. They
>>> probably will not appreciate that this is a divisive point in terms
>>> of the avalon component model. They will probably not appreciate that
>>> it introduces a separation at the core of Avalon and from that
>>> separation there will eternally be those that do and those that don't.
>>
>>
>>
>> Can you succinctly list the ramifications?
>
>
>
> I'll try!
>
> There is a social implication complicated by a contractual limitation.
>
> The social implications is:
>
> * "it's not I the avalon namespace I don't have to worry about it"
>
> This is complicated by a contractual limitations:
>
> * "the avalon namespace model does not support model extension"
>
> I want to start things off with the social implication, however, let me
> just note that under the @avalon namespace we do not have any notion or
> mechanism to declare expansion of that namespace. This means that if
> something is not inside Avalon namespace - well - it just does not exist
> in terms of something standard and recognized. But I'll come back to
> this in more detail.
Point 1:
* The meta tags are client contracts. If the client doesn't want to use
extensions, they don't have to worry about it.
* At the current time, all Avalon containers will be required to recognize
it, no matter what namespace it is in.
Point 2:
* The avalon namespace model shouldn't *have* to support model extension.
* I personally would prefer model extension to be done in dedicated
namespaces.
> On social implications:
> -----------------------
>
> The @avalon.stage tag declares that a component has a deployment phase
> dependency relative to a container. This means that a container should
> either fulfill that deployment phase dependency or toss out the
> component. The @avalon.stage tag does not dictate a mechanisms to a
> container - it simply declares a deployment criteria.
Not in all cases. There are several examples that I can think of where the
extension is more an assembly concern than a component definition concern.
There are some extensions that are absolutely a component definition concern.
More below.
> If we retract the @avalon.stage (and the corresponding
> @avalon.extension) tags from the Avalon namespace, we are stating that
> the notions of deployment phase (versus classic runtime phase) notions
> are concepts that can be ignored. There is dilemma here, because the
> vote in question does not address the implications. If you remove
> @avalon.stage from core Avalon - then any component that leverages
> deployment phase dependencies (i.e. components that fulfill stage
> execution) will no longer be a valid Avalon components. The implication
> of this is that a container could be asked to deploy such a component,
> and unless the component does its own error checking to validate that in
> fact its lifecycle stages have been executed, we enter the gray zone of
> unpredictable components. This gray zone is components executing on the
> assumption that they have been fully deployed. This potential false
> assumption can lead to failures in security, inconsistency in service
> delivery behavior, and potential damage by a component simply because it
> is acting under incorrect assumptions.
I disagree. All that needs to be done is the user needs to be made aware
that they must ensure that their container supports the @lifecycle extension.
Its that simple. So far, two out of three will (i.e. Merlin and Fortress will
but Phoenix won't unless someone wants to incorporate it).
>
> The counter argument to this case is that the notion of a lifecycle
> dependency can be moved to @lifecycle. Socially this will ignored. As
> soon as we start down the track of multiple compliance levels we will
> have lost. Containers outside (and quite probably inside) Avalon will
> ignore @lifecycle because its not part of a "core" @avalon contract.
> Those containers will not validate components in the same way. Those
> components and will be running blind.
You don't know until it happens. If it is ignored, then it is simply
additional cruft that would have been ignored in the avalon namespace
anyway.
> If we don't do a complete description of container responsibility - they
> we must do nothing less that revert to container specific solutions
> @phoenix, @fortress and @merlin.
I dislike the container specific namespaces. I prefer function specific
namespaces. HOwever this is a topic for future discussion.
> On contractual limitations
> --------------------------
>
> As mentioned about - @avalon.stage is not about excalibur-lifecycle.
> Its about the declaration of a deployment phase dependency. One cannot
> simply retract this tag from the Avalon namespace without providing a
> solution. The problem concerns many components that use extensions and
> their need/requirement to declare that criteria to a container in a
> consistent fashion. Under an @lifecycle solution - you MUST have a way
> of declaring within the @avalon namespace, that an @lifecycle is to be
> including in the component deployment criteria. This is non-trivial.
Bear in mind that not all extensions are necessarily described in the
component definition. In fact, adding aspects to the components to
extend their function beyond what they were originally intended will
be something that cannot be expressed in an @avalon.stage. In fact
it would be pointless as we should not have to recompile a JAR just to
add support for an assembly/deployment concern.
As long as the container claims that it is "lifecycle" extension compliant,
the component can expect to work without problems. There are several ways
of accomplishing this, but for the short term it will be an informal contract.
> In my own experience the lifecycle stage model has served to address
> some key limitations of the Avalon component contract. This is based on
> experience with stage extensions that use excalibur-lifecycle and others
> that are totally independent of excalibur-lifecycle. These advantages
> must not be lost. To assure this we have a choice .. we either
> recognize the deployment phase dependencies can exist, or we halt this
> process and go back to the drawing board and come up with a revised
> specification that addresses component criteria at a more abstract
> level. I believe that what we have today is complete and consistent. I
> believe that we will come up with a small but interesting number of
> different approaches to stage management (including inceptors and event
> based handlers). I do not believe that this will be contradictory to
> the @avalon.stage tag. Instead, they will represent different, smatter
> better solutions to handling the criteria expressed by an @avalon.stage.
As I recently discovered in talking to Stefano about adaptive caching, our
own experience can be very misleading. Just because we see something one
way does not mean that it holds true in all situations. I believe the all
or nothing argument does not hold. Think big but start small. To be honest,
the stage and extension tags are the least understood of all of the tags
proposed. At least to me it is clear what everything else does, and how it
applies to pure Avalon components. The stage and extension tags are not so
clear, but I am willing to learn. Forcing all users to be aware of them
increases the learning curve for Avalon. I am against that. By placing them
in a separate namespace, we give the user a chance to grasp things in chunks.
It is a very useful tool.
> I also thing that as we move forward, with experience based largely from
> work with extensions, we will figure out what we need in terms of tags
> extension semantics (i.e. how to tell a parser to look beyond @avalon
> and what to do with the result). Those ideas will have ramifications on
> tag definitions, meta info, meta data, meta models, and containers. In
> the meantime, a complete solution (i.e. including the deployment phase
> dependencies) will provide more than most people will need and
> everything that Avalon needs.
All these can be done -- even when the extension tags are in a separate
namespace. So, I believe your arguments are not as strong as you believe.
>
> Summary:
> --------
>
> * moving out of core means death to the idea of reliable deployment
> across containers
I don't see that at all. Moving out of core means we need to learn how to
deal with non-core namespaces in a predictable and scalable manner. Since
there is only one additional proposed standard namespace, we can start with
the simplest thing: documentation. Later we can address more exciting concepts.
> * an absence of an extension mechanism in @avalon core makes the
> proposal technically invalid
Again, I don't see this at all. How can it be technically invalid? We are
talking about extensions. Extensions are not core to Avalon, but they should
be recognized. We can move from just one namespace to more than one, and
be able to work with them all.
> Now is not the time to throw together an extension mechanisms - the
> problem is non-trivial and a solution need to grow from common needs,
> interests and experience. Now is not the time for another divergent
> split in Avalon - containers that see and contains that don't (i.e.
> containers that recognize the full criteria and containers that claim
> Avalon compliance but ignore the reality of what developers are doing
> using release Avalon product).
How is this different from what we have now? Essentially what will happen
is that we will have containers that do, and do so consistently (unlike now),
and a container that doesn't. However that container will be able to recognize
the components it can't handle.
Is there a problem with that?
Also, do not confuse the proposal of namespace with an immediate proposal
for container extension mechanisms. The problem is non-trivial, and your
arguments give more and more credence to allowing us to grow the solution
in a namespace outside of the core Avalon one.
So far the only arguments I have seen don't yeild the vote invalid.
>
> Cheers, Steve.
>
--
"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: lifecycle extension checklist
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
> <snip/>
>
>>
>> Berin:
>>
>> There are no technical issues in your email.
>
>
> Correct, they are management issues. (Management in the sense of code
> management, not in the sense of personell management).
I asked for technical issues - and you provided none.
That's what I wanted to confirm.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: lifecycle extension checklist
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
<snip/>
>
> Berin:
>
> There are no technical issues in your email.
Correct, they are management issues. (Management in the sense of code
management, not in the sense of personell management).
> Instead what you have said is that you are:
>
> (a) opposed to introducing something into the Avalon namespace that you
> don't understand
Correction: that all the committers don't understand (which happens to include
me).
> (b) feel that a broader base of developer knowledge is needed
On this ONE issue.
> (c) that more user experience is needed
On this ONE issue.
> All of these points I can understand. However, your vote does not say
> this - in fact it calls up people to make a decision on a subject that
> is directly linked to a question concerning extension management that
> you yourself do not feel competent to address at this time.
It is a question of putting it in an alternative namespace until the time
we are on the same page. I.e. managing the change to the API.
> I think that some time and experience with a released Merlin will go a
> long way towards addressing all three of the points you have raised. It
> would ensure a broader knowledge base, greater experience, and as a
> consequence, future actions can be taken with full knowledge and
> responsibility as to the actions we propose, the votes that we take, and
> the implications of those decisions.
We are on the same page on 90% of the issues. Everything not related to
lifecycle extension is good to go.
I want to publish the 90%, with the hopes that we come to 100% over time.
Instead of removing the tags altogether, I proposed to put them into an
alternative namespace for the immediate release, with the possibility that
they (or something similar to them) will be incorporated later.
That is all I am asking us to agree to. We can't blindly be all or nothing.
--
"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: lifecycle extension checklist
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>> Extensions became intrinsic to the component deployment model when
>>>> we voted for the release of the excalibur-extension package (a vote
>>>> that received your +1). At that point we said to everyone out
>>>> there that there is a notion of lifecycle stage extensions in
>>>> Avalon. We documented in that release the support for that
>>>> abstraction in both Merlin and Fortress. There are simply no
>>>> issues to solve - this is simply a matter of getting back to a
>>>> process of collaboration.
>>>
>>>
>>>
>>>
>>> I don't buy that reasoning. Lifecycle extensions (as released) are
>>> a set of interfaces. Those interfaces work. Currently Fortress and
>>> Merlin have two different ways of addressing how to work with them.
>>> I don't think you have been listening to the points I have been
>>> raising either.
>>
>>
>>
>>
>> Could you please take a moment to detail any problems you see
>> concerning stage management. I have (on at least two occuations)
>> offered to assist you on this subjet and remain willing to help you
>> out on this. Perhaps we can nail down you technical concerns once
>> and for all.
>
>
>
> Here they are (mostly related to growing the API):
>
> * First, when growing an API we need to get everyone on board so that
> they
> understand what that API is doing.
* confirming that this process is premature
>
> * Second, we need a way for users to be able to play with the new
> functionality
> without being lulled into thinking everyone is on board with it.
> While the
> Avalon namespace does imply that, IMO is should only be used for
> pure Avalon
> components.
* confirming that we should release outside of the core Avalon namespace
* confirming that more time is needed for users to experiment and
provide feedback
>
> * Third, I believe that we should embrace a multi-namespace world (we
> will have
> to for management extensions). This could lay the foundation for
> container
> extensions which in turn would encourage users to embrace tags not
> specified
> in the Avalon namespace. Esp. when it doesn't matter what container
> they
> use, they can still keep the same functionality.
We agree on this - but I suspect we disagree on the details. I
mentioned a couple of time before that I think this subject should be
addressed based on experience in dealing with real problems. The
subject will arise following a release of Merlin as we move forward with
a comprehensive JMX solution. Throughout that process I am confident
that we will gain a lot more insight into what belongs where.
>
> * Fourth, in my mind the stage/extension stuff is a risk due to the
> general lack
> of knowledge with it. While I do want to understand it, that takes
> time, and
> I would rather have a release of Meta-info now so we can start
> integrating the
> libraries.
* confirming that this is largely a question of insufficient understanding
* confirming that the current vote can be held up as representing a
representative opinion
* confirming that this process is premature
>
> * Lastly, we need to manage user expectation. I have a project that
> will be
> using the lifecycle extensions, so it is of great interest to me.
> It will
> also help me to understand what I do and don't like about the way it
> is now.
> Until such a time, I really don't feel comfortable signing off on
> them being
> in the Avalon namespace.
* confirming that your vote is really about your level of understanding
* confirming that this process is premature
Berin:
There are no technical issues in your email.
Instead what you have said is that you are:
(a) opposed to introducing something into the Avalon namespace that you
don't understand
(b) feel that a broader base of developer knowledge is needed
(c) that more user experience is needed
All of these points I can understand. However, your vote does not say
this - in fact it calls up people to make a decision on a subject that
is directly linked to a question concerning extension management that
you yourself do not feel competent to address at this time.
I think that some time and experience with a released Merlin will go a
long way towards addressing all three of the points you have raised. It
would ensure a broader knowledge base, greater experience, and as a
consequence, future actions can be taken with full knowledge and
responsibility as to the actions we propose, the votes that we take, and
the implications of those decisions.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: lifecycle extension checklist
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>> Extensions became intrinsic to the component deployment model when we
>>> voted for the release of the excalibur-extension package (a vote that
>>> received your +1). At that point we said to everyone out there that
>>> there is a notion of lifecycle stage extensions in Avalon. We
>>> documented in that release the support for that abstraction in both
>>> Merlin and Fortress. There are simply no issues to solve - this is
>>> simply a matter of getting back to a process of collaboration.
>>
>>
>>
>> I don't buy that reasoning. Lifecycle extensions (as released) are a
>> set of interfaces. Those interfaces work. Currently Fortress and
>> Merlin have two different ways of addressing how to work with them. I
>> don't think you have been listening to the points I have been raising
>> either.
>
>
>
> Could you please take a moment to detail any problems you see concerning
> stage management. I have (on at least two occuations) offered to assist
> you on this subjet and remain willing to help you out on this. Perhaps
> we can nail down you technical concerns once and for all.
Here they are (mostly related to growing the API):
* First, when growing an API we need to get everyone on board so that they
understand what that API is doing.
* Second, we need a way for users to be able to play with the new functionality
without being lulled into thinking everyone is on board with it. While the
Avalon namespace does imply that, IMO is should only be used for pure Avalon
components.
* Third, I believe that we should embrace a multi-namespace world (we will have
to for management extensions). This could lay the foundation for container
extensions which in turn would encourage users to embrace tags not specified
in the Avalon namespace. Esp. when it doesn't matter what container they
use, they can still keep the same functionality.
* Fourth, in my mind the stage/extension stuff is a risk due to the general lack
of knowledge with it. While I do want to understand it, that takes time, and
I would rather have a release of Meta-info now so we can start integrating the
libraries.
* Lastly, we need to manage user expectation. I have a project that will be
using the lifecycle extensions, so it is of great interest to me. It will
also help me to understand what I do and don't like about the way it is now.
Until such a time, I really don't feel comfortable signing off on them being
in the Avalon namespace.
Please see my response to the other email so that you can see a few further
arguments.
Please understand that I am not ignoring your oppinions at all, but I am trying
to get you to recognize the value in my oppinions.
--
"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
lifecycle extension checklist
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Extensions became intrinsic to the component deployment model when we
>> voted for the release of the excalibur-extension package (a vote that
>> received your +1). At that point we said to everyone out there that
>> there is a notion of lifecycle stage extensions in Avalon. We
>> documented in that release the support for that abstraction in both
>> Merlin and Fortress. There are simply no issues to solve - this is
>> simply a matter of getting back to a process of collaboration.
>
>
> I don't buy that reasoning. Lifecycle extensions (as released) are a
> set of interfaces. Those interfaces work. Currently Fortress and
> Merlin have two different ways of addressing how to work with them. I
> don't think you have been listening to the points I have been raising
> either.
Could you please take a moment to detail any problems you see concerning
stage management. I have (on at least two occuations) offered to assist
you on this subjet and remain willing to help you out on this. Perhaps
we can nail down you technical concerns once and for all.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> I am not trying to attack you. I am protecting the integrity of the
> Merlin product and the interests of Merlin users. I am trying to hold
> together something that is complete. I am trying to prevent your
> introduction of fractures to an object model arising out of you lack of
> understanding. Finally, I am questioning the validity of the process you
> are using to coerce this community into a decision that would conflict
> with my rights as an Apache committer.
>
The Merlin product and Merlin users need to be Avalon users. It should not
need protecting. Let the rest of the community put in their voices. I have
said enough already.
--
"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: releasing merlin
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>>
>>> I think I eloquently stated my position, and I believe my goal is
>>> compatible with yours.
>>
>>
>> I agree completely. You elequantly confirmed that you don't
>> understand the problem. You eloquently described your *fear* of the
>> pollution of the avalon namespace. You eloquently described you
>> *uncertainty* as to technical applicability, and you eloquently
>> described your *doubt* with respect to utility. This is common
>> referred to *FUD*.
>
>
> Is this how you define "working with others"? I put forth my concerns in
> as simple and unconfrontational method as I could. I would appreciate it
> if you would return the favor. I would also appreciate it if you would
> meet halfway on this which you seem to be unable to do, and cannot
> express
> why.
Berin - I asked a simple question addressing the technical issues that
you had. You replied with an that confirmed that in fact you have no
technical issues. Instead you presented the basis of your agreement for
the modification to avalon-meta package on the grounds of fears,
uncertainties and doubts. I would appreciate it if you could go back to
the technical issues - i.e. actually raise a technical issue support you
position. That at least would provide grounds for some sort of
collaboration.
I have objected to you proposal, siting the technical inconsitency you
creating between the object model and the tag model. I have also stated
that this has import ramifications. I consider my rejection of your
attempt at coersion equivelent to a veto against your attempts to change
the codebase in a manner that I consider techincally detrimental.
>
>> The only person who is making a Merlin release a big deal is yourself.
>
>
> Pete Royal just negated your assertion.
I would not say that.
Peter is not making a big deal of of the the release subject.
He expressed a concern - a concern that is completely valid.
http://marc.theaimsgroup.com/?l=avalon-dev&m=105949900927447&w=2
I have replied to Pete message including some thoughts on the subject.
http://marc.theaimsgroup.com/?l=avalon-dev&m=105949993028565&w=2
>
>> You commenced the process by stating that you would block a release
>> unless it fulfilled you preconditions. This statement was grossly
>> misleading simply because you do not have that authority. It is this
>> majority of committers in this community of which you are only one
>> that carry the decision on a release. Secondly, you have argued your
>> FUD agenda using every possible avenue including threats of my
>> dismissal from Avalon. We are not 90% on anything. I moved what is a
>> complete, working and stable sub-system out of Merlin and into
>> sandbox to facilitate collaboration on establishing a common
>> platform. A lot of time has been spent addressing many aspects
>> bringing in in-line. During that process you have launched what can
>> only be described as an attack against me on the subject of
>> extensions. And yet your rationalization comes down to nothing more
>> than FUD arrising from you self proclaimed lack of knowledge. Once
>> you actually take the time to address the technical issues - there
>> will be the potential to reach 100%. In the meantime you have a lot
>> of credibility that you need to recover.
>
>
> Did I EVER threaten to dismiss you from Avalon? Please point out the
> exact message, complete with a link. What you have just done is defined
> as either slander or libel depending on how you interpret emails (written
> or spoken word). It is a serious allegation, and without PROOF which is
> your burden, I demand and appology.
Lets take into consideration the following the following context that
you established yesterday.
Berin Loritsch wrote to PMC:
> Stephen, it is this anti cooperative spirit that is causing most
> of the
> problems. We can continue the discussion of you refusing to cooperate
> on the PMC list. For now, the vote stands, and any publicly released
> Avalon technology *will* be bound by its outcome. I advise you to
> vote.
>
> If you refuse to abide by the decisions of the Avalon team, then I
> highly
> recommend you reevaluate that position.
In a following email on the same day, you clarified your position.
Berin Loritsch wrote to PMC:
> This will hopefully be my last hard-line message, but I want it to
> be very
> clear that the tail will not wag the dog. Either learn to work
> with everyone
> else, and RESPECT THEIR DECISIONS, or leave.
What exactly should I conclude from this. You are telling me that I must
accept your attempt to coerce a decision supporting your idea of a what
a product should be when you have not contributed to that product
(beyond the addition of some test cases). You require that I accept the
outcome of that decision, even though the process is for decision making
is questionable and your own knowledge on the subject (you yourself
said) is insufficient. Irrespective of this, you present me with an
ultimatum - either I respect the outcome or I leave.
My interpretation of these remarks are that if I do not accept your
attempts at coercion (as opposed to following the Jakarta guidelines and
respecting the rights of contributors and policy concerning product
releases), then I presumably will be forced to leave. If have
misunderstood the implications and ultimatums that you have put to me,
then I humbly apologize.
In the meantime, I will seeking formal clarification of my rights as a
Apache committer to protect by veto changes to a product which are in my
opinion detrimental.
>
> I also expect you to come to grips with reality. Take a break if you
> have to.
>
>
>>> All a user needs to know is that if they implement the set of Avalon
>>> tags, their
>>> component will work accross all the containers.
>>
>>
>> Look - you said it here "All a user needs to know is that if they
>> implement the set of Avalon tags" and yet you want to fragment that
>> same namespace in such a way that users of will be obliged to use
>> Avalon tags plus Lifecycle tags. This is simply indicative of the
>> problem you are creating. Your statement reflects the impact of your
>> suggestion - disenfranchising a core subset of a object model simply
>> because you do not understand it.
>
>
> ?! Come again? I don't understand your logic here.
Please take a deep breath - go for a walk around the block - come back,
sit down and reead this carefully.
Your words:
-----------
* "All a user needs to know is that if they implement the set of Avalon
tags".
Logical interpritation:
-----------------------
* "All a user needs to to is implement @avalon"
Result:
-------
* notions of extension management will be sidelined
* attempts at reconsiling container differences will be made more difficult
* Merlin development and users will be prejudiced.
Rational:
---------
* fear of poluting the namespace
* uncertainty with respect to applicabilty
* doubt concerning utility
Solution:
---------
* don't attempt this now - there clearly isn't concensus
* take some time to understand the implications and the consequences
* revist the subject when we have greater user and developer experience
>
>> On one hand you imply support for the meta-info model as it is - with
>> full support for stage and extension declaration. On the other hand
>> you claim that these features are not needed, unsupported, and you
>> even go so far to imply that related products are not released. In
>> the context of all of this - I have zero confidence that you will not
>> continue this process of disruption and fragmentation into the tools
>> and the meta-info API.
>
>
> ?! Come again? I never suggested full support for the stage and extension
> declaration. I suggested support for it as a starting point--that is all.
> I also never said that the features were not needed, but I did correct
> your
> assertions.
What level of confidence can I have in you persistence on this subject?
Do you intend to remove or re-package and non-core, the stage and
extension defintions from the meta-info model type defintion? If yes -
then we can stop this discussion right here. If no - they you need to
explain why you are determined to break apart that model at the level of
tag declarations.
>
>>> Let's start with what we know. We can add in what we don't over time.
>>
>>
>> I suggest we move @avalon.meta -or @merlin - we maintain integrity of
>> the model. And you can sleep at night in the knowledge that your
>> Avalon namespace is clean. In the meantime some up who are much more
>> interested in putting together a complete and integral solution can
>> get on with the things we like doing.
>
>
> Why are you posturing? There is no need.
Please Berin - ths is not posturing. It is being pragmatic. You are
creating obsticle after obsticle. You are suggesting more preconditions
on a Merlin a release. You are now suggesting that a Merlin release
could occur after release Avalon-Meta, after incorporating that into
Fortress and incorporating this into Phoneix. This is completely
unrealistic, totally inconsitent with procedures, and completely
dissassociated with volontary open-souce collaboration.
>
>>> If we release the general Meta Info library with the set of Avalon
>>> tags we have
>>> agreed to up to this point,
>>
>>
>> We haven’t agreed anything of substance. We have an AMTAGS proposal
>> that does not meet requirements. We have you attempt to force a
>> decision from a position of ignorance that not only is biased against
>> the Merlin platform, but will itself lead to fragmentation and
>> confusion.
>
>
> The ONLY thing we have not agreed to is the extension/stage tags. That is
> it. Everything else is ok. So are you saying that unless extension/stage
> are included in the Avalon namespace that we haven't agreed to
> anything of
> substance?
>
> Why respond to kind words with harsh?
Has it occured to you as a result of you sustained assult on a product
that you don't understand, that I can only assume that after you get
what you want - you will not leave it at that. No. I can only assume
that you intend to continue the attack of the notion of extensions such
that you will continue until you isolate this notion to the Merlin
platform.
>
>>> then after we incorporate it into Fortress and
>>> Phoenix, I have no issues with a Merlin release.
>>
>>
>> More preconditions? Perhaps you could do everyone a favor and stop
>> this ridiculous process of preconditioning. While you’re at it -
>> could you pull back on the FUD and drop the threats. In the meantime
>> I'm going back to things that are fun and interesting. In particular,
>> I will continue to move Merlin forward with the support of the user
>> community as a complete and viable solution.
>
>
> How about one more. Unless you stop your own FUD marketing and threats
> no Merlin technology can be released in any way shape or form.
As a committer within Avalon - this is not your decision. As a member of
the PMC - this is not you decision. As chairman of the PMC you could set
a precedent and override the decision of a community.
> As long as you continue to attack those trying to work with you and
> refuse to work
> with anyone else (including me) I definitely cannot support its release.
> It's that simple.
I am not trying to attack you. I am protecting the integrity of the
Merlin product and the interests of Merlin users. I am trying to hold
together something that is complete. I am trying to prevent your
introduction of fractures to an object model arising out of you lack of
understanding. Finally, I am questioning the validity of the process you
are using to coerce this community into a decision that would conflict
with my rights as an Apache committer.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>>
>> I think I eloquently stated my position, and I believe my goal is
>> compatible with yours.
>
> I agree completely. You elequantly confirmed that you don't understand
> the problem. You eloquently described your *fear* of the pollution of
> the avalon namespace. You eloquently described you *uncertainty* as to
> technical applicability, and you eloquently described your *doubt* with
> respect to utility. This is common referred to *FUD*.
Is this how you define "working with others"? I put forth my concerns in
as simple and unconfrontational method as I could. I would appreciate it
if you would return the favor. I would also appreciate it if you would
meet halfway on this which you seem to be unable to do, and cannot express
why.
> The only person who is making a Merlin release a big deal is yourself.
Pete Royal just negated your assertion.
> You commenced the process by stating that you would block a release
> unless it fulfilled you preconditions. This statement was grossly
> misleading simply because you do not have that authority. It is this
> majority of committers in this community of which you are only one that
> carry the decision on a release. Secondly, you have argued your FUD
> agenda using every possible avenue including threats of my dismissal
> from Avalon. We are not 90% on anything. I moved what is a complete,
> working and stable sub-system out of Merlin and into sandbox to
> facilitate collaboration on establishing a common platform. A lot of
> time has been spent addressing many aspects bringing in in-line. During
> that process you have launched what can only be described as an attack
> against me on the subject of extensions. And yet your rationalization
> comes down to nothing more than FUD arrising from you self proclaimed
> lack of knowledge. Once you actually take the time to address the
> technical issues - there will be the potential to reach 100%. In the
> meantime you have a lot of credibility that you need to recover.
Did I EVER threaten to dismiss you from Avalon? Please point out the
exact message, complete with a link. What you have just done is defined
as either slander or libel depending on how you interpret emails (written
or spoken word). It is a serious allegation, and without PROOF which is
your burden, I demand and appology.
I also expect you to come to grips with reality. Take a break if you
have to.
>> All a user needs to know is that if they implement the set of Avalon
>> tags, their
>> component will work accross all the containers.
>
> Look - you said it here "All a user needs to know is that if they
> implement the set of Avalon tags" and yet you want to fragment that same
> namespace in such a way that users of will be obliged to use Avalon tags
> plus Lifecycle tags. This is simply indicative of the problem you are
> creating. Your statement reflects the impact of your suggestion -
> disenfranchising a core subset of a object model simply because you do
> not understand it.
?! Come again? I don't understand your logic here.
> On one hand you imply support for the meta-info model as it is - with
> full support for stage and extension declaration. On the other hand you
> claim that these features are not needed, unsupported, and you even go
> so far to imply that related products are not released. In the context
> of all of this - I have zero confidence that you will not continue this
> process of disruption and fragmentation into the tools and the meta-info
> API.
?! Come again? I never suggested full support for the stage and extension
declaration. I suggested support for it as a starting point--that is all.
I also never said that the features were not needed, but I did correct your
assertions.
>> Let's start with what we know. We can add in what we don't over time.
>
> I suggest we move @avalon.meta -or @merlin - we maintain integrity of
> the model. And you can sleep at night in the knowledge that your Avalon
> namespace is clean. In the meantime some up who are much more interested
> in putting together a complete and integral solution can get on with the
> things we like doing.
Why are you posturing? There is no need.
>> If we release the general Meta Info library with the set of Avalon
>> tags we have
>> agreed to up to this point,
>
> We haven’t agreed anything of substance. We have an AMTAGS proposal that
> does not meet requirements. We have you attempt to force a decision from
> a position of ignorance that not only is biased against the Merlin
> platform, but will itself lead to fragmentation and confusion.
The ONLY thing we have not agreed to is the extension/stage tags. That is
it. Everything else is ok. So are you saying that unless extension/stage
are included in the Avalon namespace that we haven't agreed to anything of
substance?
Why respond to kind words with harsh?
>> then after we incorporate it into Fortress and
>> Phoenix, I have no issues with a Merlin release.
>
> More preconditions? Perhaps you could do everyone a favor and stop this
> ridiculous process of preconditioning. While you’re at it - could you
> pull back on the FUD and drop the threats. In the meantime I'm going
> back to things that are fun and interesting. In particular, I will
> continue to move Merlin forward with the support of the user community
> as a complete and viable solution.
How about one more. Unless you stop your own FUD marketing and threats
no Merlin technology can be released in any way shape or form. As long
as you continue to attack those trying to work with you and refuse to work
with anyone else (including me) I definitely cannot support its release.
It's that simple.
--
"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: releasing merlin
Posted by Stephen McConnell <mc...@apache.org>.
Peter Royal wrote:
> On Tuesday, July 29, 2003, at 01:10 PM, Stephen McConnell wrote:
>
>> The only person who is making a Merlin release a big deal is yourself.
>
>
> I have reservations about a release, only because I thought the
> roadmap towards a single container coming out of this project that we
> all decided upon included incorporating merlin into a release of that
> container, but not a release of merlin by itself.
Please keep in mind that I don't want to do a release in the classic
Avalon tradition. What I want to see put in place is a frequent release
process with binary drops every months or two (i.e. much like the Maven
approach). This will provide ample opportunity for people to learn and
discover what is important and what isn't. It is absolutely clear to me
that we cannot move forward on a common solution without a greater
level of developer participation and with broader community knowledge of
the issues involved.
As that process moves forward we will gain broader participation and
understanding. And from that, there will perhaps be technologies of
relevance that the Merlin project can contribute to a common Avalon
solution. The difference is that those contributions will have been
more broadly validated and the their value towards Avalon will be more
relevant.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, July 29, 2003, at 01:10 PM, Stephen McConnell wrote:
> The only person who is making a Merlin release a big deal is yourself.
I have reservations about a release, only because I thought the roadmap
towards a single container coming out of this project that we all
decided upon included incorporating merlin into a release of that
container, but not a release of merlin by itself.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>>
>>>> This really has created an environment where I do not feel
>>>> confident in accepting your statements without a lot a suspicion
>>>> and skepticism. I think it would be better for everyone concerned
>>>> if I simply move the avalon-meta package back into Merlin, moving
>>>> everything into the merlin namespace, and move forward from there.
>>>> This will enable the assessment of Merlin's approach to
>>>> meta-management, tags, tools, extensions, components, etc. - and
>>>> from this, hopefully and more informed decision can be taken at
>>>> some time in the future.
>>>
>>>
>>> Don't do that. We have been making progress, and I would be against
>>> destroying
>>> that progress.
>>
>>
>> In your reply to my request for a checklist of lifecycle extension
>> concerns:
>>
>> http://marc.theaimsgroup.com/?l=avalon-dev&m=105948538408807&w=2
>>
>> You detailed that fact that you concerns are not in fact technical in
>> nature - but instead - concerns related to the inclusion of
>> facilities into the Avalon core namespace without sufficient
>> understanding of these concerns by the development community and
>> without sufficient feedback from t he user community. In fact we can
>> summarize this entire "conflict" as a question of fear of the
>> unknown, uncertainty of applicability, and doubt concerning utility.
>
>
> I think I eloquently stated my position, and I believe my goal is
> compatible with yours.
I agree completely. You elequantly confirmed that you don't understand
the problem. You eloquently described your *fear* of the pollution of
the avalon namespace. You eloquently described you *uncertainty* as to
technical applicability, and you eloquently described your *doubt* with
respect to utility. This is common referred to *FUD*.
>
>> Releasing Merlin would address each and every-one of your concerns.
>> Based on broader user feedback and greater developer experience we
>> will be in a much better position to move forward constructively.
>
>
> Actually, I think it would make things a little worse by diluting our
> already
> thin resources. We have 90% of the equation agreed to. I think it
> would be
> better for us to publish that 90% now, so that we can integrate them
> into the
> other containers. That way, a realease of Merlin won't be such a big
> deal.
The only person who is making a Merlin release a big deal is yourself.
You commenced the process by stating that you would block a release
unless it fulfilled you preconditions. This statement was grossly
misleading simply because you do not have that authority. It is this
majority of committers in this community of which you are only one that
carry the decision on a release. Secondly, you have argued your FUD
agenda using every possible avenue including threats of my dismissal
from Avalon. We are not 90% on anything. I moved what is a complete,
working and stable sub-system out of Merlin and into sandbox to
facilitate collaboration on establishing a common platform. A lot of
time has been spent addressing many aspects bringing in in-line. During
that process you have launched what can only be described as an attack
against me on the subject of extensions. And yet your rationalization
comes down to nothing more than FUD arrising from you self proclaimed
lack of knowledge. Once you actually take the time to address the
technical issues - there will be the potential to reach 100%. In the
meantime you have a lot of credibility that you need to recover.
>
> All a user needs to know is that if they implement the set of Avalon
> tags, their
> component will work accross all the containers.
Look - you said it here "All a user needs to know is that if they
implement the set of Avalon tags" and yet you want to fragment that same
namespace in such a way that users of will be obliged to use Avalon tags
plus Lifecycle tags. This is simply indicative of the problem you are
creating. Your statement reflects the impact of your suggestion -
disenfranchising a core subset of a object model simply because you do
not understand it.
On one hand you imply support for the meta-info model as it is - with
full support for stage and extension declaration. On the other hand you
claim that these features are not needed, unsupported, and you even go
so far to imply that related products are not released. In the context
of all of this - I have zero confidence that you will not continue this
process of disruption and fragmentation into the tools and the meta-info
API.
>
>
> Let's start with what we know. We can add in what we don't over time.
I suggest we move @avalon.meta -or @merlin - we maintain integrity of
the model. And you can sleep at night in the knowledge that your Avalon
namespace is clean. In the meantime some up who are much more interested
in putting together a complete and integral solution can get on with the
things we like doing.
>
> If we release the general Meta Info library with the set of Avalon
> tags we have
> agreed to up to this point,
We haven’t agreed anything of substance. We have an AMTAGS proposal that
does not meet requirements. We have you attempt to force a decision from
a position of ignorance that not only is biased against the Merlin
platform, but will itself lead to fragmentation and confusion.
> then after we incorporate it into Fortress and
> Phoenix, I have no issues with a Merlin release.
More preconditions? Perhaps you could do everyone a favor and stop this
ridiculous process of preconditioning. While you’re at it - could you
pull back on the FUD and drop the threats. In the meantime I'm going
back to things that are fun and interesting. In particular, I will
continue to move Merlin forward with the support of the user community
as a complete and viable solution.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>>
>>> This really has created an environment where I do not feel confident
>>> in accepting your statements without a lot a suspicion and
>>> skepticism. I think it would be better for everyone concerned if I
>>> simply move the avalon-meta package back into Merlin, moving
>>> everything into the merlin namespace, and move forward from there.
>>> This will enable the assessment of Merlin's approach to
>>> meta-management, tags, tools, extensions, components, etc. - and from
>>> this, hopefully and more informed decision can be taken at some time
>>> in the future.
>>
>> Don't do that. We have been making progress, and I would be against
>> destroying
>> that progress.
>
> In your reply to my request for a checklist of lifecycle extension
> concerns:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=105948538408807&w=2
>
> You detailed that fact that you concerns are not in fact technical in
> nature - but instead - concerns related to the inclusion of facilities
> into the Avalon core namespace without sufficient understanding of these
> concerns by the development community and without sufficient feedback
> from the user community. In fact we can summarize this entire
> "conflict" as a question of fear of the unknown, uncertainty of
> applicability, and doubt concerning utility.
I think I eloquently stated my position, and I believe my goal is compatible
with yours.
> Releasing Merlin would address each and every-one of your concerns.
> Based on broader user feedback and greater developer experience we will
> be in a much better position to move forward constructively.
Actually, I think it would make things a little worse by diluting our already
thin resources. We have 90% of the equation agreed to. I think it would be
better for us to publish that 90% now, so that we can integrate them into the
other containers. That way, a realease of Merlin won't be such a big deal.
All a user needs to know is that if they implement the set of Avalon tags, their
component will work accross all the containers.
Let's start with what we know. We can add in what we don't over time.
If we release the general Meta Info library with the set of Avalon tags we have
agreed to up to this point, then after we incorporate it into Fortress and
Phoenix, I have no issues with a Merlin release.
From that point forward, we can work on collaborating for that last 10%.
--
"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
releasing merlin
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> This really has created an environment where I do not feel confident
>> in accepting your statements without a lot a suspicion and
>> skepticism. I think it would be better for everyone concerned if I
>> simply move the avalon-meta package back into Merlin, moving
>> everything into the merlin namespace, and move forward from there.
>> This will enable the assessment of Merlin's approach to
>> meta-management, tags, tools, extensions, components, etc. - and from
>> this, hopefully and more informed decision can be taken at some time
>> in the future.
>
>
>
> Don't do that. We have been making progress, and I would be against
> destroying
> that progress.
In your reply to my request for a checklist of lifecycle extension concerns:
http://marc.theaimsgroup.com/?l=avalon-dev&m=105948538408807&w=2
You detailed that fact that you concerns are not in fact technical in
nature - but instead - concerns related to the inclusion of facilities
into the Avalon core namespace without sufficient understanding of these
concerns by the development community and without sufficient feedback
from the user community. In fact we can summarize this entire
"conflict" as a question of fear of the unknown, uncertainty of
applicability, and doubt concerning utility.
Releasing Merlin would address each and every-one of your concerns.
Based on broader user feedback and greater developer experience we will
be in a much better position to move forward constructively.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: limiting the scope of avalon
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>>
>>>
>>> Berin Loritsch wrote:
>>>
>>>> ?! The only things we officially have in place are ECM, Fortress, and
>>>> Phoenix. It should be limited to that function set.
>>>
>>>
>>>
>>>
>>>
>>> Berin:
>>>
>>> I would like to draw you attention to the following:
>>>
>>> * The excalibur-lifecycle package is released and is a part of the
>>> Avalon toolkit.
>>> * The meta-info package is in sandbox and is certainly ready for
>>> release as is.
>>> * The Merlin container is also ready for release.
>>>
>>> I don't think we should ignore our responsibilities with respect to
>>> released packages, and I don't think we should promote an artificial
>>> and self-serving discrimination against the contributions that exist
>>> in the sandbox.
>>
>>
>>
>> I hear you loud and clear. However, getting back to my question about
>> how to manage the growth of APIs, please let me draw your attention to
>> the
>> following:
>>
>> * I would like meta-info and Merlin released
>> * For those function areas that we have not all had time to digest,
>> namely
>> the extension meta info, I would like a breakin period.
>> * The rest of the meta-info standard is ready for release without any
>> reservations.
>
>
>
> Berin:
>
> I've put a lot of time into the separation of the meta-info package out
> of Merlin and into a avalon-meta. This included documentation, APIs,
> synchronizing on tags, etc. During this process:
>
> * I have been accused by you of being diverse.
Look, maybe diverse was a bad choice of terms. However, the fact remains
that there were different ways of doing things, and we needed to come
together on it. That was my intent. Unfortunately you chose to focus on
the word "diverse".
> * I have been told by you that a release will not happen until your
> issues are resolved
You have the same right to raise issues for things I propose to release.
> * I have been accused of ignoring your views.
You have not recognized them at all. You keep restating your views without
acknowleging mine. Can you blame me for accusing you that?
> * I have been told by you to pull in line or leave Avalon.
Right. You stated that you will choose not to abide by the decision or
outcome of a vote, ignoring your peers. I was well within my rights to
call you on the carpet on this.
>
> This really has created an environment where I do not feel confident in
> accepting your statements without a lot a suspicion and skepticism. I
> think it would be better for everyone concerned if I simply move the
> avalon-meta package back into Merlin, moving everything into the merlin
> namespace, and move forward from there. This will enable the assessment
> of Merlin's approach to meta-management, tags, tools, extensions,
> components, etc. - and from this, hopefully and more informed decision
> can be taken at some time in the future.
Don't do that. We have been making progress, and I would be against destroying
that progress. In fact, do not move anything in the sandbox CVS. Let's hash
out the issues and move forward.
Secondly, Merlin will never get released unless you can work with the rest of
us. You can't run and hide in a corner just because you reached a little
opposition.
--
"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: limiting the scope of avalon
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> ?! The only things we officially have in place are ECM, Fortress, and
>>> Phoenix. It should be limited to that function set.
>>
>>
>>
>>
>> Berin:
>>
>> I would like to draw you attention to the following:
>>
>> * The excalibur-lifecycle package is released and is a part of the
>> Avalon toolkit.
>> * The meta-info package is in sandbox and is certainly ready for
>> release as is.
>> * The Merlin container is also ready for release.
>>
>> I don't think we should ignore our responsibilities with respect to
>> released packages, and I don't think we should promote an artificial
>> and self-serving discrimination against the contributions that exist
>> in the sandbox.
>
>
> I hear you loud and clear. However, getting back to my question about
> how to manage the growth of APIs, please let me draw your attention to
> the
> following:
>
> * I would like meta-info and Merlin released
> * For those function areas that we have not all had time to digest,
> namely
> the extension meta info, I would like a breakin period.
> * The rest of the meta-info standard is ready for release without any
> reservations.
Berin:
I've put a lot of time into the separation of the meta-info package out
of Merlin and into a avalon-meta. This included documentation, APIs,
synchronizing on tags, etc. During this process:
* I have been accused by you of being diverse.
* I have been told by you that a release will not happen until your
issues are resolved
* I have been accused of ignoring your views.
* I have been told by you to pull in line or leave Avalon.
This really has created an environment where I do not feel confident in
accepting your statements without a lot a suspicion and skepticism. I
think it would be better for everyone concerned if I simply move the
avalon-meta package back into Merlin, moving everything into the merlin
namespace, and move forward from there. This will enable the assessment
of Merlin's approach to meta-management, tags, tools, extensions,
components, etc. - and from this, hopefully and more informed decision
can be taken at some time in the future.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: limiting the scope of avalon
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> ?! The only things we officially have in place are ECM, Fortress, and
>> Phoenix. It should be limited to that function set.
>
>
>
> Berin:
>
> I would like to draw you attention to the following:
>
> * The excalibur-lifecycle package is released and is a part of the
> Avalon toolkit.
> * The meta-info package is in sandbox and is certainly ready for release
> as is.
> * The Merlin container is also ready for release.
>
> I don't think we should ignore our responsibilities with respect to
> released packages, and I don't think we should promote an artificial and
> self-serving discrimination against the contributions that exist in the
> sandbox.
I hear you loud and clear. However, getting back to my question about
how to manage the growth of APIs, please let me draw your attention to the
following:
* I would like meta-info and Merlin released
* For those function areas that we have not all had time to digest, namely
the extension meta info, I would like a breakin period.
* The rest of the meta-info standard is ready for release without any
reservations.
My idea to grow the API in a controllable and sustainable way is to introduce
new ideas and concepts in a separate namespace. I prefer a functional one as
opposed to a container specific one. This will allow the rest of us to see
how it works with Fortress/Merlin/and possibly even Phoenix. When the rest of
us (including me) are comfortable with the solution, we can vote to include it
in the Avalon namespace.
So far, the only side of the equation that I have asked us to change is the
meta-info gathering tool (meta-tools). That means the rest of the entire
equation (i.e. the XML descriptors and serialized meta info) has not changed.
Those are the container contracts--and for now I am most interested in the
client contracts. The only impact to moving the attributes back into the
avalon namespace is to have the meta-tools recognize both @avalon and
@lifecycle, issuing a deprecation warning for @lifecycle.
I really don't think that is unreasonable, do you?
--
"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
limiting the scope of avalon
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> ?! The only things we officially have in place are ECM, Fortress, and
> Phoenix. It should be limited to that function set.
Berin:
I would like to draw you attention to the following:
* The excalibur-lifecycle package is released and is a part of the
Avalon toolkit.
* The meta-info package is in sandbox and is certainly ready for release
as is.
* The Merlin container is also ready for release.
I don't think we should ignore our responsibilities with respect to
released packages, and I don't think we should promote an artificial and
self-serving discrimination against the contributions that exist in the
sandbox.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>>
>>> The subject is about a set of tags that describe the requirements a
>>> container has to fulfil for reliable and predictable component
>>> deployment. To achieve that we must either (a) provide a complete
>>> model, or (b) provide a model extension mechanism. One of the
>>> options described in the vote will only result in division and
>>> failure to achieve the objective. As such the vote calls for
>>> unification but presents a solution that will divide. Hopefully a
>>> majority of people will figure out that this vote is premature and
>>> that perhaps there are some important and unresolved issues to be
>>> addressed. If not, I guess its history repeating itself.
>>>
>>
>> The problem is that the solution to these issues is not going to be easy.
>> By CMM/RUP standards that means we should tackle it first. By XP
>> standards,
>> it means that we might want to take advantage of what we have already
>> agreed
>> to, make a release, and expand when we know what we want to do later.
>
>
>
> The practical approach is to use what we have already in place. It is
> an approach that ensures that the interests and concerns of all
> interested parties is addressed. It is also an approach that delivers
> what we promising now - validated - working - and complete.
?! The only things we officially have in place are ECM, Fortress, and
Phoenix. It should be limited to that function set.
>> I would like to fully address these issues, but I don't want to give the
>> impression that the extensions are core supported Avalon tags until we
>> have solved those issues.
>
> Extensions became intrinsic to the component deployment model when we
> voted for the release of the excalibur-extension package (a vote that
> received your +1). At that point we said to everyone out there that
> there is a notion of lifecycle stage extensions in Avalon. We
> documented in that release the support for that abstraction in both
> Merlin and Fortress. There are simply no issues to solve - this is
> simply a matter of getting back to a process of collaboration.
I don't buy that reasoning. Lifecycle extensions (as released) are a
set of interfaces. Those interfaces work. Currently Fortress and Merlin
have two different ways of addressing how to work with them. I don't think
you have been listening to the points I have been raising either.
>
>>
>> That said, I would like to get a point release out there so that we
>> can start
>> integrating Avalon Meta into Fortress and Phoenix (superceding what is
>> currently
>> there).
>
> Then please retract your vote and reconsider the subject with the
> interests of everyone involved.
The only interest that doesn't seem to be addressed is yours (if that is
an incorrect statement, someone other than Stephen speak up). If we can't
address everyone's concern (which it seems we can't) then we can address
the majority's concerns. The vote stands
>> We have some difficult issues ahead of us as we resolve how we want to
>> handle
>> things like management extensions, ad-hoc instrumentation, lifecycle
>> extensions,
>> etc. If we get the core stuff out there now, then people can start
>> migrating
>> the currently defined components/containers to use the proper meta
>> tags and
>> have something that we can play with in more than one container (i.e.
>> Fortress
>> and Merlin).
>
> We can do this now without introducing any fragmentation or division.
> Simply proceed with the platform we have.
We don't have a platform. We are trying to work towards one, which you
have to be willing to come halfway. I don't think the platform as written
fully addresses the issues surrounding extensions. That is why I don't
want it in the main avalon space.
>> We need to be clear that the extension mechanisms while they are
>> really cool,
>> are still extensions. It lets people who are adventurous play first,
>> thus
>> allowing us to gain a better understanding of the problem space and
>> adopt the
>> viewpoints of others. By placing the extensions in the lifecycle
>> namespace
>> now, it allows early adopters to play around with it, knowing it is
>> alpha,
>> as we come up with the formal plan.
>
> Please - you are completely ignoring the issue I've raised. The
> suggestion to split (delivering an incomplete solution under @avalon)
> combined with publication under avalon is something I cannot support.
> The implications of this proposal are far reaching. Things outside of
> @avalon will be ignored and there is nothing you can do about it. At
> least if we keep the model complete we have a fighting chance of turning
> this into something useful.
No I am not ignoring the issue you've raised, but I see no evidence of
you listening the issue I've raised.
Things outside of the @avalon may or may not get ignored. That is a risk,
but you are not able to predict the future. Many people said things outside
of the java.*/javax.* packages would be ignored, and while there are Java
standards for logging, Log4J still thrives. Your argument doesn't hold
weight.
>> If we try to solve this now, we will essentially hold up development
>> by a large
>> number of people/projects that really can use the standard for the
>> core tags.
>
> There is nothing to solve in the short term. A complete, viable, proven
> solution is in place.
Only in your oppinion.
>> Not everyone is interested in the extensions yet. I want to leverage the
>> existing momentum and help us move forward.
>
> If you want to gain momentum, then please try another approach. You
> could consider this as a case of getting all of the players on board.
> That would suggest that a solution to this problem must address the
> intents of all parties without prejudice. So long as you try to
> engineer an outcome, you will not gain the momentum you seek. In fact,
> it will be (and are presently) achieving quite the opposite.
Tell me your oppinions on managing growth of APIs and such. Are you in
favor of starting small and including as necessary or starting large and
excluding over time?
>
>> Who is to say that the extension
>> tags won't end up officially in the avalon namespace?
>
> Spin this either way - what it comes down to is that your don't know.
> What you cannot deny is that this notion is in use, is appreciated, is
> relevant, is supported, is released, and is not less important than any
> other of the 10 abstractions we are discussing.
I can deny that it is released in any official capacity. In fact it should
not be released in any official capacity. Releases must be approved by the
PMC, and this library has never gone up for vote. As to it being in use
and appreciated, a few folks are benefiting. As to relevant, I can't say
either way. As to supported, only by one person, not the whole of Avalon.
You don't know either. Allow others to test your vision, poke holes in it,
ask questions, and decide for themselves if it is truly relevant or if there
are actually better ways of accomplishing the goal.
>> They very well may,
>> but by the time they get there, everyone will know how to use them and
>> what
>> they enable. THen again, what finally does get adopted may be very
>> different.
>>
>> While they are being experimented with, I believe it is important not
>> to have
>> them in the core avalon namespace.
>
> Berin - please - this is not experimental stuff.
IMO it is. Extensions as a whole are an experiment. That is why Extensions
are not in Framework. If Extensions ever make it to Framework, THEN it is
no longer an experiment, and it is officially part of the CORE of Avalon.
>> Otherwise we will end up with the equivalent
>> of the Component interface in our avalon tags. Arguing to hold up a
>> potential
>> release and integration of the same tags library because we don't have
>> everything specified, seems to imply that we are closer to a solution
>> than we
>> really are.
>>
>> Can you at least agree to them being placed in an alternative
>> namespace while
>> we hash out the implications with the goal that something enabling
>> extensions
>> will be included in the avalon namespace when we are done? I would
>> like to
>> do a release RSN so that we can start integration. When we solve
>> those hard
>> problems, we can adopt the resolution. Does that sound fair?
>
> Fair (within the context of this development community) means ensuring
> everyone's interests are addressed in what is the first step towards
> convergence of three containers. Fair means not putting up obstacles to
> convergence. Fair (towards our users) means being responsible and
> delivering a solution that will provide and deliver a common, complete
> solution where nothing is more or less important than anything else.
>
> What I'm hoping for is that we:
>
> * get back to the process of working together
agreed.
> * stop once and for all this process of selective discrimination
?!? I don't follow. I am who I am and respond the way I respond to
anyone the same way.
> * do something that address everyone needs
Over time. We can address the needs we all agree on now. The ones we
don't need to be hashed out some more.
--
"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: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> The subject is about a set of tags that describe the requirements a
>> container has to fulfil for reliable and predictable component
>> deployment. To achieve that we must either (a) provide a complete
>> model, or (b) provide a model extension mechanism. One of the
>> options described in the vote will only result in division and
>> failure to achieve the objective. As such the vote calls for
>> unification but presents a solution that will divide. Hopefully a
>> majority of people will figure out that this vote is premature and
>> that perhaps there are some important and unresolved issues to be
>> addressed. If not, I guess its history repeating itself.
>>
>
> The problem is that the solution to these issues is not going to be easy.
> By CMM/RUP standards that means we should tackle it first. By XP
> standards,
> it means that we might want to take advantage of what we have already
> agreed
> to, make a release, and expand when we know what we want to do later.
The practical approach is to use what we have already in place. It is
an approach that ensures that the interests and concerns of all
interested parties is addressed. It is also an approach that delivers
what we promising now - validated - working - and complete.
>
> I would like to fully address these issues, but I don't want to give the
> impression that the extensions are core supported Avalon tags until we
> have solved those issues.
Extensions became intrinsic to the component deployment model when we
voted for the release of the excalibur-extension package (a vote that
received your +1). At that point we said to everyone out there that
there is a notion of lifecycle stage extensions in Avalon. We
documented in that release the support for that abstraction in both
Merlin and Fortress. There are simply no issues to solve - this is
simply a matter of getting back to a process of collaboration.
>
> That said, I would like to get a point release out there so that we
> can start
> integrating Avalon Meta into Fortress and Phoenix (superceding what is
> currently
> there).
Then please retract your vote and reconsider the subject with the
interests of everyone involved.
>
> We have some difficult issues ahead of us as we resolve how we want to
> handle
> things like management extensions, ad-hoc instrumentation, lifecycle
> extensions,
> etc. If we get the core stuff out there now, then people can start
> migrating
> the currently defined components/containers to use the proper meta
> tags and
> have something that we can play with in more than one container (i.e.
> Fortress
> and Merlin).
We can do this now without introducing any fragmentation or division.
Simply proceed with the platform we have.
>
> We need to be clear that the extension mechanisms while they are
> really cool,
> are still extensions. It lets people who are adventurous play first,
> thus
> allowing us to gain a better understanding of the problem space and
> adopt the
> viewpoints of others. By placing the extensions in the lifecycle
> namespace
> now, it allows early adopters to play around with it, knowing it is
> alpha,
> as we come up with the formal plan.
Please - you are completely ignoring the issue I've raised. The
suggestion to split (delivering an incomplete solution under @avalon)
combined with publication under avalon is something I cannot support.
The implications of this proposal are far reaching. Things outside of
@avalon will be ignored and there is nothing you can do about it. At
least if we keep the model complete we have a fighting chance of turning
this into something useful.
>
> If we try to solve this now, we will essentially hold up development
> by a large
> number of people/projects that really can use the standard for the
> core tags.
There is nothing to solve in the short term.
A complete, viable, proven solution is in place.
>
> Not everyone is interested in the extensions yet. I want to leverage the
> existing momentum and help us move forward.
If you want to gain momentum, then please try another approach. You
could consider this as a case of getting all of the players on board.
That would suggest that a solution to this problem must address the
intents of all parties without prejudice. So long as you try to
engineer an outcome, you will not gain the momentum you seek. In fact,
it will be (and are presently) achieving quite the opposite.
> Who is to say that the extension
> tags won't end up officially in the avalon namespace?
Spin this either way - what it comes down to is that your don't know.
What you cannot deny is that this notion is in use, is appreciated, is
relevant, is supported, is released, and is not less important than any
other of the 10 abstractions we are discussing.
> They very well may,
> but by the time they get there, everyone will know how to use them and
> what
> they enable. THen again, what finally does get adopted may be very
> different.
>
> While they are being experimented with, I believe it is important not
> to have
> them in the core avalon namespace.
Berin - please - this is not experimental stuff.
> Otherwise we will end up with the equivalent
> of the Component interface in our avalon tags. Arguing to hold up a
> potential
> release and integration of the same tags library because we don't have
> everything specified, seems to imply that we are closer to a solution
> than we
> really are.
>
> Can you at least agree to them being placed in an alternative
> namespace while
> we hash out the implications with the goal that something enabling
> extensions
> will be included in the avalon namespace when we are done? I would
> like to
> do a release RSN so that we can start integration. When we solve
> those hard
> problems, we can adopt the resolution. Does that sound fair?
Fair (within the context of this development community) means ensuring
everyone's interests are addressed in what is the first step towards
convergence of three containers. Fair means not putting up obstacles to
convergence. Fair (towards our users) means being responsible and
delivering a solution that will provide and deliver a common, complete
solution where nothing is more or less important than anything else.
What I'm hoping for is that we:
* get back to the process of working together
* stop once and for all this process of selective discrimination
* do something that address everyone needs
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> The subject is about a set of tags that describe the requirements a
> container has to fulfil for reliable and predictable component
> deployment. To achieve that we must either (a) provide a complete model,
> or (b) provide a model extension mechanism. One of the options
> described in the vote will only result in division and failure to
> achieve the objective. As such the vote calls for unification but
> presents a solution that will divide. Hopefully a majority of people
> will figure out that this vote is premature and that perhaps there are
> some important and unresolved issues to be addressed. If not, I guess
> its history repeating itself.
>
The problem is that the solution to these issues is not going to be easy.
By CMM/RUP standards that means we should tackle it first. By XP standards,
it means that we might want to take advantage of what we have already agreed
to, make a release, and expand when we know what we want to do later.
I would like to fully address these issues, but I don't want to give the
impression that the extensions are core supported Avalon tags until we
have solved those issues.
That said, I would like to get a point release out there so that we can start
integrating Avalon Meta into Fortress and Phoenix (superceding what is currently
there).
We have some difficult issues ahead of us as we resolve how we want to handle
things like management extensions, ad-hoc instrumentation, lifecycle extensions,
etc. If we get the core stuff out there now, then people can start migrating
the currently defined components/containers to use the proper meta tags and
have something that we can play with in more than one container (i.e. Fortress
and Merlin).
We need to be clear that the extension mechanisms while they are really cool,
are still extensions. It lets people who are adventurous play first, thus
allowing us to gain a better understanding of the problem space and adopt the
viewpoints of others. By placing the extensions in the lifecycle namespace
now, it allows early adopters to play around with it, knowing it is alpha,
as we come up with the formal plan.
If we try to solve this now, we will essentially hold up development by a large
number of people/projects that really can use the standard for the core tags.
Not everyone is interested in the extensions yet. I want to leverage the
existing momentum and help us move forward. Who is to say that the extension
tags won't end up officially in the avalon namespace? They very well may,
but by the time they get there, everyone will know how to use them and what
they enable. THen again, what finally does get adopted may be very different.
While they are being experimented with, I believe it is important not to have
them in the core avalon namespace. Otherwise we will end up with the equivalent
of the Component interface in our avalon tags. Arguing to hold up a potential
release and integration of the same tags library because we don't have
everything specified, seems to imply that we are closer to a solution than we
really are.
Can you at least agree to them being placed in an alternative namespace while
we hash out the implications with the goal that something enabling extensions
will be included in the avalon namespace when we are done? I would like to
do a release RSN so that we can start integration. When we solve those hard
problems, we can adopt the resolution. Does that sound fair?
--
"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: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>* moving out of core means death to the idea of reliable deployment
>>across containers
>>
>>
>
>I think your social observations are spot-on, and your technical
>assessment is correct. The absence of the tag in the avalon
>namespace makes it optional, and thus people will ignore it.
>The absence also makes it impossible to guarantee that a component
>will run in any Avalon container.
>
Yes... that's the crux of the situation.
>
>
>But I think your summary is way off.
>
>It is not the death of cross-container deployment. We will get
>there. Is it the death of Fortress/Merlin-style extensions? Maybe.
>
Consider that Merlin will not discontinue the use of extensions
semantics - in fact if anything it will embrace these semantics at
increasing more sophisticated and interesting ways. This means that
Merlin will continue on a path that is deferent from the rest of Avalon
- just as Phoenix and ECM split in two directions. What is important to
recognize is that today this is a hair-line fracture - we can choose to
recognize and resolve that fracture or we can choose to ignore it. In
my opinion - this little hair-line fracture will grow and we will see
real divergence. It will mean that Merlin will focus on providing a
solution platform - not for Avalon components - but for Merlin
components. Why, because is users follow Merlin rules they will be safe
and if users follow Avalon rules they do so at their own risk.
>
>I don't think the current extension model should go into the
>core, because I don't think it satisfies all needs.
>
I agree that excalibur-extension should not go into core.
I do not agree that the notion of deplyment phase depedencies can be
considered non-core.
>Peter Donald
>explained some difficulties with it - mostly it didn't support
>interceptors, which I have tried, used and found very helpful
>since then.
>
Keep in mind that this is not about excalibur-lifecycle - its about the
notion of deployment dependencies as peers to runtime dependencies.
>>* an absence of an extension mechanism in @avalon core makes the
>> proposal technically invalid
>>
>>
>
>I don't understand this.
>
>All the proposal says is this:
>
> Put the extension stuff into @lifecycle, not @avalon, because,
> well, we just don't know whether this type of extensions will
> be the final version.
>
>In what way is the proposal invalid?
>
The subject is about a set of tags that describe the requirements a
container has to fulfil for reliable and predictable component
deployment. To achieve that we must either (a) provide a complete model,
or (b) provide a model extension mechanism. One of the options
described in the vote will only result in division and failure to
achieve the objective. As such the vote calls for unification but
presents a solution that will divide. Hopefully a majority of people
will figure out that this vote is premature and that perhaps there are
some important and unresolved issues to be addressed. If not, I guess
its history repeating itself.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Vinay Chandran <vi...@yahoo.com>.
--- Leo Sutic <le...@inspireinfrastructure.com>
wrote:
>
> I don't think the current extension model should go
> into the
> core,
> because I don't think it satisfies all needs.
Agree.
> Peter Donald
> explained some difficulties with it - mostly it
> didn't support
> interceptors, which I have tried, used and found
> very helpful
> since then.
>
Interceptors are the way to go!!!
Regards,
Vinay
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> * moving out of core means death to the idea of reliable deployment
> across containers
I think your social observations are spot-on, and your technical
assessment is correct. The absence of the tag in the avalon
namespace makes it optional, and thus people will ignore it.
The absence also makes it impossible to guarantee that a component
will run in any Avalon container.
But I think your summary is way off.
It is not the death of cross-container deployment. We will get
there. Is it the death of Fortress/Merlin-style extensions? Maybe.
I don't think the current extension model should go into the
core, because I don't think it satisfies all needs. Peter Donald
explained some difficulties with it - mostly it didn't support
interceptors, which I have tried, used and found very helpful
since then.
> * an absence of an extension mechanism in @avalon core makes the
> proposal technically invalid
I don't understand this.
All the proposal says is this:
Put the extension stuff into @lifecycle, not @avalon, because,
well, we just don't know whether this type of extensions will
be the final version.
In what way is the proposal invalid?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Stephen McConnell <mc...@apache.org>.
Peter Royal wrote:
> On Monday, July 28, 2003, at 11:04 AM, Stephen McConnell wrote:
>
>> Do they understand what they are voting for? My guess is that they
>> will assume the very simplistic line from Berin that this is about a
>> namespace. They will not take into account the ramifications. They
>> probably will not appreciate that this is a divisive point in terms
>> of the avalon component model. They will probably not appreciate that
>> it introduces a separation at the core of Avalon and from that
>> separation there will eternally be those that do and those that don't.
>
>
> Can you succinctly list the ramifications?
I'll try!
There is a social implication complicated by a contractual limitation.
The social implications is:
* "it's not I the avalon namespace I don't have to worry about it"
This is complicated by a contractual limitations:
* "the avalon namespace model does not support model extension"
I want to start things off with the social implication, however, let me
just note that under the @avalon namespace we do not have any notion or
mechanism to declare expansion of that namespace. This means that if
something is not inside Avalon namespace - well - it just does not exist
in terms of something standard and recognized. But I'll come back to
this in more detail.
On social implications:
-----------------------
The @avalon.stage tag declares that a component has a deployment phase
dependency relative to a container. This means that a container should
either fulfill that deployment phase dependency or toss out the
component. The @avalon.stage tag does not dictate a mechanisms to a
container - it simply declares a deployment criteria.
If we retract the @avalon.stage (and the corresponding
@avalon.extension) tags from the Avalon namespace, we are stating that
the notions of deployment phase (versus classic runtime phase) notions
are concepts that can be ignored. There is dilemma here, because the
vote in question does not address the implications. If you remove
@avalon.stage from core Avalon - then any component that leverages
deployment phase dependencies (i.e. components that fulfill stage
execution) will no longer be a valid Avalon components. The implication
of this is that a container could be asked to deploy such a component,
and unless the component does its own error checking to validate that in
fact its lifecycle stages have been executed, we enter the gray zone of
unpredictable components. This gray zone is components executing on the
assumption that they have been fully deployed. This potential false
assumption can lead to failures in security, inconsistency in service
delivery behavior, and potential damage by a component simply because it
is acting under incorrect assumptions.
The counter argument to this case is that the notion of a lifecycle
dependency can be moved to @lifecycle. Socially this will ignored. As
soon as we start down the track of multiple compliance levels we will
have lost. Containers outside (and quite probably inside) Avalon will
ignore @lifecycle because its not part of a "core" @avalon contract.
Those containers will not validate components in the same way. Those
components and will be running blind.
If we don't do a complete description of container responsibility - they
we must do nothing less that revert to container specific solutions
@phoenix, @fortress and @merlin.
On contractual limitations
--------------------------
As mentioned about - @avalon.stage is not about excalibur-lifecycle.
Its about the declaration of a deployment phase dependency. One cannot
simply retract this tag from the Avalon namespace without providing a
solution. The problem concerns many components that use extensions and
their need/requirement to declare that criteria to a container in a
consistent fashion. Under an @lifecycle solution - you MUST have a way
of declaring within the @avalon namespace, that an @lifecycle is to be
including in the component deployment criteria. This is non-trivial.
In my own experience the lifecycle stage model has served to address
some key limitations of the Avalon component contract. This is based on
experience with stage extensions that use excalibur-lifecycle and others
that are totally independent of excalibur-lifecycle. These advantages
must not be lost. To assure this we have a choice .. we either
recognize the deployment phase dependencies can exist, or we halt this
process and go back to the drawing board and come up with a revised
specification that addresses component criteria at a more abstract
level. I believe that what we have today is complete and consistent. I
believe that we will come up with a small but interesting number of
different approaches to stage management (including inceptors and event
based handlers). I do not believe that this will be contradictory to
the @avalon.stage tag. Instead, they will represent different, smatter
better solutions to handling the criteria expressed by an @avalon.stage.
I also thing that as we move forward, with experience based largely from
work with extensions, we will figure out what we need in terms of tags
extension semantics (i.e. how to tell a parser to look beyond @avalon
and what to do with the result). Those ideas will have ramifications on
tag definitions, meta info, meta data, meta models, and containers. In
the meantime, a complete solution (i.e. including the deployment phase
dependencies) will provide more than most people will need and
everything that Avalon needs.
Summary:
--------
* moving out of core means death to the idea of reliable deployment
across containers
* an absence of an extension mechanism in @avalon core makes the
proposal technically invalid
Now is not the time to throw together an extension mechanisms - the
problem is non-trivial and a solution need to grow from common needs,
interests and experience. Now is not the time for another divergent
split in Avalon - containers that see and contains that don't (i.e.
containers that recognize the full criteria and containers that claim
Avalon compliance but ignore the reality of what developers are doing
using release Avalon product).
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Peter Royal <pr...@apache.org>.
On Monday, July 28, 2003, at 11:04 AM, Stephen McConnell wrote:
> Do they understand what they are voting for? My guess is that they
> will assume the very simplistic line from Berin that this is about a
> namespace. They will not take into account the ramifications. They
> probably will not appreciate that this is a divisive point in terms of
> the avalon component model. They will probably not appreciate that it
> introduces a separation at the core of Avalon and from that separation
> there will eternally be those that do and those that don't.
Can you succinctly list the ramifications?
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Calling for a vote is about the least productive thing you
>>could do to get consensus.
>>
>>
>
>I've done that many times in order to force *a* decision
>either way. It is a great way to say "OK, we've fired off
>our best arguments, let's put the issue to the team."
>
>
Forcing a decision when all of the cards are on the table and the
choices are valid is ok. This is forcing a decision without a solution
and introducing a fracture into whatever we do from here. We have lived
with the ECM Phoenix divide for long enough - do we really have to do
for divsion again and again? Forcing a vote at this time is a blunder
of major proportion. The questions are important - the issue need to
resolved. I've already explain that we need to either complete things
properly or abstract ourselves.
>>I will consider it totally invalid and I certainly will not
>>feel bound by any outcome.
>>
>>
>
>So does that mean we can ignore your votes, vetoes and so
>on as we see fit from now on?
>
Feel free to do whatever you want.
There is simply insufficient understanding of this implications
of the options that Berin put forward to call a vote at this time.
I cannot support or endorce a process that that I know is faulted
in motivation and technical argument.
>Stephen, the votes aren't something you can choose to ignore
>when and as you see fit. If a vote is completely invalid, then
>nobody will vote, or everyone will vote -1. Right now there
>are people voting +1. That in itself makes it valid.
>
Yes - there are people voting +1.
Do they understand what they are voting for? My guess is that they will
assume the very simplistic line from Berin that this is about a
namespace. They will not take into account the ramifications. They
probably will not appreciate that this is a divisive point in terms of
the avalon component model. They will probably not appreciate that it
introduces a separation at the core of Avalon and from that separation
there will eternally be those that do and those that don't.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [ANTI-VOTE] Lifecycle Extension Tags
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Calling for a vote is about the least productive thing you
> could do to get consensus.
I've done that many times in order to force *a* decision
either way. It is a great way to say "OK, we've fired off
our best arguments, let's put the issue to the team."
> I will consider it totally invalid and I certainly will not
> feel bound by any outcome.
So does that mean we can ignore your votes, vetoes and so
on as we see fit from now on?
Stephen, the votes aren't something you can choose to ignore
when and as you see fit. If a vote is completely invalid, then
nobody will vote, or everyone will vote -1. Right now there
are people voting +1. That in itself makes it valid.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[ANTI-VOTE] Lifecycle Extension Tags
Posted by Stephen McConnell <mc...@apache.org>.
Calling for a vote is about the least productive thing you could do to
get consensus. If you want consensus then address the real issue. That
means addressing the real problems of a container understanding the full
implication of component deployment.
I am not even going to bother voting on this vote. This is simply a
mistake. I will consider it totally invalid and I certainly will not
feel bound by any outcome. Until we recognize and address and solution
to the problem of full and complete description of a components
requirements to a container – we are simply not addressing the real
problem. Either abstract the problem or solve the problem. Calling a
vote is a waste of everyone’s time.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Lifecycle Extension Tags
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> [VOTE]
>
> Place the extension tags (.extension and .stage) in the @lifecycle
> namespace.
>
> [ ] +1 I like the proposal
> [ ] -1 I am fine with them in the @avalon namespace
> [X] 0 I don't really care (I'll go with the majority)
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Lifecycle Extension Tags
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Berin, Stephen,
I can't vote on these counter props. I'm known to stand for a) No doclet
tags per se, and b) different for different containers if it must be done.
- 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: [VOTE] Lifecycle Extension Tags
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> [VOTE]
>
> Place the extension tags (.extension and .stage) in the
> @lifecycle namespace.
>
> [X] +1 I like the proposal
> [ ] -1 I am fine with them in the @avalon namespace
> [ ] 0 I don't really care (I'll go with the majority)
+1
Motivation:
Like Berin stated, stages are likely to be superceded in the
near-to-mid future by interceptors (or something similar).
XP and "we can change it later" is all good stuff - as is
most/all what the Dutch Leo writes - but I think the cruft
potential here is too strong to allow me to say "we'll
change it later" and vote for the avalon namespace.
We can always revisit this and move them into the avalon
namespace at a later time, if my intuition proves wrong.
That will also be easier than to move something *out*
of avalon namespace, and I guess I'll use the XP excuse
here...
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Lifecycle Extension Tags
Posted by Peter Royal <pr...@apache.org>.
On Monday, July 28, 2003, at 09:48 AM, Berin Loritsch wrote:
> [VOTE]
>
> Place the extension tags (.extension and .stage) in the @lifecycle
> namespace.
>
> [X] +1 I like the proposal
> [ ] -1 I am fine with them in the @avalon namespace
> [ ] 0 I don't really care (I'll go with the majority)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org