You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/03/11 17:49:29 UTC
[PROPOSAL] lifecycle release
As part of the Phase II release process we need to address the
release of the Lifecycle Extensions package. This package is
currently in the avalon-sandbox CVS. Package documentation is
available at the following URL:
http://avalon.apache.org/sandbox/lifecycle/
I propose
* that the package be migrated from the avalon-sandbox
CVS to the avalon CVS as a separate project along-side
the avalon framework
* the release of the avalon-lifecycle package shall be
considered as an "optional" extension to the framework
contracts
* the release shall be made under an independent
distribution (i.e. avalon-lifecycle-1.0.jar)
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote, On 13/03/2003 22.52:
> On Fri, 14 Mar 2003 07:55, Rodent of Unusual Size wrote:
>
>>Peter Donald wrote:
>>
>>>Get over. I have spent hours upon hours explaining this and wrote up
>>>several long emails and documents explaining this in the past. I have
>>>given oodles and oodles of links to both java and dot.net based
>>>approaches. What is it you find lacking in my previous explanations?
>>
>>possibly the lack of that list of links in the same message as the
>>veto.
>
> Go back to the veto and yoou will see the reason was
>
> "It is the same approach that has been done before and failed and can't
> cleanly produce some aspects like delayed activation, passivation,
> persistence, transaction demarcation, bifuricating interception etc."
>
> which is still true and still justification for the veto.
That code is not the solution to the aspects you define. It has not been
made to solve them, so the lack of them is not a justification.
As for "done in the past", it's not a reason.
> When asked for my opinion on possible paths to fix I suggested that
> interceptor pattern is the solution. I sent along a couple of links (as has
> Leo) and that should be enough. If there is something missing then feel free
> to ask questions after reading the links I have sent.
We are all interested in the interceptor mechanism, but it solves a
different issue.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Didier,
I am receiving Peter's e-mails on dev@.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Didier Villevalois <dv...@phpapp.org>.
Hi
>>When asked for my opinion on possible paths to fix I suggested that
>>interceptor pattern is the solution. I sent along a couple of links
>>(as has Leo) and that should be enough. If there is something missing
>>then feel free to ask questions after reading the links I have sent.
>>
>>
>
>As I mention in another message, since there appear to be two different
>proposals in the offering, it would be helpful to see a TERSE AND PITHY
>comparison of them leading to a discussion of what the Community wants to
>do; perhaps taking the best ideas from each.
>
> --- Noel
>
>
Maybe, there is something i did not understand. I really would like to
follow the discussion about the lifecycle proposals but... i do not
receive any of Peter's mail on the lists users@ and dev@ ???
The two last emails i received were from him are two reply to GUMP
failures : one this morning and one on the first of March. But i can see
many people reply to him so i can read parts of his replies but not the
whole. Is he only sending to PMC's list ?? If yes, this is not fair at all.
Thanks. Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Didier Villevalois wrote:
>>> When asked for my opinion on possible paths to fix I suggested that
>>> interceptor pattern is the solution. I sent along a couple of links
>>> (as has Leo) and that should be enough. If there is something missing
>>> then feel free to ask questions after reading the links I have sent.
>>
>> As I mention in another message, since there appear to be two different
>> proposals in the offering, it would be helpful to see a TERSE AND PITHY
>> comparison of them leading to a discussion of what the Community wants to
>> do; perhaps taking the best ideas from each.
>>
>>
> Maybe, there is something i did not understand. I really would like to
> follow the discussion about the lifecycle proposals but... i do not
> receive any of Peter's mail on the lists users@ and dev@ ???
> The two last emails i received were from him are two reply to GUMP
> failures : one this morning and one on the first of March. But i can see
> many people reply to him so i can read parts of his replies but not the
> whole. Is he only sending to PMC's list ?? If yes, this is not fair at all.
nope, I suspect there is something wrong on your end or on the route to
your end from the asf mail machine. I'm getting these messages, and
they're arriving through gmane (www.gmane.org) as well; you could use
the gmane news gateway for reading and posting until we fix this.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Go back to the veto and yoou will see the reason was
> "It is the same approach that has been done before and failed and can't
> cleanly produce some aspects like delayed activation, passivation,
> persistence, transaction demarcation, bifuricating interception etc."
Peter, you still need to explain things. Such as why you believe that the
proposed solution doesn't cleanly produce those things, and what you feel
would need to be done, either to that proposal, or with an alternative, that
does satisfy all of the competing requirements.
An interesting irony is that your signature-bot added the following on your
earlier commentary to Jason van Zyl:
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
You should understand that he is saying that you may explore all sorts of
paths, and indeed wander full circle. But just because you end up where you
started doesn't mean that the journey was in vain. Having made it, you now
have a different appreciation.
> When asked for my opinion on possible paths to fix I suggested that
> interceptor pattern is the solution. I sent along a couple of links
> (as has Leo) and that should be enough. If there is something missing
> then feel free to ask questions after reading the links I have sent.
As I mention in another message, since there appear to be two different
proposals in the offering, it would be helpful to see a TERSE AND PITHY
comparison of them leading to a discussion of what the Community wants to
do; perhaps taking the best ideas from each.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 07:55, Rodent of Unusual Size wrote:
> Peter Donald wrote:
> > Get over. I have spent hours upon hours explaining this and wrote up
> > several long emails and documents explaining this in the past. I have
> > given oodles and oodles of links to both java and dot.net based
> > approaches. What is it you find lacking in my previous explanations?
>
> possibly the lack of that list of links in the same message as the
> veto.
Go back to the veto and yoou will see the reason was
"It is the same approach that has been done before and failed and can't
cleanly produce some aspects like delayed activation, passivation,
persistence, transaction demarcation, bifuricating interception etc."
which is still true and still justification for the veto.
When asked for my opinion on possible paths to fix I suggested that
interceptor pattern is the solution. I sent along a couple of links (as has
Leo) and that should be enough. If there is something missing then feel free
to ask questions after reading the links I have sent.
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Mon, 17 Mar 2003 06:23, Stefano Mazzocchi wrote:
>
>>>The JSR has not been made public but from the grapevine heres the scoop.
>>>The metadata will be store in .class file as "class attributes". So it
>>>will not require a JVM change but the utility files to load the metadata
>>>will be in the next JVM. However that does not stop us developing our own
>>>loader that parses the the .class files using BCEL.
>>
>>I see.
>>
>>But once you have that metadata inside your class, how are you going to
>>find out something about it? introspection or direct bytecode manipulation?
>
>
> direct bytecode manipulation pre jdk1.5. However we can also store metadata
> side by side class and load via standard classloader.
I see.
>>Those sounds much less elegant than any instanceof() calls. What am I
>>missing?
>
> you can include rich metadata in here that interfaces can't handle. ie You can
> say method X is capable of being remoted, interface y is transaction aware,
> component y takes a service using key A of type B but it is optional etc.
Gotcha.
>>>@meta Fortress{lifecycle="ThreadSafe"}
>>>@fortress lifecycle="ThreadSafe"
>>>@meta org.apache.avalon.fortress.FortressMetaData("ThreadSafe")
>>
>>Ok, makes sense.
>>
>>do you think this is going to be enough for the metadata needs you
>>foresee? just curious.
>
>
> Mostly. Somethings are ugly. Essentially it gets ugly when you nest metadata
> greater than two levels and have repeating groups.
Yes, that's what I was envisioning.
> However I have only needed
> that once and after going through the dot.net stuff and following xdoclet
> development I can see there is always work arounds. ie Rather than repeating
> groups xdoclet tends to design their tag schemas to use different prefixes.
micro-namespacing. I see.
makes sense.
Thanks for filling up some of my ignorance on these topics.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 17 Mar 2003 06:23, Stefano Mazzocchi wrote:
> > The JSR has not been made public but from the grapevine heres the scoop.
> > The metadata will be store in .class file as "class attributes". So it
> > will not require a JVM change but the utility files to load the metadata
> > will be in the next JVM. However that does not stop us developing our own
> > loader that parses the the .class files using BCEL.
>
> I see.
>
> But once you have that metadata inside your class, how are you going to
> find out something about it? introspection or direct bytecode manipulation?
direct bytecode manipulation pre jdk1.5. However we can also store metadata
side by side class and load via standard classloader.
> Those sounds much less elegant than any instanceof() calls. What am I
> missing?
you can include rich metadata in here that interfaces can't handle. ie You can
say method X is capable of being remoted, interface y is transaction aware,
component y takes a service using key A of type B but it is optional etc.
> > @meta Fortress{lifecycle="ThreadSafe"}
> > @fortress lifecycle="ThreadSafe"
> > @meta org.apache.avalon.fortress.FortressMetaData("ThreadSafe")
>
> Ok, makes sense.
>
> do you think this is going to be enough for the metadata needs you
> foresee? just curious.
Mostly. Somethings are ugly. Essentially it gets ugly when you nest metadata
greater than two levels and have repeating groups. However I have only needed
that once and after going through the dot.net stuff and following xdoclet
development I can see there is always work arounds. ie Rather than repeating
groups xdoclet tends to design their tag schemas to use different prefixes.
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote, On 19/03/2003 9.39:
> On Mon, 17 Mar 2003 18:32, Nicola Ken Barozzi wrote:
>
>>If I have logging in many places in my app, it means that I *need* it
>>there, like asserts... ever tried moving asserts outside of the code?
>
> yep. We did in Avalon actually. Theres quite a few Design-By-Constraints
> toolkits out there and I actually have a written a DBC interceptor that
> performs validation as appropriate.
Hmmm, I agree that doing that for pre+post conditions is possible
outside of the code, although I don't really lkie it that much, as I
would not like to have javadocs in a separate file.
But as for assertions that are inside the code? That is what I to
address: not doing it before and after a method, but inside.
Although one could argue that any method can be split up in smaller ones
that have their own pre+post assertions...
>>For me logging, asserts, etc I call them "concerns" rather than
>>"aspects". They are not part of the application architecture, but are a
>>common concern for all classes.
>
> Depends on the logging. System level logging, entrance to methods, or resource
> usage I would consider something controllable by AOP but domain level logging
> is different kettle of fish.
Yup.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 17 Mar 2003 18:32, Nicola Ken Barozzi wrote:
> If I have logging in many places in my app, it means that I *need* it
> there, like asserts... ever tried moving asserts outside of the code?
yep. We did in Avalon actually. Theres quite a few Design-By-Constraints
toolkits out there and I actually have a written a DBC interceptor that
performs validation as appropriate.
> For me logging, asserts, etc I call them "concerns" rather than
> "aspects". They are not part of the application architecture, but are a
> common concern for all classes.
Depends on the logging. System level logging, entrance to methods, or resource
usage I would consider something controllable by AOP but domain level logging
is different kettle of fish.
--
Cheers,
Peter Donald
*------------------------------------*
| God has no religion - Gandhi |
*------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote, On 17/03/2003 0.21:
> Nicola,
>
>>> Attributes is a bit quiet. I have a pending request to the list and
>>> CC the author about removal of commons-logging (it is only used for 1
>>> warning). I am plucking up courage to make teh commit.
>>
>> ;-))
>>
>> I'd commit it without remorse. Put yourself in the name of the
>> committers and commit it, it really makes no sense.
>
>
> Gulp. I lack the karma.
? Isn't it J-C-sandbox? Anyone can ask for commit karma and have it with
no questions asked. As for partecipating in codebases, well, it's a
sandbox... if noone replied, commit as per lazy consensus.
> That despite putting in a marathon pairing
> session with James Strachan, Joe Walnes, Charles Lowell, and Mike Royal
> at TW head office. James committer the patches other than the one
> Charles and I had done. A neat excercise in TDD and
>
>> BTW, I'm still thinking about the logging thing.
>>
>> Imagine that we have all logging calls done like this:
>>
>> //@log("hello log");
>
>
> As a comment? Or a javadoc tag generates into some type of attribute,
> then conditionally aspected into action. Neat.
Something like that... the fact is that AOP has a big problem, which is
the easiness of coding and maintaining the code.
AOP is cool for pre and post processing of methods, and for the
establishment of pluggable chains, but it looks like it already hit the
"everything is a nail" antipattern in some projects.
For example,IMHO logging is not a an aspect that is estraneous to the
initial source code.
If I have logging in many places in my app, it means that I *need* it
there, like asserts... ever tried moving asserts outside of the code?
Some call them unit tests ;-), but it's simply another use case.
For me logging, asserts, etc I call them "concerns" rather than
"aspects". They are not part of the application architecture, but are a
common concern for all classes.
Thus I see these embedded in code, instead of being specified elswhere,
but defined with a meta-language, that can be morphed at will at compile
time.
To make the classes compileable without concerns easily I put them in
comments. Not usual javadoc tags, because they pertain to methods or
classes. I want them to be part of the code.
I'm still thinking about implementation details, but the easiest way I
see now is Ant filtered copy with a special filterchain.
> I am actually leaning towards no-logging. AltRMI now does not depend on
> any logger. It has a monitor that can be added, and logging can adapt
> from that.
monitor... ?
>> we would have logging disabled by default, but we can transform the
>> class to use logging when running, and even transform the log calls to
>> make them compatible with the logging toolkit we want to use.
>
> Not quite sure how, unless I hit it on the head above.
The class is filtered for these before being compiled. I think also
about a special filter that adds a logging class for every package, so
it becomes the logging aggregator of that package.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
>> Attributes is a bit quiet. I have a pending request to the list and
>> CC the author about removal of commons-logging (it is only used for 1
>> warning). I am plucking up courage to make teh commit.
>
>
> ;-))
>
> I'd commit it without remorse. Put yourself in the name of the
> committers and commit it, it really makes no sense.
Gulp. I lack the karma. That despite putting in a marathon pairing
session with James Strachan, Joe Walnes, Charles Lowell, and Mike Royal
at TW head office. James committer the patches other than the one
Charles and I had done. A neat excercise in TDD and
> BTW, I'm still thinking about the logging thing.
>
> Imagine that we have all logging calls done like this:
>
> //@log("hello log");
As a comment? Or a javadoc tag generates into some type of attribute,
then conditionally aspected into action. Neat.
I am actually leaning towards no-logging. AltRMI now does not depend on
any logger. It has a monitor that can be added, and logging can adapt
from that.
> we would have logging disabled by default, but we can transform the
> class to use logging when running, and even transform the log calls to
> make them compatible with the logging toolkit we want to use.
Not quite sure how, unless I hit it on the head above.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>>BTW, I'm still thinking about the logging thing.
>>>Imagine that we have all logging calls done like this:
>>> //@log("hello log");
>>>we would have logging disabled by default, but we can transform the
>>>class to use logging when running
>>We do something similar in James with Ant, but the changes are at compile
>>time.
>Ahhh. Kewl - two jars for each package.
No, just one. In our case we use it with JVM detection so if you do a
source build you can get a build optimized for your JVM.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>>BTW, I'm still thinking about the logging thing.
>>Imagine that we have all logging calls done like this:
>> //@log("hello log");
>>we would have logging disabled by default, but we can transform the
>>class to use logging when running
>>
>>
>
>We do something similar in James with Ant, but the changes are at compile
>time.
>
Ahhh. Kewl - two jars for each package.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Tue, 18 Mar 2003 21:09, Stefano Mazzocchi wrote:
>
>>Peter Donald wrote:
>>
>>>On Tue, 18 Mar 2003 08:59, Peter Royal wrote:
>>>
>>>>>Rickard Oberg has something waiting in the wings too.
>>>>
>>>>what's he got up his sleeve?
>>>
>>>something very neat.
>>
>>c'mon, Peter, we are curious! :)
>
>
> Its all in his blog about 3-4 months ago.
>
> I think it is at http://www.dreambean.com/ but the site seems to be down atm.
Ok, thanks for the pointer.
>>>Unfortunately hes been promising to release it since
>>>december and hasn't yet ;(
>>
>>Would this be runtime based or compile-time?
>
>
> metadata is compiled in (though he has hooks for runtime metadata from
> database or whatever). But the interceptor chains are built up at runtime and
> you can easily add in or remove interceptors on the fly.
Ok, cool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, March 18, 2003, at 06:01 AM, Peter Donald wrote:
> On Tue, 18 Mar 2003 21:09, Stefano Mazzocchi wrote:
>> Peter Donald wrote:
>>> On Tue, 18 Mar 2003 08:59, Peter Royal wrote:
>>>>> Rickard Oberg has something waiting in the wings too.
>>>>
>>>> what's he got up his sleeve?
>>>
>>> something very neat.
>>
>> c'mon, Peter, we are curious! :)
>
> Its all in his blog about 3-4 months ago.
>
> I think it is at http://www.dreambean.com/ but the site seems to be
> down atm.
Near the bottom of the page here...
http://roller.anthonyeden.com/page/rickard?catname=Java
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 18 Mar 2003 21:09, Stefano Mazzocchi wrote:
> Peter Donald wrote:
> > On Tue, 18 Mar 2003 08:59, Peter Royal wrote:
> >>>Rickard Oberg has something waiting in the wings too.
> >>
> >>what's he got up his sleeve?
> >
> > something very neat.
>
> c'mon, Peter, we are curious! :)
Its all in his blog about 3-4 months ago.
I think it is at http://www.dreambean.com/ but the site seems to be down atm.
> > Unfortunately hes been promising to release it since
> > december and hasn't yet ;(
>
> Would this be runtime based or compile-time?
metadata is compiled in (though he has hooks for runtime metadata from
database or whatever). But the interceptor chains are built up at runtime and
you can easily add in or remove interceptors on the fly.
--
Cheers,
Peter Donald
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Tue, 18 Mar 2003 08:59, Peter Royal wrote:
>
>>>Rickard Oberg has something waiting in the wings too.
>>
>>what's he got up his sleeve?
>
>
> something very neat.
c'mon, Peter, we are curious! :)
> Unfortunately hes been promising to release it since
> december and hasn't yet ;(
Would this be runtime based or compile-time?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 18 Mar 2003 08:59, Peter Royal wrote:
> > Rickard Oberg has something waiting in the wings too.
>
> what's he got up his sleeve?
something very neat. Unfortunately hes been promising to release it since
december and hasn't yet ;(
--
Cheers,
Peter Donald
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Royal <pr...@apache.org>.
On Monday, March 17, 2003, at 04:45 PM, Paul Hammant wrote:
> You seen nanning?
I just heard about that one via javablogs the other day.. haven't dug
in..
> Rickard Oberg has something waiting in the wings too.
what's he got up his sleeve?
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Paul Hammant <Pa...@yahoo.com>.
Stefano
> Right, that's how almost everybody does aspect-oriented things today
> but code preprocessing is evil. Java cries for a little more aspect
> orientation but aspectj (or even worse hyperj) are simply too much.
You seen nanning? Rickard Oberg has something waiting in the wings too.
-ph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Stefano Mazzocchi wrote:
> Right, that's how almost everybody does aspect-oriented things today but
> code preprocessing is evil. Java cries for a little more aspect
> orientation but aspectj (or even worse hyperj) are simply too much.
>
> Nicola's approach sounds hacky as hell.
>
> What we need is a way to add multidimensionality (a-la namespace) to
> java code, but I can't figure out a way to do it without breaking the
> java syntax.
1) hack the bytecode. It's basically what MS has done with the CLR and
its gazillion (actually compatible) extensions, and it appears to be
where java is going, JSR 175 looking to be the first step. Waaaay behind
on .net though.
2) Alternatively, replace method calls with events (flyweights) and
layer AOP on top of OOP. Too slow in java.
3) define a finite number of aspects and support them using "aspect
marker" interfaces (enter: avalon! :D)
4) JNI. Won't even go into it :D
...
all potentiallly or by design hacky!
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Tue, 18 Mar 2003 20:55, Stefano Mazzocchi wrote:
>
>>One thing if for sure: the java syntax was not designed to be aspect
>>orientable. so every solution will be partially hacky. We have to accept
>>his until the new best-of-breed language comes around.
>
>
> I dunno. I think javadoc tags are perfect for the job of declaring metadata
> (which is an independent concern of aspects).
>
> Aspects are completely different and *may* choose to use the rich data, may be
> hardwired, may be application configured etc. I also prefer to have aspects
> at boundaries.
>
> Given that we are mainly doing COP that mostly occurs at interfaces which is
> perfect given that interceptors + dynamic proxies can fill that gap.
Agreed on the general concept that (metadata-capable) COP != AOP (can we
say that AOP extends COP? maybe not even that).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 18 Mar 2003 20:55, Stefano Mazzocchi wrote:
> One thing if for sure: the java syntax was not designed to be aspect
> orientable. so every solution will be partially hacky. We have to accept
> his until the new best-of-breed language comes around.
I dunno. I think javadoc tags are perfect for the job of declaring metadata
(which is an independent concern of aspects).
Aspects are completely different and *may* choose to use the rich data, may be
hardwired, may be application configured etc. I also prefer to have aspects
at boundaries.
Given that we are mainly doing COP that mostly occurs at interfaces which is
perfect given that interceptors + dynamic proxies can fill that gap.
--
Cheers,
Peter Donald
A right is not what someone gives you; it's what no one can take from you.
-- Ramsey Clark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 18 Mar 2003 21:00, Niclas Hedhman wrote:
> Or even to enforce a particular tool, such as UML, which embedd metadata in
> source comments, but present it in GUI?
I have found that if the metadata is human readable then marking up files is
by far the simplest solution. At some point you have to associate metadata
with classes - usually config files. But they are usually far more complex
than marking up .java files.
I know people who barely know what an EJB descriptor looks like but develope
them all the time via xdoclet ;)
--
Cheers,
Peter Donald
He strains to hear a whisper who refuses to hear a shout.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 20 Mar 2003 20:32, Niclas Hedhman wrote:
> On Thursday 20 March 2003 16:28, Peter Donald wrote:
> > On Thu, 20 Mar 2003 15:14, Niclas Hedhman wrote:
> > > Also, if you are requiring me to have dedicated Ant tasks (not
> > > everybody builds with Ant (strangely enough)) to be used when I develop
> > > my Avalon blocks/components, then you ARE raising the bar
> > > significantly.
> >
> > whether it is ant tasks, commandline tools or maven plugins most people
> > use tools of one sort or another so I don't see that as a major barrier
> > of entry. In JDK1.5 it will be part of javac so then there will be 0
> > changes.
>
> Maybe you are more dense than I thought.
hmmm.
> Every project, looked at only from the perspective of such project, have a
> list of "Because..." a particular "oddity" should come to life and it is
> often hard to come up with counter-argument.
> The members of such project are so "self-occupied" (not trying to be rude,
> just don't have a better word at the moment ) that they don't see the
> "bigger picture".
heh - the bigger picture is that this is the way all major technical paths
look like going via ADD. It is native in C#, will be in Java and most major
technical
> Finally, your assumption that JSR-175 will be included in JSR-176 is
> perhaps a bit pre-mature. JSR-176 sure lists itself as targetting Tiger,
> but JSR-176 doesn't list 175.
Given the political context in which it is developed I doubt it will not be
part of Tiger. Especially given that the lead is one hell of a doer.
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 20 March 2003 16:28, Peter Donald wrote:
> On Thu, 20 Mar 2003 15:14, Niclas Hedhman wrote:
> > Also, if you are requiring me to have dedicated Ant tasks (not everybody
> > builds with Ant (strangely enough)) to be used when I develop my Avalon
> > blocks/components, then you ARE raising the bar significantly.
>
> whether it is ant tasks, commandline tools or maven plugins most people use
> tools of one sort or another so I don't see that as a major barrier of
> entry. In JDK1.5 it will be part of javac so then there will be 0 changes.
Maybe you are more dense than I thought.
_I_ am saying that _I_ am shying away from projects (including EJB ;o) ) that
are adding tools, concepts, quirks, you name it, not part of my standard
"toolkit". _My_ toolkit is very small, KISS.
Every project, looked at only from the perspective of such project, have a
list of "Because..." a particular "oddity" should come to life and it is
often hard to come up with counter-argument.
The members of such project are so "self-occupied" (not trying to be rude,
just don't have a better word at the moment ) that they don't see the "bigger
picture".
_My_ bigegr picture is that _I_ am writing code utilizing/interfacing with;
* UML
* EJB
* Kodo
* Servlets
* Netbeans
* Avalon
* Cocoon
* Batik
* kXML-RPC
* jUnit
* Log4J
* (possibly forgot some)
Do you really think I wouldn't mind having one extra tool for each of those?
(I'm sure that other "commercial" developers has lists just as long or
longer.)
There is also a difference between the "project requires" (and comes with) a
tool to build the distro, vs forcing upon me tools, to be able to develop
against that project. Netbeans for instance has several (never bother to
check how many) Ant tasks part of its build process, but I don't need them to
make _my_ things work, and they are not part of _my_ build process.
Finally, your assumption that JSR-175 will be included in JSR-176 is perhaps a
bit pre-mature. JSR-176 sure lists itself as targetting Tiger, but JSR-176
doesn't list 175.
Also, the @ use has not been specified as an "absolute" and the JSR is to
investigate the options available.
An extremely self-centered, self-occupied PITA Avaloner, who doesn't
understand complex stuff, is signing-off ;o)
Enjoy life !!!
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 20 Mar 2003 15:14, Niclas Hedhman wrote:
> > Metadata makes the components easier to use, deploy and maintain. You
> > could store it outside the components in config files but then you have
> > to make sure multiple artefacts keep in sync. Having the config files
> > generated from the source (or baked in) makes maintainence simple. Best
> > place to document code is with the code and metadata is just aform of
> > documentation.
>
> We live in an XML world (or at least I do), and having a "unified" XML Meta
> description document, that can be transformed (for compatibility reasons?)
> to each containers requirement, sounds a lot easier to me...
Doesn't to me.
The trend of technology is to add them in. Witness C# and its
incorporation of ADD, witness the success of xdoclet, ejbdoclet etc (Do you
know of anyone who still hand codes EJBs?). Most development technology has
been moving towards self documenting code.
> Especially considering the @tags already in some of my source, from UML and
> JDO (Kodo). It is outright ugly, and after specified (hardly every up for
> change), just occupies vasts amount of precious screen space. Easily get
> half the screen of @tag lines.
so - Its a crap implementation then ;)
Have you looked at ADD (either XDoclet or C#)?
> Also, if you are requiring me to have dedicated Ant tasks (not everybody
> builds with Ant (strangely enough)) to be used when I develop my Avalon
> blocks/components, then you ARE raising the bar significantly.
whether it is ant tasks, commandline tools or maven plugins most people use
tools of one sort or another so I don't see that as a major barrier of entry.
In JDK1.5 it will be part of javac so then there will be 0 changes.
--
Cheers,
Peter Donald
*----------------------------------------------------*
| "the mother of idiots is always pregnant." |
*----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Wednesday 19 March 2003 16:53, Peter Donald wrote:
> On Wed, 19 Mar 2003 14:08, Niclas Hedhman wrote:
> > I, for one, like to keep things simple and understandable. I don't favour
> > "essential information" hidden in comments, in a parser friendly format.
>
> Where do you want it put?
>
> Metadata makes the components easier to use, deploy and maintain. You could
> store it outside the components in config files but then you have to make
> sure multiple artefacts keep in sync. Having the config files generated
> from the source (or baked in) makes maintainence simple. Best place to
> document code is with the code and metadata is just aform of documentation.
We live in an XML world (or at least I do), and having a "unified" XML Meta
description document, that can be transformed (for compatibility reasons?) to
each containers requirement, sounds a lot easier to me...
Especially considering the @tags already in some of my source, from UML and
JDO (Kodo). It is outright ugly, and after specified (hardly every up for
change), just occupies vasts amount of precious screen space. Easily get half
the screen of @tag lines.
Also, if you are requiring me to have dedicated Ant tasks (not everybody
builds with Ant (strangely enough)) to be used when I develop my Avalon
blocks/components, then you ARE raising the bar significantly.
I'm pretty new to Avalon (apart from being used in Cocoon), and it has been a
breeze to start developing components. If I had to get Ant tasks to work for
my builds, I would probably have turned at the doorway.
Step out of your boxes and look at it from the 3rdParty person's POV. The
world don't center around Avalon "core components", and for Avalon to really
take off, we need a friendlier entry point, and XML is (today) a lot
friendlier and more accepted, than "yet-another-semi-obscure-@-tagset" in
comments.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 19 Mar 2003 14:08, Niclas Hedhman wrote:
> > Well, this is because this thread is very much diluted into an 'how to
> > do AOP in java' which has only very little to do with the title.
>
> So, the question is then, is this the right forum for it? Should Avalon
> "invent" these approaches, with the possibility that "a new brave world"
> are arriving around the corner?
Nope. Theres plenty of people outside Avalon who have been doing it longer and
know better.
> I, for one, like to keep things simple and understandable. I don't favour
> "essential information" hidden in comments, in a parser friendly format.
Where do you want it put?
Metadata makes the components easier to use, deploy and maintain. You could
store it outside the components in config files but then you have to make
sure multiple artefacts keep in sync. Having the config files generated from
the source (or baked in) makes maintainence simple. Best place to document
code is with the code and metadata is just aform of documentation.
--
Cheers,
Peter Donald
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Wednesday 19 March 2003 01:45, Stefano Mazzocchi wrote:
> Niclas Hedhman wrote:
> > Or even to enforce a particular tool, such as UML, which embedd metadata
> > in source comments, but present it in GUI?
>
> Pfff, you won't hear that suggestion from me.
Maybe the sarcasm wasn't strong enough ;o)
> > No matter which approach, it is IMHO very "awkward", and raises the bar
> > for newcomers to a project by a magnitude or two, as a new completely
> > foreign concept has to be assimilated (in parallel with the codebase
> > itself) by such individual. KISS ;o)
>
> I bet the people first proposing object orientation in a world of C
> coders had to face the same comments :)
Yes, probably, but I doubt Bjarne "invented" C++ constructs (and created a C++
-> C compiler) half way into a project/product.
More likely, he saw the light, stepped away and elaborated on the subject with
peers, and then wrote a book.
> Well, this is because this thread is very much diluted into an 'how to
> do AOP in java' which has only very little to do with the title.
So, the question is then, is this the right forum for it? Should Avalon
"invent" these approaches, with the possibility that "a new brave world" are
arriving around the corner?
I, for one, like to keep things simple and understandable. I don't favour
"essential information" hidden in comments, in a parser friendly format. Kodo
is using this, TogetherSoft (UML) is using this, Javadoc sure, now Avalon,
later another dozen technologies, and we may have a mess beyond explaination.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Tuesday 18 March 2003 17:55, Stefano Mazzocchi wrote:
>
>> /*+ */ --> metadata
>>
>>[there is no single-line metadata comment]
>>
>> //[...] --> single-line AOP
>> /*[...] */ --> multiple-line AOP
>>
>>where [...] is the aspect associated with it
>>
>> - o -
>>
>>the above would, for example, solve the current cocoon issues with
>>making the flow and the instrumentation modular.
>>
>>and could well be implemented with a code prepreprocessor.
>>
>>but there is something in the back of my mind that keeps setting my
>>elegance alarms off and I don't know what this is.
>>
>>One thing if for sure: the java syntax was not designed to be aspect
>>orientable. so every solution will be partially hacky. We have to accept
>>his until the new best-of-breed language comes around.
>
>
> What is the difference between "language hacks in comments" with its
> special-purpose compiler AND using aspect-orientation (or other
> non-mainstream) languages?
If a language syntax is designed around a particular feature, the
overall impression is elegance. Otherwise, the impression is hacky-ness.
> Or even to enforce a particular tool, such as UML, which embedd metadata in
> source comments, but present it in GUI?
Pfff, you won't hear that suggestion from me.
> No matter which approach, it is IMHO very "awkward", and raises the bar for
> newcomers to a project by a magnitude or two, as a new completely foreign
> concept has to be assimilated (in parallel with the codebase itself) by such
> individual. KISS ;o)
I bet the people first proposing object orientation in a world of C
coders had to face the same comments :)
> Just 0.02sen of ME not being able to comprehend the full extent of this
> proposal.
Well, this is because this thread is very much diluted into an 'how to
do AOP in java' which has only very little to do with the title.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Tuesday 18 March 2003 17:55, Stefano Mazzocchi wrote:
> /*+ */ --> metadata
>
> [there is no single-line metadata comment]
>
> //[...] --> single-line AOP
> /*[...] */ --> multiple-line AOP
>
> where [...] is the aspect associated with it
>
> - o -
>
> the above would, for example, solve the current cocoon issues with
> making the flow and the instrumentation modular.
>
> and could well be implemented with a code prepreprocessor.
>
> but there is something in the back of my mind that keeps setting my
> elegance alarms off and I don't know what this is.
>
> One thing if for sure: the java syntax was not designed to be aspect
> orientable. so every solution will be partially hacky. We have to accept
> his until the new best-of-breed language comes around.
What is the difference between "language hacks in comments" with its
special-purpose compiler AND using aspect-orientation (or other
non-mainstream) languages?
Or even to enforce a particular tool, such as UML, which embedd metadata in
source comments, but present it in GUI?
No matter which approach, it is IMHO very "awkward", and raises the bar for
newcomers to a project by a magnitude or two, as a new completely foreign
concept has to be assimilated (in parallel with the codebase itself) by such
individual. KISS ;o)
Just 0.02sen of ME not being able to comprehend the full extent of this
proposal.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 18/03/2003 10.55:
> Nicola Ken Barozzi wrote:
>
>> What is so eeevil about it? What makes javadoc tags as attributes much
>> better?
...
> I would be proposing to *namespace* comments, so
> that we have a easily parserable way to separate concern areas in the
> syntax.
>
> so
>
> // --> single line comment
>
> /* */ --> multiple line comment
>
> would be general comments
>
> /** */ --> javadoc comment
>
> [there is no single-line javadoc comment]
>
> /*+ */ --> metadata
>
> [there is no single-line metadata comment]
>
> //[...] --> single-line AOP
> /*[...] */ --> multiple-line AOP
>
> where [...] is the aspect associated with it
Hey, that's the same thinbg I'm saying :-D
You said
//[...] --> single-line AOP
/*[...] */ --> multiple-line AOP
I said
//@... --> single-line AOP
/*@... */ --> multiple-line AOP
Just syntax ;-)
> - o -
>
> the above would, for example, solve the current cocoon issues with
> making the flow and the instrumentation modular.
For instrumentation, I agree. For the flow, I'm not sure. Actually I
tend to think it's not so.
> and could well be implemented with a code prepreprocessor.
Yup.
> but there is something in the back of my mind that keeps setting my
> elegance alarms off and I don't know what this is.
Zut zut, the problem is that multidimensionality is always inelegant to
map do 2d.
We could make relational source codes, (like relational dbs WS flat
table or trees), but then we would need a special editor for them, etc
etc and it would become a mess.
> One thing if for sure: the java syntax was not designed to be aspect
> orientable. so every solution will be partially hacky. We have to accept
> his until the new best-of-breed language comes around.
Which I still do not see BTW.
See, it's not se eeevil after all ;-P
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> What is so eeevil about it? What makes javadoc tags as attributes much
> better?
Nono, I think that using javadoc tags for metadata just as hacky. It's
horrible.
Java got polluted the day when the compiler looked into javadoc tags to
find out if a method is deprecated.
SoC is not something the java architects were to clean about after 1.0
was nailed down.
This is why, at least, I would be proposing to *namespace* comments, so
that we have a easily parserable way to separate concern areas in the
syntax.
so
// --> single line comment
/* */ --> multiple line comment
would be general comments
/** */ --> javadoc comment
[there is no single-line javadoc comment]
/*+ */ --> metadata
[there is no single-line metadata comment]
//[...] --> single-line AOP
/*[...] */ --> multiple-line AOP
where [...] is the aspect associated with it
- o -
the above would, for example, solve the current cocoon issues with
making the flow and the instrumentation modular.
and could well be implemented with a code prepreprocessor.
but there is something in the back of my mind that keeps setting my
elegance alarms off and I don't know what this is.
One thing if for sure: the java syntax was not designed to be aspect
orientable. so every solution will be partially hacky. We have to accept
his until the new best-of-breed language comes around.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote, On 18/03/2003 0.19:
>>why can't the compiler do it? Taht would be a cool AOPed compiler.
>>Imagine that we feed the compiler a filesystem that has file
>>requests intercepted by filters... an extensible compiler! ;-)
>
>
> See OpenJava: http://openjava.sourceforge.net/.
Yes, I've seen it, thanks. It looks like one of the most complete
preprocessing systems. I've also looked at EPP, Jaco, and others.
It seems to me that this project is far more complete and comprehensive
than the idea I'm playing with. I also don't want the java code to be
incompatible with normal compilers (hence the comment), and to KISS
there should be no info to the processor on the context of the file,
just what pertains to it. It's up to the programmer to ensure that
references to objects are correct.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
> why can't the compiler do it? Taht would be a cool AOPed compiler.
> Imagine that we feed the compiler a filesystem that has file
> requests intercepted by filters... an extensible compiler! ;-)
See OpenJava: http://openjava.sourceforge.net/.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 17/03/2003 22.09:
> Noel J. Bergman wrote:
>
>>> BTW, I'm still thinking about the logging thing.
>>> Imagine that we have all logging calls done like this:
>>> //@log("hello log");
>>> we would have logging disabled by default, but we can transform the
>>> class to use logging when running
>>
>>
>> We do something similar in James with Ant, but the changes are at compile
>> time.
>
>
> Right, that's how almost everybody does aspect-oriented things today but
> code preprocessing is evil.
Not evil, just evilly done. Copying sources just to filter... why can't
the compiler do it? Taht would be a cool AOPed compiler. Imagine that we
feed the compiler a filesystem that has file requests intercepted by
filters... an extensible compiler! ;-)
> Java cries for a little more aspect
> orientation but aspectj (or even worse hyperj) are simply too much.
>
> Nicola's approach sounds hacky as hell.
Ha :-D
> What we need is a way to add multidimensionality (a-la namespace) to
> java code, but I can't figure out a way to do it without breaking the
> java syntax.
Hey, that's what I am doing! :-PPP
really-Poor-man AOP? Sure. Like javadoc tags are really-Poor-man attributes.
Seriously, think about it a minute.
Aspectj AOP says that their AOP it's good for logging, which is
generally *wrong*.
Aspects like logging are nice to do what there is a /pattern/ in code
that can be more syntetically be described by AOPish definitions. But if
you don't have the way of making it more generic, you will just move the
same code out of the file and just point to the source to where it must
be called.
We cannot use interceptors. There are two types of interceptors,
interceptors that are called when an object is constructed and
interceptors that are called when methods are called, but none can
easily map log calls to *parts* of a method.
So I asked myself: what system is there that makes these aspects not
make java code inconpatible with normal java compilers? Comments.
Then how do we make these logs easily expressible. Put them where they
belong, in teh code.
Finally, how to make java compile them? Use pre-filtering of the class
files. This can be done in Ant filtered copies for a prototype, but the
goal is to add this to the Eclipse compiler so it happens without
needing copying files.
What is so eeevil about it? What makes javadoc tags as attributes much
better?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Noel J. Bergman wrote:
>>BTW, I'm still thinking about the logging thing.
>>Imagine that we have all logging calls done like this:
>> //@log("hello log");
>>we would have logging disabled by default, but we can transform the
>>class to use logging when running
>
>
> We do something similar in James with Ant, but the changes are at compile
> time.
Right, that's how almost everybody does aspect-oriented things today but
code preprocessing is evil. Java cries for a little more aspect
orientation but aspectj (or even worse hyperj) are simply too much.
Nicola's approach sounds hacky as hell.
What we need is a way to add multidimensionality (a-la namespace) to
java code, but I can't figure out a way to do it without breaking the
java syntax.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
> BTW, I'm still thinking about the logging thing.
> Imagine that we have all logging calls done like this:
> //@log("hello log");
> we would have logging disabled by default, but we can transform the
> class to use logging when running
We do something similar in James with Ant, but the changes are at compile
time.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> Imagine that we have all logging calls done like this:
>
> //@log("hello log");
>
> we would have logging disabled by default, but we can transform the
> class to use logging when running, and even transform the log calls to
> make them compatible with the logging toolkit we want to use.
really-Poor-man AOP?
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote, On 17/03/2003 0.03:
> Nicola,
>
>> http://jakarta.apache.org/commons/sandbox/attributes/usage.html
>
> Attributes is a bit quiet. I have a pending request to the list and CC
> the author about removal of commons-logging (it is only used for 1
> warning). I am plucking up courage to make teh commit.
;-))
I'd commit it without remorse. Put yourself in the name of the
committers and commit it, it really makes no sense.
BTW, I'm still thinking about the logging thing.
Imagine that we have all logging calls done like this:
//@log("hello log");
we would have logging disabled by default, but we can transform the
class to use logging when running, and even transform the log calls to
make them compatible with the logging toolkit we want to use.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
> http://jakarta.apache.org/commons/sandbox/attributes/usage.html
Attributes is a bit quiet. I have a pending request to the list and CC
the author about removal of commons-logging (it is only used for 1
warning). I am plucking up courage to make teh commit.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote, On 16/03/2003 23.25:
>
> Stefano Mazzocchi wrote, On 16/03/2003 20.23:
...
>> But once you have that metadata inside your class, how are you going
>> to find out something about it? introspection or direct bytecode
>> manipulation?
>
> ...but how does one read it?
>
> I'd assume that one would read them with the Class 'class'.
I'll also add that also in Jakarta Commons there are already two
projects that work on this: attributes and clazz.
http://jakarta.apache.org/commons/sandbox/attributes/usage.html
http://jakarta.apache.org/commons/sandbox/clazz/overview.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 16/03/2003 20.23:
> Peter Donald wrote:
>
>> On Sat, 15 Mar 2003 05:51, Stefano Mazzocchi wrote:
...
>>> This is a totally different argument. Can you outline here how the
>>> metadata concept is going to work for JSR 175? would that require a JVM
>>> change?
>>
>> The JSR has not been made public but from the grapevine heres the
>> scoop. The metadata will be store in .class file as "class
>> attributes". So it will not require a JVM change but the utility files
>> to load the metadata will be in the next JVM. However that does not
>> stop us developing our own loader that parses the the .class files
>> using BCEL.
>
> I see.
I don't ;-)
Ok, so I've looked in the JVM spec and now I understand what it means.
Here is what class "attributes" are:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#43817
"
All attributes have the following general format:
attribute_info {
u2 attribute_name_index;
u4 attribute_length;
u1 info[attribute_length];
}
"
"
Certain attributes are predefined as part of the class file
specification. The predefined attributes are the SourceFile (§4.7.7),
ConstantValue (§4.7.2), Code (§4.7.3), Exceptions (§4.7.4), InnerClasses
(§4.7.5), Synthetic (§4.7.6), LineNumberTable (§4.7.8),
LocalVariableTable (§4.7.9), and Deprecated (§4.7.10) attributes. Within
the context of their use in this specification, that is, in the
attributes tables of the class file structures in which they appear, the
names of these predefined attributes are reserved.
"
"
Java virtual machine implementations are required to silently ignore
attributes they do not recognize.
For instance, defining a new attribute to support vendor-specific
debugging is permitted. Because Java virtual machine implementations are
required to ignore attributes they do not recognize, class files
intended for that particular Java virtual machine implementation will be
usable by other implementations even if those implementations cannot
make use of the additional debugging information that the class files
contain.
"
Ok, so this means that it's easy to add metadata to the .class files...
> But once you have that metadata inside your class, how are you going to
> find out something about it? introspection or direct bytecode manipulation?
...but how does one read it?
I'd assume that one would read them with the Class 'class'.
[RT] BTW, there are attributes that give line numbers in the original
source file (4.7.8 The LineNumberTable Attribute)... so we could
manipulate the class files to refer to the original xml files of XSPs [/RT]
> Those sounds much less elegant than any instanceof() calls. What am I
> missing?
>
>> However from what I understand that the metadata will be extracted
>> from javadocs. A few different proposals have been made but I am not
>> sure what they will pick. Some proposals IIRC are
>>
>> @meta Fortress{lifecycle="ThreadSafe"}
>> @fortress lifecycle="ThreadSafe"
>> @meta org.apache.avalon.fortress.FortressMetaData("ThreadSafe")
>
>
> Ok, makes sense.
>
> do you think this is going to be enough for the metadata needs you
> foresee? just curious.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Sat, 15 Mar 2003 05:51, Stefano Mazzocchi wrote:
>
>>>The main call against that is that it is not what everyone else uses or
>>>supports.
>>
>>Are you getting shy at forking projects for elegance's sake, I can't
>>believe it :)
>
>
> Of course not :)
Damn, I thought you learned something during all these phases.
> It is just way too massive an undertaking. XDoclet / qdox /
> vdoclet have already put many man years into development so I want to reuse
> their stuff.
But probably you did, you just don't want to admit it :)
>>>People have already developed parsers, validators, editors and heaps of
>>>other tools to work with these formats which is not something we can even
>>>get close to getting as comprehensive support for a custom format.
>>
>>Oh, please, that's not an argument.
>
>
> sure its is ... or to put it another way - Are you volunteering? :)
Don't get me wrong, I see your point, but I think that writing a
parser/validator for that stuff is *really* piece of cake. As for
editors and IDE support, they will follow what the market will follow,
see Ant.
>>>Add in the fact that JSR175 will probably use javadoc based metadata and
>>>I don't think there is support for a custom format.
>>
>>This is a totally different argument. Can you outline here how the
>>metadata concept is going to work for JSR 175? would that require a JVM
>>change?
>
>
> The JSR has not been made public but from the grapevine heres the scoop. The
> metadata will be store in .class file as "class attributes". So it will not
> require a JVM change but the utility files to load the metadata will be in
> the next JVM. However that does not stop us developing our own loader that
> parses the the .class files using BCEL.
I see.
But once you have that metadata inside your class, how are you going to
find out something about it? introspection or direct bytecode manipulation?
Those sounds much less elegant than any instanceof() calls. What am I
missing?
> However from what I understand that the metadata will be extracted from
> javadocs. A few different proposals have been made but I am not sure what
> they will pick. Some proposals IIRC are
>
> @meta Fortress{lifecycle="ThreadSafe"}
> @fortress lifecycle="ThreadSafe"
> @meta org.apache.avalon.fortress.FortressMetaData("ThreadSafe")
Ok, makes sense.
do you think this is going to be enough for the metadata needs you
foresee? just curious.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 15 Mar 2003 05:51, Stefano Mazzocchi wrote:
> > The main call against that is that it is not what everyone else uses or
> > supports.
>
> Are you getting shy at forking projects for elegance's sake, I can't
> believe it :)
Of course not :) It is just way too massive an undertaking. XDoclet / qdox /
vdoclet have already put many man years into development so I want to reuse
their stuff.
> > People have already developed parsers, validators, editors and heaps of
> > other tools to work with these formats which is not something we can even
> > get close to getting as comprehensive support for a custom format.
>
> Oh, please, that's not an argument.
sure its is ... or to put it another way - Are you volunteering? :)
> > Add in the fact that JSR175 will probably use javadoc based metadata and
> > I don't think there is support for a custom format.
>
> This is a totally different argument. Can you outline here how the
> metadata concept is going to work for JSR 175? would that require a JVM
> change?
The JSR has not been made public but from the grapevine heres the scoop. The
metadata will be store in .class file as "class attributes". So it will not
require a JVM change but the utility files to load the metadata will be in
the next JVM. However that does not stop us developing our own loader that
parses the the .class files using BCEL.
However from what I understand that the metadata will be extracted from
javadocs. A few different proposals have been made but I am not sure what
they will pick. Some proposals IIRC are
@meta Fortress{lifecycle="ThreadSafe"}
@fortress lifecycle="ThreadSafe"
@meta org.apache.avalon.fortress.FortressMetaData("ThreadSafe")
--
Cheers,
Peter Donald
*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It |
| just happens to be selective on who it makes friendship |
| with. |
| - Richard Cook |
*---------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Fri, 14 Mar 2003 22:52, Stefano Mazzocchi wrote:
>
>>Peter Donald wrote:
>>
>>>The last six months I have been developing a container that extracts all
>>>metadata from attributes/javadoc tags (similar to commons-attributes,
>>>dot.net attributes or the various interceptor frameworks). So it would
>>>end up being specified by something like
>>>
>>>/**
>>> * @fortress.lifecycle name="ThreadSafe"
>>> */
>>>public class MyComponent {}
>>
>>Sounds cool.
>>
>>What about specifying a different comment namespace rather than the
>>javadoc one and use an xml syntax instead of the
>>soon-to-be-too-simple-for-the-purpose javadoc one?
>
>
> The main call against that is that it is not what everyone else uses or
> supports.
Are you getting shy at forking projects for elegance's sake, I can't
believe it :)
> XDoclet (xdoclet.sf.net) is fairly pervasive through most enterprise
> developers and if they had ever managed to get stable would have dominated
> the whole landscape. They didn't and a whole crop of other toolkits cropped
> up such as qdox.sf.net (which we already use) or vdoclet, or ejbdoclet etc
It doesn't surprise me at all.
> People have already developed parsers, validators, editors and heaps of other
> tools to work with these formats which is not something we can even get close
> to getting as comprehensive support for a custom format.
Oh, please, that's not an argument. I'm talking about XML inside some
special comment tags. I can write a parser for that in half an hour and
tools, well, tools emerge after technology is used, only microsoft does
the other way around.
> Add in the fact that JSR175 will probably use javadoc based metadata and I
> don't think there is support for a custom format.
This is a totally different argument. Can you outline here how the
metadata concept is going to work for JSR 175? would that require a JVM
change?
> Though it would make documentation of all that easier :)
And not only that.
> However I have never come across a case where the metadata was incapable of
> representing what I wanted
This is another good argument.
> it may be clumsy at times but still useful.
> Check out MSDN docs on dot.net attributes or the xdoclet website.
I will.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 22:52, Stefano Mazzocchi wrote:
> Peter Donald wrote:
> > The last six months I have been developing a container that extracts all
> > metadata from attributes/javadoc tags (similar to commons-attributes,
> > dot.net attributes or the various interceptor frameworks). So it would
> > end up being specified by something like
> >
> > /**
> > * @fortress.lifecycle name="ThreadSafe"
> > */
> > public class MyComponent {}
>
> Sounds cool.
>
> What about specifying a different comment namespace rather than the
> javadoc one and use an xml syntax instead of the
> soon-to-be-too-simple-for-the-purpose javadoc one?
The main call against that is that it is not what everyone else uses or
supports.
XDoclet (xdoclet.sf.net) is fairly pervasive through most enterprise
developers and if they had ever managed to get stable would have dominated
the whole landscape. They didn't and a whole crop of other toolkits cropped
up such as qdox.sf.net (which we already use) or vdoclet, or ejbdoclet etc
People have already developed parsers, validators, editors and heaps of other
tools to work with these formats which is not something we can even get close
to getting as comprehensive support for a custom format.
Add in the fact that JSR175 will probably use javadoc based metadata and I
don't think there is support for a custom format. Though it would make
documentation of all that easier :)
However I have never come across a case where the metadata was incapable of
representing what I wanted - it may be clumsy at times but still useful.
Check out MSDN docs on dot.net attributes or the xdoclet website.
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> The last six months I have been developing a container that extracts all
> metadata from attributes/javadoc tags (similar to commons-attributes, dot.net
> attributes or the various interceptor frameworks). So it would end up being
> specified by something like
>
> /**
> * @fortress.lifecycle name="ThreadSafe"
> */
> public class MyComponent {}
Sounds cool.
What about specifying a different comment namespace rather than the
javadoc one and use an xml syntax instead of the
soon-to-be-too-simple-for-the-purpose javadoc one?
/*+
| <avalon:metadata xmlns="http://apache.org/avalon/matadata/1.0">
| <avalon:lifecycle name="ThreadSafe"/>
| </avalon:metadata>
+*/
That gives you:
1) complete Soc between javadoc comments
2) complete SoC between code and attributes
3) versioning of the metadata schema (thru namespace URI identify)
that will ease transition in the future
4) complete visual separation between javadocs and object metadata
5) easier to automate in editors (due to #5)
what do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 09:10, Noel J. Bergman wrote:
> So you are promoting a flexibile metadata approach derived from the
> component source files?
I would promote a extensible metadata approach but are less concerned about
flexability except at a few important join points - in particular the
mechanism via which metadata is loaded should be relatively flexible. One of
my friends is currently loading metadata from a database (yikes!) and thinks
that is the ants pants because of ability to centrally manage this.
But then again I tend to consider metadata that needs to be managed as
configuration rather than type information and thus probably should not be
stored with component as such or maybe via some other mechanism.
Marking up metadata in source files is definetly my preferred approach but
there is plenty of other mechanisms that are valid.
> Do you propose a tool and standard manifest format
> so that a jar can carry metadata related to its components?
I will eventually when I find one I like. A standard manifest format is going
to be harder to do given the broad range of resources usually stored in jars.
However it would be more than possible to have to get a stop gap measure in
that just stored classnames of components.
> > The last six months I have been developing a container that extracts all
> > metadata from attributes/javadoc tags (similar to commons-attributes,
> > dot.net attributes or the various interceptor frameworks). So it would
> > end up being specified by something like
> >
> > @fortress.lifecycle name="ThreadSafe"
>
> Is it necessary for the container name to be part of the tag? How do I
> declare the metadata to be more portable between containers? Or am I
> misunderstanding the tag semantics?
The tags can be whatever you want. Very little of it is cross container though
hence they should stay in container specific or domain specific namespaces.
ie altrmi.* is for altrmi stuff, fortress.* for fortress stuff etc.
I used to have some docs up on the website but it looks like someone
disapeared them.
You can see the source of the docs in avalon-sandbox/info. Have a look at
doclet.xml and you will see a bunch of tags that define common meta data for
resources required and offered by the component. It does not define the full
set but it does define a common subset.
Also look to features.xml and you will see the mechanism by which extensions
are added and required. So a component can declare that it requires
"fortress" semantics present to run and will optionally use "altrmi" features
if present.
The info docs are relatively old and crusty but there is a bit in there that I
will eventually harvest again.
> Also, is there a mechanism for components to modify the container
> lifecycle, e.g., to add new lifecycle methods that are managed by container
> extensions?
In my system - yep. Hell - the components don't even have to be Avalon
components, they can be RMI objects, JMX objects or some custom lifecycle
objects. They can be any objects from any system that I can see. Just another
interceptor chain. Avalon is justa an implementation detail.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Noel J. Bergman wrote:
> Given the fact that no one has yet to
> release a processor with an ego pipeline, let's stick to the 1s and 0s.
Oh, I'm writing this down, this is beautiful. Thanks :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
> If such concepts exist then they will be specified by metadata of some
sort.
> Could be like fortress with per assembly metadata or like Phoenix with per
> component metadata.
So you are promoting a flexibile metadata approach derived from the
component source files? Do you propose a tool and standard manifest format
so that a jar can carry metadata related to its components?
> The last six months I have been developing a container that extracts all
> metadata from attributes/javadoc tags (similar to commons-attributes,
> dot.net attributes or the various interceptor frameworks). So it would
> end up being specified by something like
> @fortress.lifecycle name="ThreadSafe"
Is it necessary for the container name to be part of the tag? How do I
declare the metadata to be more portable between containers? Or am I
misunderstanding the tag semantics?
Also, is there a mechanism for components to modify the container lifecycle,
e.g., to add new lifecycle methods that are managed by container extensions?
> For Selectors that take strings then hopefully
> lookup( Blah.ROLE + "/Selector" ).get( "foo" );
> will be replaced by
> lookup( Blah.ROLE + "/foo" );
Can we please have some terse and pithy technical discussion related to
Peter's proposal vs. the existing proposal put forth by Berin, Stephen, et
al?
Please remember that technical assessments require proper justification. To
preempt a repeat of earlier conversational patterns, let me note in advance
that words like "interface", "metadata", "flexible", "reentrant",
"performance", "overhead", or even "flawed" are descriptive. Words like
"sucks" and "stupid" are inappropriate; they may be emotionally satisfying,
but are hardly technical in nature. Given the fact that no one has yet to
release a processor with an ego pipeline, let's stick to the 1s and 0s.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 13 Mar 2003 00:28, Jason van Zyl wrote:
> So marker interfaces like ThreadSafe? So handlers will be specified via
> configuration like in Fortress with the specification of a handler?
If such concepts exist then they will be specified by metadata of some sort.
Could be like fortress with per assembly metadata or like Phoenix with per
component metadata.
The last six months I have been developing a container that extracts all
metadata from attributes/javadoc tags (similar to commons-attributes, dot.net
attributes or the various interceptor frameworks). So it would end up being
specified by something like
/**
* @fortress.lifecycle name="ThreadSafe"
*/
public class MyComponent {}
> If the Selector interfaces are going to be deprecated what will replace
> them?
For Selectors that take strings then hopefully
lookup( Blah.ROLE + "/Selector" ).get( "foo" );
will be replaced by
lookup( Blah.ROLE + "/foo" );
For non string based selectors they should be implemented as specific
"Manager" objects like.
interface BlahManager
{
Blah getManager(....);
void releaseManager(Manager);
}
> Just curious as I want to keep Plexus current. We added Selector goodies
> in not knowing they would be deprecated along with a default selector
> mechanism. How will one grab a specific implementation among many now?
Hopefully array and map dependencies will also be more widely adopted. ie
(Blah[])lookup( Blah.ROLE + "[]" );
(Map)lookup( Blah.ROLE + "{}" ); //returns a map of name to service
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Jason van Zyl wrote:
> On Wed, 2003-03-12 at 05:35, Peter Donald wrote:
>
>
> So marker interfaces like ThreadSafe? So handlers will be specified via
> configuration like in Fortress with the specification of a handler?
Fortress, Merlin, and Phoenix all specify that meta information
a little differently. The XFC project is there to help smooth
the transition.
> If the Selector interfaces are going to be deprecated what will replace
> them?
Not any time soon.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-03-12 at 05:35, Peter Donald wrote:
>
> The Marker interfaces will probably be deprecated post fortress release.
> The *Selector interfaces can also be considered for deprecation.
> In the future I can see the release() methods also being deprecated.
>
So marker interfaces like ThreadSafe? So handlers will be specified via
configuration like in Fortress with the specification of a handler?
If the Selector interfaces are going to be deprecated what will replace
them?
Just curious as I want to keep Plexus current. We added Selector goodies
in not knowing they would be deprecated along with a default selector
mechanism. How will one grab a specific implementation among many now?
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
>
> Stefano Mazzocchi wrote:
>
>> Stephen McConnell wrote:
>>
>> >> after that, nobody should be able to place vetos. avalon is owned by
>>
>>>> the community, not by individuals.
>>>
>>>
>>>
>>> +1
>>
>>
>>
>> a few hours before the same Stephen McConnell wrote:
>>
>>> -1 (veto)
>>
>>
>>
>> I'm starting to find this list rather funny.
>
>
>
> What do you find funny?
the fact that you agreed that nobody had to place vetos but you did
three hours before. years ago I would have been pissed, now that I don't
care that much it's just funny.
> Do you find it funny the fact that after community discussion of the
> subject of rationalization and consideration of Avalon - and the
> resulting decision to migrate from Excalibur CLI to Commons CLI, that
> Peter Donald changes the Phoenix CVS to (a) reference a forked version
> of the CLI package (b) contravening the ASL license, (c) in
> contravention with community consensus, and (d) without any
> consultation with the Avalon Community? Personally I don't find that
> funny.
I do. Peter is harming himself without even recognizing it. And you are
harming yourself by caring and falling into his traps each and every time.
if you step back a little and stop being so serious about it, you'll see
how funny and childlish all this is and, after a good laugh, you'll feel
much better and refreshed.
> While I do see signs of a certain level of disrespect by Peter Donald
> for the Avalon Community and the ASF, I don't see any reason to hold
> this against him personally. After all - there is nothing in our bylaws
> that require committers to engage with and support the consensus of
> opinion of the communities to which they are associated. If you consider
> the actions of Peter Donald and the veto that I have put in place, it
> will not take a major leap of understanding to reach the conclusion that
> I simply stating to Peter Donald that the changes that he has made are
> not acceptable based on the information available to me. I remain open
> and receptive to comments from Peter Donald and/or other ASF commiters
> as to why the introduction of dependencies with an external source
> repository offering an inferior solution to the Jakarta Commons CLI
> package is beneficial to the Avalon or ASF community. If you have a
> specific opinion on this matter I am more than will to listen to it. If
> on the other-hand you remark is simply a throw-away line designed to
> undermine a veto then I can safely ignore it.
You can do whatever it pleases you. So can Peter, so can I.
But nothing is harmless in the context of community dynamics.
I, personally, will only look for the fun I had and now I don't see anymore.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
> Stephen McConnell wrote:
>
> >> after that, nobody should be able to place vetos. avalon is owned by
>
>>> the community, not by individuals.
>>
>>
>> +1
>
>
> a few hours before the same Stephen McConnell wrote:
>
>> -1 (veto)
>
>
> I'm starting to find this list rather funny.
What do you find funny?
Do you find it funny the fact that after community discussion of the
subject of rationalization and consideration of Avalon - and the
resulting decision to migrate from Excalibur CLI to Commons CLI, that
Peter Donald changes the Phoenix CVS to (a) reference a forked version
of the CLI package (b) contravening the ASL license, (c) in
contravention with community consensus, and (d) without any
consultation with the Avalon Community? Personally I don't find that funny.
While I do see signs of a certain level of disrespect by Peter Donald
for the Avalon Community and the ASF, I don't see any reason to hold
this against him personally. After all - there is nothing in our bylaws
that require committers to engage with and support the consensus of
opinion of the communities to which they are associated. If you consider
the actions of Peter Donald and the veto that I have put in place, it
will not take a major leap of understanding to reach the conclusion that
I simply stating to Peter Donald that the changes that he has made are
not acceptable based on the information available to me. I remain open
and receptive to comments from Peter Donald and/or other ASF commiters
as to why the introduction of dependencies with an external source
repository offering an inferior solution to the Jakarta Commons CLI
package is beneficial to the Avalon or ASF community. If you have a
specific opinion on this matter I am more than will to listen to it. If
on the other-hand you remark is simply a throw-away line designed to
undermine a veto then I can safely ignore it.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>> after that, nobody should be able to place vetos. avalon is owned by
>> the community, not by individuals.
>
> +1
a few hours before the same Stephen McConnell wrote:
> -1 (veto)
I'm starting to find this list rather funny.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
> Peter Donald wrote:
>
>> It is just "organisation". Framework CVS/Code/whatever is stable now
>> and one of the few pieces we have managed to a decent level of
>> quality. Sure theres plenty of stuff about it that still crap but it
>> works and people respect if for being stable.
>
>
> Agreed. There is 'crap' in the framework, as much as 'cobol' is crap
> or AS/400 is 'crap', but remove it without providing a significant
> (socially and economically) migration path would litterarely make the
> world collapse.
>
>> All of the other stuff you mentioned is not anywhere near that level
>> of quality of framework - so why group them together. What possible
>> advantage is there to pushing bits around? Would it not be more
>> productive to focus on improving the quality of the code?
>
>
> The real issue is: nothing should ever enter the framework CVS without
> a previous community design phase aimed to create consensus.
>
> did that phase happen?
YES - and its probably one of the best examples of Avalon Community
collaboration ever.
>
>
> after that, nobody should be able to place vetos. avalon is owned by
> the community, not by individuals.
+1
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> It is just "organisation". Framework CVS/Code/whatever is stable now and one
> of the few pieces we have managed to a decent level of quality. Sure theres
> plenty of stuff about it that still crap but it works and people respect if
> for being stable.
Agreed. There is 'crap' in the framework, as much as 'cobol' is crap or
AS/400 is 'crap', but remove it without providing a significant
(socially and economically) migration path would litterarely make the
world collapse.
> All of the other stuff you mentioned is not anywhere near that level of
> quality of framework - so why group them together. What possible advantage is
> there to pushing bits around? Would it not be more productive to focus on
> improving the quality of the code?
The real issue is: nothing should ever enter the framework CVS without a
previous community design phase aimed to create consensus.
did that phase happen?
after that, nobody should be able to place vetos. avalon is owned by the
community, not by individuals.
> Everytime some gets an idea to reorganize it seems that a half assed job is
> done and we go through months of agony to get stable again ... if that ever
> happens.
I had the same perception but I'm starting to change it given the hard
work done by people (not perfect, but everybody has to learn by making
mistakes).
I think the real issue is to have gump work right.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 01:57, Leo Simons wrote:
> Peter,
>
> could you either retract your vetoes issued as part of this thread or
> reply to my last e-mail concerning those vetoes (or do both, of course)?
Whats to reply. Still disagree.
> >> No one has proposed making them part of FRAMEWORK. It is a question
> >> of which repository to move to.
> >>
> >> It is a question of whether we want to make the "avalon" CVS
> >> repository support a framework directory structure and an extension
> >> directory structure.
> >
> > to make that even more clear (well maybe), the idea is something like
I understand what the proposal was and there has never been any confusion on
my part. Feel free to replace "framework CVS" anytime i said "framework"
> > Clearly, neither a meta model nor lifecycle extensions nor interceptors
> > nor fortress would be common across containers (anytime soon). Its just
> > about organisation.
Theres your answer.
It is just "organisation". Framework CVS/Code/whatever is stable now and one
of the few pieces we have managed to a decent level of quality. Sure theres
plenty of stuff about it that still crap but it works and people respect if
for being stable.
All of the other stuff you mentioned is not anywhere near that level of
quality of framework - so why group them together. What possible advantage is
there to pushing bits around? Would it not be more productive to focus on
improving the quality of the code?
Everytime some gets an idea to reorganize it seems that a half assed job is
done and we go through months of agony to get stable again ... if that ever
happens.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Niclas Hedhman <ni...@internuscorp.com>.
Being an outside observer (not really knowing anything), it seems to me that
you are communicating over each other's heads.
I suggest that you start from scratch, blank paper, forward the propsal in
shortlist form and why this proposal is important, and Peter outline the
objections, including his fear of the net effects, and perhaps conditions
required before he can accept (or at least remove the veto) the proposal.
Is this worth 2cent? I doubt it.
Niclas
On Friday 14 March 2003 17:34, Leo Simons wrote:
> Peter Donald wrote:
> > On Fri, 14 Mar 2003 01:57, Leo Simons wrote:
> >>could you either retract your vetoes issued as part of this thread or
> >>reply to my last e-mail concerning those vetoes (or do both, of course)?
> >
> > Whats to reply.
>
> The point is that you've issued some vetoes which I and others believe
> to be applying to something not subject to a veto. We need to agree on
> this point: letting vetoes lying around is not good. So a good reply
> would be to conceed that the vetoes are inappropriate, or provide
> arguments that will convince us that they are.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 24 Mar 2003 19:43, Leo Simons wrote:
> > Sounds like a totally different issue, normally referred
> > as Trademarks.
>
> "Apache" is not a registered trademark for the ASF. You will notice the
> lack of "TM" or "SM" in the logos :D
trademarks don't have to be registered to be trademarks. Registeration only
gives more weight but non-registered are defensible if certain conventions
are followed (ie you have defended and enforced historically or this is a
first violation).
> > Am I allowed to release a software called "Niclas Excel"? Even a
> > spreadsheet application?
>
> probably, since Excel is not a registered trademark, you could release
> software called like that. In the case of a spreadsheet application,
You couldn't without violating a trademark (regardless of whether it is
registered or not but I assume it is).
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Leo Simons wrote:
> IANAL!
>
> Niclas Hedhman wrote:
>> ?? That means that if I _don't_ use Apache software I can call the software
>> "RedHat Apache" ??
>
> yep, but it wouldn't be a very cool thing to do :D.
>
>> Sounds like a totally different issue, normally referred
>> as Trademarks.
>
> "Apache" is not a registered trademark for the ASF. You will notice the
> lack of "TM" or "SM" in the logos :D
that does not prevent it from being an unregistered mark --
which it is -- that cannot be used without the permission
of the mark's owner.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list
Posted by Leo Simons <le...@apache.org>.
IANAL!
Niclas Hedhman wrote:
> ?? That means that if I _don't_ use Apache software I can call the software
> "RedHat Apache" ??
yep, but it wouldn't be a very cool thing to do :D.
> Sounds like a totally different issue, normally referred
> as Trademarks.
"Apache" is not a registered trademark for the ASF. You will notice the
lack of "TM" or "SM" in the logos :D
> Am I allowed to release a software called "Niclas Excel"? Even a spreadsheet
> application?
probably, since Excel is not a registered trademark, you could release
software called like that. In the case of a spreadsheet application,
you'll probably get sued, because you're deceiving your buyers, lifting
on the marketing budget of MS, etc etc. In cases like this, the one with
the most lawyers often wins.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 20 March 2003 20:02, Stefano Mazzocchi wrote:
> Niclas Hedhman wrote:
> > Today I CAN take the code and do something else with it, without
> > consulting Apache, I can spawn it, make it commercial, practically
> > anything except leveraging on the Apache name.
> > What more can I do IF ASF didn't have copyright on a particular file?
>
> Call it RedHat Apache.
?? That means that if I _don't_ use Apache software I can call the software
"RedHat Apache" ?? Sounds like a totally different issue, normally referred
as Trademarks.
Am I allowed to release a software called "Niclas Excel"? Even a spreadsheet
application?
Sorry, for getting way off-topic...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list (was: Re: [PROPOSAL] lifecycle release)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> It is my understanding that a work is copyrighted automatically,
> copyright notice or not, as soon as it exist on any transfer
> medium (i.e. not just in my head).
Confirmed by Al Schlessinger (the top formost authority on the
subject).
The copyright notice that we present includes a license for use.
We (the Apache Software Foundation) retain ownership of the code,
and license it to our users. We happen to have a liberal license
while others are more restrictive (and much longer).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list (was: Re: [PROPOSAL] lifecycle release)
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Thu, 20 Mar 2003 19:24, Leo Sutic wrote:
>
>>I think this is standard practice internationally. A copyright
>>notice is *not* needed for copyright protection. You get that
>>automatically.
>
>
> yep (well almost - it depends on your country) - but that has nothing to do
> with what I am talking about. But without a license no user can use the file
> (well thats depends on place in the world actually). Explicitly stating
> incorrect facts in a "contract" when you know the facts to be incorrect is a
> little bit different.
The copyright year is not a fact in a contract. The *license* is one
thing, the copyright is another.
The Apache License 2.0 will make this distinction more obvious and solve
our issues once and for all.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: todo list (was: Re: [PROPOSAL] lifecycle release)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> Explicitly stating incorrect facts in a "contract" when you
> know the facts to be incorrect is a little bit different.
I don't think it's fatal in this case so I see no reason
to consider a wrong copyright notice in our licenses to be
serious. But I see no reason to go to any lengths to *keep*
it wrong either. (I.e. dropping this.)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list (was: Re: [PROPOSAL] lifecycle release)
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 20 Mar 2003 19:24, Leo Sutic wrote:
> I think this is standard practice internationally. A copyright
> notice is *not* needed for copyright protection. You get that
> automatically.
yep (well almost - it depends on your country) - but that has nothing to do
with what I am talking about. But without a license no user can use the file
(well thats depends on place in the world actually). Explicitly stating
incorrect facts in a "contract" when you know the facts to be incorrect is a
little bit different.
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: todo list (was: Re: [PROPOSAL] lifecycle release)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
It is my understanding that a work is copyrighted automatically,
copyright notice or not, as soon as it exist on any transfer
medium (i.e. not just in my head).
The University of Washington seems to agree with this:
http://depts.washington.edu/uwcopy/information/copyrightlaw/1.shtml
"Copyright protection subsists... in original works of authorship fixed
in any tangible medium of expression... from which they can be
perceived,
reproduced, or otherwise communicated, either directly or with the aid
of
a machine or device." 17 USC §102(a)
I think this is standard practice internationally. A copyright
notice is *not* needed for copyright protection. You get that
automatically.
/LS
> From: Peter Donald [mailto:peter@realityforge.org]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Copyright notices (was: RE: todo list (was: Re: [PROPOSAL] lifecycle release))
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 20 Mar 2003 19:25, Leo Sutic wrote:
> More on copyright notices:
>
> http://depts.washington.edu/uwcopy/information/copyrightlaw/12.shtml
Read the paragraph under "Important note:". Though it barely touched on the
point.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Copyright notices (was: RE: todo list (was: Re: [PROPOSAL] lifecycle release))
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
More on copyright notices:
http://depts.washington.edu/uwcopy/information/copyrightlaw/12.shtml
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list (was: Re: [PROPOSAL] lifecycle release)
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 20 Mar 2003 17:28, Niclas Hedhman wrote:
> On Wednesday 19 March 2003 21:53, Leo Simons wrote:
> > Peter Donald wrote:
> > > So if it was created in 2000 and edited in all years since it would be
> > > 2000-2003, if it was edited in 2000 and again this year it would be
> > > 2000,2003 or various other combinations (ie 2000-2001,2003).
> >
> > We talked about this on the PMC list recently (or was it here?). The
> > resolution was that it is not terribly important from a legal POV to
> > update this copyright information very exactly.
if you want to ever be able to enforce the license it is. While not covered by
contractual law (at least in Australia/US) it is close enough and it would
never stand up in court of law.
> If something is marked
> > as copyrighted in 2000, it will remain copyrighted for the next 50 years
> > or so (forgot the exact number); not renewing the copyright claim simply
> > means that after that time the copyright becomes non-enforcable.
It is not about that.
> Maybe I'm too frivolous on this, and missing something truely important.
no - you got it.
--
Cheers,
Peter Donald
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 19 March 2003 21:53, Leo Simons wrote:
>
>>Peter Donald wrote:
>>
>>>So if it was created in 2000 and edited in all years since it would be
>>>2000-2003, if it was edited in 2000 and again this year it would be
>>>2000,2003 or various other combinations (ie 2000-2001,2003).
>>
>>We talked about this on the PMC list recently (or was it here?). The
>>resolution was that it is not terribly important from a legal POV to
>>update this copyright information very exactly. If something is marked
>>as copyrighted in 2000, it will remain copyrighted for the next 50 years
>>or so (forgot the exact number); not renewing the copyright claim simply
>>means that after that time the copyright becomes non-enforcable.
>
>
> Maybe I'm too frivolous on this, and missing something truely important.
>
> What happens in 2050, when Apache looses the Copyright??
Apache looses copyright of the stuff that hasn't been touched in 50
years. I think I would love to see software that is 50 years old just die!
> It becomes FREE, freer than ASL !! ??
Yes. It's called 'public domain' and it's different.
> Today I CAN take the code and do something else with it, without consulting
> Apache, I can spawn it, make it commercial, practically anything except
> leveraging on the Apache name.
> What more can I do IF ASF didn't have copyright on a particular file?
Call it RedHat Apache.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list (was: Re: [PROPOSAL] lifecycle release)
Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Wednesday 19 March 2003 21:53, Leo Simons wrote:
> Peter Donald wrote:
> > So if it was created in 2000 and edited in all years since it would be
> > 2000-2003, if it was edited in 2000 and again this year it would be
> > 2000,2003 or various other combinations (ie 2000-2001,2003).
>
> We talked about this on the PMC list recently (or was it here?). The
> resolution was that it is not terribly important from a legal POV to
> update this copyright information very exactly. If something is marked
> as copyrighted in 2000, it will remain copyrighted for the next 50 years
> or so (forgot the exact number); not renewing the copyright claim simply
> means that after that time the copyright becomes non-enforcable.
Maybe I'm too frivolous on this, and missing something truely important.
What happens in 2050, when Apache looses the Copyright??
It becomes FREE, freer than ASL !! ??
Today I CAN take the code and do something else with it, without consulting
Apache, I can spawn it, make it commercial, practically anything except
leveraging on the Apache name.
What more can I do IF ASF didn't have copyright on a particular file?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>> So if it was created in 2000 and edited in all years since it would be
>> 2000-2003, if it was edited in 2000 and again this year it would be
>> 2000,2003 or various other combinations (ie 2000-2001,2003).
>>
>>
>
> Perhaps you have not noticed but the licesences inside sources files
> have been progressively updated. You welcome to contribute to that
> process if so inclinded. Perhaps a constuctive action would be to post
> a list of the packages that need attention. This would assist others
> who also interesting in bring these things in line.
All a copyright notice has to reflect is when the code was initially
created. For new stuff this is 2003. A copyright lasts for 50 years
after the owner's death--I need to double check for corporate ownership
which is the case for ALL Aapche code.
>> * "unified coordinated releases" - really bad idea. Components should
>> be releases when they are stable and supported. They should be
>> released by the people who are willing to support them after they are
>> released. The only reason why coordinated releases could make sense is
>> if there is high coupling between components - in which case I would
>> argue that the components should not be released. I would have thought
>> that this was learned from the last big ball of mud release.
>
> You could think of this as a stocktacking exercise where we step though
> everything - everything get our attention, everybody gets a little more
> aware of the status of things. The PMC progressively moves towards a
> position where is has a good grip on what it is responsible for, I see
> this is really constructive and so far, the impact on the code based and
> documetation has been positive.
It is also bringing up the code that we are not willing to maintain as a
community as we come accross it and deal with it at that time.
>> Two main things.
>> 1. Empower those who are doing the work
I thought we all could do the work.
>> * Delete junk docs (ie docs that don't say anything but are just
>> placeholders). (I will also do this if no one -1s it)
Better solution: determine if we are supporting the library, and
write real docs if we are or place it somewhere else if not.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Sun, 16 Mar 2003 10:57, Leo Simons wrote:
>
>
>>>* released components have backwards compat broken haphazardly
>>>
>>>
>>just in cvs, and they get fixed, too. Having CVS means some experiments are
>>possible!
>>
>>
>
>Still no one has fixed the backwards incompatible changes to thread. It has
>been a couple of weeks now, a -1 and ... nothing.
>
I saw a response to this from Berin and confirmation that things were
working properly.
Can you be specific about the situation your referring to? At least
will save Berin some time if indeed the problem isn't resolved.
>
>
>
>>>* licenses on 90% of files is invalid
>>>
>>>
>>could you please elaborate on this one? One of the things on my TTD is
>>figuring out the last bits of any license issues.
>>
>>
>
>majority of licenses are unenforcable because they include the incorrect years
>or they contain things like @year@ as the year. Because we attach the full
>license to each file the files are considered separately licensed. Which
>means that if a file must have the correct years in copyright years.
>
>So if it was created in 2000 and edited in all years since it would be
>2000-2003, if it was edited in 2000 and again this year it would be 2000,2003
>or various other combinations (ie 2000-2001,2003).
>
>
Perhaps you have not noticed but the licesences inside sources files
have been progressively updated. You welcome to contribute to that
process if so inclinded. Perhaps a constuctive action would be to post
a list of the packages that need attention. This would assist others
who also interesting in bring these things in line.
>
>
>>Have these things always been "screwed"?
>>
>>
>
>some of it has, some hasn't. Several of the things that have got more screwed
>over time you will actually find me arguing against in the past.
>
>
>
>>If not, when did that happen, how,
>>and what can we do to prevent it from happening in the future? Do you think
>>the work currently being done by some of us (ie slimming avalon down,
>>"unified coordinated releases", replacing cocoon with forrest, forrestbot,
>>jira tracker, using a wiki) is going in the right direction?
>>
>>
>
> one point at a time.
>
>* "slimming avalon down" - unfortunate that it has to occur but probably for
>the best
>
>* "unified coordinated releases" - really bad idea. Components should be
>releases when they are stable and supported. They should be released by the
>people who are willing to support them after they are released. The only
>reason why coordinated releases could make sense is if there is high coupling
>between components - in which case I would argue that the components should
>not be released. I would have thought that this was learned from the last big
>ball of mud release.
>
>
You could think of this as a stocktacking exercise where we step though
everything - everything get our attention, everybody gets a little more
aware of the status of things. The PMC progressively moves towards a
position where is has a good grip on what it is responsible for, I see
this is really constructive and so far, the impact on the code based and
documetation has been positive.
>* "replacing cocoon with forrest" - good for framework. Not necessary for
>phoenix atm but I would like to keep it because it may be in the future. For
>the rest the complexity is not justified so axe it.
>
>* "forrestbot, jira tracker, using a wiki" are just tools and are as useful as
>they are used. I love forrestbot and the fact that jeff is maintaing it
>(thanks!), jira is better than bugzilla IMHO and wiki ... seems to be at
>least generating some docs.
>
>
>
>>If not, what
>>should we be doing? Are there other things we should be doing?
>>
>>
>
>Two main things.
>
>1. Empower those who are doing the work
>
Empower whom? For what work in particular? Perhaps you could switch in
-verbose so that your coment could be translated into a constructive and
usable suggestion?
>2. stop putting fingers in the holes and start fixing the leaks.
>
>
Stop groaning and fix the license that are incorrect.
>For (1) stop vetoes for non-technical reasons and by those who aren't willing
>to actually put in work to solve the problem.
>
>
If you feel that a veto is inappropriate the best course of action is to
post a message to PMC stating your case. The PMC is there to ensure
that things are done properly. They can certainly retract a veto if
they feelit is appropriate.
>For (2) there is a lot to do.
>
>* Drop ant as build system for excalibur and replace with maven (I volunteer
>to do this if no one will -1 it).
>
So take this as a -1.
We have put in a maven build on the Merlin package. The reports we have
at the moment indicate that there are some problems. One of the reasons
for putting in a maven build within Merlin was enable experimentation
with Maven here within the community. Out of that experimentation we
will be able to make reasonable decisions about the convensions we
apply, approaches, etc. There are clealy things that remain to be
resolved - Forrest doc build integration and gump integration are two
examples. Perhaps you consider contributing to the community by
applying your expertise to getting the Merlin example to the point where
all of the points are resolved.
>* Delete junk docs (ie docs that don't say anything but are just
>placeholders). (I will also do this if no one -1s it)
>
What about putting in place actual documetation - you know - two of
three paragraph summary, maybe a component table, example of usage. I
think that would be more constructive.
>* Delete docs from apps and all references from website - not maintained
>anyways (I will axe)
>
Same comment as above.
>* Delete any other non-maintained code or docs
>
Verbose mode required - which are codebases that you consider are
non-maintained? In what respect are they non-maintained - unresolved
bugs? Incomplete documetation? Maybe you could do a little audit and
break down projects in terms of actions that in your opinion could be
taken / should be taken?
>* Drop Forrest dependency except where needed
>* Stop insanity of uploading all the docs to site module and use site:deploy
>from maven
>
See maven comments above.
>* stop the pointless moving around of code. It can be deprecated in place if
>need be
>
I actually prefer the compatability jar approach - it really does
encourage people to migrate.
>* remove all one-man codebases without prejudice
>etc.
>
>
Do you have any specific codebases in mind?
Perhaps you could could make some specific recommendations?
>Plenty more things to do.
>
>
Great, I've got plently of time to listen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list (was: Re: [PROPOSAL] lifecycle release)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> up front, thanks for writing this.
>
> Peter Donald wrote:
>
>> On Sun, 16 Mar 2003 10:57, Leo Simons wrote:
>>
>>>> * released components have backwards compat broken haphazardly
>>>
>>>
>>> just in cvs, and they get fixed, too. Having CVS means some
>>> experiments are
>>> possible!
>>
>>
>> Still no one has fixed the backwards incompatible changes to thread.
>> It has been a couple of weeks now, a -1 and ... nothing.
>
>
> I was under the impression Berin had reverted this (he said so on-list).
> I'll have a look. In the meantime you should feel free to make the
> revert yourself IMO.
I reverted the stuff in Cornerstone. I unintentionally did not revert
the changes in Thread.
>> The only reason why coordinated releases could make sense is if there
>> is high coupling between components - in which case I would argue that
>> the components should not be released.
>
>
> hmm. Even when there is no tight coupling it makes sense to do extra
> testing (besides the continuous integration gump affords, and our nearly
> nonexistent unit tests) on some snapshots. Especially since our gump
> setup has been broken so long: changes might have crept into the
> packages which might've broken somewhere else. With the huge size of the
> avalon codebase, the broken integration, and the limited unit tests, I
> simply cannot be sure no incompatible changes have been made. Can you?
We also have alot of questions with our users that come up from time
to time. They are along the lines of "Excalibur Logger doesn't work
with LogKit X because of exception Y". Instead of finding all the
places where components are not working with each other (because they
are in CVS), we are baselining our product-set.
This fresh start approach allows us to audit what we will support,
and validate that it does not break back compatibility. That also
means we need to add tests--so any help will be appreciated.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: todo list
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote, On 19/03/2003 14.53:
...
>> So if it was created in 2000 and edited in all years since it would be
>> 2000-2003, if it was edited in 2000 and again this year it would be
>> 2000,2003 or various other combinations (ie 2000-2001,2003).
>
> We talked about this on the PMC list recently (or was it here?). The
> resolution was that it is not terribly important from a legal POV to
> update this copyright information very exactly. If something is marked
> as copyrighted in 2000, it will remain copyrighted for the next 50 years
> or so (forgot the exact number); not renewing the copyright claim simply
> means that after that time the copyright becomes non-enforcable.
>
> In short, yes, we should update this, but the license is not invalid if
> the copyright date is a bit "stale".
Actually, a file's copyright should really be updated only when really
modifying it, not in bulk.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
todo list (was: Re: [PROPOSAL] lifecycle release)
Posted by Leo Simons <le...@apache.org>.
up front, thanks for writing this.
Peter Donald wrote:
> On Sun, 16 Mar 2003 10:57, Leo Simons wrote:
>>>* released components have backwards compat broken haphazardly
>>
>>just in cvs, and they get fixed, too. Having CVS means some experiments are
>>possible!
>
> Still no one has fixed the backwards incompatible changes to thread. It has
> been a couple of weeks now, a -1 and ... nothing.
I was under the impression Berin had reverted this (he said so on-list).
I'll have a look. In the meantime you should feel free to make the
revert yourself IMO.
>>>* licenses on 90% of files is invalid
>>
>>could you please elaborate on this one? One of the things on my TTD is
>>figuring out the last bits of any license issues.
>
> majority of licenses are unenforcable because they include the incorrect years
> or they contain things like @year@ as the year.
I'll run a grep for those this weekend; I thought we'd got them all out.
Should be pretty easy to run a one-off filter for @year@.
> So if it was created in 2000 and edited in all years since it would be
> 2000-2003, if it was edited in 2000 and again this year it would be 2000,2003
> or various other combinations (ie 2000-2001,2003).
We talked about this on the PMC list recently (or was it here?). The
resolution was that it is not terribly important from a legal POV to
update this copyright information very exactly. If something is marked
as copyrighted in 2000, it will remain copyrighted for the next 50 years
or so (forgot the exact number); not renewing the copyright claim simply
means that after that time the copyright becomes non-enforcable.
In short, yes, we should update this, but the license is not invalid if
the copyright date is a bit "stale".
>>If not, when did that happen, how,
>>and what can we do to prevent it from happening in the future? Do you think
>>the work currently being done by some of us (ie slimming avalon down,
>>"unified coordinated releases", replacing cocoon with forrest, forrestbot,
>>jira tracker, using a wiki) is going in the right direction?
>
> one point at a time.
sure :D I actually didn't want to list lots of points; just threw out a few.
> * "slimming avalon down" - unfortunate that it has to occur but probably for
> the best
+1
> * "unified coordinated releases" - really bad idea.
you seem to have a different idea of what that means than I...see below.
> Components should be
> releases when they are stable and supported.
+1
> They should be released by the
> people who are willing to support them after they are released.
+1
> The only
> reason why coordinated releases could make sense is if there is high coupling
> between components - in which case I would argue that the components should
> not be released.
hmm. Even when there is no tight coupling it makes sense to do extra
testing (besides the continuous integration gump affords, and our nearly
nonexistent unit tests) on some snapshots. Especially since our gump
setup has been broken so long: changes might have crept into the
packages which might've broken somewhere else. With the huge size of the
avalon codebase, the broken integration, and the limited unit tests, I
simply cannot be sure no incompatible changes have been made. Can you?
Sure, we should fix the actual problems rather than work around them,
but in the meantime the world should keep on spinning, too.
> I would have thought that this was learned from the last big
> ball of mud release.
yep. I would like to think that our releases get better every time. As
long as there is an improvement from release to release things don't
need to be perfect in one go.
> * "replacing cocoon with forrest" - good for framework. Not necessary for
> phoenix atm but I would like to keep it because it may be in the future. For
> the rest the complexity is not justified so axe it.
hmm. I totally agree forrest is too complex for simple doc projects (the
forrest peeps agree, too!). IIUC it should be easily doable to write a
plugin for maven which can generate docs from the forrest doc format.
When/if we move to maven we can tackle that too.
In the meantime, forrest is better than plain cocoon.
> * "forrestbot, jira tracker, using a wiki" are just tools and are as useful as
> they are used.
+1
>>If not, what
>>should we be doing? Are there other things we should be doing?
>
> Two main things.
>
> 1. Empower those who are doing the work
> 2. stop putting fingers in the holes and start fixing the leaks.
>
> For (1) stop vetoes for non-technical reasons and by those who aren't willing
> to actually put in work to solve the problem.
I think we've pretty much done that; when/if you feel a veto was thrown
for a non-technical reason please do not hesistate to say so, or contact
the PMC, so that matters can be resolved. Anything else that would lead
to even more empowerment?
> For (2) there is a lot to do.
>
> * Drop ant as build system for excalibur and replace with maven (I volunteer
> to do this if no one will -1 it).
my idea was to wait for beta 0.9 based on recommendations from jason,
before getting started on any migration. Still, there is already
consensus (see archives) that we should be setting up maven next to the
ant system, at least to try things out. We don't want to go halfway with
maven and end up with a broken maven setup and a broken ant setup.
Wit that in mind, please feel more than free to set this up, but please
don't throw ant out just yet. Perhaps it would also be a good idea to
get the things with an actually half-working rather than just a real
annoying build system over to maven first.
> * Delete junk docs (ie docs that don't say anything but are just
> placeholders). (I will also do this if no one -1s it)
+1, provided you make some noise about the specific docs that you think
are just placeholders first, so people (like me or you) might have a
chance to replace placeholders with something that is not a placeholder,
and so we are sure we all agree on which docs are just placeholders :D
> * Delete docs from apps and all references from website - not maintained
> anyways (I will axe)
Paul just updated this I believe, so I'm not sure how dead this is.
Still, stuff like phyre has been getting gump failures for a long time,
so if no-one steps up to do maintainance, yes, those things should
definately go.
> * Delete any other non-maintained code or docs
if it is not released, and no-one has plans to start maintaining things
again, +1. Again, please do ask&confirm before acting :D
> * Drop Forrest dependency except where needed
as long as our site stays up and running, docs can be created and
maintained in a neat and intuitive xml format, and transformed as part
of the build process, I don't care what tool we use. Forrest works for
me, even if it is a bit heavy.
> * Stop insanity of uploading all the docs to site module and use site:deploy
> from maven
you aware of the talks about this on the infrastructure list? I believe
there's a couple of people looking at doing this for various projects.
Options mentioned include maven, forrestbot, and webdav/svn. I dunno how
site:deploy works, but if it is an improvement then its a good idea :D
> * stop the pointless moving around of code. It can be deprecated in place if
> need be
I think it was a good idea to remove some of the cruft from excalibur. I
agree that it didn't make too much sense to set up the excalibur compat/
thing, but it makes even less sense to move things back now :D
> * remove all one-man codebases without prejudice
---
http://dictionary.reference.com/search?q=prejudice
prej·u·dice n.
1.
1. An adverse judgment or opinion formed beforehand or without
knowledge or examination of the facts.
2. A preconceived preference or idea.
2. The act or state of holding unreasonable preconceived judgments
or convictions. See Synonyms at predilection.
3. Irrational suspicion or hatred of a particular group, race, or
religion.
4. Detriment or injury caused to a person by the preconceived,
unfavorable conviction of another or others.
---
sure thing. We need to do this in an evolutionary way imo, not just
throw lots of stuff out happy-snappy.
>>>I have explained the same things in the past. It is annoying to have to
>>>repeat
>>>things when I know you will only ignore things again this time.
>>
>>what on earth makes you believe I'm ignoring you? When have I ignored you
>>in the past?
>
> You ask the same things over and over. If you were asking for clarification
> that would be different.
so call me a slow learner or a bad listener, but I do act on your
suggestions as well (if I agree with 'em)! Even when I or others don't,
surely you are "empowered" to do things yourself (as long as there's
consensus of course). Still, lacking a tracker tool setup, this e-mail
has been printed and taped to the wall :D
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 16 Mar 2003 10:57, Leo Simons wrote:
> > * released components have backwards compat broken haphazardly
>
> just in cvs, and they get fixed, too. Having CVS means some experiments are
> possible!
Still no one has fixed the backwards incompatible changes to thread. It has
been a couple of weeks now, a -1 and ... nothing.
> > * licenses on 90% of files is invalid
>
> could you please elaborate on this one? One of the things on my TTD is
> figuring out the last bits of any license issues.
majority of licenses are unenforcable because they include the incorrect years
or they contain things like @year@ as the year. Because we attach the full
license to each file the files are considered separately licensed. Which
means that if a file must have the correct years in copyright years.
So if it was created in 2000 and edited in all years since it would be
2000-2003, if it was edited in 2000 and again this year it would be 2000,2003
or various other combinations (ie 2000-2001,2003).
> Have these things always been "screwed"?
some of it has, some hasn't. Several of the things that have got more screwed
over time you will actually find me arguing against in the past.
> If not, when did that happen, how,
> and what can we do to prevent it from happening in the future? Do you think
> the work currently being done by some of us (ie slimming avalon down,
> "unified coordinated releases", replacing cocoon with forrest, forrestbot,
> jira tracker, using a wiki) is going in the right direction?
one point at a time.
* "slimming avalon down" - unfortunate that it has to occur but probably for
the best
* "unified coordinated releases" - really bad idea. Components should be
releases when they are stable and supported. They should be released by the
people who are willing to support them after they are released. The only
reason why coordinated releases could make sense is if there is high coupling
between components - in which case I would argue that the components should
not be released. I would have thought that this was learned from the last big
ball of mud release.
* "replacing cocoon with forrest" - good for framework. Not necessary for
phoenix atm but I would like to keep it because it may be in the future. For
the rest the complexity is not justified so axe it.
* "forrestbot, jira tracker, using a wiki" are just tools and are as useful as
they are used. I love forrestbot and the fact that jeff is maintaing it
(thanks!), jira is better than bugzilla IMHO and wiki ... seems to be at
least generating some docs.
> If not, what
> should we be doing? Are there other things we should be doing?
Two main things.
1. Empower those who are doing the work
2. stop putting fingers in the holes and start fixing the leaks.
For (1) stop vetoes for non-technical reasons and by those who aren't willing
to actually put in work to solve the problem.
For (2) there is a lot to do.
* Drop ant as build system for excalibur and replace with maven (I volunteer
to do this if no one will -1 it).
* Delete junk docs (ie docs that don't say anything but are just
placeholders). (I will also do this if no one -1s it)
* Delete docs from apps and all references from website - not maintained
anyways (I will axe)
* Delete any other non-maintained code or docs
* Drop Forrest dependency except where needed
* Stop insanity of uploading all the docs to site module and use site:deploy
from maven
* stop the pointless moving around of code. It can be deprecated in place if
need be
* remove all one-man codebases without prejudice
etc.
Plenty more things to do.
> > > Also, you are a smart guy who knows quite well how the voting and
> > > discussion process flows here, and dragging out an explanation of
> > > something I know you understand perfectly well (as you taught me!) is
> > > just as annoying, so please stop that too.
> >
> > I have explained the same things in the past. It is annoying to have to
> > repeat
> > things when I know you will only ignore things again this time.
>
> what on earth makes you believe I'm ignoring you? When have I ignored you
> in the past?
You ask the same things over and over. If you were asking for clarification
that would be different.
--
Cheers,
Peter Donald
USER, n.:
The word computer professionals use when they mean "idiot."
-- Dave Barry, "Claw Your Way to the Top"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 17 Mar 2003 06:43, Stefano Mazzocchi wrote:
> There is a continous sense of "my code vs. your code" in your posts.
you see what you want to see.
> If there is something wrong, either make friendly suggestions, or get
> your hands dirty and fix it yourself.
I am fixing things that I can fix. Some I can't and some require others to
stop talking and start doing.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <l....@student.utwente.nl>.
replying via webmail coz moz broke...sorry for any bad formatting...
Citeren Peter Donald <pe...@realityforge.org>:
> On Fri, 14 Mar 2003 20:34, Leo Simons wrote:
> > The point is that you've issued some vetoes which I and others believe
> > to be applying to something not subject to a veto ... or provide
> > arguments that will convince us that they are.
>
> Its a code change and thus subject to veto. I have a solid technical reason
> for veto, effects code that I work with and I am willing to do the work of
> supporting my vote.
I think I should not spend more time talking about this with you; seems
pointless, we're totally not getting through to each other I guess. Someone
with better communication skills will have to try and get the points across.
> > The point is also that other points you've made in this thread about the
> > technical validity of the package should be addressed. If a package has
> > no use or an unacceptable implementation, we shouldn't release it, hence
> > claims like this need to be addressed when made, if the intent is indeed
> > to release the package.
>
> I don't care if it is released or not. Quality matters less than your
> commitment to maintain it. If there is people who will maintain and support
> it then it should be released else not.
+1
> > On a personal note, I am also pretty annoyed with your whining about us
> > doing a "half-assed job" in various respects. I think the picture you
> > paint is wrong, and you should either stop painting it and "get over it"
> > or back things up.
>
> * website is screwed
+1, esp. /apps/
> * released components have backwards compat broken haphazardly
just in cvs, and they get fixed, too. Having CVS means some experiments are
possible!
> * indepent release of components is non existent
eh?
> * docs are non existent for many components
+1
> * unit tests are non existent for many components
+1
> * unit tests when present have poor coverage
+1
> * unit tests when present and with good coverage are not run (and thus
> "released" code fails to pass them)
+1
> * when changes are made the required work of making changes is rarely done
> (involves updating all avalon users of change, gump, build system and docs).
+1
> * licenses on 90% of files is invalid
could you please elaborate on this one? One of the things on my TTD is figuring
out the last bits of any license issues.
anyways, one could add
* docs are outdated for many components
* various docs contradict each other for many components
* ...
we can put together a large detailed list of these things, stuff it in an issue
tracker, then actually fix things and tick them off. It will show both that
there are things to fix and that things are being fixed. But just talk won't
help us there, nor will just complaining.
Have these things always been "screwed"? If not, when did that happen, how, and
what can we do to prevent it from happening in the future? Do you think the
work currently being done by some of us (ie slimming avalon down, "unified
coordinated releases", replacing cocoon with forrest, forrestbot, jira tracker,
using a wiki) is going in the right direction? If not, what should we be doing?
Are there other things we should be doing?
> Oh I am sure that you can say "you are working on it" but I have heard that
> story for years now and nothing has changed.
how about you say you are working on it? Or better yet, we all say we are
working on it? Certainly, I'm not working on everything! I'll disagree
on "nothing has changed for years"; I've been around for a bit over 2 years I
think, and in that time avalon went from some obscure completely alpha project
not many people knew about, to providing some rock-solid and real cool software.
> > Also, you are a smart guy who knows quite well how the voting and
> > discussion process flows here, and dragging out an explanation of
> > something I know you understand perfectly well (as you taught me!) is
> > just as annoying, so please stop that too.
>
> I have explained the same things in the past. It is annoying to have to
> repeat
> things when I know you will only ignore things again this time.
what on earth makes you believe I'm ignoring you? When have I ignored you in
the past?
> > So, turning this around: what possible advantage is there to being a
> > royal pain in the butt trying to block these things? Would it not be
> > much more productive to focus on improving the quality of the code?
>
> I am not blocking release (as that is impossible). All I am blocking is
> diluting quality of framework CVS for the sake of change and chest thumping.
oh, come on! There is absolytely no-one looking to dilute quality of anything
for the sake of change and chest thumping. If that is all you are wanting to
block then we can all go to bed happily. Which is in fact is exactly what I'm
going to do now ;)
> *----------------------------------------------------*
> | We must become the change we want to see. - Gandhi |
> *----------------------------------------------------*
gotta love those quotes :D
g'night (on my end anyway),
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 14 Mar 2003 20:34, Leo Simons wrote:
>
> * website is screwed
Leo is addressing that (can't remember which one).
> * released components have backwards compat broken haphazardly
Released? Where?
> * indepent release of components is non existent
We are doing that *now*. The Lifecycle question is part of that
release.
> * docs are non existent for many components
As we get ready for a release we are addressing that as well.
It would be a pleasure to have your support to help us get
under way with the ones on our plate at this time.
> * unit tests are non existent for many components
Again, we are addressing these as we get to them. We would be more
than happy to have your help as we get each set of components to
work with each other.
> * unit tests when present have poor coverage
Again, help us out.
> * unit tests when present and with good coverage are not run (and thus
> "released" code fails to pass them)
Example? By released we mean something accessible on
www.apache.org/dist/avalon/
> * when changes are made the required work of making changes is rarely done
> (involves updating all avalon users of change, gump, build system and docs).
Those are being addressed. GUMP is working for the important parts of
Avalon now.
> * licenses on 90% of files is invalid
I seem to remember a war in CVS about this... We are adding in the
official full license as we go through preparing a component for
release. You are welcome to accelerate this process.
> Oh I am sure that you can say "you are working on it" but I have heard that
> story for years now and nothing has changed.
Better look again. It *is* changing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
> * website is screwed
Have you posted a checklist of issues?
> * released components have backwards compat broken haphazardly
True. But that is being corrected. And the whole issue of compatibility
has been brought to the forefront, with a much higher profile than
previously.
> * indepent release of components is non existent
How so? I see that Avalon is pushing to go through ALL packages and release
them in dependency order as we speak.
> * docs are non existent for many components
Perpetual problem for most open source projects. I'm going to write some
config docs for tomcat/jk2 because I need to figure out answers to configure
my own system, and I might as well share them.
> * unit tests are non existent for many components
> * unit tests when present have poor coverage
See above.
This also appears to be an issue for a number of container environments.
Has anyone tried working with the Cactus project to get Avalon support
added?
> * unit tests when present and with good coverage are not run (and thus
> "released" code fails to pass them)
Get them put into GUMP.
> * when changes are made the required work of making changes is rarely done
> (involves updating all avalon users of change, gump, build system and
docs).
Propose a CHECKLIST.
> * licenses on 90% of files is invalid
Because of the short license? I posted an sed script to community@ some
weeks ago to help with that process. Be happy to help someone use it, if
they want.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> * website is screwed
> * released components have backwards compat broken haphazardly
> * indepent release of components is non existent
> * docs are non existent for many components
> * unit tests are non existent for many components
> * unit tests when present have poor coverage
> * unit tests when present and with good coverage are not run (and thus
> "released" code fails to pass them)
> * when changes are made the required work of making changes is rarely done
> (involves updating all avalon users of change, gump, build system and docs).
> * licenses on 90% of files is invalid
>
> Oh I am sure that you can say "you are working on it" but I have heard that
> story for years now and nothing has changed.
There is a continous sense of "my code vs. your code" in your posts.
Peter, you decided to remain here so you are part of this community and
therefore the screwed code is *yours* as much as *mine* as much as
anybody else's around here.
It's *our* code.
If there is something wrong, either make friendly suggestions, or get
your hands dirty and fix it yourself.
This is a meritocracy and a do-ocracy, not a FUD-ocracy. Otherwise, you
would be president of the foundation by now.
You are just fixing what you feel is *yours* and complain about the fact
that *their* code is polluting the beauty of the Avalon project thus
reflecting poorly on *your* stuff.
In my book, this is called acting like a primadonna by abusing the stage.
The only thing that hasn't changed in Avalon is your attitude.
Too bad we can't have gump runs to show *evidence* of attitude changes
for people.
Luckily, we *do* have gump runs for showing evidence of trends in code
and *they* prove you wrong.
So, use that brain and stop that stupid fud, it's just hurting you and
the results is that when you have interesting and valuable comments,
they are lost in the low signal/noise ration of your regular posts,
resulting in more frustration on all sides.
And stop being so defensive: I'm trying *hard* to help you getting back
the respect you deserve. Please, help me (and yourself) back.
If not, I won't be suggesting you to leave anymore, I'll be the one to
leave because I'm getting sick of all this negative energy around here
and things are moving in the right direction and I trust Berin enough to
leave and be peaceful with it.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 20:34, Leo Simons wrote:
> The point is that you've issued some vetoes which I and others believe
> to be applying to something not subject to a veto ... or provide
> arguments that will convince us that they are.
Its a code change and thus subject to veto. I have a solid technical reason
for veto, effects code that I work with and I am willing to do the work of
supporting my vote.
> The point is also that other points you've made in this thread about the
> technical validity of the package should be addressed. If a package has
> no use or an unacceptable implementation, we shouldn't release it, hence
> claims like this need to be addressed when made, if the intent is indeed
> to release the package.
I don't care if it is released or not. Quality matters less than your
commitment to maintain it. If there is people who will maintain and support
it then it should be released else not.
> On a personal note, I am also pretty annoyed with your whining about us
> doing a "half-assed job" in various respects. I think the picture you
> paint is wrong, and you should either stop painting it and "get over it"
> or back things up.
* website is screwed
* released components have backwards compat broken haphazardly
* indepent release of components is non existent
* docs are non existent for many components
* unit tests are non existent for many components
* unit tests when present have poor coverage
* unit tests when present and with good coverage are not run (and thus
"released" code fails to pass them)
* when changes are made the required work of making changes is rarely done
(involves updating all avalon users of change, gump, build system and docs).
* licenses on 90% of files is invalid
Oh I am sure that you can say "you are working on it" but I have heard that
story for years now and nothing has changed.
> Also, you are a smart guy who knows quite well how the voting and
> discussion process flows here, and dragging out an explanation of
> something I know you understand perfectly well (as you taught me!) is
> just as annoying, so please stop that too.
I have explained the same things in the past. It is annoying to have to repeat
things when I know you will only ignore things again this time.
> So, turning this around: what possible advantage is there to being a
> royal pain in the butt trying to block these things? Would it not be
> much more productive to focus on improving the quality of the code?
I am not blocking release (as that is impossible). All I am blocking is
diluting quality of framework CVS for the sake of change and chest thumping.
I would similarly block addition of all other similar stuff and it has
nothing to do with the quality of lifecycle or event that it is lifecycle.
--
Cheers,
Peter Donald
*----------------------------------------------------*
| We must become the change we want to see. - Gandhi |
*----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
> On Fri, 14 Mar 2003 01:57, Leo Simons wrote:
>
>>could you either retract your vetoes issued as part of this thread or
>>reply to my last e-mail concerning those vetoes (or do both, of course)?
>
> Whats to reply.
The point is that you've issued some vetoes which I and others believe
to be applying to something not subject to a veto. We need to agree on
this point: letting vetoes lying around is not good. So a good reply
would be to conceed that the vetoes are inappropriate, or provide
arguments that will convince us that they are.
--
The point is also that other points you've made in this thread about the
technical validity of the package should be addressed. If a package has
no use or an unacceptable implementation, we shouldn't release it, hence
claims like this need to be addressed when made, if the intent is indeed
to release the package.
I need you to make me see where the problems lie in that respect, so a
good reply in that respect would probably be some code examples. If it's
not possible for you to explain these things to me (assuming here I am
technically competent enough to understand the issues), we probably need
to use some kind of poll or voting mechanism to get the sum of the parts
of the developer community to settle this. But again, having the stamp
of "this is a bad idea" on a package we're readying for release is
something we should not do.
--
On a personal note, I am also pretty annoyed with your whining about us
doing a "half-assed job" in various respects. I think the picture you
paint is wrong, and you should either stop painting it and "get over it"
or back things up.
Also, you are a smart guy who knows quite well how the voting and
discussion process flows here, and dragging out an explanation of
something I know you understand perfectly well (as you taught me!) is
just as annoying, so please stop that too.
But this is just a request at this point, even if it would make my life
easier if you would, so please do give it some thought.
--
finally...
> What possible advantage is
> there to pushing bits around? Would it not be more productive to focus on
> improving the quality of the code?
It would be _much_ more productive to just do stuff, and let others do
stuff too, rather than veto things because they might not be very
productive. Your vetoes are forcing a response, where we would probably
could have fixed all issues with the package, done several bugfix
releases, and implement an interceptor-based version of the package, in
the time it has taken various people to craft those responses and
investigate the issue.
So, turning this around: what possible advantage is there to being a
royal pain in the butt trying to block these things? Would it not be
much more productive to focus on improving the quality of the code?
greetz,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Peter,
could you either retract your vetoes issued as part of this thread or
reply to my last e-mail concerning those vetoes (or do both, of course)?
Leaving this "hanging in mid-air" seems like a bad idea :D
cheers!
- Leo
Leo Simons wrote:
> Peter Donald wrote:
>
>>> we have discussed moving materials which do not belong at the same
>>> level as avalon-framework into the avalon CVS module before.
>>
>>
>> And yet it hasn't happened.
>
>
> twist those words around a bit:
>
> and it hasn't happened yet
>
> :D
>
>>> Can you motivate why you think that is not a good idea?
>>
>>
>> Because it is not common to all containers or development strategies.
>
>
> So you are saying that materials that go into the avalon CVS module
> should be common to all containers and development strategies. Why?
>
> Berin wrote:
>
>> CLARIFICATION:
>>
>> No one has proposed making them part of FRAMEWORK. It is a question
>> of which repository to move to.
>>
>> It is a question of whether we want to make the "avalon" CVS
>> repository support a framework directory structure and an extension
>> directory structure.
>
>
> to make that even more clear (well maybe), the idea is something like
>
> ssh cvs.apache.org
> umask 002
> cd /home/cvs/avalon
> cp -Rfp * framework
> cp -Rfp ../avalon-sandbox/lifecycle .
> exit
> cd ~/cvs/avalon
> cvs rm -Rf *
> cvs commit -m 'moving into framework/ subdirectory'
> cvs up -P -d
>
> this was talked about before; the idea back then was to move everything
> that is not generic utility code (ie meta, containerkit, similar stuff,
> but not IO or CLI) into the main avalon cvs (when ready to move out of
> the sandbox). You would end up with
>
> /home/cvs/avalon
> README.txt
> LICENSE.txt
> framework/
> lifecycle/
> meta/
> interceptor/
> fortress/
> ...
>
> Clearly, neither a meta model nor lifecycle extensions nor interceptors
> nor fortress would be common across containers (anytime soon). Its just
> about organisation.
>
>> The Marker interfaces will probably be deprecated post fortress
>> release. The *Selector interfaces can also be considered for
>> deprecation. In the future I can see the release() methods also being
>> deprecated.
>
>
> that's quite another (ancient ;) discussion.
>
>>>>> * the release of the avalon-lifecycle package shall be considered
>>>>> as an "optional" extension to the framework contracts
>>>>
>>>>
>>>> -1
>>>>
>>>> It is the same approach that has been done before and failed and
>>>> can't cleanly produce some aspects like delayed activation,
>>>> passivation, persistence, transaction demarcation, bifuricating
>>>> interception etc.
>>>
>>>
>>> Taking your -1 as a veto rather than an opinion, you should provide
>>> a viable alternative for it to be valid, which AFAIK you haven't
>>> done.
>>
>>
>> Several times before - you even committed one of my emails to CVS.
>>
>> Interceptors will solve all these problems (and many more besides).
>> Go to Rickard Öbergs blog for a good description. Alternatively go
>> through the links I have provided in the past. Several good articles
>> are available in msdn these days aswell.
>
>
> Your -1 applies to "the release of the avalon-lifecycle package shall be
> considered as an "optional" extension to the framework contracts",
> doesn't it? Saying "avalon-lifecycle (c/sh)ould be implemented
> differently using interceptors" is a different story alltogether, innit?
>
> I am all for finding the best implementation. In the meantime, fortress
> doesn't have an interceptor-based architecture, it sounds like a lot of
> work to put it in now, and I think it needs a release.
>
>>> Also, could you please provide more specific information about why
>>> the approach in the lifecycle package fails, perhaps with a code
>>> example?
>>
>>
>> Perhaps you could show me how it succeeds.
>
>
> sure. Fortress provides support for instrumentation management by using
> the lifecycle and instrument-manager packages. This is, atm, my usecase
> for the lifecycle package, and it succeeds there.
>
>> We have tried it in the
>> past and it led to spagetti code.
>
>
> you think the way fortress does instrumentation is "spaghetti-like"? I
> sorta like it. Its the only time I've tried using lifecycle extensions,
> IIRC.
>
>>> I would also like to point out that IMHO you're "throwing a veto"
>>> rather lightly. I think it makes the discussion more productive if
>>> you take some more effort to back a -1 before issueing it.
>>
>>
>> Get over. I have spent hours upon hours explaining this and wrote up
>> several long emails and documents explaining this in the past. I have
>> given oodles and oodles of links to both java and dot.net based
>> approaches. What is it you find lacking in my previous explanations?
>
>
> - you didn't mention them when vetoeing;
> - it apperas like you haven't bothered to fully digest what the proposal
> was about (see above), and what context it was issued in;
>
> - You've pointed to lots of alternative approaches which look pretty
> promising, but I can remember nor find in the archives any example as to
> why the lifecycle package is so bad it should be dismissed as a "hack".
> Just the fact that something could be implemented differently and is in
> other architectures is not a good enough reason to do it IMO, if the
> other way happens to make sense and accomplish its goals. In fact, I
> have code working just fine in front of my face (fortress) which uses it.
>
> Pete, I think this is not something where we should just say "get over
> it". When we had all the flame fests in august/september, that started
> with some "lightly thrown" vetoes, too.
>
> cheers,
>
> - Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
>> we have discussed moving materials which do not belong at the same
>> level as avalon-framework into the avalon CVS module before.
>
> And yet it hasn't happened.
twist those words around a bit:
and it hasn't happened yet
:D
>> Can you motivate why you think that is not a good idea?
>
> Because it is not common to all containers or development strategies.
So you are saying that materials that go into the avalon CVS module
should be common to all containers and development strategies. Why?
Berin wrote:
> CLARIFICATION:
>
> No one has proposed making them part of FRAMEWORK. It is a question
> of which repository to move to.
>
> It is a question of whether we want to make the "avalon" CVS
> repository support a framework directory structure and an extension
> directory structure.
to make that even more clear (well maybe), the idea is something like
ssh cvs.apache.org
umask 002
cd /home/cvs/avalon
cp -Rfp * framework
cp -Rfp ../avalon-sandbox/lifecycle .
exit
cd ~/cvs/avalon
cvs rm -Rf *
cvs commit -m 'moving into framework/ subdirectory'
cvs up -P -d
this was talked about before; the idea back then was to move everything
that is not generic utility code (ie meta, containerkit, similar stuff,
but not IO or CLI) into the main avalon cvs (when ready to move out of
the sandbox). You would end up with
/home/cvs/avalon
README.txt
LICENSE.txt
framework/
lifecycle/
meta/
interceptor/
fortress/
...
Clearly, neither a meta model nor lifecycle extensions nor interceptors
nor fortress would be common across containers (anytime soon). Its just
about organisation.
> The Marker interfaces will probably be deprecated post fortress
> release. The *Selector interfaces can also be considered for
> deprecation. In the future I can see the release() methods also being
> deprecated.
that's quite another (ancient ;) discussion.
>>>> * the release of the avalon-lifecycle package shall be
>>>> considered as an "optional" extension to the framework
>>>> contracts
>>>
>>> -1
>>>
>>> It is the same approach that has been done before and failed and
>>> can't cleanly produce some aspects like delayed activation,
>>> passivation, persistence, transaction demarcation, bifuricating
>>> interception etc.
>>
>> Taking your -1 as a veto rather than an opinion, you should provide
>> a viable alternative for it to be valid, which AFAIK you haven't
>> done.
>
> Several times before - you even committed one of my emails to CVS.
>
> Interceptors will solve all these problems (and many more besides).
> Go to Rickard Öbergs blog for a good description. Alternatively go
> through the links I have provided in the past. Several good articles
> are available in msdn these days aswell.
Your -1 applies to "the release of the avalon-lifecycle package shall be
considered as an "optional" extension to the framework contracts",
doesn't it? Saying "avalon-lifecycle (c/sh)ould be implemented
differently using interceptors" is a different story alltogether, innit?
I am all for finding the best implementation. In the meantime, fortress
doesn't have an interceptor-based architecture, it sounds like a lot of
work to put it in now, and I think it needs a release.
>> Also, could you please provide more specific information about why
>> the approach in the lifecycle package fails, perhaps with a code
>> example?
>
> Perhaps you could show me how it succeeds.
sure. Fortress provides support for instrumentation management by using
the lifecycle and instrument-manager packages. This is, atm, my usecase
for the lifecycle package, and it succeeds there.
> We have tried it in the
> past and it led to spagetti code.
you think the way fortress does instrumentation is "spaghetti-like"? I
sorta like it. Its the only time I've tried using lifecycle extensions,
IIRC.
>> I would also like to point out that IMHO you're "throwing a veto"
>> rather lightly. I think it makes the discussion more productive if
>> you take some more effort to back a -1 before issueing it.
>
> Get over. I have spent hours upon hours explaining this and wrote up
> several long emails and documents explaining this in the past. I have
> given oodles and oodles of links to both java and dot.net based
> approaches. What is it you find lacking in my previous explanations?
- you didn't mention them when vetoeing;
- it apperas like you haven't bothered to fully digest what the proposal
was about (see above), and what context it was issued in;
- You've pointed to lots of alternative approaches which look pretty
promising, but I can remember nor find in the archives any example as to
why the lifecycle package is so bad it should be dismissed as a "hack".
Just the fact that something could be implemented differently and is in
other architectures is not a good enough reason to do it IMO, if the
other way happens to make sense and accomplish its goals. In fact, I
have code working just fine in front of my face (fortress) which uses it.
Pete, I think this is not something where we should just say "get over
it". When we had all the flame fests in august/september, that started
with some "lightly thrown" vetoes, too.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Peter Donald wrote:
>
> Get over. I have spent hours upon hours explaining this and wrote up several
> long emails and documents explaining this in the past. I have given oodles
> and oodles of links to both java and dot.net based approaches. What is it you
> find lacking in my previous explanations?
possibly the lack of that list of links in the same message as the
veto. issuing a veto with a justification of 'i've explained this
before' is not on, peter. the authority to veto is burdened by
the responsibility to provide justication according to the project/
community rules -- which afaik throughout apache say, 'a veto must
be *accompanied* by a justification.'
so if you would please be so kind as to assemble links to all these
previous messages and explanations that you are using to justify
the veto, i think it would be appreciated -- as opposed to expecting
people to go hunting for them.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 20:44, Leo Simons wrote:
> Peter Donald wrote:
> > On Wed, 12 Mar 2003 03:49, Stephen McConnell wrote:
> >> * that the package be migrated from the avalon-sandbox
> >> CVS to the avalon CVS as a separate project along-side
> >> the avalon framework
> >
> > -1 as it does not belong at same level as framework.
>
> we have discussed moving materials which do not belong at the same level
> as avalon-framework into the avalon CVS module before.
And yet it hasn't happened.
> Can you motivate
> why you think that is not a good idea?
Because it is not common to all containers or development strategies. Look at
all the other stuff that has a similar story.
The Marker interfaces will probably be deprecated post fortress release.
The *Selector interfaces can also be considered for deprecation.
In the future I can see the release() methods also being deprecated.
>
> >> * the release of the avalon-lifecycle package shall be
> >> considered as an "optional" extension to the framework
> >> contracts
> >
> > -1
> >
> > It is the same approach that has been done before and failed and can't
> > cleanly produce some aspects like delayed activation, passivation,
> > persistence, transaction demarcation, bifuricating interception etc.
>
> Taking your -1 as a veto rather than an opinion, you should provide a
> viable alternative for it to be valid, which AFAIK you haven't done.
Several times before - you even committed one of my emails to CVS.
Interceptors will solve all these problems (and many more besides). Go to
Rickard Öbergs blog for a good description. Alternatively go through the
links I have provided in the past. Several good articles are available in
msdn these days aswell.
> Also, could you please provide more specific information about why the
> approach in the lifecycle package fails, perhaps with a code example?
Perhaps you could show me how it succeeds. We have tried it in the past and it
led to spagetti code. Not to mention that pretty much all the major players
in industry moving away from that model to interception based models
(servlets, ejbs, jmx, etc).
> I would also like to point out that IMHO you're "throwing a veto" rather
> lightly. I think it makes the discussion more productive if you take
> some more effort to back a -1 before issueing it.
Get over. I have spent hours upon hours explaining this and wrote up several
long emails and documents explaining this in the past. I have given oodles
and oodles of links to both java and dot.net based approaches. What is it you
find lacking in my previous explanations?
--
Cheers,
Peter Donald
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Peter,
Peter Donald wrote:
> On Wed, 12 Mar 2003 03:49, Stephen McConnell wrote:
>
>> * that the package be migrated from the avalon-sandbox
>> CVS to the avalon CVS as a separate project along-side
>> the avalon framework
>
> -1 as it does not belong at same level as framework.
we have discussed moving materials which do not belong at the same level
as avalon-framework into the avalon CVS module before. Can you motivate
why you think that is not a good idea?
>> * the release of the avalon-lifecycle package shall be
>> considered as an "optional" extension to the framework
>> contracts
>
> -1
>
> It is the same approach that has been done before and failed and can't cleanly
> produce some aspects like delayed activation, passivation, persistence,
> transaction demarcation, bifuricating interception etc.
Taking your -1 as a veto rather than an opinion, you should provide a
viable alternative for it to be valid, which AFAIK you haven't done.
Could you?
Also, could you please provide more specific information about why the
approach in the lifecycle package fails, perhaps with a code example?
I would also like to point out that IMHO you're "throwing a veto" rather
lightly. I think it makes the discussion more productive if you take
some more effort to back a -1 before issueing it. We've pretty much all
come to the conclusion that vetoes should be a last resort, not a first
one. Could you either explain why you disagree with that, or start
following that guideline?
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Wed, 12 Mar 2003 03:49, Stephen McConnell wrote:
>
>
>> * that the package be migrated from the avalon-sandbox
>> CVS to the avalon CVS as a separate project along-side
>> the avalon framework
>>
>
>-1 as it does not belong at same level as framework.
>
Pete:
Given the interfaces in the Avalon framework and there to
provide the patterns and contracts of interaction between a
component and a container, and given that this is not proposed
as part of the framework - but simply as the interfaces
defining contract extension, could you perhaps illuminate us
as to where you believe the package fits and the reasons for
your assertion.
>
>
>> * the release of the avalon-lifecycle package shall be
>> considered as an "optional" extension to the framework
>> contracts
>>
>>
>
>-1
>
Shall I presume that you -1 is that the extensions should not be
considered optional? In which case can I assume that you would
prefer that this is a mandatory requirement on containers? If so,
I would just like to not my personal appreciation for you change in
heart. It's encouraging to see you take a positive attitude to the
development of others. Even so, I still this should remain an
optional requirement with respect to containment compliance.
>
>It is the same approach that has been done before and failed and
>can't cleanly produce some aspects like delayed activation,
>passivation, persistence, transaction demarcation, bifuricating
>interception etc.
>
Could you please expand on the point you raised above. My own
experience has shown that the interfaces are sufficiently general
to provide solutions to several of the above areas. Perhaps you
are confusing the current work with something that was done before
(that I am not aware of). I'm finding it difficult to understand
why a component provided support for some aspect of a lifecycle
can be implemented using the interfaces in question. Is there, in
your opinion, some characteristic of the interfaces that inhibit
implementation of any of the above - or were these just random
examples?
I would be really interested in your reply because I'm currently
using extensions across several areas you mentioned and finding
the overall approach *really* functional. Obviously, I must be
doing something wrong.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
> personally, I don't appreciate the classification of result of the
> work that put into the extension package by Berin, Marcus and
> myself as a "hack"
Fair enough. But you can express your discontent of Peter's lack of respect
with more self-control.
Obviously, progress cannot be made if people continuously block change.
However, please remember that a binding -1 vote, a veto, is NOT BINDING
without technical justification. That is NOT an empty qualification to
"observe the niceties" of social interaction. A technical reason is
obligatory, and lays the ground for resolving the conflict.
So please focus on the TECHNICAL ISSUES at hand.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
hi gang,
just a note that we've moved discussion of the nontechnical part of the
matter at hand to the PMC list.
cheers,
- Leo
Stephen McConnell wrote:
> Nicola Ken Barozzi wrote:
>> Stephen McConnell wrote, On 11/03/2003 23.42:
<stuff/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote, On 11/03/2003 23.42:
> ...
>
>> Knowing that day-to-day I have your considered remarks, insightful
>> comments and astute observations to look forward to
>
> ...
>
> Stephen, please stop this nonsense. With this comment I see only one
> of you two behaving like a child, and it's not Peter.
>
Nicola:
Maybe you read to lie down and let Peter Donald miss all over the place
but personally, I don't appreciate the classification of result of the
work that put into the extension package by Berin, Marcus and myself as
a "hack" - a remark that typifies his attitude and appreciation for
others. As long as Peter Donald maintains his ambivalence to the ideas
and contributions of those around him, he will gain from me the respect
he deserves. I am simply am not interested in playing a game of
tolerating the rubbish the Pete likes to put forth. When Pete gets his
act together and starts to behave with some degree of respect and
appreciation of other - then, and only then, will he gain any degree of
respect from myself.
Apologies to everyone about this - but sorry - I'm not ready for Peter
Donald to screw this community twice. If he has an option - surely Peter
Donald presumably has a sufficient intellect to present his opinions in
a constructive and helpful manner. If Peter Donald chooses not do to
this - what are the conclusions that your can draw?
Please - Berin is not fool, neither is Marcus, and neither and I.
If you have a complaint - take it up Peter Donald.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote, On 11/03/2003 23.42:
...
> Knowing that day-to-day I have your considered remarks, insightful
> comments and astute observations to look forward to
...
Stephen, please stop this nonsense. With this comment I see only one of
you two behaving like a child, and it's not Peter.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 22:10, Stefano Mazzocchi wrote:
> no, not the ASF board or the PMC chair, but a single avalon committer
> that will start proposing to kick offending *code* out of the avalon
> repositories.
+1
Better you than me.
--
Cheers,
Peter Donald
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 23:57, Leo Simons wrote:
> indeed! Consider the amount of trouble you have replacing apache 1.3
> with 2.0.
Lets not use that as an example. Having just watched someone jump through
loops to get php and everything else playing nicely on a debian system I
don't think that should be our baseline. ;)
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
>
>>From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>>
>>Consider the amount of trouble you have replacing apache 1.3
>>with 2.0.
>
>
> Ummm... As one who might have to do that - I hope this is
> irony.
Replacing Apache 1.3 with 2.0 is piece of cake if you don't have to
rewrite your own modules.
that's because teh module api was completely refactored and cleaned up
in an totally back-incompatible manner.
But since almost nobody nowadays writes an apache module, this should
not be a problem for you as a web server user.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> Consider the amount of trouble you have replacing apache 1.3
> with 2.0.
Ummm... As one who might have to do that - I hope this is
irony.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
> On Fri, 14 Mar 2003 22:55, Niclas Hedhman wrote:
>
>>Hooahh, and how much of that will affect me, just starting to migrate my
>>"legacy" application to Avalon-Phoenix?? Not at all? A little bit?
>
> If you are using just framework/phoenix then not at all. If you use some of
> the other components (excalibur, cornerstone) then you may be required to
> change package names but we will provide a clear migration path.
indeed! Consider the amount of trouble you have replacing apache 1.3
with 2.0. We're aiming at a similar stable migration path, if there is a
need for one. Apache is about solid, quality software, and avalon is no
different.
As a general suggestion, when you're new to an open source project
mailing list don't get too scared of wild ideas flying around all the
time. We do that a lot, like spending a month or two talking about a
radical new avalon 5, and then what happens in the end is that we
solidify our release process even more and remove an '@depcrated' tag
from 2 or 3 sourcefiles :D
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 22:55, Niclas Hedhman wrote:
> Hooahh, and how much of that will affect me, just starting to migrate my
> "legacy" application to Avalon-Phoenix?? Not at all? A little bit?
If you are using just framework/phoenix then not at all. If you use some of
the other components (excalibur, cornerstone) then you may be required to
change package names but we will provide a clear migration path.
--
Cheers,
Peter Donald
*----------------------------------------------------*
| "the mother of idiots is always pregnant." |
*----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Sunday 16 March 2003 00:25, Stefano Mazzocchi wrote:
>
>>Niclas Hedhman wrote:
>>
>>>Thanks to everyone who has brought Avalon-Phoenix this far, although
>>>reading this list over the last couple of days, I must say you quabble(?)
>>>a lot.
>>
>>quabble?
>
>
> I found it - "QUIBBLE"
>
> http://dictionary.reference.com/search?q=quibble&r=2
>
> "To find fault or criticize for petty reasons; cavil."
ah! then yes, Avalon is 'picky-land', Niclas. There is a history of a
hundred messages-long threads for just changing the name of a single
empty interface.
Now, everywhere else, people would simply think you are nuts if you get
so picky. Here, they would think you are nuts if you are *NOT* picky
about names and ultra elegance.
But Avalon is learning how to mix that elegance-driven design with
real-life concerns and this is, IMO, a very good thing.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Sunday 16 March 2003 00:25, Stefano Mazzocchi wrote:
> Niclas Hedhman wrote:
> > Thanks to everyone who has brought Avalon-Phoenix this far, although
> > reading this list over the last couple of days, I must say you quabble(?)
> > a lot.
>
> quabble?
I found it - "QUIBBLE"
http://dictionary.reference.com/search?q=quibble&r=2
"To find fault or criticize for petty reasons; cavil."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>P.S. Stephen - You really enjoy writing emails, don't you ;o)
>
It's more fun than watching CNN.
;-)
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> So here I am. You met me ONline... Stefano knows me for being a loud and
> critical ba***rd at the Cocoon list.
That's for sure :-)
Happy to see you moving some of reality touch overhere.
> Well, I know that individuals are still individuals in a community, but I
> interpreted 2 things in Peter's message + one from other messages surrounding
> Merlin;
>
> 1. The changes were a roadmap of what to do next.
> 2. "Implied" that a lot of "dead meat" is going to be cut away, and new "dead
> meat" to be defined.
> 3. Phoenix future may be a deprecation into Merlin.
Hmmm, nobody can know what will happen if avalon reaches that point.
> Also, Stefano has been fairly "loud" about Cocoon's dependency on Avalon, and
> Avalon was a "moving target", continiously creating problems in the Cocoon
> camp. That's part of my baggage coming here.
i would like to point out that I'm fairly pleased to see how avalon is
working toward resolving this. Also Berin has been valuable in helping
us getting things in place and keeping up updated on where avalon is going.
the proof of this is that cocoon was now able to compile on gump last night.
This is a proof of the fact that work and communication has been
valuable for both projects.
> BTW, I managed the conversion ( Phase I ) of my Process Control framework into
> a Phoenix server in just over 2 days (+4 hours of studying Avalon in papers).
> Steps that were taken;
> 1. Introduced a new class, implementing a bunch of Avalon interfaces, and
> coping the "startup code" from the old bootstrapper. And a .xinfo file for
> this block.
> 2. Moved some code around in that class.
> 3. Change in the build.xml
> 4. Changed the code for establishing ProductRoot and ProjectRoot dirs.
> 5. Created a new "legacy Logger" class, and let the "LoggerFactory" serve it,
> mapping old logs to Avalon Logger.
>
> 6. A separate project for the SAR assembly. Killed off one text file in favour
> of config.xml.
>
> That's it.
>
> Phase II is starting next week, where the legacy services will be transformed
> into Avalon Blocks. And the legacy stuff should be just as easy as the "whole
> app", since they follow the same "similar" life cycle as Avalon has in place.
>
> I AM VERY PLEASED!!!!
there are jewels sparsed around avalon. sometimes it's hard to find
them, sometimes, it's hard to appreciate them.
I consider ego fights a transitional thing, hopefully, in the future,
those egos will get tired of fighting and new people will bring fresh
air and things will get back to normal testosterone levels.
> Thanks to everyone who has brought Avalon-Phoenix this far, although reading
> this list over the last couple of days, I must say you quabble(?) a lot.
quabble?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> Phase II is starting next week, where the legacy services will be transformed
> into Avalon Blocks. And the legacy stuff should be just as easy as the "whole
> app", since they follow the same "similar" life cycle as Avalon has in place.
>
> I AM VERY PLEASED!!!!
>
> Thanks to everyone who has brought Avalon-Phoenix this far, although reading
> this list over the last couple of days, I must say you quabble(?) a lot.
Maybe so, but we bring up important points to make things like your
Phoenix conversion go smoothly. In a project that affects core things,
correctness is very important.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Saturday 15 March 2003 05:54, Stephen McConnell wrote:
> Stefano Mazzocchi wrote:
> > Stephen McConnell wrote:
> >> Niclas Hedhman wrote:
> >>> Hooahh, and how much of that will affect me, just starting to
> >>> migrate my "legacy" application to Avalon-Phoenix?? Not at all? A
> >>> little bit?
> >>
> >> Please note that the comments express by Peter Donald should in no
> >> way be considered as a position of this community or in any way
> >> reflective of the community consensus.
> >
> > I think everybody around apache knows that and Niclas has been around
> > for enough time to know this very well.
>
> Please excuse my ignorance. I have not had the opportunity of meeting
> Niclas Hedhman on-line or off. From his comments it was apparent to me
> that he considered the comments and opinions as expressed by Peter
> Donald's as in some way or form an indication of the community opinion.
> My response was provided with the objective of reassuring Niclas Hedhman
> that the Avalon Community has not taken any such decision. I would like
> to reassert the point that the opinions stated by Peter Donald are his
> own and should not be interpreted in any way or form as a reflection of
> the opinions of the Avalon Community at this time.
So here I am. You met me ONline... Stefano knows me for being a loud and
critical ba***rd at the Cocoon list.
Well, I know that individuals are still individuals in a community, but I
interpreted 2 things in Peter's message + one from other messages surrounding
Merlin;
1. The changes were a roadmap of what to do next.
2. "Implied" that a lot of "dead meat" is going to be cut away, and new "dead
meat" to be defined.
3. Phoenix future may be a deprecation into Merlin.
Also, Stefano has been fairly "loud" about Cocoon's dependency on Avalon, and
Avalon was a "moving target", continiously creating problems in the Cocoon
camp. That's part of my baggage coming here.
BTW, I managed the conversion ( Phase I ) of my Process Control framework into
a Phoenix server in just over 2 days (+4 hours of studying Avalon in papers).
Steps that were taken;
1. Introduced a new class, implementing a bunch of Avalon interfaces, and
coping the "startup code" from the old bootstrapper. And a .xinfo file for
this block.
2. Moved some code around in that class.
3. Change in the build.xml
4. Changed the code for establishing ProductRoot and ProjectRoot dirs.
5. Created a new "legacy Logger" class, and let the "LoggerFactory" serve it,
mapping old logs to Avalon Logger.
6. A separate project for the SAR assembly. Killed off one text file in favour
of config.xml.
That's it.
Phase II is starting next week, where the legacy services will be transformed
into Avalon Blocks. And the legacy stuff should be just as easy as the "whole
app", since they follow the same "similar" life cycle as Avalon has in place.
I AM VERY PLEASED!!!!
Thanks to everyone who has brought Avalon-Phoenix this far, although reading
this list over the last couple of days, I must say you quabble(?) a lot.
Cheers.
Niclas
P.S. Stephen - You really enjoy writing emails, don't you ;o)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
> [ ...] Based on the comments from XXXXX, he is clearly and without
> community consultation undermining the decisions of the same
> community. XXXXX has the right to do this - however, [...] The
> community surrounding this application are demonstrating a very clear
> silence with respect to the technical direction of the project with
> the single exception of XXXXX. In that particular case, XXXXX is
> choosing to undermine community interests in favor of his own.
> Naturally, while I don't endorse this actions - I am concerned with
> the impact of his actions on the greater Avalon Community.
Respect! This is a public email list. Are you trying to make sure he
never gets a job again. This is your conjecture Stephen, take it to PMC
list. How many times do I have to tell you this. How would you like it
is Google returned shit said about you by another.
Hold all in high esteem. It is very very simple. Note I have not put
your surname in this mail.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Niclas Hedhman wrote:
>>
>>> On Friday 14 March 2003 20:02, Peter Donald wrote:
>>>
>>>
>>>> On Fri, 14 Mar 2003 22:10, Stefano Mazzocchi wrote:
>>>>
>>>>
>>>>> This is the problem and Peter appears to be the only one *really*
>>>>> watching over what's going on in this project. Probably because he's
>>>>> doing some sneaky moves himself so he's more sensible about them.
>>>>>
>>>>
>>>>
>>>> Please don't. I have been fairly open about what I am going to be
>>>> doing
>>>> over next bit.
>>>>
>>>> I am moving all the code out that I am sole author for. I am
>>>> encouraging
>>>> others to do the same - I hope within a few months that most of
>>>> avalon-apps
>>>> will be gone and significant portions of excalibur will also be
>>>> gone. Paul
>>>> has already moved some stuff out, as has Eung-Ju and I. I have been
>>>> poking
>>>> the other Peter to do the same.
>>>>
>>>> In time I will start poking some of the Cocoon peeps to migrate
>>>> some of the
>>>> Cocoon originated stuff back into Cocoon - much better for Cocoon
>>>> that way
>>>> and hopefully better for Avalon.
>>>>
>>>> Post fortress release I intend to attempt to get framework cleaned up;
>>>> marker interfaces, component.*, *Selectors deprecated. Provide a solid
>>>> ECM-> fortress migration path and finally start process of dumping the
>>>> crappy code we have been carrying for ages.
>>>>
>>>> At the same time I have consolidating Phoenix. Basically means
>>>> getting unit
>>>> tests solid and trying to get 95% test coverage on all the supporting
>>>> libraries. I also plan to make it more agile by reducing dependencies,
>>>> reducing duplication, internal decoupling and so forth.
>>>>
>>>> In the end I want to see the majority of cornerstone/excalibur/apps
>>>> gone.
>>>> Framework to be half deprecated, docs to be decrufted. Hows that for
>>>> sneaky?
>>>>
>>>
>>>
>>>
>>>
>>> Hooahh, and how much of that will affect me, just starting to
>>> migrate my "legacy" application to Avalon-Phoenix?? Not at all? A
>>> little bit?
>>>
>>>
>>
>> Please note that the comments express by Peter Donald should in no
>> way be considered as a position of this community or in any way
>> reflective of the community consensus.
>
>
> I think everybody around apache knows that and Niclas has been around
> for enough time to know this very well.
Please excuse my ignorance. I have not had the opportunity of meeting
Niclas Hedhman on-line or off. From his comments it was apparent to me
that he considered the comments and opinions as expressed by Peter
Donald's as in some way or form an indication of the community opinion.
My response was provided with the objective of reassuring Niclas Hedhman
that the Avalon Community has not taken any such decision. I would like
to reassert the point that the opinions stated by Peter Donald are his
own and should not be interpreted in any way or form as a reflection of
the opinions of the Avalon Community at this time.
>> Irrespective of the actions of Peter Donald within or external to the
>> Avalon Community, concrete and viable solutions exist today to
>> protect any investment you make into the development of Phoenix
>> components. However, from a pragmatic development perspective, I
>> would strongly recommend that you do not use interfaces or classes
>> under the phoenix namespace - which simply means that you are
>> building a portable component. For more information concerning the
>> development of a code base that is container independent - you can
>> email requests to either the user or dev list. For an example of a
>> complex Phoenix style application that is maintaining container
>> independence please take a look at the James project.
>
>
> Can we stop throwing FUD and get back to work together?
You prior email referred to the Avalon Lifecycle project as a "hack".
This email refers to real and pragmatic suggestions concerning the use
and development of components related to Phoenix as FUD. I'm assuming
your "hack" remark was made with the same degree of indifference to the
subject as the message from Peter Donald. Should I assume your FUD
remark is made is the same vain or should I assume that you have
something more substantive to put forward?
Lets' focus on the important aspects. There is in my personal
perception - some degree on instability related to the Phoenix project.
I (personally and as a community member) do not consider this as a
problem on the grounds that (a) there are several members of the Phoenix
community that are capable of maintaining the product, and (b)
components developer for Phoenix can be deployed today in non-Phoenix
containers. I.e. in the worst case scenario there is a viable solution
for the user community.
>
> Sheesh.
No familiar with that particular word.
:-)
>
> if there is something wrong with Phoenix, what stops you from going
> there and fix it instead of whining or even propose your own version
> of it?
Sorry - but where exactly am I whining about Phoenix? I am only
presenting those actions that I happen to consider as the most
appropriate for any developer using the Phoenix product. Based on the
comments from Peter Donald, he is clearly and without community
consultation undermining the decisions of the same community. Peter
Donald has the right to do this - however, as a member of this
community, I am concerned about the interests of users of the Avalon
technologies. In particular up on the top-seven of my concerns are the
users of the Phoenix application. The community surrounding this
application are demonstrating a very clear silence with respect to the
technical direction of the project with the single exception of Peter
Donald. In that particular case, Peter Donald is choosing to undermine
community interests in favor of his own. Naturally, while I don't
endorse this actions - I am concerned with the impact of his actions on
the greater Avalon Community.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
>
> Niclas Hedhman wrote:
>
>> On Friday 14 March 2003 20:02, Peter Donald wrote:
>>
>>
>>> On Fri, 14 Mar 2003 22:10, Stefano Mazzocchi wrote:
>>>
>>>
>>>> This is the problem and Peter appears to be the only one *really*
>>>> watching over what's going on in this project. Probably because he's
>>>> doing some sneaky moves himself so he's more sensible about them.
>>>>
>>>
>>> Please don't. I have been fairly open about what I am going to be doing
>>> over next bit.
>>>
>>> I am moving all the code out that I am sole author for. I am encouraging
>>> others to do the same - I hope within a few months that most of
>>> avalon-apps
>>> will be gone and significant portions of excalibur will also be gone.
>>> Paul
>>> has already moved some stuff out, as has Eung-Ju and I. I have been
>>> poking
>>> the other Peter to do the same.
>>>
>>> In time I will start poking some of the Cocoon peeps to migrate some
>>> of the
>>> Cocoon originated stuff back into Cocoon - much better for Cocoon
>>> that way
>>> and hopefully better for Avalon.
>>>
>>> Post fortress release I intend to attempt to get framework cleaned up;
>>> marker interfaces, component.*, *Selectors deprecated. Provide a solid
>>> ECM-> fortress migration path and finally start process of dumping the
>>> crappy code we have been carrying for ages.
>>>
>>> At the same time I have consolidating Phoenix. Basically means
>>> getting unit
>>> tests solid and trying to get 95% test coverage on all the supporting
>>> libraries. I also plan to make it more agile by reducing dependencies,
>>> reducing duplication, internal decoupling and so forth.
>>>
>>> In the end I want to see the majority of cornerstone/excalibur/apps
>>> gone.
>>> Framework to be half deprecated, docs to be decrufted. Hows that for
>>> sneaky?
>>>
>>
>>
>>
>> Hooahh, and how much of that will affect me, just starting to migrate
>> my "legacy" application to Avalon-Phoenix?? Not at all? A little bit?
>>
>>
>
> Please note that the comments express by Peter Donald should in no way
> be considered as a position of this community or in any way reflective
> of the community consensus.
I think everybody around apache knows that and Niclas has been around
for enough time to know this very well.
> Irrespective of the actions of Peter Donald
> within or external to the Avalon Community, concrete and viable
> solutions exist today to protect any investment you make into the
> development of Phoenix components. However, from a pragmatic
> development perspective, I would strongly recommend that you do not use
> interfaces or classes under the phoenix namespace - which simply means
> that you are building a portable component. For more information
> concerning the development of a code base that is container independent
> - you can email requests to either the user or dev list. For an example
> of a complex Phoenix style application that is maintaining container
> independence please take a look at the James project.
Can we stop throwing FUD and get back to work together?
Sheesh.
if there is something wrong with Phoenix, what stops you from going
there and fix it instead of whining or even propose your own version of it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Friday 14 March 2003 20:02, Peter Donald wrote:
>
>
>>On Fri, 14 Mar 2003 22:10, Stefano Mazzocchi wrote:
>>
>>
>>>This is the problem and Peter appears to be the only one *really*
>>>watching over what's going on in this project. Probably because he's
>>>doing some sneaky moves himself so he's more sensible about them.
>>>
>>>
>>Please don't. I have been fairly open about what I am going to be doing
>>over next bit.
>>
>>I am moving all the code out that I am sole author for. I am encouraging
>>others to do the same - I hope within a few months that most of avalon-apps
>>will be gone and significant portions of excalibur will also be gone. Paul
>>has already moved some stuff out, as has Eung-Ju and I. I have been poking
>>the other Peter to do the same.
>>
>>In time I will start poking some of the Cocoon peeps to migrate some of the
>>Cocoon originated stuff back into Cocoon - much better for Cocoon that way
>>and hopefully better for Avalon.
>>
>>Post fortress release I intend to attempt to get framework cleaned up;
>>marker interfaces, component.*, *Selectors deprecated. Provide a solid
>>ECM-> fortress migration path and finally start process of dumping the
>>crappy code we have been carrying for ages.
>>
>>At the same time I have consolidating Phoenix. Basically means getting unit
>>tests solid and trying to get 95% test coverage on all the supporting
>>libraries. I also plan to make it more agile by reducing dependencies,
>>reducing duplication, internal decoupling and so forth.
>>
>>In the end I want to see the majority of cornerstone/excalibur/apps gone.
>>Framework to be half deprecated, docs to be decrufted. Hows that for
>>sneaky?
>>
>>
>
>
>Hooahh, and how much of that will affect me, just starting to migrate my
>"legacy" application to Avalon-Phoenix?? Not at all? A little bit?
>
>
Please note that the comments express by Peter Donald should in no way
be considered as a position of this community or in any way reflective
of the community consensus. Irrespective of the actions of Peter Donald
within or external to the Avalon Community, concrete and viable
solutions exist today to protect any investment you make into the
development of Phoenix components. However, from a pragmatic
development perspective, I would strongly recommend that you do not use
interfaces or classes under the phoenix namespace - which simply means
that you are building a portable component. For more information
concerning the development of a code base that is container independent
- you can email requests to either the user or dev list. For an example
of a complex Phoenix style application that is maintaining container
independence please take a look at the James project.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Friday 14 March 2003 20:02, Peter Donald wrote:
> On Fri, 14 Mar 2003 22:10, Stefano Mazzocchi wrote:
> > This is the problem and Peter appears to be the only one *really*
> > watching over what's going on in this project. Probably because he's
> > doing some sneaky moves himself so he's more sensible about them.
>
> Please don't. I have been fairly open about what I am going to be doing
> over next bit.
>
> I am moving all the code out that I am sole author for. I am encouraging
> others to do the same - I hope within a few months that most of avalon-apps
> will be gone and significant portions of excalibur will also be gone. Paul
> has already moved some stuff out, as has Eung-Ju and I. I have been poking
> the other Peter to do the same.
>
> In time I will start poking some of the Cocoon peeps to migrate some of the
> Cocoon originated stuff back into Cocoon - much better for Cocoon that way
> and hopefully better for Avalon.
>
> Post fortress release I intend to attempt to get framework cleaned up;
> marker interfaces, component.*, *Selectors deprecated. Provide a solid
> ECM-> fortress migration path and finally start process of dumping the
> crappy code we have been carrying for ages.
>
> At the same time I have consolidating Phoenix. Basically means getting unit
> tests solid and trying to get 95% test coverage on all the supporting
> libraries. I also plan to make it more agile by reducing dependencies,
> reducing duplication, internal decoupling and so forth.
>
> In the end I want to see the majority of cornerstone/excalibur/apps gone.
> Framework to be half deprecated, docs to be decrufted. Hows that for
> sneaky?
Hooahh, and how much of that will affect me, just starting to migrate my
"legacy" application to Avalon-Phoenix?? Not at all? A little bit?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Sat, 15 Mar 2003 05:27, Stefano Mazzocchi wrote:
>
>>>I am moving all the code out that I am sole author for. I am encouraging
>>>others to do the same - I hope within a few months that most of
>>>avalon-apps will be gone and significant portions of excalibur will also
>>>be gone. Paul has already moved some stuff out, as has Eung-Ju and I. I
>>>have been poking the other Peter to do the same.
>>
>>Why do you think this is good? (I'm not ironic, I'm just curious)
>
>
> Because it is not developed by Avalon but by individuals. Some it is dead or
> not under development or use. Even the solid stuff will never get released -
> at least not if it has my name on it :) Better for the code to move out and
> better for Avalon as use of a product is determined by merit alone - not
> whether it is inside Apache.
I resonate with your reasoning.
Thank you for sharing your thoughts.
The only problem I see is that there are potentially tricky copyright
issues that must be resolved before those moves if we want to avoid
future legal problems.
But if everything is done in a friendly attitude and for the good cause
of Avalon, I'm sure there won't be problems.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 15 Mar 2003 05:27, Stefano Mazzocchi wrote:
> > I am moving all the code out that I am sole author for. I am encouraging
> > others to do the same - I hope within a few months that most of
> > avalon-apps will be gone and significant portions of excalibur will also
> > be gone. Paul has already moved some stuff out, as has Eung-Ju and I. I
> > have been poking the other Peter to do the same.
>
> Why do you think this is good? (I'm not ironic, I'm just curious)
Because it is not developed by Avalon but by individuals. Some it is dead or
not under development or use. Even the solid stuff will never get released -
at least not if it has my name on it :) Better for the code to move out and
better for Avalon as use of a product is determined by merit alone - not
whether it is inside Apache.
--
Cheers,
Peter Donald
*----------------------------------------------------*
| "the mother of idiots is always pregnant." |
*----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Fri, 14 Mar 2003 22:10, Stefano Mazzocchi wrote:
>
>>This is the problem and Peter appears to be the only one *really*
>>watching over what's going on in this project. Probably because he's
>>doing some sneaky moves himself so he's more sensible about them.
>
>
> Please don't. I have been fairly open about what I am going to be doing over
> next bit.
Sorry, you are right, that was a little over the line. I apologize.
> I am moving all the code out that I am sole author for. I am encouraging
> others to do the same - I hope within a few months that most of avalon-apps
> will be gone and significant portions of excalibur will also be gone. Paul
> has already moved some stuff out, as has Eung-Ju and I. I have been poking
> the other Peter to do the same.
Why do you think this is good? (I'm not ironic, I'm just curious)
> In time I will start poking some of the Cocoon peeps to migrate some of the
> Cocoon originated stuff back into Cocoon - much better for Cocoon that way
> and hopefully better for Avalon.
I'm *soooo* glad to hear that. Moving stuff from cocoon to avalon was a
mistake. I agree.
The problem is that I don't want to see yet another migration. there are
many avalon committers maintaining that code. As long as this this done,
I don't see a reason to move it back.
> Post fortress release I intend to attempt to get framework cleaned up; marker
> interfaces, component.*, *Selectors deprecated. Provide a solid ECM->
> fortress migration path and finally start process of dumping the crappy code
> we have been carrying for ages.
As long as you provide a sane and socially-acceptable migration path,
I'm all for it.
> At the same time I have consolidating Phoenix. Basically means getting unit
> tests solid and trying to get 95% test coverage on all the supporting
> libraries. I also plan to make it more agile by reducing dependencies,
> reducing duplication, internal decoupling and so forth.
Good stuff.
> In the end I want to see the majority of cornerstone/excalibur/apps gone.
> Framework to be half deprecated, docs to be decrufted. Hows that for sneaky?
Finally I was able to have you speak about what your plans are.
Great.
Now that we know your vision, at least, we can interpret your moves.
Thanks for clarifying. I think this is really helpful for everybody.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
dvillevalois@phpapp.org wrote:
> Quoting Paul Hammant <pa...@yahoo.com>:
>
> Does this mean that in the future the Avalon project won't host any components
> but only the framework and some RI containers ??
> I thought that the new avalon.apache.org global project change was to enable
> such a big code base, wasn't it ? Don't understand anymore!!!
The components question is still in the air. To be fair, alot of
Excalibur code is merely utility code--not components. In fact I
would say most of the named projects are that way.
The purpose of avalon.apache.org global project change is to allow
us to focus on what we do best. Also to let us manage ourselves
a little better than has been done in the past.
Eventually all utility code will either be donated to other Apache
projects, or through a formal process (there is the legalities that
the ASF owns the code in our CVS repos) moved to a third party
location that best fits it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by dv...@phpapp.org.
Thanks for the quick answer...
> > Does this mean that in the future the Avalon project won't host any
> components
> > but only the framework and some RI containers ??
> > I thought that the new avalon.apache.org global project change was to
> enable
> > such a big code base, wasn't it ? Don't understand anymore!!!
>
> No don't worry. There will be highly resuable components too.
>
> It is just that some of us (myself most guilty) were filling our CVs
> with cruft. We're making a
> few snips taht in the end will make the picture of Avalon clearer.
Okay, cool. I feel like i must witness (as an Avalon new commer) that you are
right. I was very frightened the first time i've checkout the CVS. The last time
i was frightened was when i looked in the build system of the framework,
Excalibur and LogKit. Thoses circular dependencies are really a pain for people
who work on IDEs like Eclipse...
But anyway, i love all the Avalon concept...
A+. Didier.
BTW: I still do not receive some of the emails, verified configurations of my
mail tools, checked my firewall (you never know :) ) but nothing changes... :(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Paul Hammant <pa...@yahoo.com>.
> > > In the end I want to see the majority of cornerstone/excalibur/apps
> > gone.
> > > Framework to be half deprecated, docs to be decrufted. Hows that for
> > sneaky?
> >
> > OK, lighten up folks, all that is unquestioned good work, though I'm not
> > sure home much of
> > Cornerstone is to go (that has not been trimmed already) :-)
>
> Does this mean that in the future the Avalon project won't host any components
> but only the framework and some RI containers ??
> I thought that the new avalon.apache.org global project change was to enable
> such a big code base, wasn't it ? Don't understand anymore!!!
No don't worry. There will be highly resuable components too.
It is just that some of us (myself most guilty) were filling our CVs with cruft. We're making a
few snips taht in the end will make the picture of Avalon clearer.
Regards,
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by dv...@phpapp.org.
Quoting Paul Hammant <pa...@yahoo.com>:
> Peter,
>
> ** Folks, can we drop this in the public list? It is being discussed
> **
> ** in the PMC list. We'll come back with some requests and ideas maybe
> **
> ** shortly.
> **
Thanks :)
> > In the end I want to see the majority of cornerstone/excalibur/apps
> gone.
> > Framework to be half deprecated, docs to be decrufted. Hows that for
> sneaky?
>
> OK, lighten up folks, all that is unquestioned good work, though I'm not
> sure home much of
> Cornerstone is to go (that has not been trimmed already) :-)
Does this mean that in the future the Avalon project won't host any components
but only the framework and some RI containers ??
I thought that the new avalon.apache.org global project change was to enable
such a big code base, wasn't it ? Don't understand anymore!!!
Cheers, Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Paul Hammant <pa...@yahoo.com>.
Peter,
> Please don't. I have been fairly open about what I am going to be doing over
> next bit.
>
> I am moving all the code out that I am sole author for. I am encouraging
> others to do the same - I hope within a few months that most of avalon-apps
> will be gone and significant portions of excalibur will also be gone. Paul
> has already moved some stuff out, as has Eung-Ju and I. I have been poking
> the other Peter to do the same.
All true... but potentially there is some problem binging back Spice code
for reuse in Avalon on a couple of levels.
** Folks, can we drop this in the public list? It is being discussed **
** in the PMC list. We'll come back with some requests and ideas maybe **
** shortly. **
> At the same time I have consolidating Phoenix. Basically means getting unit
> tests solid and trying to get 95% test coverage on all the supporting
> libraries. I also plan to make it more agile by reducing dependencies,
> reducing duplication, internal decoupling and so forth.
All Great work, keep it up dude.
> In the end I want to see the majority of cornerstone/excalibur/apps gone.
> Framework to be half deprecated, docs to be decrufted. Hows that for sneaky?
OK, lighten up folks, all that is unquestioned good work, though I'm not sure home much of
Cornerstone is to go (that has not been trimmed already) :-)
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 22:10, Stefano Mazzocchi wrote:
> This is the problem and Peter appears to be the only one *really*
> watching over what's going on in this project. Probably because he's
> doing some sneaky moves himself so he's more sensible about them.
Please don't. I have been fairly open about what I am going to be doing over
next bit.
I am moving all the code out that I am sole author for. I am encouraging
others to do the same - I hope within a few months that most of avalon-apps
will be gone and significant portions of excalibur will also be gone. Paul
has already moved some stuff out, as has Eung-Ju and I. I have been poking
the other Peter to do the same.
In time I will start poking some of the Cocoon peeps to migrate some of the
Cocoon originated stuff back into Cocoon - much better for Cocoon that way
and hopefully better for Avalon.
Post fortress release I intend to attempt to get framework cleaned up; marker
interfaces, component.*, *Selectors deprecated. Provide a solid ECM->
fortress migration path and finally start process of dumping the crappy code
we have been carrying for ages.
At the same time I have consolidating Phoenix. Basically means getting unit
tests solid and trying to get 95% test coverage on all the supporting
libraries. I also plan to make it more agile by reducing dependencies,
reducing duplication, internal decoupling and so forth.
In the end I want to see the majority of cornerstone/excalibur/apps gone.
Framework to be half deprecated, docs to be decrufted. Hows that for sneaky?
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Stefano Mazzocchi wrote, On 14/03/2003 12.10:
>> ...
>>
>>> This project used to be the place where people discussed
>>> architectural issues about new paradigms that extended object
>>> orientation.
>>>
>>> What happened to that?
>>
>>
>>
>> Someone decided to reply with smartass comments to technical matters
>> and discussions.
>
>
> but what if those smartass comments contain gold and not shit as they
> seem from ego-fragile minds?
>
>>> Since reaching consensus on Avalon 5 was too hard, several of you
>>> are trying to push your ideas into the framework by working it thru
>>> your one-man-show container.
>>
>>
>> Example?
>
>
> 1) things are developped in merlin
> 2) things are developped in fortress
> 3) three people work together to merge ideas
> 4) then it's proposed to be made part of framework
>
> Is my perception wrong?
YES.
I'll have a more comprehensive anser for you shortly.
Cheers, Steve.
>
>
>>> This is the problem and Peter appears to be the only one *really*
>>> watching over what's going on in this project. Probably because he's
>>> doing some sneaky moves himself so he's more sensible about them.
>>>
>>> Sure, he uses his usual smartass tone that really used to irritate
>>> me, but I'm now able to sense his frustruation and I resonate with it.
>>>
>>> One-man-shows have to stop.
>>>
>>> *all* of them.
>>>
>>> Please, and this is for everybody, work to reach consensus or leave.
>>
>>
>>
>> Are you implying that the lifecycle extension system is a one-man show?
>>
>> I remember extensive discussions and changes about them, all here on
>> this mailing list. I also remember a joint Fortress-Merlin effort on
>> them.
>>
>>
>> We have a tentative roadmap we have informally agreed upon. IIUC the
>> only one that does not acknowledge it is Peter. We have discussed *at
>> lengths* in the past about getting to a single design, and you know
>> what happened.
>>
>>
>> We want consensus, yes we do. Here is the roadmap; since you resonate
>> with Peter, lead us into the discussion (no pun intended) and update
>> the STATUS file.
>> http://cvs.apache.org/viewcvs/avalon/STATUS.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
>
>
> This has *NOTHING* to do with placing stuff into framework.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>
> 1) things are developped in merlin
> 2) things are developped in fortress
> 3) three people work together to merge ideas
> 4) then it's proposed to be made part of framework
>
> Is my perception wrong?
Yes. It was *never* meant to be *part* of framework. I repeat that:
it was *never* meant to be part of framework. Never.
Please remove that from your thinking.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stefano Mazzocchi wrote, On 14/03/2003 12.10:
> ...
>
>> This project used to be the place where people discussed architectural
>> issues about new paradigms that extended object orientation.
>>
>> What happened to that?
>
>
> Someone decided to reply with smartass comments to technical matters and
> discussions.
but what if those smartass comments contain gold and not shit as they
seem from ego-fragile minds?
>> Since reaching consensus on Avalon 5 was too hard, several of you are
>> trying to push your ideas into the framework by working it thru your
>> one-man-show container.
>
> Example?
1) things are developped in merlin
2) things are developped in fortress
3) three people work together to merge ideas
4) then it's proposed to be made part of framework
Is my perception wrong?
>> This is the problem and Peter appears to be the only one *really*
>> watching over what's going on in this project. Probably because he's
>> doing some sneaky moves himself so he's more sensible about them.
>>
>> Sure, he uses his usual smartass tone that really used to irritate me,
>> but I'm now able to sense his frustruation and I resonate with it.
>>
>> One-man-shows have to stop.
>>
>> *all* of them.
>>
>> Please, and this is for everybody, work to reach consensus or leave.
>
>
> Are you implying that the lifecycle extension system is a one-man show?
>
> I remember extensive discussions and changes about them, all here on
> this mailing list. I also remember a joint Fortress-Merlin effort on them.
>
>
> We have a tentative roadmap we have informally agreed upon. IIUC the
> only one that does not acknowledge it is Peter. We have discussed *at
> lengths* in the past about getting to a single design, and you know what
> happened.
>
>
> We want consensus, yes we do. Here is the roadmap; since you resonate
> with Peter, lead us into the discussion (no pun intended) and update the
> STATUS file.
> http://cvs.apache.org/viewcvs/avalon/STATUS.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
This has *NOTHING* to do with placing stuff into framework.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 14/03/2003 12.10:
...
> This project used to be the place where people discussed architectural
> issues about new paradigms that extended object orientation.
>
> What happened to that?
Someone decided to reply with smartass comments to technical matters and
discussions.
> Since reaching consensus on Avalon 5 was too hard, several of you are
> trying to push your ideas into the framework by working it thru your
> one-man-show container.
Example?
> This is the problem and Peter appears to be the only one *really*
> watching over what's going on in this project. Probably because he's
> doing some sneaky moves himself so he's more sensible about them.
>
> Sure, he uses his usual smartass tone that really used to irritate me,
> but I'm now able to sense his frustruation and I resonate with it.
>
> One-man-shows have to stop.
>
> *all* of them.
>
> Please, and this is for everybody, work to reach consensus or leave.
Are you implying that the lifecycle extension system is a one-man show?
I remember extensive discussions and changes about them, all here on
this mailing list. I also remember a joint Fortress-Merlin effort on them.
We have a tentative roadmap we have informally agreed upon. IIUC the
only one that does not acknowledge it is Peter. We have discussed *at
lengths* in the past about getting to a single design, and you know what
happened.
We want consensus, yes we do. Here is the roadmap; since you resonate
with Peter, lead us into the discussion (no pun intended) and update the
STATUS file.
http://cvs.apache.org/viewcvs/avalon/STATUS.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
o Roadmap
Avalon will be focussing container development into two efforts.
The first one is the creation of Avalon ESCA. To this end, most
existing avalon container projects will refocus to be part of
that goal.
The roadmap for this effort is roughly as follows:
- Milestone 1: ECM replacement (Codename: Fortress)
- Milestone 2: Proper Meta Model (Codename: Merlin3)
- Milestone 3: Phoenix Compatible (Codename: Phoenix5)
- Milestone 4: Profileable, pluggable container
(Codename: Spearhead)
The second container development effort is the maintainance of
existing released efforts with an existing userbase, ie phoenix.
This will merge into the ESCA effort when there is an ESCA
release compatible with those existing efforts.
====================================================================
ECM --> Fortress --> Merlin3 --> Phoenix5 --> Spearhead --> ...
^ ^ ^
| : |
Merlin1&2 (unreleased)-| : |
All other | :(synergy) |
container dev code -/ : |
: |
Phoenix4 -------------------------------/
====================================================================
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
> one person strongly disagrees and another (me) wants to
> see why and wants to see more people involved
Make that two others. I've also been asking for both Peter and Berin,
Stephen, et al to compare the two proposals. Finally, we have seen one
technical one from Berin, and one from Peter.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Noel J. Bergman wrote:
>>Pete definately has a point wrt interceptor architecture (it really
>>is the "next big thing", except it is become the "current big thing"
>>fast).
>
> Would you comment on your view of the relative technical merits of the two
> proposals that are on the table, the interceptor architecture and the
> lifecycle proposal?
That question is too difficult to answer. There is one working tested
implementation with a setup similar to the one avalon uses for the
lifecycle management, ie the lifecycle package. It works well, but I'm
not sure about performance figures, extensibility, etc.
There is no working implementation that I know of which is easily
compatible with existing avalon code which manages lifecycle materials
(there's lots of implementations, but the only one I know of which
doesn't come with a massive amount of cruft like a J2EE server is
nanning (http://nanning.sourceforge.net/), and I don't think that is
ready for use; I'm not sure how for xinvoke (over @ spice) has
progressed, but it is moving so fast I can't keep track), so a
comparison is difficult.
In theory, an interceptor architecture could radically improve
performance, design, scalability and pluggability of avalon containers.
I've been experimenting with event-based AOP, and results are amazing,
but it'll be a few months before any such setup will actually be
workable in java.
IMO, the thing to do here is ensure that it will be possible in the
feature to provide a 'wrapper' around the lifecycle package which fits
in an event- or interceptor-based architecture. The way I see it, this
is trivially simple, and the suggestion of the other Leo to make the
methods return Object should make it even easier, but I'm not sure
that's neccessary.
An interceptor usually looks something like
class Interceptor
void setup( [Context] )
void intercept( Invocation )
where setup( [Context] ) can be implemented by using the constructor, or
by having an active interceptor looking things up using jndi, or by
having some kind of initialize/contextualize setup, or by using aspects.
It should be trivial to write a CreatorInterceptor:
class CreatorInterceptor implements Interceptor
void setup( Context context )
m_context = context
clazz = context.get( "class" )
class = Class.forName( clazz )
m_creator = class.newInstance()
m_creator.contextualize( context )
m_creator.initialize()
void intercept( invocation )
context = getContext( invocation )
if( invocation.method == create )
m_creator.create( invocation.target, context )
if( invocation.method == destroy )
m_creator.destroy( invocation.target, context )
and something similar for an AccessInterceptor.
That way, it would be easy to support the lifecycle package in an
interceptor-based system. So I don't see why the two approaches are
incompatible in any way.
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Leo,
>
>
>
>>Pete definately has a point wrt interceptor architecture (it really
>>is the "next big thing", except it is become the "current big thing"
>>fast).
>>
>>
>
>Would you comment on your view of the relative technical merits of the two
>proposals that are on the table, the interceptor architecture and the
>lifecycle proposal?
>
Noel:
Just for reference there is another thread between Jakob Praher and
myself in which the we have discussed some of the semantic differences
between the notion of interceptors and the notion of lifecycle interfaces.
http://marc.theaimsgroup.com/?t=104755526600001&r=1&w=2
Cheers, Steve.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
> Pete definately has a point wrt interceptor architecture (it really
> is the "next big thing", except it is become the "current big thing"
> fast).
Would you comment on your view of the relative technical merits of the two
proposals that are on the table, the interceptor architecture and the
lifecycle proposal?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Stefano Mazzocchi wrote:
>> A couple of months agro we started a coordinated release process
>> commencing with the release of the LogKit package following by the
>> framework. Work has moved on to the packages under the excalibur CVS
>> with iminent releases of the component,testcase, instrument,
>> instrument-manager, logger, and pool packages. Work in underway for
>> the release of serveral additional excalibur components including the
>> lifecycle package.
>
> Wasn't the proposal about migrating the lifecycle package into framework
> or did I overlook something?
you did :D
the proposal is for some cvs restructuring where we move several modules
into avalon cvs, lifecycle being the first. Not into avalon-framework.jar.
> =>> 2) clarify the future of cornerstone
>>
>> Work has already been underten to seperate individual Corenerstone
>> packages enabling some degreee of release control. The release process
>> for individual corenerstone units will be undertaken following
>> completion of the dependent excalibur packages.
>
> Good.
search archives for "roadmap" for more ideas of the general plan.
Basically following the gump dependency trail, we are.
>>> 3) stop one-man-shows
>>
>> Can you be more specific - what in you view are the one-man shows that
>> must stop?
>
> I don't see many people working on Merlin. Is this a wrong perception?
nope. Merlin is a sandbox effort and will stay that way until lots of
people (ie the entire community) have worked on it, looked at it, liked
it, perhaps refactored a few times. We've talked about this, lots of
people are looking at the developments. Steve's aware of all this,
again, @see roadmap threads :D
>> Are these one-man shows related to released packages, packages
>> scheduled for release, or are you referring to activities under the
>> avalon-sandbox project.
>
> I'm referring to Phoenix and Merlin. Both seem to me one-man-shows. But
> hopefully I'm wrong.
yep.
> 1) something is moving into avalon framework
> 2) in my view of the world, this *something* is therefore going to be
> considered *ROCK* solid
> 3) in my view of the way this project should work, *ROCK* solid is
> something where we have consensus and has been discussed by many more
> than three people.
> 4) a person that I technically respect highly believes that this
> solution is half-baked (hack is a bad term) and there are better
> solutions on the table.
>
> This is enough set my 'serious avalon users' alarms off.
>
> If any of the above is wrong, please, enlighten me.
#1 is, wrt #4, no working solutions which 'fit in' are on the table yet,
but Pete definately has a point wrt interceptor architecture (it really
is the "next big thing", except it is become the "current big thing"
fast). #2 and #3, agreed.
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Didier Villevalois <dv...@phpapp.org>.
Leo Simons wrote:
> Didier Villevalois wrote:
>
>> I would like to give our example. We do develop and test our
>> components on Fortress for now.
>> Migration to Merlin is planned for March/mid-March...
>
>
> just a note to let you know merlin is unlikely to come out of alpha
> stage in march. Not that it is not usable, but that apis will change
> and keeping up might take quite a bit of time!
First, you read have read Mai... Sorry, i'm a bit overworked and i wrote
too quickly. ;(
(Damn, we are in March, this is my birthday soon and i'm completly lost
in time...)
I know this is still dev quality. I already ran into the code. You might
have guess that our software is also still alpha. So we did choose to be
prepared for the next container. This is why we want to work on it.
However if we get out sooner than we expected then our application will
come out of the box with minimal configuration for Merlin too. (even if
it's unusual) As our application bootstrap is a service implementation
developped independently from its main functionnality, we are not
affraid to move. We developped the minimal container abstraction we
needed so that we can do this quickly.
A+. Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Leo Simons <le...@apache.org>.
Didier Villevalois wrote:
> I would like to give our example. We do develop and test our components
> on Fortress for now.
> Migration to Merlin is planned for March/mid-March...
Hi Didier,
just a note to let you know merlin is unlikely to come out of alpha
stage in march. Not that it is not usable, but that apis will change and
keeping up might take quite a bit of time!
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Didier Villevalois <dv...@phpapp.org>.
Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>> I don't see many people working on Merlin. Is this a wrong perception?
>
> It will after we get the Unified Avalon release done.
I think things do go slowly and that is the natural pernicious effect of
the team working.
I would like to give our example. We do develop and test our components
on Fortress for now.
Migration to Merlin is planned for March/mid-March...
You can be sure i am impatient to help!!! :)
A+. Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
>> Stephen McConnell wrote:
>>
>> Wasn't the proposal about migrating the lifecycle package into
>> framework or did I overlook something?
>
>
> No it was about placing it in the "avalon" CVS repository, and
> being maintained separately from Framework.
Then I don't understand what this means.
>>> Can you be more specific - what in you view are the one-man shows
>>> that must stop?
>>
>>
>> I don't see many people working on Merlin. Is this a wrong perception?
>
>
> It will after we get the Unified Avalon release done.
All right. I trust you on this.
>>> Are these one-man shows related to released packages, packages
>>> scheduled for release, or are you referring to activities under the
>>> avalon-sandbox project.
>>
>>
>> I'm referring to Phoenix and Merlin. Both seem to me one-man-shows.
>> But hopefully I'm wrong.
>
>
> Phoenix is actively maintained by more than one individual. There are
> some projects that depend on it so we also cannot just get rid of it.
Oh, I know, I know.
>>> Perhaps you could put forward you concrete arguments. Nothing below
>>> even suggests that you're familiar with the package in question. In
>>> fact several of the comments suggest that you may be confusing the
>>> lifecycle package with something else. You response on this is
>>> important because if you really think that the result of the
>>> collaboration between Marcus, Berin and myself is a "hack" - then I
>>> would like to discuss that will you. I will disagree with your
>>> position and present substantial evidence supporting that position.
>>> If however you comment is made with same level of indifference as the
>>> original hack comment from Peter Donald, then I can safely ignore it.
>>
>>
>>
>> From there I stand:
>>
>> 1) something is moving into avalon framework
>
>
> That was a misperception. That is not happening.
Good. Then I can set my alarms off.
>> 2) in my view of the world, this *something* is therefore going to be
>> considered *ROCK* solid
>
>
> How about *next* to framework--but not *in* it?
This worries me. I would like to hear what this means before restarting
my vote.
>>> The lifecycle package was a successful process of collaboration by
>>> three people each with relatively different ideas on the approaches
>>> concerning lifecycle stage management under the Avalon framework.
>>
>>
>> I now see a forth disagreeing. This is valuable input from me.
>
>
> Can I ask you a question? How comfortable are you with the complexities
> of interception?
Comfortable? you mean knowledged? I know absolutely nothing about their
complexities, althought, as a java programmer that knows java a little,
I think I can grasp the outline of the problem.
> It is not as simple and straight-forward as its main
> proponent suggests. In order for it to work effectively, we need to
> use a dynamically generated approach which either means incorporating
> CGLib or using Dynamic Proxies.
>
> Either way, I haven't seen where the code is really more understandable
> using interceptions than the proposed extensions standard.
>
> Don't get me wrong, interceptions are a cool concept--if the user can
> be successfully hidden from the implementation details. We have not
> had an opportunity to do that as a community yet.
So you are stating that this lifecycle is just a step in the direction
toward a more AOP-oriented solution?
That would be fair. But I want to know how this impacts the framework
before allowing it in.
I hope this is not seen as obsessive obstructionism, but just a concern.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Berin,
> Can I ask you a question? How comfortable are you with the complexities
> of interception? It is not as simple and straight-forward as its main
> proponent suggests. In order for it to work effectively, we need to
> use a dynamically generated approach which either means incorporating
> CGLib or using Dynamic Proxies.
> Either way, I haven't seen where the code is really more understandable
> using interceptions than the proposed extensions standard.
> Don't get me wrong, interceptions are a cool concept--if the user can
> be successfully hidden from the implementation details.
OK ... THIS is the discussion that OUGHT to be occuring. THIS is something
that can be discussed on a technical basis.
So you feel that Peter's solution is based upon dynamic proxy generation as
the core tool to solve the issues. The hammer that makes everything look
like a nail, if you will. And you feel that the Lifecycle proposal has
different characteristics?
OK ... now please elaborate on these topics.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> Stephen McConnell wrote:
>
> Wasn't the proposal about migrating the lifecycle package into framework
> or did I overlook something?
No it was about placing it in the "avalon" CVS repository, and
being maintained separately from Framework.
>> Can you be more specific - what in you view are the one-man shows that
>> must stop?
>
> I don't see many people working on Merlin. Is this a wrong perception?
It will after we get the Unified Avalon release done.
>> Are these one-man shows related to released packages, packages
>> scheduled for release, or are you referring to activities under the
>> avalon-sandbox project.
>
> I'm referring to Phoenix and Merlin. Both seem to me one-man-shows. But
> hopefully I'm wrong.
Phoenix is actively maintained by more than one individual. There are
some projects that depend on it so we also cannot just get rid of it.
>> Perhaps you could put forward you concrete arguments. Nothing below
>> even suggests that you're familiar with the package in question. In
>> fact several of the comments suggest that you may be confusing the
>> lifecycle package with something else. You response on this is
>> important because if you really think that the result of the
>> collaboration between Marcus, Berin and myself is a "hack" - then I
>> would like to discuss that will you. I will disagree with your
>> position and present substantial evidence supporting that position. If
>> however you comment is made with same level of indifference as the
>> original hack comment from Peter Donald, then I can safely ignore it.
>
>
> From there I stand:
>
> 1) something is moving into avalon framework
That was a misperception. That is not happening.
> 2) in my view of the world, this *something* is therefore going to be
> considered *ROCK* solid
How about *next* to framework--but not *in* it?
>> The lifecycle package was a successful process of collaboration by
>> three people each with relatively different ideas on the approaches
>> concerning lifecycle stage management under the Avalon framework.
>
> I now see a forth disagreeing. This is valuable input from me.
Can I ask you a question? How comfortable are you with the complexities
of interception? It is not as simple and straight-forward as its main
proponent suggests. In order for it to work effectively, we need to
use a dynamically generated approach which either means incorporating
CGLib or using Dynamic Proxies.
Either way, I haven't seen where the code is really more understandable
using interceptions than the proposed extensions standard.
Don't get me wrong, interceptions are a cool concept--if the user can
be successfully hidden from the implementation details. We have not
had an opportunity to do that as a community yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
> The framework is not being touched.
Then all my points where moot. Sorry for wasting your time over my
misunderstanding.
> Ok - I have no problem with a reference to Merlin as a one-man-commit
> effort.
Ok.
> Ok, technically I'm wrong - there are at least 3 others that
> have comitted to Merlin and at least 6 that has submitted patches.
Yeah, well, this doesn't count as a community-driven design methodology
in my book. Hopefully it doesn't in yours as well.
> Bottom line - would I want it to be any different - yes and no. No in
> that I have may hands full getting Merlin to a state where I am ready to
> say to the rest of the Avalon Community "here it is, let's go".
Nice to hear that.
> Until
> that time I'm happy to be somewhat in control.
Oh, I have no problems whatsoever in one person having control of a
proposal for a new generation of software. I've done it myself several
times and I've seen people doing it without creating community problems.
> But please recognize that
> control is relative. Control in this context means multiple days
> responding to the wims of the avalon community. Ok, yes - it would be
> nice to have a couple of other comitters pumping away - but to be honest
> - its just not stable enough at this time and they would probably cause
> more work than assistance. Take for example the patches from Jörg to
> internationalize the command line interface - the CLI logic has been
> restructured and not the German language messages he submitted are
> inconsistent with the behavior.
>
> To be really honest - a few more weeks is needed. The service access
> mechanisms on the Block interface need top be finalized and there is a
> bunch of documentation that needs to be updated. After that it's open game.
don't feel pushed. I don't want to push anybody, just to understand.
Now that my alarms set by misunderstanding are off and now that I was
able to get people recognize that if a valuable committer has a problem
with the technical issues involved the community should value his
contribution (no matter what language he/she used to express it), I'm
happy and I can go back to work.
Please understand that I don't have time/energy to follow deeply the
technical discussions here on avalon-land.
I just want to make sure this community is happy and safe and healthy so
that I can finally leave with lots of trust.
i'm getting more and more closer to that point.
And this is making me happy and it's a good thing.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
> Stephen McConnell wrote:
>
>>
>> Stanfano:
>
>
> ahahah, 'Stanfano' in some italian areas means 'they stink', that's
> the most creative mispell I had in years, that's :)
Gosh - yes it was a misspeeling - sorry about that!
>
>
>> I rather surprised at your email - have included lots of
>> comments/questions in-line.
>
>
> Glad to surprise you.
>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> This project has been making progress around working together but
>>> there are issues unresolved:
>>>
>>> 1) solidify excalibur but stopping it to be a moving target
>>
>>
>>
>>
>> This is already in progress.
>
>
> I know.
>
>> A couple of months agro we started a coordinated release process
>> commencing with the release of the LogKit package following by the
>> framework. Work has moved on to the packages under the excalibur CVS
>> with iminent releases of the component,testcase, instrument,
>> instrument-manager, logger, and pool packages. Work in underway for
>> the release of serveral additional excalibur components including the
>> lifecycle package.
>
>
> Wasn't the proposal about migrating the lifecycle package into
> framework or did I overlook something?
The proposal was to add the lifecycle package to the "avalon CVS" along
side framework. This is consistent with the discussions concerning the
structure of the avalon that we engaged in during the process of
identifying Avalon scope relative to the PMC charter (i.e. there is a
lot of discussion about this several months ago). Currently the avalon
CVS is occupied by one project - the avalon framework. Peter Donald has
suggested that the CVS structure is associated with some notion of
quality - and that you grade quality downward commencing with avalon,
next sub-category is Excalibur - etc. Presumably according to Peter
Donald idea of CVS structure - the lowest point in the scale of quality
is the sandbox. Personally I disagree with that position. In
contradiction with the views Peter Donald, the discussions back during
the formation of the Avalon PMC separated out the notions of utilities
used to build containers from the notion of framework, meta model,
framework extensions, container APIs, etc. The consensus was clear - the
Excalibur CVS should contain those utilities we use in the construction
of containers and components. A consequence of this discussion and
consensus was the transfer of the "lifecycle" package from excalibur to
sandbox. Since that time the lifecycle package has been in use -
unchanged, by both the Fortress and Merlin containers.
As a result of the recent coordinated release process the lifecycle
package is subject of an imminent release. If we follow the consensus
established back when the PMC was formed - the lifecycle package should
exist under the avalon CVS. Peter Donald has opposed that on the grounds
that the package is a "hack" - a position which you have chosen to
endorse - apparently without due consideration for the content or
community supporting it. Neither you not Peter Donald have expressed any
concrete opinions supporting the "hack" argument - in the meantime,
discussions with users on the subject of lifecycle extensions has been
ongoing on the avalon lists. I should not that those discussions have
gone into a lot of detail as to the deference between lifecycle stage
extensions as opposed to framework extension at the level of invocation
policy. Peter Donald has suggested that "interceptor" solutions are
preferable to the lifecycle extension interfaces developed by Berin,
Marcus and myself. I should also note that Peter Donald, for whatever
reason, has chosen to abstain from any participation or constructive
contribution to that result. As such, it is difficult for me to
understand Peter Donald's criticism at this time - just as it difficult
for me to understand you endorsement of that criticism.
Bottom line - this is not a change to framework.
>
> =>> 2) clarify the future of cornerstone
>
>>
>> Work has already been underten to seperate individual Corenerstone
>> packages enabling some degreee of release control. The release
>> process for individual corenerstone units will be undertaken
>> following completion of the dependent excalibur packages.
>
>
> Good.
>
>>>
>>> 3) stop one-man-shows
>>
>>
>>
>>
>> Can you be more specific - what in you view are the one-man shows
>> that must stop?
>
>
> I don't see many people working on Merlin. Is this a wrong perception?
Leo Simons - has been active in his critique of the project since day
one - has experimented with Merlin and validated the embedding of Merlin
inside Oracle. Gary Shea has been testing and validating Merlin and
providing valuable feedback include reporting on problems related to the
original manifest formats resulting in the modification of Merlin to do
a manifest independent scanning of jar files. Marcus Crafter has been
working with Merlin as part of the work on the lifecycle interfaces and
has reviewed Merlin in detail. The opinions on Marcus related to his
work on the XFC project resulted in the separation of the meta model
work into a separate project. Berin Loritsch has spent time looking into
Merlin and posted several criticisms to this list concerning the
complexity of the classloading mechanisms - resulting in a refactor of
this entire sub-system. In addition Berin has initiated work on Fortress
to Merlin Meta experimentation (although to be frank this is somewhat
suspended pending the current release). Richard Wallace has been
experimenting with Merlin in a web services environment and has provided
valuable feedback related to limitations that existed at the level of
kernel establishment in a non-expanded webapp context. Peter Royal has
investigated the application of Merlin in the Mac OSM environment during
which he located problems relating to the MacOS support of the shutdown
hook - and issue that remains to be resolved. Jörg Schaible has provided
really solid and constructive feedback on the use and application of
Merlin in the servlet environment and has contributed patches supporting
internationalization. Jörg's trials demonstrated that Merlin was
changing a little too much relative to his development needs - however -
his trials and feedback on the user list remain constructive and
concrete contributions. Finally, Leif Mortenson has provided support for
the establishment of the support for the Windows NT service deployment
of Merlin. Today it is possible to deploy James as a composite component
running as an NT service under Merlin based on the assistance and
contributions from Leif.
Ok - that's just off the top of my head - if you want more details - I
could go digging and double the length of the paragraph.
>
>> Are these one-man shows related to released packages, packages
>> scheduled for release, or are you referring to activities under the
>> avalon-sandbox project.
>
>
> I'm referring to Phoenix and Merlin. Both seem to me one-man-shows.
> But hopefully I'm wrong.
You are wrong.
Merlin is alpha. As far as code commits are concerned it is largely
driven my myself. As far as the content of those commits are concerned
it is largely driven by the opinions and input of the community - in
particular the input received from the users@avalon.apache.org list has
made a concrete and irreversible impact on the Merlin product. There
remain some chunks of work on Merlin that are pending completion. Prior
to completion that is not a lot of logic in having lots of people
working on Merlin because things are changing too much. Given three or
four weeks and maybe we will see a signal for a wider involvement - but
for the moment the wider involvement is expressed through the list.
>
>>> - o -
>>>
>>> Peter said he didn't like your solution because he thought it was a
>>> hack. Guess what, I agree with him.
>>
>>
>> <snip-warm-and-fluffy-comment/>
>>
>> Perhaps you could put forward you concrete arguments. Nothing below
>> even suggests that you're familiar with the package in question. In
>> fact several of the comments suggest that you may be confusing the
>> lifecycle package with something else. You response on this is
>> important because if you really think that the result of the
>> collaboration between Marcus, Berin and myself is a "hack" - then I
>> would like to discuss that will you. I will disagree with your
>> position and present substantial evidence supporting that position.
>> If however you comment is made with same level of indifference as the
>> original hack comment from Peter Donald, then I can safely ignore it.
>
>
> From there I stand:
>
> 1) something is moving into avalon framework
Incorrect - this is misinformation.
>
> 2) in my view of the world, this *something* is therefore going to be
> considered *ROCK* solid
It is a definition of a contract between a container extension and a
container implementation. Implementations of the lifecycle extensions
contracts have been implemented in both Fortress and Merlin. It is rock
solid - proven, validated.
>
> 3) in my view of the way this project should work, *ROCK* solid is
> something where we have consensus and has been discussed by many more
> than three people.
The process of collaboration between Berin, Marcus and myself was very
open. In fact there were occasions of disagreement in which a broad
spectrum of this community got involved. This was a community solution -
a solution with a level of quality that exceeds the framework itself.
>
> 4) a person that I technically respect highly believes that this
> solution is half-baked (hack is a bad term) and there are better
> solutions on the table.
>
> This is enough set my 'serious avalon users' alarms off.
I respectfully suggest that you take the time and effort to asses this
package independently. I am confident that you will find that the
package simple, functional, usable and certainly beyond the
characterizations put forward by Peter Donald.
>
> If any of the above is wrong, please, enlighten me.
If there is anything in the above which is not sufficiently detailed -
please let me know.
>
>>> This project used to be the place where people discussed
>>> architectural issues about new paradigms that extended object
>>> orientation.
>>
>>
>>
>>
>> The lifecycle package was a successful process of collaboration by
>> three people each with relatively different ideas on the approaches
>> concerning lifecycle stage management under the Avalon framework.
>
>
> I now see a forth disagreeing. This is valuable input from me.
>
>> It remains a good example of collaboration and effective resolution
>> of architectural issues. Furthermore, it is a concrete demonstration
>> of the willingness of different people to work together towards the
>> achievement of common solutions on the container side of the Avalon
>> equation.
>
>
> Great, but now you are pushing this 'collaboration' at a higher level
> and this requires *more* consensus. Build it.
I'm not sure what you are talking about - "higher level". If you are
talking about a particular level of abstraction in terms of "level" then
what is inconsistent with the inclusion of the lifecycle extensions
package into the avalon cvs. It clearly is inconsistent with the
Excalibur package and its abstraction level of container and component
utilities. I don't see it making sense inside logkit. The cornerstone
cvs seems somewhat different and the avalon-apps CVS does not seem
appropriate.
>
>>>
>>> What happened to that?
>>
>>
>> Seems to me that it is alive and well. If you have been following the
>> discussion here - there is a workplan that involes getting existing
>> content released and managable, including the release of Fortress and
>> later, Merlin. Berin and I have undertaken to work together on
>> addressing the questions of ECM/Fortress component management in an
>> architecture based on the Merlin Assembly package. This is part of
>> the process of moving forward with the objective of resolving
>> differences across Avalon.
>
>
> Great.
>
> But you are now moving stuff into avalon and one person strongly
> disagrees and another (me) wants to see why and wants to see more
> people involved when the framework gets touched.
The framework is not being touched.
The one person you refer to happens to have an idea about what it better
and like4 to promote that idea over and above concrete, substantive and
validated results established through collaboration across this
community. Perhaps you could ask this person to put articulate his
concerns as he has categorically failed to put forward anything of
substance at this time.
>
> the higher you get, the more consensus you need.
What is higher - is the work in sandbox any less quality that the work
in avalon CVS? Are the components in Cornerstone subject to some lesser
quality of compliance that the avalon CVS. This is absolutely meaningless.
>
>
> This is the only way we can maintain oversight over a codebase that is
> sooooo-down-the-foodchain.
>
>>> Since reaching consensus on Avalon 5 was too hard, several of you
>>> are trying to push your ideas into the framework by working it thru
>>> your one-man-show container.
>>
>>
>>
>>
>> I disagree. A5 is a subject that requires focus and solid
>> consideration. I don't think a lot of progress will be made on that
>> while the release process is underway. With the releases done, I
>> fully expect the resumption of A5 discussions and hope that everyone
>> here applies a constructive approach to the process.
>
> >
>
>>
>>> This is the problem and Peter appears to be the only one *really*
>>> watching over what's going on in this project. Probably because he's
>>> doing some sneaky moves himself so he's more sensible about them.
>>
>>
>> I disagree. You comment ignores the time and effort people are
>> putting into the release process. It ignores the time and effort
>> people are putting into establishing a clean sandbox structure. It
>> also ignores completely the community concensus reached on direction.
>>
>>> Sure, he uses his usual smartass tone that really used to irritate
>>> me, but I'm now able to sense his frustruation and I resonate with it.
>>
>>
>>
>>
>> Instead of putting forward a half-hearted attempt to justifiy the
>> behaviour of Peter Donald
>
>
> half-hearted? nono, full-hearted.
Every man is entitled to an opinion!
>
>> perhaps you could explain the frustrations that you resonate with.
>> That would be constructive and helpfull (and
>> certainly more constructive and helpful than some of the suggestions
>> you have made in your email).
>
> >
>
>>> One-man-shows have to stop.
>>>
>>> *all* of them.
>>
>>
>>
>>
>> Please be specific and either identity the project in question or
>> actually state the issue. If you referring to the work that I have
>> been leading with respect to the Merlin project then say so (but
>> please be prepared to present you case in the context of the
>> community involvement in that project).
>
>
> Go right ahead.
Ok - I have no problem with a reference to Merlin as a one-man-commit
effort. Ok, technically I'm wrong - there are at least 3 others that
have comitted to Merlin and at least 6 that has submitted patches.
Bottom line - would I want it to be any different - yes and no. No in
that I have may hands full getting Merlin to a state where I am ready to
say to the rest of the Avalon Community "here it is, let's go". Until
that time I'm happy to be somewhat in control. But please recognize that
control is relative. Control in this context means multiple days
responding to the wims of the avalon community. Ok, yes - it would be
nice to have a couple of other comitters pumping away - but to be honest
- its just not stable enough at this time and they would probably cause
more work than assistance. Take for example the patches from Jörg to
internationalize the command line interface - the CLI logic has been
restructured and not the German language messages he submitted are
inconsistent with the behavior.
To be really honest - a few more weeks is needed. The service access
mechanisms on the Block interface need top be finalized and there is a
bunch of documentation that needs to be updated. After that it's open game.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
> Stanfano:
ahahah, 'Stanfano' in some italian areas means 'they stink', that's the
most creative mispell I had in years, that's :)
> I rather surprised at your email - have included lots of
> comments/questions in-line.
Glad to surprise you.
> Stefano Mazzocchi wrote:
>
>>
>> This project has been making progress around working together but
>> there are issues unresolved:
>>
>> 1) solidify excalibur but stopping it to be a moving target
>
>
>
> This is already in progress.
I know.
> A couple of months agro we started a
> coordinated release process commencing with the release of the LogKit
> package following by the framework. Work has moved on to the packages
> under the excalibur CVS with iminent releases of the component,testcase,
> instrument, instrument-manager, logger, and pool packages. Work in
> underway for the release of serveral additional excalibur components
> including the lifecycle package.
Wasn't the proposal about migrating the lifecycle package into framework
or did I overlook something?
=>> 2) clarify the future of cornerstone
>
> Work has already been underten to seperate individual Corenerstone
> packages enabling some degreee of release control. The release process
> for individual corenerstone units will be undertaken following
> completion of the dependent excalibur packages.
Good.
>>
>> 3) stop one-man-shows
>
>
>
> Can you be more specific - what in you view are the one-man shows that
> must stop?
I don't see many people working on Merlin. Is this a wrong perception?
> Are these one-man shows related to released packages,
> packages scheduled for release, or are you referring to activities under
> the avalon-sandbox project.
I'm referring to Phoenix and Merlin. Both seem to me one-man-shows. But
hopefully I'm wrong.
>> - o -
>>
>> Peter said he didn't like your solution because he thought it was a
>> hack. Guess what, I agree with him.
>
> <snip-warm-and-fluffy-comment/>
>
> Perhaps you could put forward you concrete arguments. Nothing below even
> suggests that you're familiar with the package in question. In fact
> several of the comments suggest that you may be confusing the lifecycle
> package with something else. You response on this is important because
> if you really think that the result of the collaboration between Marcus,
> Berin and myself is a "hack" - then I would like to discuss that will
> you. I will disagree with your position and present substantial evidence
> supporting that position. If however you comment is made with same level
> of indifference as the original hack comment from Peter Donald, then I
> can safely ignore it.
From there I stand:
1) something is moving into avalon framework
2) in my view of the world, this *something* is therefore going to be
considered *ROCK* solid
3) in my view of the way this project should work, *ROCK* solid is
something where we have consensus and has been discussed by many more
than three people.
4) a person that I technically respect highly believes that this
solution is half-baked (hack is a bad term) and there are better
solutions on the table.
This is enough set my 'serious avalon users' alarms off.
If any of the above is wrong, please, enlighten me.
>> This project used to be the place where people discussed architectural
>> issues about new paradigms that extended object orientation.
>
>
>
> The lifecycle package was a successful process of collaboration by three
> people each with relatively different ideas on the approaches concerning
> lifecycle stage management under the Avalon framework.
I now see a forth disagreeing. This is valuable input from me.
> It remains a good
> example of collaboration and effective resolution of architectural
> issues. Furthermore, it is a concrete demonstration of the willingness
> of different people to work together towards the achievement of common
> solutions on the container side of the Avalon equation.
Great, but now you are pushing this 'collaboration' at a higher level
and this requires *more* consensus. Build it.
>>
>> What happened to that?
>
> Seems to me that it is alive and well. If you have been following the
> discussion here - there is a workplan that involes getting existing
> content released and managable, including the release of Fortress and
> later, Merlin. Berin and I have undertaken to work together on
> addressing the questions of ECM/Fortress component management in an
> architecture based on the Merlin Assembly package. This is part of the
> process of moving forward with the objective of resolving differences
> across Avalon.
Great.
But you are now moving stuff into avalon and one person strongly
disagrees and another (me) wants to see why and wants to see more people
involved when the framework gets touched.
the higher you get, the more consensus you need.
This is the only way we can maintain oversight over a codebase that is
sooooo-down-the-foodchain.
>> Since reaching consensus on Avalon 5 was too hard, several of you are
>> trying to push your ideas into the framework by working it thru your
>> one-man-show container.
>
>
>
> I disagree. A5 is a subject that requires focus and solid consideration.
> I don't think a lot of progress will be made on that while the release
> process is underway. With the releases done, I fully expect the
> resumption of A5 discussions and hope that everyone here applies a
> constructive approach to the process.
>
>
>> This is the problem and Peter appears to be the only one *really*
>> watching over what's going on in this project. Probably because he's
>> doing some sneaky moves himself so he's more sensible about them.
>
> I disagree. You comment ignores the time and effort people are putting
> into the release process. It ignores the time and effort people are
> putting into establishing a clean sandbox structure. It also ignores
> completely the community concensus reached on direction.
>
>> Sure, he uses his usual smartass tone that really used to irritate me,
>> but I'm now able to sense his frustruation and I resonate with it.
>
>
>
> Instead of putting forward a half-hearted attempt to justifiy the
> behaviour of Peter Donald
half-hearted? nono, full-hearted.
> perhaps you could explain the frustrations
> that you resonate with. That would be constructive and helpfull (and
> certainly more constructive and helpful than some of the suggestions you
> have made in your email).
>
>> One-man-shows have to stop.
>>
>> *all* of them.
>
>
>
> Please be specific and either identity the project in question or
> actually state the issue. If you referring to the work that I have been
> leading with respect to the Merlin project then say so (but please be
> prepared to present you case in the context of the community involvement
> in that project).
Go right ahead.
I have no problems saying I was wrong in stating something.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
> Noel J. Bergman wrote:
>
>>> Since reaching consensus on Avalon 5 was too hard, several of you are
>>> trying to push your ideas into the framework by working it thru your
>>> one-man-show container.
>>
>>
>>
>> Different perspective. Avalon 5 is in the future, but right now they
>> have a
>> mish-mash of Avalon 4, and folks like Berin instigated a major push
>> to clean
>> and polish what they have before pushing on to build something new.
>> Most if
>> not all of the Community has rallied behind this push to clean up
>> Avalon 4,
>> and that should only be viewed as a good thing, but technically and
>> socially.
>
>
> I don't get it.
>
> This list is trying to clean up Avalon 4 by adding new stuff to it?
Quoi?
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> Noel J. Bergman wrote:
>
> I don't get it.
>
> This list is trying to clean up Avalon 4 by adding new stuff to it?
>
> Please, explain.
Easy--we are not adding new stuff to it.
Next question?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Noel J. Bergman wrote:
>>Since reaching consensus on Avalon 5 was too hard, several of you are
>>trying to push your ideas into the framework by working it thru your
>>one-man-show container.
>
>
> Different perspective. Avalon 5 is in the future, but right now they have a
> mish-mash of Avalon 4, and folks like Berin instigated a major push to clean
> and polish what they have before pushing on to build something new. Most if
> not all of the Community has rallied behind this push to clean up Avalon 4,
> and that should only be viewed as a good thing, but technically and
> socially.
I don't get it.
This list is trying to clean up Avalon 4 by adding new stuff to it?
Please, explain.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Since reaching consensus on Avalon 5 was too hard, several of you are
> trying to push your ideas into the framework by working it thru your
> one-man-show container.
Different perspective. Avalon 5 is in the future, but right now they have a
mish-mash of Avalon 4, and folks like Berin instigated a major push to clean
and polish what they have before pushing on to build something new. Most if
not all of the Community has rallied behind this push to clean up Avalon 4,
and that should only be viewed as a good thing, but technically and
socially.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Stanfano:
I rather surprised at your email - have included lots of
comments/questions in-line.
Stefano Mazzocchi wrote:
>
> This project has been making progress around working together but
> there are issues unresolved:
>
> 1) solidify excalibur but stopping it to be a moving target
This is already in progress. A couple of months agro we started a
coordinated release process commencing with the release of the LogKit
package following by the framework. Work has moved on to the packages
under the excalibur CVS with iminent releases of the component,testcase,
instrument, instrument-manager, logger, and pool packages. Work in
underway for the release of serveral additional excalibur components
including the lifecycle package.
>
> 2) clarify the future of cornerstone
Work has already been underten to seperate individual Corenerstone
packages enabling some degreee of release control. The release process
for individual corenerstone units will be undertaken following
completion of the dependent excalibur packages.
>
> 3) stop one-man-shows
Can you be more specific - what in you view are the one-man shows that
must stop? Are these one-man shows related to released packages,
packages scheduled for release, or are you referring to activities under
the avalon-sandbox project.
>
> - o -
>
> Peter said he didn't like your solution because he thought it was a
> hack. Guess what, I agree with him.
<snip-warm-and-fluffy-comment/>
Perhaps you could put forward you concrete arguments. Nothing below even
suggests that you're familiar with the package in question. In fact
several of the comments suggest that you may be confusing the lifecycle
package with something else. You response on this is important because
if you really think that the result of the collaboration between Marcus,
Berin and myself is a "hack" - then I would like to discuss that will
you. I will disagree with your position and present substantial evidence
supporting that position. If however you comment is made with same level
of indifference as the original hack comment from Peter Donald, then I
can safely ignore it.
>
> This project used to be the place where people discussed architectural
> issues about new paradigms that extended object orientation.
The lifecycle package was a successful process of collaboration by three
people each with relatively different ideas on the approaches concerning
lifecycle stage management under the Avalon framework. It remains a good
example of collaboration and effective resolution of architectural
issues. Furthermore, it is a concrete demonstration of the willingness
of different people to work together towards the achievement of common
solutions on the container side of the Avalon equation.
>
> What happened to that?
Seems to me that it is alive and well. If you have been following the
discussion here - there is a workplan that involes getting existing
content released and managable, including the release of Fortress and
later, Merlin. Berin and I have undertaken to work together on
addressing the questions of ECM/Fortress component management in an
architecture based on the Merlin Assembly package. This is part of the
process of moving forward with the objective of resolving differences
across Avalon.
>
> Since reaching consensus on Avalon 5 was too hard, several of you are
> trying to push your ideas into the framework by working it thru your
> one-man-show container.
I disagree. A5 is a subject that requires focus and solid consideration.
I don't think a lot of progress will be made on that while the release
process is underway. With the releases done, I fully expect the
resumption of A5 discussions and hope that everyone here applies a
constructive approach to the process.
> This is the problem and Peter appears to be the only one *really*
> watching over what's going on in this project. Probably because he's
> doing some sneaky moves himself so he's more sensible about them.
I disagree. You comment ignores the time and effort people are putting
into the release process. It ignores the time and effort people are
putting into establishing a clean sandbox structure. It also ignores
completely the community concensus reached on direction.
> Sure, he uses his usual smartass tone that really used to irritate me,
> but I'm now able to sense his frustruation and I resonate with it.
Instead of putting forward a half-hearted attempt to justifiy the
behaviour of Peter Donald, perhaps you could explain the frustrations
that you resonate with. That would be constructive and helpfull (and
certainly more constructive and helpful than some of the suggestions you
have made in your email).
>
> One-man-shows have to stop.
>
> *all* of them.
Please be specific and either identity the project in question or
actually state the issue. If you referring to the work that I have been
leading with respect to the Merlin project then say so (but please be
prepared to present you case in the context of the community involvement
in that project).
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
> Peter Donald:
>
> I would like to apologize for the remarks I made below. As has been
> correctly pointed out to me by several of the members here, my reaction
> was inappropriate. Furthermore - as a member of this community I now
> regret making the remark as it is contradictory with the behavior that I
> expect from others. As such, I would like to extend this apology to the
> Avalon Community as well.
As part of thsi community, I welcome your apologies and accept them.
This project has been making progress around working together but there
are issues unresolved:
1) solidify excalibur but stopping it to be a moving target
2) clarify the future of cornerstone
3) stop one-man-shows
- o -
Peter said he didn't like your solution because he thought it was a
hack. Guess what, I agree with him.
No, please, don't piss in your wetsuite :) and don't get me wrong:
This project used to be the place where people discussed architectural
issues about new paradigms that extended object orientation.
What happened to that?
Since reaching consensus on Avalon 5 was too hard, several of you are
trying to push your ideas into the framework by working it thru your
one-man-show container.
This is the problem and Peter appears to be the only one *really*
watching over what's going on in this project. Probably because he's
doing some sneaky moves himself so he's more sensible about them.
Sure, he uses his usual smartass tone that really used to irritate me,
but I'm now able to sense his frustruation and I resonate with it.
One-man-shows have to stop.
*all* of them.
Please, and this is for everybody, work to reach consensus or leave.
The price to pay for having an apache label on top of your work is to
work thru the rules of consensus, any sneaky move to route around the
obstacles will next lead to drastic proposals from my side.
no, not the ASF board or the PMC chair, but a single avalon committer
that will start proposing to kick offending *code* out of the avalon
repositories.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald:
I would like to apologize for the remarks I made below. As has been
correctly pointed out to me by several of the members here, my reaction
was inappropriate. Furthermore - as a member of this community I now
regret making the remark as it is contradictory with the behavior that I
expect from others. As such, I would like to extend this apology to the
Avalon Community as well.
Steve.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> On Wed, 12 Mar 2003 07:49, Berin Loritsch wrote:
>>
>>
>>> Furthermore, the lifecycle package addresses a common need in both
>>> Fortress and Merlin--alowing for a smooth migration path for users
>>> as they upgrade their containers.
>>>
>>
>>
>> Then why not merge it into fortress? If Merlin is the successor of
>> Fortress then that should be no problem.
>>
>> BTW I was not -1'ing a release (which is impossible) but that it be
>> considered a "optional" extension to the framework contracts. It is a
>> hack shared by fortress and Merlin
>>
>
> Peter:
>
> I'm so glad your back!
>
> Knowing that day-to-day I have your considered remarks, insightful
> comments and astute observations to look forward to - it gives me a
> "warm and fluffy feeling" ... you know ... like pissing in a wetsuit.
> If only you could dedicate more of your time to the same. Heck - the
> whole world could be a warmer fluffier place and we would all have you
> to thank for it.
>
> Cheers, Steve.
>
> ;-)
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Wed, 12 Mar 2003 07:49, Berin Loritsch wrote:
>
>
>>Furthermore, the lifecycle package addresses a common need in both
>>Fortress and Merlin--alowing for a smooth migration path for users
>>as they upgrade their containers.
>>
>>
>
>Then why not merge it into fortress? If Merlin is the successor of Fortress
>then that should be no problem.
>
>BTW I was not -1'ing a release (which is impossible) but that it be considered
>a "optional" extension to the framework contracts. It is a hack shared by
>fortress and Merlin
>
Peter:
I'm so glad your back!
Knowing that day-to-day I have your considered remarks, insightful
comments and astute observations to look forward to - it gives me a
"warm and fluffy feeling" ... you know ... like pissing in a wetsuit.
If only you could dedicate more of your time to the same. Heck - the
whole world could be a warmer fluffier place and we would all have you
to thank for it.
Cheers, Steve.
;-)
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 07:49, Berin Loritsch wrote:
> Furthermore, the lifecycle package addresses a common need in both
> Fortress and Merlin--alowing for a smooth migration path for users
> as they upgrade their containers.
Then why not merge it into fortress? If Merlin is the successor of Fortress
then that should be no problem.
BTW I was not -1'ing a release (which is impossible) but that it be considered
a "optional" extension to the framework contracts. It is a hack shared by
fortress and Merlin
--
Cheers,
Peter Donald
"The ability to quote is a serviceable substitute for wit." -- Maugham
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 12 Mar 2003 03:49, Stephen McConnell wrote:
>
>> * the release of the avalon-lifecycle package shall be
>> considered as an "optional" extension to the framework
>> contracts
>
>
> -1
>
> It is the same approach that has been done before and failed and can't cleanly
> produce some aspects like delayed activation, passivation, persistence,
> transaction demarcation, bifuricating interception etc.
These are aspects that are best taken care of using your interceptor
approach. However for simpler problems like EventBusEnabled (allowing
the container to set the EventBus for each component that needs it)
it is just the ticket.
Furthermore, the lifecycle package addresses a common need in both
Fortress and Merlin--alowing for a smooth migration path for users
as they upgrade their containers.
The important thing is for the near to mid term it is a solution
that works immediately (the simplist approach), and for the long
term can still easily be supported with the interceptor approach.
We aren't trying to produce the aspects you listed above. Those
can be done in Phoenix with the more elegant solution you have.
As we look into the "super container" architecture I want to seriously
persue the interceptors. However the lifecycle extensions architecture
does solve a present need.
It is *optional* as in not all containers are required to support it.
ECM will never support it--for that they will need Fortress at a
minimum. Merlin will support it. Phoenix won't--it has a better
mechanism. Third party containers that want to solve a simple extension
problem will use it.
The question is where does it belong.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 12 Mar 2003 21:14, Leo Sutic wrote:
>
> I would hardly call these interfaces well tested or mature. Given them a year
> or more and if they are still about then we can consider moving them in. Even
> then I doubt they should be in framework as they would not be specific to
> avalon
CLARIFICATION:
No one has proposed making them part of FRAMEWORK. It is a question of
which repository to move to.
It is a question of whether we want to make the "avalon" CVS repository
support a framework directory structure and an extension directory
structure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Interceptors and Lifecycle (was: RE: [PROPOSAL] lifecycle release)
Posted by Leo Simons <le...@apache.org>.
AOP link of the day:
http://www.easycomp.org/
AOP link of yesterday:
http://www.emn.fr/x-info/sudholt/papers/tr-11-2002.pdf
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Interceptors and Lifecycle (was: RE: [PROPOSAL] lifecycle
release)
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-03-12 at 15:28, Leo Simons wrote:
> I was just talking with a flatmate about n-d SoC. Guess what? Our
> university is leading the field :D
Undoubtedly, that's where the first AOP conference was. I probably
walked right by you at some point! :-)
> AOP link of tomorrow:
> http://trese.cs.utwente.nl/
>
> cheers,
>
> - Leo
>
> Leo Simons wrote:
> > AOP link of the day:
> > http://www.easycomp.org/
> >
> > AOP link of yesterday:
> > http://www.emn.fr/x-info/sudholt/papers/tr-11-2002.pdf
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Interceptors and Lifecycle (was: RE: [PROPOSAL] lifecycle release)
Posted by Leo Simons <le...@apache.org>.
Jason van Zyl wrote:
> On Wed, 2003-03-12 at 15:28, Leo Simons wrote:
>
>>I was just talking with a flatmate about n-d SoC. Guess what? Our
>>university is leading the field :D
>
> Undoubtedly, that's where the first AOP conference was. I probably
> walked right by you at some point! :-)
heh :D I think I was in Oz at the time. Also, I'm not a CompSci at all:
my study concerns physics. So I would probably not be attending...still,
its a small world after all!
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Interceptors and Lifecycle (was: RE: [PROPOSAL] lifecycle release)
Posted by Leo Simons <le...@apache.org>.
I was just talking with a flatmate about n-d SoC. Guess what? Our
university is leading the field :D
AOP link of tomorrow:
http://trese.cs.utwente.nl/
cheers,
- Leo
Leo Simons wrote:
> AOP link of the day:
> http://www.easycomp.org/
>
> AOP link of yesterday:
> http://www.emn.fr/x-info/sudholt/papers/tr-11-2002.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Interceptors and Lifecycle Consensus?
Posted by dv...@phpapp.org.
Quoting Leo Sutic <le...@inspireinfrastructure.com>:
> Here:
>
> http://www.java.no/web/moter/moteSep02/AOP_files/frame.html
And there for better rendering of graphics :)
http://www.java.no/web/moter/moteSep02/AOP.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[PROPOSAL] Interceptors and Lifecycle Consensus?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Here:
http://www.java.no/web/moter/moteSep02/AOP_files/frame.html
is an article on interceptors.
As far as the lifecycle package is concerned, I'd like to paint a
big bullseye on that article.
The objections to the lifecycle package seem to be that it is not
capable enough, so how about this:
1. Release it as-is, but keep it in Excalibur
Hey, we need to get stuff out the door.
2. Set your GPS systems, laser guidance kits etc. to:
http://www.java.no/web/moter/moteSep02/AOP_files/frame.html
That's what we should be able to support.
3. Hold off on moving lifecycle -> framework.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Interceptors and Lifecycle (was: RE: [PROPOSAL] lifecycle release)
Posted by Paul Hammant <pa...@yahoo.com>.
> > I found this:
> >
> > http://www.java.no/web/moter/moteSep02/AOP_files/frame.html
Ricard is working with my buddy Joe Walnes on a book that includes a project 'PetSoar'. For that
they have created a bespoke container that uses a generic and interfaceless form of IoC. It does
not leverage Avalon at all, but at least they mention it in the book. Another container, with its
own component lacing scheme. At least there are new (and significant) allies to our cause now.
Can't convince Joe on logging though :-(
Regards,
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Interceptors and Lifecycle (was: RE: [PROPOSAL] lifecycle release)
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 21:38, Leo Sutic wrote:
> I'm trying to find some common ground - it is complicated mostly because
> while I know what an interceptor *is* I have no clue at all just what
> difficulties I would run up against when trying to implement it.
They are actually relatively easy to implement - just hard to manage
generically ;)
> I found this:
>
> http://www.java.no/web/moter/moteSep02/AOP_files/frame.html
thats a good one. I sent another to Berin recently ... Berin can you post the
link?
> Now, if a lifecycle package could be constructed that would support
> everything described there, would it be enough?
sure - if it could support all that then it would not suck technically. Still
has no place in framework CVS though - especially if it has not had time to
mature and settle (Remember even the current framework took at least 3 years
to settle and we got oodles wrong with that).
Though I believe Rickard Öbergs is going to release his toolkit soon (though
he was going to do it in december ... then january ...) so you may want to
wait for that. I susepct it will be fairly solid - though maybe "gritty"
tech. There is also nanning at sourceforge that may form a base if you want
to start it imediately though nanning is not really scalable enough for fine
grain components.
I am working on a toolkit also to do this stuff but it is no where near mature
enough at this stage. A basic overview that assumes exisitng knowledge
http://spice.sourceforge.net/xinvoke/selectors.html
http://spice.sourceforge.net/xinvoke/interceptor.html
But thats not going to be worked on for a while.
BTW I dont object to it being released as an excalibur component or whatever
but not as part of framework or in anyway given the same level of maturity or
support as framework.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Interceptors and Lifecycle (was: RE: [PROPOSAL] lifecycle release)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 12 Mar 2003 21:14, Leo Sutic wrote:
> > I assume those things can be handled with interceptors. An
> interceptor
> > can be realized via wrapping a component in a proxy, yes?
>
> one approach.
>
> > Then if the methods in the Creator and Accessor interfaces
> are made to
> > *return* an Object, then they can be used to wrap components in
> > proxies.
> >
> > Would this be enough to realize those use cases?
>
> it would be an improvement but still no cigar.
>
> I would hardly call these interfaces well tested or mature.
> Given them a year
> or more and if they are still about then we can consider
> moving them in. Even
> then I doubt they should be in framework as they would not be
> specific to
> avalon
I'm trying to find some common ground - it is complicated mostly because
while I know what an interceptor *is* I have no clue at all just what
difficulties I would run up against when trying to implement it.
I found this:
http://www.java.no/web/moter/moteSep02/AOP_files/frame.html
Now, if a lifecycle package could be constructed that would support
everything described there, would it be enough?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 21:14, Leo Sutic wrote:
> I assume those things can be handled with interceptors. An
> interceptor can be realized via wrapping a component in a proxy, yes?
one approach.
> Then if the methods in the Creator and Accessor interfaces are made to
> *return* an Object, then they can be used to wrap components in
> proxies.
>
> Would this be enough to realize those use cases?
it would be an improvement but still no cigar.
I would hardly call these interfaces well tested or mature. Given them a year
or more and if they are still about then we can consider moving them in. Even
then I doubt they should be in framework as they would not be specific to
avalon
--
Cheers,
Peter Donald
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] lifecycle release
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 12 Mar 2003 03:49, Stephen McConnell wrote:
> > * that the package be migrated from the avalon-sandbox
> > CVS to the avalon CVS as a separate project along-side
> > the avalon framework
>
> -1 as it does not belong at same level as framework.
>
> > * the release of the avalon-lifecycle package shall be
> > considered as an "optional" extension to the framework
> > contracts
>
> -1
>
> It is the same approach that has been done before and failed
> and can't cleanly
> produce some aspects like delayed activation, passivation,
> persistence,
> transaction demarcation, bifuricating interception etc.
I assume those things can be handled with interceptors. An
interceptor can be realized via wrapping a component in a proxy, yes?
Then if the methods in the Creator and Accessor interfaces are made to
*return* an Object, then they can be used to wrap components in
proxies.
Would this be enough to realize those use cases?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 03:49, Stephen McConnell wrote:
> * that the package be migrated from the avalon-sandbox
> CVS to the avalon CVS as a separate project along-side
> the avalon framework
-1 as it does not belong at same level as framework.
> * the release of the avalon-lifecycle package shall be
> considered as an "optional" extension to the framework
> contracts
-1
It is the same approach that has been done before and failed and can't cleanly
produce some aspects like delayed activation, passivation, persistence,
transaction demarcation, bifuricating interception etc.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] lifecycle release
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> As part of the Phase II release process we need to address the
> release of the Lifecycle Extensions package. This package is
> currently in the avalon-sandbox CVS. Package documentation is
> available at the following URL:
>
> http://avalon.apache.org/sandbox/lifecycle/
The migrated version is in Excalibur (along with the forrestized
documentation). The only difference between the two right now
is the build system.
> I propose
>
> * that the package be migrated from the avalon-sandbox
> CVS to the avalon CVS as a separate project along-side
> the avalon framework
+/- 0 No matter where it exists we need to do a release ASAP.
Fortress requires it.
> * the release of the avalon-lifecycle package shall be
> considered as an "optional" extension to the framework
> contracts
+1 This has always been the intention.
> * the release shall be made under an independent
> distribution (i.e. avalon-lifecycle-1.0.jar)
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org