You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/04/19 15:58:03 UTC
[vote] Excalibur CVS
Hi,
Just want to know your opinions on creating a new CVS for Excalibur. Not
neccessary just yet but will be in a few weeks IMHO (just before we go
beta). This way we can keep the framework separate from component
repository etc. Votes?
Cheers,
Pete
*-----------------------------------------------------*
| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Peter Donald <do...@apache.org>.
At 01:42 21/4/01 +0200, Stephen McConnell wrote:
>Lets be real - the above comments simply establish a context for moving
>forward, with, or without your support. The bottom line is that failure to
>move to beta because you cannot get your way simply means that you are the
>principal obstacle. If moving to beta means loosing your contribution and
>knowledge about Avalon, then this is an acceptable loss - because if we
>don't
>move to beta we (the Avalon fledgling community) will die. I don't want to
>see that happen - instead I want to see a broader process - an open process
>reflecting the consensus of the community - higher levels of contribution
>and active participation - a community where your opinions matter but a
>community where your opinion is just that - one opinion amongst many others.
That I would like. Read this
http://jakarta.apache.org/site/understandingopensource.html. You want it -
you do it. Feel free to ask me what needs doing to get release working.
>From memory the following needs doing
* fix build files (I am not sure both src and bin distrbitions build
properly since migration to new CVSes). Verify distributions run/build on
*nix and win32.
* add in changelog style change list for each project.
* patch docs in all the correct places to make it of beta quality
* prepare a list of news sites to send stuff to
* prepare mail-out announcement
If you want I am sure you can get commit access at which point you will be
able to build and upload the binaries in
http://jakarta.apache.org/builds/jakarta-avalon/release. You can also send
patches against jakarta website to indicate the release and add a news item
(see jakarta-site CVS).
As has been indicated my -1 is not a veto but an indication I don't support
it and neither am I willing to do the work - doesn't mean you can't do it
though. Release Manager is currently a vacant position ;)
As to the rest I would love to never have to touch anything again besides
cornerstone and perhaps kernel stuff (mainly because it is challenging).
Feel free to step up and put in the time and I will stop being so active in
the other areas ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 05:37 20/4/01 +0200, Stephen McConnell wrote:
> >Can I just confirm a couple of things -
> >perhaps its just me sifting through what is noise and what is
> >serious.... but I would appreciate confirmation of the following
> >two points:
> >
> > 1. there was a proposed creating a new CVS to which there was
> > uniform disagreement ... therefore, I am presuming that it
> > now off the agenda (after all, this is an open process -
> > and votes count)
>
> It has been vetoed ... wait a few months and I will surely bring
> it up again though ;)
LOL!!
Your assuming that I'm going to be on this list in two months!!
Given the level of noise your creating in opposition to the "general"
interest in getting a beta out (as opposed you to "personal" idea of
what a beta should be), I'll be out of here. Leo was right - some of
us will just get too pissed-off because we have better things to do
with our time.
> > 2. I'm assuming the "veto" comment was off-the-cuff and should
> > not be taken seriously ... (but if I'm wrong, then there is
> > a very serious issue!)
>
> No it was serious. I have already accepted change that I don't think
> are 100% optimal. My opinion is that there should be nothing in
> org.apache.avalon.* namespace (bad advertising). It is much better to
> make everything in other namespaces but use advertising to get message
> across about where it is from (ie AvalonFramework or avalon-framework
> as name of jars). I also don't like idea of merging in components+aut
> code, nor merging framework code and component code etc. The
> implementation-interface non-separation is also a little yucky but not
> something that I think is worth persuing yet. All in all I have made
> many a compromise to try to bring Avalon to beta ... and I was willing
> to support it as such. However a straw can break a camels back ;)
OK, lets see how much the camel can take.
You are personally not happy with attributing beta to Avalon and yet it
seems that everyone else on this list wants immediate resolution of this.
You are opposing this strongly but at the same time you are not coming
up with concrete proposals. This means that members of this list, and
people considering take-up of Avalon as framework are obliged to put up
with things like:
> From: Peter Donald
> Sent: Friday, 20 April, 2001 01:49
> well I guess I differ in opinion ... enough to veto a beta
> release ;)
> From: Peter Donald [mailto:donaldp@apache.org]
> consider this the line in the sand - no further will I
> compromise
> From: Peter Donald
> You can beta it all you want ... however don't expect me to
> stake my reputation on it or support it in anyway. If you are
> willing to do that .... then thats your perogative.
Lets be real - the above comments simply establish a context for moving
forward, with, or without your support. The bottom line is that failure to
move to beta because you cannot get your way simply means that you are the
principal obstacle. If moving to beta means loosing your contribution and
knowledge about Avalon, then this is an acceptable loss - because if we
don't
move to beta we (the Avalon fledgling community) will die. I don't want to
see that happen - instead I want to see a broader process - an open process
reflecting the consensus of the community - higher levels of contribution
and active participation - a community where your opinions matter but a
community where your opinion is just that - one opinion amongst many others.
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Peter Donald <do...@apache.org>.
At 05:37 20/4/01 +0200, Stephen McConnell wrote:
>Can I just confirm a couple of things -
>perhaps its just me sifting through what is noise and what is serious....
>but I would appreciate confirmation of the following two points:
>
> 1. there was a proposed creating a new CVS to which there was uniform
> disagreement ... therefore, I am presuming that it now off the agenda
> (after all, this is an open process - and votes count)
It has been vetoed ... wait a few months and I will surely bring it up
again though ;)
> 2. I'm assuming the "veto" comment was off-the-cuff and should not be
> taken seriously ... (but if I'm wrong, then there is a very serious
> issue!)
No it was serious. I have already accepted change that I don't think are
100% optimal. My opinion is that there should be nothing in
org.apache.avalon.* namespace (bad advertising). It is much better to make
everything in other namespaces but use advertising to get message across
about where it is from (ie AvalonFramework or avalon-framework as name of
jars). I also don't like idea of merging in components+aut code, nor
merging framework code and component code etc. The implementation-interface
non-separation is also a little yucky but not something that I think is
worth persuing yet. All in all I have made many a compromise to try to
bring Avalon to beta ... and I was willing to support it as such. However a
straw can break a camels back ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] Excalibur CVS
Posted by Peter Donald <do...@apache.org>.
At 09:52 20/4/01 -0400, Berin Loritsch wrote:
>Peter Donald wrote:
>>
>> At 11:12 19/4/01 -0400, Berin Loritsch wrote:
>> >-1 for all the reasons outlined in my other email. We need to make sure
>> > that Avalon is not only Modular, but that it isn't fragmented either.
>> > It's a fine line to walk--and I think that this should be revisited
>> > when JSR-111 has it's first public deliverable.
>>
>> Well it is probably best to look at use case. As I have said before most of
>> my uses of the framework part do not need *anything* out of excalibur
>> (except maybe CLI package). The framework is just that - framework -
>> completely independent of any arbitrary components created using said
>> framework.
>
>If you don't need it, don't use it. Simple.
stupid arguement - do I really need to point out why ?
>> What benefit to our users does including the components provide?
>
>Tons. It means that they don't have to reinvent the wheel if they don't
>want to. It means that they have examples readily available of the
>framework in action. People are basically lazy, and won't bother looking
>in another project (even if it is associated) so they will start implementing
>their own version of things before they realize that they are wasting or
>have wasted time on something that works just as well.
So why not include all the commons projects in avalonapi?
>> >I think the timing is bad for this kind of move, because the ramifications
>> >can't possibly be completely thought out yet.
>>
>> agreed - but I am reluctant to beta-ize before doing this.
>
>Why is that? All I am saying is go beta with the components in the jar.
>We can then discuss the ramifications, so that for a _distant_ release
>we will revisit this.
So we go beta now with the assumption that we will change the arrangement
later to break everyones builds ? Does that really sound like a good thing?
>To be honest, I would have a real problem if we didn't go beta because
>you didn't get to remove excalibur into a new CVS. According to all the
>feedback, noone agrees with the move--so why do it? And why punish those
>of us who want beta and stability because we don't have a separate CVS?
I am not punishing you in anyway - you are free to put in the work and veto
any changes that come along - thats the beauty of a meritocracy. I have
already compromised enough on technical matters - consider this the line in
the sand - no further will I compromise. I don't mind supporting a beta
even if it is not 100% what I want - however this goes beyond what I
consider an acceptable compromise.
Cheers,
Pete
*-----------------------------------------------------*
| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] Excalibur CVS
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> [last para from Berin email]
> > To be honest, I would have a real problem if we didn't go beta because
> > you didn't get to remove excalibur into a new CVS. According to all the
> > feedback, noone agrees with the move--so why do it? And why punish those
> > of us who want beta and stability because we don't have a separate CVS?
>
> Can I just confirm a couple of things -
> perhaps its just me sifting through what is noise and what is serious....
> but I would appreciate confirmation of the following two points:
>
> 1. there was a proposed creating a new CVS to which there was uniform
> disagreement ... therefore, I am presuming that it now off the agenda
> (after all, this is an open process - and votes count)
Yes. (Hopefully noone thinks it is still on the agenda for beta release)
> 2. I'm assuming the "veto" comment was off-the-cuff and should not be
> taken seriously ... (but if I'm wrong, then there is a very serious
> issue!)
I sure hope so.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Stephen McConnell <mc...@osm.net>.
[last para from Berin email]
> To be honest, I would have a real problem if we didn't go beta because
> you didn't get to remove excalibur into a new CVS. According to all the
> feedback, noone agrees with the move--so why do it? And why punish those
> of us who want beta and stability because we don't have a separate CVS?
Can I just confirm a couple of things -
perhaps its just me sifting through what is noise and what is serious....
but I would appreciate confirmation of the following two points:
1. there was a proposed creating a new CVS to which there was uniform
disagreement ... therefore, I am presuming that it now off the agenda
(after all, this is an open process - and votes count)
2. I'm assuming the "veto" comment was off-the-cuff and should not be
taken seriously ... (but if I'm wrong, then there is a very serious
issue!)
Feedback please ....
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] Excalibur CVS
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> At 11:12 19/4/01 -0400, Berin Loritsch wrote:
> >-1 for all the reasons outlined in my other email. We need to make sure
> > that Avalon is not only Modular, but that it isn't fragmented either.
> > It's a fine line to walk--and I think that this should be revisited
> > when JSR-111 has it's first public deliverable.
>
> Well it is probably best to look at use case. As I have said before most of
> my uses of the framework part do not need *anything* out of excalibur
> (except maybe CLI package). The framework is just that - framework -
> completely independent of any arbitrary components created using said
> framework.
If you don't need it, don't use it. Simple.
> What benefit to our users does including the components provide?
Tons. It means that they don't have to reinvent the wheel if they don't
want to. It means that they have examples readily available of the
framework in action. People are basically lazy, and won't bother looking
in another project (even if it is associated) so they will start implementing
their own version of things before they realize that they are wasting or
have wasted time on something that works just as well.
> >I think the timing is bad for this kind of move, because the ramifications
> >can't possibly be completely thought out yet.
>
> agreed - but I am reluctant to beta-ize before doing this.
Why is that? All I am saying is go beta with the components in the jar.
We can then discuss the ramifications, so that for a _distant_ release
we will revisit this.
> >There is already a Jakarta
> >Commons project, and creating a competing project that is Avalon focussed
> >doesn't entirely make sense.
>
> Commons won't accept any of the Avalon components because they are
> "tainted" ;)
That's their loss :P
Really though, I don't think that we should keep fragmenting.
> >The package separation of interface and implementation IMO is
> >enough at this time.
>
> Thats a misconception - we don't do this at the moment. We separate between
> components and framework but interface and implementation sit side-by-side.
I stand corrected. That is what I meant in my head, although I didn't
write it correctly...
> >Let momentum build up around Avalon framework with the Components in
> >the Excalibur package--and when we have more developers we can revisit
> >this.
>
> Put it this way - I want to be able to build AvalonFramework-4.0b.jar and
> place it in C2 CVS. It should not be updated until we release next version
> of framework (ie stable release or RCs if needed)? Can you guarentee that
> you will not modify any code in the excalibur package for that long
> (possibly 4-5 months) ? I doubt it - hence the separation.
Put it this way - I want to be able to build AvalonFramework-4.0b.jar and
update with bugfixes as they come.
Our versioning system should be one like this:
Major number change = structuring or major shift of focus
Minor number change = feature additions
Micro number change = bug fixes.
That way we have a regular release schedule. In that approach, this release
would be Avalon API 4.0b. Bug fixes releases should be Avalon API 4.0b1, b2,
etc.
I don't mind a 3 month release cycle if we are dealing with bug fixes or new
features. I do mind a 3 month release cycle if we are dealing with major
version changes.
When I see a package that has been inactive for a year, then I assume it is
dead and not maintained. When I see a package that has moderate changes
whether they are bug fixes or feature additions (i.e. new components) then
I am comforted to know that the project is maintained, but relatively stable.
Don't get me wrong, the way we are reorganizing Avalon framework is good,
and I like it. I think that being too radical in our changes for a framework
causes more damage than good.
To be honest, I would have a real problem if we didn't go beta because
you didn't get to remove excalibur into a new CVS. According to all the
feedback, noone agrees with the move--so why do it? And why punish those
of us who want beta and stability because we don't have a separate CVS?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] Excalibur CVS
Posted by Peter Donald <do...@apache.org>.
At 11:12 19/4/01 -0400, Berin Loritsch wrote:
>-1 for all the reasons outlined in my other email. We need to make sure
> that Avalon is not only Modular, but that it isn't fragmented either.
> It's a fine line to walk--and I think that this should be revisited
> when JSR-111 has it's first public deliverable.
Well it is probably best to look at use case. As I have said before most of
my uses of the framework part do not need *anything* out of excalibur
(except maybe CLI package). The framework is just that - framework -
completely independent of any arbitrary components created using said
framework.
What benefit to our users does including the components provide?
>I think the timing is bad for this kind of move, because the ramifications
>can't possibly be completely thought out yet.
agreed - but I am reluctant to beta-ize before doing this.
>There is already a Jakarta
>Commons project, and creating a competing project that is Avalon focussed
>doesn't entirely make sense.
Commons won't accept any of the Avalon components because they are
"tainted" ;)
>The package separation of interface and implementation IMO is
>enough at this time.
Thats a misconception - we don't do this at the moment. We separate between
components and framework but interface and implementation sit side-by-side.
>Let momentum build up around Avalon framework with the Components in
>the Excalibur package--and when we have more developers we can revisit
>this.
Put it this way - I want to be able to build AvalonFramework-4.0b.jar and
place it in C2 CVS. It should not be updated until we release next version
of framework (ie stable release or RCs if needed)? Can you guarentee that
you will not modify any code in the excalibur package for that long
(possibly 4-5 months) ? I doubt it - hence the separation.
Cheers,
Pete
*-----------------------------------------------------*
| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Stephen McConnell <mc...@osm.net>.
> From: Berin Loritsch
> Let momentum build up around Avalon framework with the Components in
> the Excalibur package--and when we have more developers we can revisit
> this.
+9.5
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] Excalibur CVS
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> Hi,
>
> Just want to know your opinions on creating a new CVS for Excalibur. Not
> neccessary just yet but will be in a few weeks IMHO (just before we go
> beta). This way we can keep the framework separate from component
> repository etc. Votes?
> Cheers,
-1 for all the reasons outlined in my other email. We need to make sure
that Avalon is not only Modular, but that it isn't fragmented either.
It's a fine line to walk--and I think that this should be revisited
when JSR-111 has it's first public deliverable.
I think the timing is bad for this kind of move, because the ramifications
can't possibly be completely thought out yet. There is already a Jakarta
Commons project, and creating a competing project that is Avalon focussed
doesn't entirely make sense. The package separation of interface and
implementation IMO is enough at this time.
Let momentum build up around Avalon framework with the Components in
the Excalibur package--and when we have more developers we can revisit
this.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Peter Donald <do...@apache.org>.
At 10:45 20/4/01 +0200, Leo Simons wrote:
>> >1) a well-documented specification (interfaces; contracts)
>> >2) a (reference) implementation that does nothing more
>> >than implement that specification
>>
>> what specification? We don't have one.
>
>Exactly! ;) (<-- meaning: we probably do need one)
heres where I have issue - we should not have one - we should have N (where
N is some number greater than 1). Because we have N different uses ;)
>> Your model only works if we consider Avalon as just an application server.
>> As soon as this assumption breakes the model falls down. I don't make that
>> assumption (and I would argue against it) so ...
>
>? Why? (really, why? I fail to see it...)
>The model I'm talking about is mostly quite similar to
>what is done with java.* and javax.*, at least with newer code
>like JMX or Connector.
No - there is a number of models in the java std/ext libs. One of them is
the definition of client interface and some utility classes *ie servlet
spec). Other approaches include;
(1) Service + Service Provider Interface. For instance JNDI has interfaces
that that the client interacts with, interfaces/classes the service
provider interacts and a set of SPI implementations (see
File/NFS/DNS/whatever JNDI implementations).
(2) Framework based spec. See swing it is prime example of this.
(3) Globbing classes with similar content together (ie lets chuck all io
stuff into java.io.*)
(4) Traditional client interface+impl as separate (see servlet spec)
We use each where appropriate. For instance throughout cornerstone we use
(1), (3) and (4) (Hopefully with more (1) in future). We use (2) with
Framework stuff etc.
I think the definition you make between interface/implementation is
artifical for a number of reasons. First reason is that the existing
*frameworks* in the JDK do not make this distinction. Swing (in particular)
and Collections both have imple and intf side-by-side. Separating them out
is not useful for our users. They can still reimplement the things from
scratch (C2s version of CM) but why should they have to for default
implementations?
ie What makes the swing model (which is also a framework) not applicable to
our framework?
> If we do this, org.apache.excalibur needs to be in the Avalon
> in the Avalon package. If we want to move parts of Cornerstone
> to excalibur, it makes sense to instead clean up cornerstone
> and then rename it to excalibur.
I am confused by this. Cornerstone is one of the things I am happy with and
I really don't want to start moving bits of it to excalibur ... ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Stephen McConnell <mc...@osm.net>.
Looks to me like there is a concrete packaging proposal from Leo
> What _can_ be done quickly:
> - define and build avalonapi-4.0b.jar which has the same role
> as "avalon-core.jar" above, but does not have the interface
> separated from implementation yet.
+1
> - Cocoon2 beta ;)
Don't know what Cocoon2 is so I'll refrain from putting up an
opinion on this.
> - start on phoenix-4.0b.jar, which has the same role as
> "phoenix-core.jar" above, and for now includes
> org.apache.avalon.atlantis as it isn't stable enough
> yet.
+1
But can you clarify - is it a question of stability or a question
of validation ?
> - start on excalibur-3.3a.jar, which contains the code not
> stable enough for avalonapi-4.0b.jar yet.
+1
Cheers, Steve.
RE: [vote] Excalibur CVS
Posted by Leo Simons <ma...@leosimons.com>.
> >1) a well-documented specification (interfaces; contracts)
> >2) a (reference) implementation that does nothing more
> >than implement that specification
>
> what specification? We don't have one.
Exactly! ;) (<-- meaning: we probably do need one)
> Your model only works if we consider Avalon as just an application server.
> As soon as this assumption breakes the model falls down. I don't make that
> assumption (and I would argue against it) so ...
? Why? (really, why? I fail to see it...)
The model I'm talking about is mostly quite similar to
what is done with java.* and javax.*, at least with newer code
like JMX or Connector.
As is see it, if you want to use nothing more than the core
framework code (say the lifecycle stuff and everything related
to that), you do a "build core-dist" or something...
i.e. you can have a J2ME, J2SE and a J2EE which have code
living in the same namespaces - you can also have a
couple of avalon distro's/.jars for different use-cases.
Let's tinker about this a little bit...
BASIC FILES IN DAILY USE
------------------------
avalonapi.jar
|
| This is the complete tree that specification implementors
| have to provide an implementation for. Some packages are
| marked "[optional]" to indicate they're an optional part of
| the spec. These could also be in avalon-spec-ext-XXX.jars
| or something.
| I've just picked some stuff randomly here.
|
|--- org.apache.avalon.* with
|--- org.apache.avalon.atlantis.* [optional]
|--- org.apache.avalon.camelot.* [optional]
\--- org.apache.avalon.collections.* [optional]
phoenix.jar
|
\ Complete implementation of avalon-spec.jar.
phoenix-core.jar
|
\ Implementing the non-optional parts of avalon-spec.jar
phoenix-atlantis.jar
|
| Implementing the atlantis part of avalon-spec.jar,
\ to be used as an add-on for phoenix-core.jar
phoenix-camelot.jar
|
| Implementing the camelot part of avalon-spec.jar,
\ to be used as an add-on for phoenix-core.jar
phoenix-collectons.jar
|
| Implementing the atlantis part of avalon-spec.jar,
\ to be used as an add-on for phoenix-core.jar
CONVENIENCE JARS FOR COMMON USE-CASES
-------------------------------------
avalon-core.jar
|
| This is a .jar to be used in places where all you need is the
| core framework code to simplify working with applications. I've
| included the RI of the spec here to reduce the number of .jars
| from 2 to 1.
|
| (SPECIFICATION)
|
|--- org.apache.avalon.lifecycle.*
|--- org.apache.avalon.context.*
|--- org.apache.avalon.configuration.*
|--- org.apache.avalon.parameters.*
|--- org.apache.avalon.component.*
|--- org.apache.avalon.log.*
|--- org.apache.avalon.thread.* (perhaps)
|--- (similar stuff)
|
| (IMPLEMENTATION)
|
|--- org.apache.phoenix.lifecycle.*
|--- org.apache.phoenix.context.*
|--- org.apache.phoenix.configuration.*
|--- org.apache.phoenix.parameters.*
|--- org.apache.phoenix.component.*
|--- org.apache.phoenix.log.*
|--- org.apache.phoenix.thread.* (perhaps)
\--- (similar stuff)
avalon-complete.jar
|
| This convenience .jar contains all the Avalon and Phoenix code.
| All you have to do is run it and the atlantis impl fires up and
| runs. You can use RMI to talk to the JMX adaptor, to provide it
| with the location of apps you wish to deploy.
|
| So you could have this .jar in the lib/ of say JAMES (together
| with logkit.jar and apache-jmx.jar), and have a small bootstrap
| class that tells Phoenix where to find the JAMES.sar and deploy
| it.
|
|--- org.apache.avalon.*
\--- org.apache.phoenix.*
EXTENSIONS / ADD-ONS / EXTERNALS
--------------------------------
apache-jmx.jar
|
| This contains the org.apache.jmx.* code, which is a requirment for
\ _Phoenix_ if you wish to use JMX.
logkit.jar
|
| This contains the org.apache.log.* code, which is likely to be a
| requirment for almost every _Phoenix_ app because it is needed for
| logging. Another Avalon implementation may implement logging
| very differently.
| The assumption here is that most of the details of logging are
| something for the implementation to worry about; most of the
| logging settings don't need to be modifiable/known to the apps
| running on top of Avalon. This might be entirely wrong. In that
| case, either org.apache.log.* should contain more (see below),
\ or it shouldn't exist.
excalibur.jar
|
| This contains all utility code for avalon applications - these are
| Components/Blocks/Services that are not defined by the specification,
| but that are needed in many apps (pooling, datasource, timer, sockets,
| store, scheduler, etc).
|
\--- org.apache.excalibur.*
excalibur-XXX.jar
|
| As excalibur grows, it will probably make sense to separate it out
| into multiple .jars so application deployers only have to include
\ the components they need.
demos.jar
|
| This contains the current demos from the Cornerstone CVS.
|
|--- org.apache.demos.avalon.* (I'm at a loss where these should end up;
\ probably org.apache.excalibur.demos)
NOTES
-----
- org.apache.avalon.log has the most basic parts of logging only;
the parts apps built on Avalon need to deal with (Loggable and
Logger interfaces only, probably).
- "phoenix" here means RI. We could also have a different name for
this and have org.apache.phoenix only serve as the RI of
org.apache.avalon.atlantis, but this is IMHO not the most logical
organisation (org.apache.avalon.atlantis should be implemented
by org.apache.XXX.atlantis).
- I know we can't do this yet...
What _can_ be done quickly:
- define and build avalonapi-4.0b.jar which has the same role
as "avalon-core.jar" above, but does not have the interface
separated from implementation yet.
- Cocoon2 beta ;)
- start on phoenix-4.0b.jar, which has the same role as
"phoenix-core.jar" above, and for now includes
org.apache.avalon.atlantis as it isn't stable enough
yet.
- start on excalibur-3.3a.jar, which contains the code not
stable enough for avalonapi-4.0b.jar yet.
If we do this, org.apache.excalibur needs to be in the Avalon
in the Avalon package. If we want to move parts of Cornerstone
to excalibur, it makes sense to instead clean up cornerstone
and then rename it to excalibur.
I think I've made myself about as clear as possible =)
cheers all,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Peter Donald <do...@apache.org>.
At 10:48 19/4/01 +0200, Leo Simons wrote:
>I think we need to look at the larger picture.
>What we want to do with avalon is provide best-
>of-practice software design and code. What is
>the best organisation for a generic, medium-to-
>large project like Avalon, where the most
>important target are the third-party developers?
>
>IMHO:
>
>1) a well-documented specification (interfaces; contracts)
>2) a (reference) implementation that does nothing more
>than implement that specification
what specification? We don't have one.
>3) extensions that extend the specification and the
>implementation
>4) reusable, pluggable components that provide
>commonly-needed code for programs that use the
>specification
>5) programs that use the specification
>6) external APIs used by the spec
>
>1 = interfaces, contracts, documentation. Stuff like
>Application, the lifecycle spec, etc.
>2 = implementation of interfaces. This should include
>an implementation of atlantis (i.e. the current phoenix).
>3 = while 1 can contain some optional parts, 3 contains
>those parts that are not likely to be used in more than
>say 60% of applications.
>4 = this is stuff like the delegating sax handler from
>XCommander.
>5 = everything built on top of Avalon.
>6 = complete J2SE, JMX API, etc.
>
>The organisation we should thus strive for, package-wise:
>
>1) org.apache.avalon containing interfaces and contracts
>2) org.apache.phoenix as the RI
>3) org.apache.avalon.** & org.apache.phoenix.** containing
> implementations
>4) org.apache.excalibur for reusable components.
>5) org.apache.tomcat; org.apache.xcommander;
> org.apache.commons.*; org.apache.commons.avalon.* etc.
>6) org.apache.jmx; javax.*; org.apache.log.* etc.
>
>With this in mind, excalibur could indeed be a separate
>CVS. But not in the role you suggest here. Excalibur now
>is purely a container for stuff not ready to move into
>org.apache.avalon yet and thus should be kept with
>that CVS.
Your model only works if we consider Avalon as just an application server.
As soon as this assumption breakes the model falls down. I don't make that
assumption (and I would argue against it) so ...
Cheers,
Pete
*-----------------------------------------------------*
| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Leo Simons <ma...@leosimons.com>.
> > > neccessary just yet but will be in a few weeks IMHO (just before we go
> > > beta). This way we can keep the framework separate from component
> > > repository etc. Votes?
> >
> > -1, I would prefer to wait until I have had a chance to play
> with the new
> > structure before addressing this.
> >
> > Steve.
>
> -1 - I'm with steve and berin here.
> Charles
-1.
I think we need to look at the larger picture.
What we want to do with avalon is provide best-
of-practice software design and code. What is
the best organisation for a generic, medium-to-
large project like Avalon, where the most
important target are the third-party developers?
IMHO:
1) a well-documented specification (interfaces; contracts)
2) a (reference) implementation that does nothing more
than implement that specification
3) extensions that extend the specification and the
implementation
4) reusable, pluggable components that provide
commonly-needed code for programs that use the
specification
5) programs that use the specification
6) external APIs used by the spec
1 = interfaces, contracts, documentation. Stuff like
Application, the lifecycle spec, etc.
2 = implementation of interfaces. This should include
an implementation of atlantis (i.e. the current phoenix).
3 = while 1 can contain some optional parts, 3 contains
those parts that are not likely to be used in more than
say 60% of applications.
4 = this is stuff like the delegating sax handler from
XCommander.
5 = everything built on top of Avalon.
6 = complete J2SE, JMX API, etc.
The organisation we should thus strive for, package-wise:
1) org.apache.avalon containing interfaces and contracts
2) org.apache.phoenix as the RI
3) org.apache.avalon.** & org.apache.phoenix.** containing
implementations
4) org.apache.excalibur for reusable components.
5) org.apache.tomcat; org.apache.xcommander;
org.apache.commons.*; org.apache.commons.avalon.* etc.
6) org.apache.jmx; javax.*; org.apache.log.* etc.
With this in mind, excalibur could indeed be a separate
CVS. But not in the role you suggest here. Excalibur now
is purely a container for stuff not ready to move into
org.apache.avalon yet and thus should be kept with
that CVS.
regards,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] Excalibur CVS
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Stephen McConnell wrote:
>
> > neccessary just yet but will be in a few weeks IMHO (just before we go
> > beta). This way we can keep the framework separate from component
> > repository etc. Votes?
>
> -1, I would prefer to wait until I have had a chance to play with the new
> structure before addressing this.
>
> Steve.
-1 - I'm with steve and berin here.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] Excalibur CVS
Posted by Stephen McConnell <mc...@osm.net>.
> neccessary just yet but will be in a few weeks IMHO (just before we go
> beta). This way we can keep the framework separate from component
> repository etc. Votes?
-1, I would prefer to wait until I have had a chance to play with the new
structure before addressing this.
Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org