> >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("[EMAIL PROTECTED]");
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
