first things first...Stephen McConnell wrote:
> Leo was right - some of
> us will just get too pissed-off because we have better things to do
> with our time.
I never said that and I am not pissed-off at all. In fact, since
I am one of the few (only?) active developers with no real-life
use for avalon; I don't really feel a need to get pissed-off.
I do recognise that the debate is getting heated and that
viewpoints are no longer defended with logical arguments but
instead with emotional ones.
I've had my share of those, and I know almost all of them would be
solved in half an hour if communication had been face-to-face
instead of electronical. _Please_ keep this in mind with all e-mails
you send on subjects that might be touchy.
Nuff said. I'll try to remove emotional arguments and obscuring
rethoric and provide a more-or-less objective analysis. Try to.
Please, everyone, take time to read my long-winded story.
final note: I'm presenting pros and cons, not counter-pros and
counter-cons. I know they're there, but from what I know of
the theory of debate, those are better used in the weighing of
arguments. I'll leave that up to you.
THE NEED FOR A BETA
-------------------
why it is there:
----------------
Many people in corporate situations want to switch to Avalon
because it is so great, but they won't since there isn't even
a beta yet.
Cocoon wants to go beta but can't as it depends on Avalon
which is alpha.
Avalon started within JServ. It has had a long time to mature,
and now really is the time for it to grow up, especially
considering the fact the rest of the world is slowly catching
up and there is now a big need for Avalon. If it doesn't
step up to satisfy that need, some other project will
(which would be a waste of a good project!).
where it is not:
----------------
Peter doesn't need it, and many others probably don't either.
They already develop (using) Avalon and will probably keep
using cvs builds anyway if we get a release.
Also, presenting a beta means having to support it which
means cycles that cannot be devoted to development. While
a release means a bigger use base, it does mean a slowed-
down development cycle.
Fortunately, those that need the release have already convinced
those that do not to go ahead with it; both sides recognise and
respect the need for the beta.
THE OPTIONS
-----------
So, we want a beta, and soon. What are the options?
0) NO beta
not a real option; see above.
1) EVERYTHING goes beta
neatly package the current CVS (avalon, cornerstone,
phoenix, logkit; the whole bunch) into 4 jar files,
create some build scripts, write some docs and do a
release (I'd call this "the microsoft approach" >:)
pro:
- great for lazy users
- we've got a complete system to show to world; could
be useful as a proof-of-concept
con:
- not everything is of beta quality yet.
- not everything is stable yet.
- some stuff is so untested it is impossible to even
say if it will work in every situations
2) THE FRAMEWORK goes beta
(i.e. everything in avalon.*, excalibur.*, framework.*,
etc)
pro:
- likely that users of current 3.1a1 release will
have an easy update
- likely that current apps will not miss
functionality thus having to depend on alpha .jars
to augment the beta.
con:
- not everything is of beta quality yet.
- not everything is stable yet.
- some stuff is so untested it is impossible to even
say if it will work in every situations
3) PART-OF-FRAMEWORK goes beta
This is the current proposal; it is supported (AFAIK),
in concept, by everyone. The stable, tested parts of
the framework code goes beta; the rest does not.
pro:
- the "beta" stamp on the stable part of the code is
something we can support much more easily.
con:
- some needed functionality might be missing for apps
that use the framework, thus preventing them to
go beta.
OUR OPTION, and things to consider
----------------------------------
1) What do we do?
Stick with #3. Some will want #0, some will want #1.
This is a neat compromise.
2) What is the problem?
On the one hand there is the risk of putting too much
into the beta so we have to update it 3 times a week
with major changes.
On the other hand there is the problem that arise when
we put too little in the beta: apps that wish to use it
get very little functionality.
3) How do we solve that?
Lots of discussion, of course. We still don't have a
real starting point for this...I'd say the primary user
of Avalon to target with this release (it is the only
public, open source, jakarta-hosted, closely-tied
project, and probably the most widely used one as well)
is Cocoon.
So, logic would dictate (as mr. Vulcan would put it)
that we include all materials in the beta that are
vital to Cocoon.
4) Which materials are vital to Cocoon?
We don't have an exhaustive, detailed, accurate list.
Can someone from Cocoon (probably Berin) provide one
as the basis for further discussion?
At least the lifecycle material, the Configuration-
Manager, the exceptions, and logging. I'm guessing
some of the threading/caching stuff as well?
***IMPORTANT POINT***
The discussion has been something like this:
- "I want to remove bla, bla2, bla3 and similar stuff..."
-- "I'll have serious problems if you remove too much
similar stuff like this. Also, don't remove the bla4
part of bla2; we need it"
- "I don't want to put stuff like bla4 in the beta.
If you test it, polish it and improve it I might,
though."
-- "That's unreasonable."
- "No it's not. You're unreasonable!"
-- "Am not!"
- "Are too!"
for more than a week. We can solve this pretty easily
by making a more detailed list of what goes into the
beta and what does not. Please be _precise_ in this
discussion...
AND THEN WHAT?
--------------
Having avalonapi-4.0b.jar is only a first step. Clearly,
this is a more-or-less temporary solution until the entire
avalon-XXX CVS material has a final release (more likely
several different releases for different use-cases).
My last e-mail had suggestions about that. It snowed in a
bit in all the discussion. Basically, I want to define the
relationship between different namespaces / avalon
components more explicitly.
I proposed a model of
1) specification (avalon.*)
2) reference implementation (phoenix.*)
3) extensions (of both spec and RI)
4) pluggable, common components
5) programs on top of Avalon
6) external APIs
So far, Stephen has made it clear several times to be +9.5
about it as well as some others (though not as 'solid' ;),
Peter has expressed serious doubts (though I think we're
actually somewhere on the same page but use different terms).
Those doubts in summary:
1) we do not have a specification (yet). Also, we need
many different specification for many different uses.
me: we do need a specification. Yes, we have many different
uses, but that doesn't mean multiple specs are neccessary,
it needs a spec that accommodates those many uses (perhaps
that is almost the same in practice as having multiple specs;
it sounds like less work to me).
2) why can't we use the framework model, like is done with
Swing?
me:
(FYI, Swing is a GUI library based on the principles
of JavaBeans, MVC and container-based creation of a GUI. Most
people that know how to program it (you need a separate
book to learn how to do it right) absolutely love it.)
I can't really see how the 'new' Avalon would look if we
use the Swing model rigourously. Also, I'm not quite sure
exactly what a framework model really is.
Anyway, some _possible_ reasons why:
- GUI programming is a very different problem space. OOP works
great for GUI; it's not good enough for server apps (which is
why we have COP).
- Swing basically has
a) containers for objects (JPanel etc)
b) objects (JButton etc)
c) handlers/listeners responding to user modifications of
those objects (ChangeListener etc)
d) utilities to manipulate those three (RTFEditorKit etc)
Avalon has a much more complex structure than that.
Automated/rapid server application programming is a lot more
complex (probably not easier!) than GUI programming. It requires
a different approach (first came J2EE, then came .Net. Now,
there is Avalon. <-- how's that for a slogan =).
I dunno. It may be appicable. I think the spec with RI and
extensions is better (more examples: the Java Language Specification
with JDK as spec and RI, and javadoc as an extension; the POSIX
specification with GNU/HURD as spec and RI, and a multitude of
tools as extensions).
3) Your model only works if we consider Avalon as just an
application server.
me: well, I simply completely disagree with that =) I think I've
also given enough examples to prove otherwise.
4-10) not heard them yet. Not saying they don't exist...anyone?
Now how do we implement that?
-----------------------------
If I'd start from scratch, I would just have a single
avalon cvs with the following...
where? what? ???
------------------------------------------------------------------------
src/api/java org.apache.avalon.* (stable interfaces)
src/phoenix/java org.apache.phoenix.* (impl of stable interfaces)
src/dev/api/java org.apache.avalon.* (unstable interfaces)
src/dev/phoenix org.apache.phoenix.* (impl of unstable interfaces)
/api
src/dev/util/java org.apache.aut.* (utility code)
src/dev/compo- org.apache.excalibur.* (re-usable components)
nents/java
src/dev/ext/NAME org.apache.avalon.* & (extensions of the core API,
/java org.apache.phoenix.* with implementations)
src/logkit/java org.apache.log.* (LogKit)
src/apps/java org.apache.avalon. (XCommander, HelloWorldServer,
apps.* etc)
...and an extensive (or several) build.xml file for creating
a multitude of different releases. This means the different
parts can always be in sync with each other, you don't need
to update .jars in different CVSes whenever you change
something, can create integrated releases more easily, and
basically don't have to loose the separation between the separate
sub-projects.
This is, essentially, what has been done for Tomcat 4.x
(they've got Catalina and Jasper in the same CVS, but in
different trees).
We don't have this, and I can live with the current setup
(I don't see many advantages to it, but there undoubtly are).
(note: if many people want to see stuff re-organised like this,
I would be willing to put in the cycles to do it; but I don't
want to poke in what might be old wounds =)
We can still do almost the same within the CVSes we currently
have, which is what I would recommend we do. I'm willing to do
re-organisation and build files.
ROADMAP
-------
Here's a (not neccessarily completely lineair)
roadmap of the steps to take, containing the items
that seem to be on people's to-do list. I've also
listed names behind the things people have already
committed to doing...
- define separation between stable and unstable api;
- move unstable to excalibur package; (Pete)
- clean up stable api; (Pete)
Pete's list included again:
* finalize *activity* related methods (init/start/resume/etc)
* move processor methods to excalibur
* write a python/perl/other script to convert (i am currently using elisp
which is not useful to everyone else)
* move camelot/atlantis to phoenix CVS
* remove compat hierarchy (done, right?)
* migrate code in avalon.util to better resting place
(either as components in phoenix or into the void)
And here's his most recent one:
* 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
- release beta of stable api;
- stabilise LogKit (it already is, isn't it? =), and create
a release (does it even need a beta?);
- make all current code in the avalon CVSes work with
the api;
- release a new alpha to work with the beta.
Also on the list...
phoenix
- finish jmx code in proposal for phoenix; (Leo)
- move jmx code for phoenix into main tree; (Leo with help of Pete)
- test phoenix.
dev framework
- work on excalibur;
- release an excalibur beta;
- update all current code again to work with that;
- release a new alpha to work with the beta.
docs
- clean up / update documentation; (partially, Leo)
- add / update / improve javadocs (project-wide, except
for the probably over-documented XCommander =);
- update website;
- put the new logo on everything; (Leo)
cornerstone
- I still don't get what it is; it's a bit messy
and javadocs are out-of-date. I thus won't try
to make a list here...
Longer-term...
more phoenix
- another round of refactoring and testing;
- phoenix beta;
- create a release which we can label as 'probably
suitable for everyday use' with avalonapi,
logkit and phoenix in it. I personally would
really like to see this before the end of
July...I guess a lot of that depens on how much
time I put in myself.
more avalon
- merge excalibur with avalon again;
- more testing;
- more documentation;
- release (I really feel Avalon should be able to
get out a production-quality release in, say,
November).
I think I've said enough for now. If you've read all
the way up to here before hitting reply, thanks for
that =)
good night, everone,
LSD
PS: one last thing...
Stephen wrote to Peter:
> If moving to beta means loosing your contribution and
>knowledge about Avalon, then this is an acceptable loss
I'd add:
"If an entire more week of heated (but civil) discussion
means we do _not_ loose Peters' contribution and
knowledge about avalon, that's a more acceptable loss."
Let's try to avoid ultimatums. This ain't a war, it's
collaborative software development.
<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]
