avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [vote] Excalibur CVS
Date Fri, 20 Apr 2001 00:27:34 GMT
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?
>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
>4) reusable, pluggable components that provide
>commonly-needed code for programs that use the
>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
>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 ...



| "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

View raw message