I like Leo's suggested package organization. Its important to reflect the separation between spec and RI in the package structure.
-----Original Message-----
From: Leo Simons [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 4:48 PM
To: Avalon Development
Subject: RE: [vote] Excalibur CVS
> > > 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("[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]
