You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <ma...@leosimons.com> on 2001/04/21 21:39:00 UTC
The Roadmap to Beta (or: diving into the fray...)
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("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: The Roadmap to Beta (or: diving into the fray...)
Posted by Leo Simons <ma...@leosimons.com>.
> >- Factories / utility classes for everything, Factory / utility
> >outside the framework and integral static methods outside, or all
> >functionality within classes.
>
> This was what I wanted to do ages ago. Namely create Factories and have
> Mutable* versions of all the objects .... however I couldn't come
> up with a
> good enough reason to warrant that. (And thus the move was vetoed;]).
Isn't security-by-design good enough?
> Same with config and cm - and any services passed in CM. Automagically
> generating proxies is the only way to do it safely.
exactly. O, well...
> I was told to not sub-class to get type safety so I have been gradually
> making it a requirement to cast things based on expectation.
darn. O, well...
> >Something like that.
>
> sounds good to me - want to update the docs ;)
next one on the list, in fact.
> If you were to be writing to a mobile app then the other interfaces would
> also need to be stripped out. Luckily there is tools that do the stripping
> for you ;) (I think someone even submitted one to ant a while back).
This still does not disprove me saying there are advantages to the
separation between interface and implementation...o, welll...I'll
agree to disagree for now.
> true but we are moving away from that model. Turbine recently split, ant
> split, in time I assume commons will split etc.
In that case I really have no argument at all, do I? =)
> When the above is achieved then I will do all the work required to put
> together a release but until ... ;)
By that schedule June 15 is something we can definately do.
regards,
Leo
<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: The Roadmap to Beta (or: diving into the fray...)
Posted by Peter Donald <do...@apache.org>.
At 07:37 22/4/01 +0200, Leo Simons wrote:
>> >We have yet to define _explicit_ contracts for many parts of
>> >the framework. We currently provide default implementations
>> >of some parts of the framework (DefaultContext), and not for
>> >other parts.
>>
>> Which other parts don't we do.
>
>Some stuff to choose:
>
>- Factories / utility classes for everything, Factory / utility
>outside the framework and integral static methods outside, or all
>functionality within classes.
This was what I wanted to do ages ago. Namely create Factories and have
Mutable* versions of all the objects .... however I couldn't come up with a
good enough reason to warrant that. (And thus the move was vetoed;]).
>- contexts are built by writing to DefaultContext. This means
>people with access to DefaultContext can make them writable
>again (simple cast). Not good for security; the configuration
>way is better (my personal preference would be an anonymous
>inner class inside a factory cast to an interface, but hey =).
Same with config and cm - and any services passed in CM. Automagically
generating proxies is the only way to do it safely.
>There is more (real shame I lost my list...). Like not all interface
>methods taking the correct argument (some upcast too much, some
>downcast). You may have fixed this in the last few weeks (I'd have
>to check =), but there are some things.
I was told to not sub-class to get type safety so I have been gradually
making it a requirement to cast things based on expectation. Other things
(like casting hints to configuration in cornerstone.blocks.masterstore) I
don't like but hey - we can't everything right ;)
>I'll go and hammer nails into excalibur and avalon if you are
>finished there for now (are you?).
slowwed - never finito ;)
>> >This leads to some unclarity of what is the framework, and what
>> >isn't.
>>
>> Easy if it has to do with any of the following it is definetly framework
>> * lifecycle relationship (ie activity, logging, context, CM, config)
>> * container-component relationship (ie camelot)
>> * kernel-app-component relationships (ie atlantis)
>
>=) That's still an "has to do with any of the following" which again
>leads to unclarity. It is not that I can't see what is framework and
>what isn't (heck I've been staring at 3 different setups the last few
>weeks =), it's that it may not be clear to outsiders.
Sounds like a damn good arguement for havin a separate CVS under namespace
org.apache.framework ;)
>> In neuroscience I would call this "form" functions. This contrasts with
>> "content" functions such as
>
>Now we're getting somewhere. "The Avalon framework consists of interfaces
>that define relationships between commonly used application components,
>form functions, best-of-practice pattern enforcements, and several
>lightweight convenience implementations of the generic components.
>
>We also provide Excalibur, which provides content functions and other
>commonly used utilities to simplify and speed up the development of
>Avalon-based applications."
>
>Something like that.
sounds good to me - want to update the docs ;)
>> Just because it also includes a DefaultTableRenderer when you may want to
>> write your own does not devalue it's structure.
>
>Uhm, yes it does. If I want to write a swing-based mobile phone app and
>remove all the fancy controls, that's a lot of work. It'd be less work
>if I'd have two trees/jars.
If you were to be writing to a mobile app then the other interfaces would
also need to be stripped out. Luckily there is tools that do the stripping
for you ;) (I think someone even submitted one to ant a while back).
>> >> thankfully we have just moved away from that model - it was unanimous
>> >> decision so you should check archives for reasoning ;)
>> >
>> >did so. My answer would be "ant" to every problem mentioned =)
>>
>> Right - but by your logic we should include all jakarta projects
>> in one CVS
>> right? (or maybe all java apache projects - or perhaps the whole jdk ;]).
>
>It is all a question of granularity. Most projects have one CVS
>(some have one for old and one for new versions). We have no less
>than 5.
>By my logic each project has its own (single) CVS =)
true but we are moving away from that model. Turbine recently split, ant
split, in time I assume commons will split etc.
>Paul Hammant wrote:
>> Also, I'll bet you we lost subscribers to the mail lists when we
>> switched from java.apache.org to
>> jakarta.apache.org as we're now spammed by CVS messages in the
>> *same* list.
>
>you almost lost me =) I'd still like to see this changed if possible...
I am indifferent to it ... but if you want it changed you can always
propose a vote ;)
>> Proposal 1) June 15th : Switch to beta
>
>+/-0.5
>
>> Proposal 2) Formal release : August 1st
>
>+/-0.5. I hate dates like this when we don't even have something of
>a release plan. We cannot say when something is finished if we don't
>know what it has to be.
Phoenix will be suitable enough IMHO when we have management and good
logging. We almost have management thanks to you after that I will do
logging as soon as I have time. Then we may be closer to being ready.
The framework will be ready when it is decoupled from the components.
I doubt components as a whole will ever be *ready* as such - maybe
individual ones will be though ;)
Cornerstone/logkit/testlet is ready enough now.
>Come up with a more detailed plan and I'll support this.
When the above is achieved then I will do all the work required to put
together a release but until ... ;)
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: The Roadmap to Beta (or: diving into the fray...)
Posted by Leo Simons <le...@wanadoo.nl>.
> >We have yet to define _explicit_ contracts for many parts of
> >the framework. We currently provide default implementations
> >of some parts of the framework (DefaultContext), and not for
> >other parts.
>
> Which other parts don't we do.
Some stuff to choose:
- Factories / utility classes for everything, Factory / utility
outside the framework and integral static methods outside, or all
functionality within classes.
- contexts are built by writing to DefaultContext. This means
people with access to DefaultContext can make them writable
again (simple cast). Not good for security; the configuration
way is better (my personal preference would be an anonymous
inner class inside a factory cast to an interface, but hey =).
There is more (real shame I lost my list...). Like not all interface
methods taking the correct argument (some upcast too much, some
downcast). You may have fixed this in the last few weeks (I'd have
to check =), but there are some things.
I'll go and hammer nails into excalibur and avalon if you are
finished there for now (are you?).
> >This leads to some unclarity of what is the framework, and what
> >isn't.
>
> Easy if it has to do with any of the following it is definetly framework
> * lifecycle relationship (ie activity, logging, context, CM, config)
> * container-component relationship (ie camelot)
> * kernel-app-component relationships (ie atlantis)
=) That's still an "has to do with any of the following" which again
leads to unclarity. It is not that I can't see what is framework and
what isn't (heck I've been staring at 3 different setups the last few
weeks =), it's that it may not be clear to outsiders.
> In neuroscience I would call this "form" functions. This contrasts with
> "content" functions such as
Now we're getting somewhere. "The Avalon framework consists of interfaces
that define relationships between commonly used application components,
form functions, best-of-practice pattern enforcements, and several
lightweight convenience implementations of the generic components.
We also provide Excalibur, which provides content functions and other
commonly used utilities to simplify and speed up the development of
Avalon-based applications."
Something like that.
> >I don't see the coupling between CVS and release.
>
> well you a rare individual indeed ;)
Probably. Talk politics with me one day; you'll be baffled ;)
> >> Yep and I said whats wrong with swings model. The specification and
> >> implementation are both in "javax.swing.*".
> >
> >that is, imo, not a proper separation of concerns.
>
> why? I still don't understand why you would say this. Users need to access
> both implementations and interfaces - just like in swing. Do you think
> swing is badly designed?
Not at all (at least not when I compare it to COM or AWT, which are the
only other GUI frameworks I know). I think some of it's design decisions
are not very applicable to generic COP solutions.
> Just because it also includes a DefaultTableRenderer when you may want to
> write your own does not devalue it's structure.
Uhm, yes it does. If I want to write a swing-based mobile phone app and
remove all the fancy controls, that's a lot of work. It'd be less work
if I'd have two trees/jars.
> It is one of the few
> successful frameworks for java - I am not sure why you would want to go
> against a proven model?
Not against; simply proposing an alternative one that is doing extremely
well at the moment in the enterprise.
> Right - but it's the way that is being used. Hence why I didn't want
> anything in the org.apache.avalon.* namespace. I wanted Avalon as a
> covername much like jakarta is cover project for a bunch of
> smaller projects.
By naming convention, all jakarta projects should probably be in
org.apache.jakarta.*. In the end, the package structure is
a) a class-hiding mechanism
b) a branding mechanism.
Making use of the "jakarta" brand in the CVS would immediately give
more credit to all the code in all of its sub-projects.
> >nah. I ment there is the Java Language Specification
> >(document/diagrams), the JDK (implementation) and the javadoc
> >tool (extension). We don't separate spec from impl.
>
> So if we update the docs does that mean we are separated ? ;)
=) In our case, we left out the complicated diagrams and used
interfaces instead.
> >> thankfully we have just moved away from that model - it was unanimous
> >> decision so you should check archives for reasoning ;)
> >
> >did so. My answer would be "ant" to every problem mentioned =)
>
> Right - but by your logic we should include all jakarta projects
> in one CVS
> right? (or maybe all java apache projects - or perhaps the whole jdk ;]).
It is all a question of granularity. Most projects have one CVS
(some have one for old and one for new versions). We have no less
than 5.
By my logic each project has its own (single) CVS =)
> Phoenix does not depend on cornerstone. Think of phoenix as the servlet
> spec (ie org.apache.phoenix.*) + a servlet implementation (ie the rest of
> phoenix). Cornerstone depends on the spec part - phoenix couldn't
> care less
> if cornerstone existed or not ;).
I know. But since you keep referring to cornerstone as utility code
for phoenix, I listed it.
Paul Hammant wrote:
> Also, I'll bet you we lost subscribers to the mail lists when we
> switched from java.apache.org to
> jakarta.apache.org as we're now spammed by CVS messages in the
> *same* list.
you almost lost me =) I'd still like to see this changed if possible...
> Proposal 1) June 15th : Switch to beta
+/-0.5
> Proposal 2) Formal release : August 1st
+/-0.5. I hate dates like this when we don't even have something of
a release plan. We cannot say when something is finished if we don't
know what it has to be.
Come up with a more detailed plan and I'll support this.
regards,
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: The Roadmap to Beta (or: diving into the fray...)
Posted by Paul Hammant <pa...@yahoo.com>.
> >Ah. We currently have a user pool that is almost not growing.
> >Little new users will probably mean little new active ones
> >as well.
> >
> >Many of the people in that pool work for companies that would
> >allow them to work on Avalon in company time as soon as that
> >company would start using Avalon - which does not happen
> >because there is nothing solid enough for them to use. See?
>
> perhaps but there is little we can do till we reach critical mass. Besides
> Avalon and it's ilk is inherently unsexy and fairly demanding - so even if
> it increases usage by many times it will only see a small increase in
> active developers ;( Have a look at other generic frameworks in OSS land -
> they all have similar fates.
We'll *never* reach critical mass unless we have a firm beta date towards which we are aiming.
There are loads of companies/oss-projs out there not using avalon becase they don't know when it
is going live. I could not hand-on-heart say this year to anyone that asks me. I am *desperate*
for OSS and work related reasons to see Avalon stabilise and go live at a certain point. If it
changes after that (package/class names, implementations) I will accomodate those changes as I
port from one version to another.
Also, I'll bet you we lost subscribers to the mail lists when we switched from java.apache.org to
jakarta.apache.org as we're now spammed by CVS messages in the *same* list.
Proposal 1) June 15th : Switch to beta
Proposal 2) Formal release : August 1st
Refactor as much as desired up to (1).
Regards,
- Paul H
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: The Roadmap to Beta (or: diving into the fray...)
Posted by Peter Donald <do...@apache.org>.
At 02:12 22/4/01 +0200, Leo Simons wrote:
>> >where it is not:
>> >----------------
>> >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
>>
>> If you have a read of the article I sent just a bit back you will realize
>> hopefully the use base means nada - the key is activity of users.
>
>Ah. We currently have a user pool that is almost not growing.
>Little new users will probably mean little new active ones
>as well.
>
>Many of the people in that pool work for companies that would
>allow them to work on Avalon in company time as soon as that
>company would start using Avalon - which does not happen
>because there is nothing solid enough for them to use. See?
perhaps but there is little we can do till we reach critical mass. Besides
Avalon and it's ilk is inherently unsexy and fairly demanding - so even if
it increases usage by many times it will only see a small increase in
active developers ;( Have a look at other generic frameworks in OSS land -
they all have similar fates.
>> >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.
>>
>> that is not a beta no matter what label we place on it - that is just an
>> alpha that someone decided to relabel.
>
>which happens all the time...and often works as well (I'll
>mention the word microsoft again).
So we should lure people to Avalon by lieing to them? Not my style really.
I would prefer to be an obscure but technically brilliant project rather
than a large sucky project ;)
>> The apps that use the *framework* get very little functionality already -
>> it is not intended to provide functionality but to be *framework*/patterns
>> etc. When you think of "framework" think of Component model.
>
>That's still pretty vague (more vague than the current docs).
>We've got inversion of control, the COP approach, separation
>of concerns (multi-dimensional).
>Those are patterns.
I wouldn't call them patterns as such - they are more abstract than that -
but then everythings a pattern ;)
>I see the framework as a representation of those patterns
>in code (interfaces with contracts defined in javadoc, that
>is).
>We have yet to define _explicit_ contracts for many parts of
>the framework. We currently provide default implementations
>of some parts of the framework (DefaultContext), and not for
>other parts.
Which other parts don't we do.
>This leads to some unclarity of what is the framework, and what
>isn't.
Easy if it has to do with any of the following it is definetly framework
* lifecycle relationship (ie activity, logging, context, CM, config)
* container-component relationship (ie camelot)
* kernel-app-component relationships (ie atlantis)
Certain other "patterns" have also been declared as part of framework
(basically define generic good practices for building component based
systems). Candidates include;
* chained exception classes
* component pipelines (except this is still untested and thus in excalibur)
* thread markers (ie singlethreaded/whatever)
* possibly the command based pattern you/Berin described would also fit here
In neuroscience I would call this "form" functions. This contrasts with
"content" functions such as
* pooling
* cli parsing
* db pooling
* thread pooling
etc. (ie include all the components in here)
>> The reason for separate CVSes was to decouple the release schedules so we
>> should be able to release any part at any time. It was also to decrease
>> that chances of interdependencies exists (still hasn't been completely
>> successful - see clutil.jar in testlet CVS).
>
>I'd solve the interdependency problem with an ant file which
>might even do a unit test to be completely sure, and then put
>indepent components in different dirs.
>I don't see the coupling between CVS and release.
well you a rare individual indeed ;)
>> >I proposed a model of
>> > 1) specification (avalon.*)
>> > 2) reference implementation (phoenix.*)
>>
>> Yep and I said whats wrong with swings model. The specification and
>> implementation are both in "javax.swing.*".
>
>that is, imo, not a proper separation of concerns.
why? I still don't understand why you would say this. Users need to access
both implementations and interfaces - just like in swing. Do you think
swing is badly designed?
Just because it also includes a DefaultTableRenderer when you may want to
write your own does not devalue it's structure. It is one of the few
successful frameworks for java - I am not sure why you would want to go
against a proven model?
>And, if we also want to allow others to do create
>their own implementations of specifications (which
>we do, I believe, at least for several parts),
>this is messy as they'll have to include the
>default implementation as well.
Which parts are we missing default impls for that we should have?
>> > 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.
>>
>> Avalon is not just server related - it is a component model (aka
>> framework), some components (most of which aren't server specific), it is
>> an application kernel (that is *slightly* server specific) and it is a set
>> of kernel services (that is server specific).
>
>even more complicated!
Right - but it's the way that is being used. Hence why I didn't want
anything in the org.apache.avalon.* namespace. I wanted Avalon as a
covername much like jakarta is cover project for a bunch of smaller projects.
>> >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;
>>
>> thats the model we have now ! ;)
>
>nah. I ment there is the Java Language Specification
>(document/diagrams), the JDK (implementation) and the javadoc
>tool (extension). We don't separate spec from impl.
So if we update the docs does that mean we are separated ? ;)
>> thankfully we have just moved away from that model - it was unanimous
>> decision so you should check archives for reasoning ;)
>
>did so. My answer would be "ant" to every problem mentioned =)
Right - but by your logic we should include all jakarta projects in one CVS
right? (or maybe all java apache projects - or perhaps the whole jdk ;]).
>> >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...
>>
>> awww - this is one of the few bits I am happy about ;) docs lack though
>... ;)
>
>That's the to-do for cornerstone then =)
true - but thats gotta wait till I am happy with phoenix first.
>dependency would be
>
>package CVS dependencies
>----------------------------------------------------------------
>org.apache.log.* log none
>org.apache.avalon.* avalon logkit
>org.apache.excalibur.* cornerstone logkit, avalon
bad to put in cornerstone as most users of excalibur do not need
corenrstones other parts.
>org.apache.cornerstone.* cornerstone logkit,avalon,excalibur
>org.apache.phoenix.* phoenix logkit,avalon,excalibur,
> cornerstone
Phoenix does not depend on cornerstone. Think of phoenix as the servlet
spec (ie org.apache.phoenix.*) + a servlet implementation (ie the rest of
phoenix). Cornerstone depends on the spec part - phoenix couldn't care less
if cornerstone existed or not ;).
>and Peter would be right in wanting to create the excalibur cvs.
>Considering I'm -1 for multiple CVSes, but all for following a
>chosen pattern, that makes me +1 for not 1 but two new CVS roots
>(the additional one being ***demos). Not that it matters after
>a veto...
My long term plan was to wait and see how commons worked out. It hasn't
decisevly failed or succedded yet so I would like to wait til that is
definete. If it doesn't succed I wanted to create a new CVS like it but
more open. It would effectively host all the components in excalibur + any
other components regardless of dependencies. (ie demo apps from
cornerstone, my cadestre and ottolith servers, any other products that
needed a place to grow etc).
Once cjan is done (someone else is working on it - yay !!!!) we should be
able to do this effectively even if commons fails.
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: The Roadmap to Beta (or: diving into the fray...)
Posted by Leo Simons <ma...@leosimons.com>.
> At 09:39 21/4/01 +0200, Leo Simons wrote:
> >I do recognise that the debate is getting heated and that
> >viewpoints are no longer defended with logical arguments but
> >instead with emotional ones.
>
> This isn't heated - you need tougher skin if you think that ;)
when I see ultimatums, that's heated. If I see !@#(*$$ language,
that's flaming. If I see weeks and weeks of flaming, then I see
what I'm used to on RPG lists....all a matter of differing
defenition ;)
> >where it is not:
> >----------------
> >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
>
> If you have a read of the article I sent just a bit back you will realize
> hopefully the use base means nada - the key is activity of users.
Ah. We currently have a user pool that is almost not growing.
Little new users will probably mean little new active ones
as well.
Many of the people in that pool work for companies that would
allow them to work on Avalon in company time as soon as that
company would start using Avalon - which does not happen
because there is nothing solid enough for them to use. See?
> >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.
>
> that is not a beta no matter what label we place on it - that is just an
> alpha that someone decided to relabel.
which happens all the time...and often works as well (I'll
mention the word microsoft again).
> The apps that use the *framework* get very little functionality already -
> it is not intended to provide functionality but to be *framework*/patterns
> etc. When you think of "framework" think of Component model.
That's still pretty vague (more vague than the current docs).
We've got inversion of control, the COP approach, separation
of concerns (multi-dimensional).
Those are patterns.
I see the framework as a representation of those patterns
in code (interfaces with contracts defined in javadoc, that
is).
We have yet to define _explicit_ contracts for many parts of
the framework. We currently provide default implementations
of some parts of the framework (DefaultContext), and not for
other parts.
This leads to some unclarity of what is the framework, and what
isn't.
> The reason for separate CVSes was to decouple the release schedules so we
> should be able to release any part at any time. It was also to decrease
> that chances of interdependencies exists (still hasn't been completely
> successful - see clutil.jar in testlet CVS).
I'd solve the interdependency problem with an ant file which
might even do a unit test to be completely sure, and then put
indepent components in different dirs.
I don't see the coupling between CVS and release.
> >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.*)
>
> Yep and I said whats wrong with swings model. The specification and
> implementation are both in "javax.swing.*".
that is, imo, not a proper separation of concerns.
And, if we also want to allow others to do create
their own implementations of specifications (which
we do, I believe, at least for several parts),
this is messy as they'll have to include the
default implementation as well.
> Considering it is the most
> similar example of a framework (The only other framework that I
> am aware of
> in javaworld that has been *standardized*).
If you define "framework" as "Component model", this
still depends on what you call a "component". On a
larger scale, there are more examples.
> > 5) programs on top of Avalon
>
> phoenix is on top of avalon's framework
> james is on top of phoenix
> cocoon is on top of avalons framework
I ment james-like, but still in this project.
> > 6) external APIs
>
> ???
bytecode.jar, connector.jar, jmxri.jar, whatever...
> > 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.
>
> Avalon is not just server related - it is a component model (aka
> framework), some components (most of which aren't server specific), it is
> an application kernel (that is *slightly* server specific) and it is a set
> of kernel services (that is server specific).
even more complicated!
> >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;
>
> thats the model we have now ! ;)
nah. I ment there is the Java Language Specification
(document/diagrams), the JDK (implementation) and the javadoc
tool (extension). We don't separate spec from impl.
> >If I'd start from scratch, I would just have a single
> >avalon cvs with the following...
>
> thankfully we have just moved away from that model - it was unanimous
> decision so you should check archives for reasoning ;)
did so. My answer would be "ant" to every problem mentioned =)
> >- stabilise LogKit (it already is, isn't it? =), and create
> > a release (does it even need a beta?);
>
> doesn't really need a beta-izing (unless we want to clean up it's bad
> design decisions now ;]). However I would prefer we didn't try to release
> it publicly as IMHO it would be bad for Apache to have two
> separate logging
> toolkits out.
Agreed. But it we can still do a logkit-4.0-RC1.jar which
we support and put in the avalon CVS and not change it for
quite a bit of time (the current logkit.jar is from jan 4).
Just a matter of what you call it.
> >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...
>
> awww - this is one of the few bits I am happy about ;) docs lack though
... ;)
That's the to-do for cornerstone then =)
> >more avalon
> >- merge excalibur with avalon again;
>
> -1 for all the reasons already indicated before - but you knew I was going
> to do that right?
yep ;) (I'm still hoping you're going to convince me of your
view; it's quite clear the reverse is not going to happen)
one more thing:
if you define excalibur as components on top of Avalon
that everyone uses, you could have this in Cornerstone
CVS:
src/java/org/apache/excalibur Components used by Cornerstone/other blocks
src/java/org/apache/cornerstone Components used by Phoenix/other kernels
src/java/org/apache/*** Components that make use of Phoenix
*** would be a new name for cornerstone.demos.*
dependency would be
package CVS dependencies
----------------------------------------------------------------
org.apache.log.* log none
org.apache.avalon.* avalon logkit
org.apache.excalibur.* cornerstone logkit, avalon
org.apache.cornerstone.* cornerstone logkit,avalon,excalibur
org.apache.phoenix.* phoenix logkit,avalon,excalibur,
cornerstone
org.apache.***demos.* cornerstone logkit,avalon,excalibur,
cornerstone,phoenix
Which might be slightly better than having excalibur inside
avalon.
When it is apparantly anonymously agreed upon to have a
separate CVSes for different packages with different dependencies,
it makes more sense to do:
package CVS dependencies
----------------------------------------------------------------
org.apache.log.* log none
org.apache.avalon.* avalon logkit
org.apache.excalibur.* excalibur logkit, avalon
org.apache.cornerstone.* cornerstone logkit,avalon,excalibur
org.apache.phoenix.* phoenix logkit,avalon,excalibur,
cornerstone
org.apache.***demos.* ***demos logkit,avalon,excalibur,
cornerstone,phoenix
and Peter would be right in wanting to create the excalibur cvs.
Considering I'm -1 for multiple CVSes, but all for following a
chosen pattern, that makes me +1 for not 1 but two new CVS roots
(the additional one being ***demos). Not that it matters after
a veto...
greetz,
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: The Roadmap to Beta (or: diving into the fray...)
Posted by Peter Donald <do...@apache.org>.
At 09:39 21/4/01 +0200, Leo Simons wrote:
>I do recognise that the debate is getting heated and that
>viewpoints are no longer defended with logical arguments but
>instead with emotional ones.
This isn't heated - you need tougher skin if you think that ;) Simple
really - this is opensource - you have an itch then scratch it - but don't
expect others to do the work for you.
>where it is not:
>----------------
>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
If you have a read of the article I sent just a bit back you will realize
hopefully the use base means nada - the key is activity of users. In many
ways an increase in user base can be a negative as it forces stagnation ...
err stabilisation ;)
BTW beta == we provide quarentees that products based on it will be
forwards for the major version.
>2) THE FRAMEWORK goes beta
>(i.e. everything in avalon.*, excalibur.*, framework.*,
>etc)
excalibur is NOT part of the framework - it has nothing to do with the
framework - it just happens to be some components that USE the framework
and we happen to use the components aswell.
>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.
keyword: *framework* ;)
>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.
that is not a beta no matter what label we place on it - that is just an
alpha that someone decided to relabel.
>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.
The apps that use the *framework* get very little functionality already -
it is not intended to provide functionality but to be *framework*/patterns
etc. When you think of "framework" think of Component model.
>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.
Instead of worrying about cocoon in general lets be concerned more with
cocoons users in particular. They are the important ones. We can always get
the cocoon developers to update the DB pool impl because they found a
threading bug or something similar but it is completely unreasonable for us
to expect their users to go through and update things (like method
signatures or packages etc).
>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?
Required to be 100% stable for beta:
* framework (as defined above)
* interfaces in excalibur.pool
* interfaces in excalibur.dbpool
They also use: (but we don't need them to be 100% stable)
* impls in excalibur.pool
* impls in excalibur.component
* impls in excalibur.dbpool
* impls in excalibur.cli
>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).
The reason for separate CVSes was to decouple the release schedules so we
should be able to release any part at any time. It was also to decrease
that chances of interdependencies exists (still hasn't been completely
successful - see clutil.jar in testlet CVS).
>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.*)
Yep and I said whats wrong with swings model. The specification and
implementation are both in "javax.swing.*". Considering it is the most
similar example of a framework (The only other framework that I am aware of
in javaworld that has been *standardized*).
> 3) extensions (of both spec and RI)
> 4) pluggable, common components
kernel components (aka Blocks): cornerstone
non-kernel components: excalibur
> 5) programs on top of Avalon
phoenix is on top of avalon's framework
james is on top of phoenix
cocoon is on top of avalons framework
> 6) external APIs
???
>2) why can't we use the framework model, like is done with
>Swing?
>
>me:
>
>I can't really see how the 'new' Avalon would look if we
>use the Swing model rigourously.
Avalons framework would look similar enough to what it looks like now ;)
(ie identical).
>Also, I'm not quite sure exactly what a framework model really is.
ahhh ... like swing ;)
> 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.
Avalon is not just server related - it is a component model (aka
framework), some components (most of which aren't server specific), it is
an application kernel (that is *slightly* server specific) and it is a set
of kernel services (that is server specific).
> 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;
thats the model we have now ! ;)
>Now how do we implement that?
>-----------------------------
>
>If I'd start from scratch, I would just have a single
>avalon cvs with the following...
thankfully we have just moved away from that model - it was unanimous
decision so you should check archives for reasoning ;)
>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).
right - ask around a few people if they think this is a good thing ;) (Even
better yet - ask the developers themselves if in retrospect they would have
chosen this).
>Pete's list included again:
> * finalize *activity* related methods (init/start/resume/etc)
> * move processor methods to excalibur
done.
> * write a python/perl/other script to convert (i am currently using elisp
> which is not useful to everyone else)
will do now ;)
> * move camelot/atlantis to phoenix CVS
done.
> * remove compat hierarchy (done, right?)
done.
> * migrate code in avalon.util to better resting place
> (either as components in phoenix or into the void)
almost done (still thinking about remainder of stuff).
>- stabilise LogKit (it already is, isn't it? =), and create
> a release (does it even need a beta?);
doesn't really need a beta-izing (unless we want to clean up it's bad
design decisions now ;]). However I would prefer we didn't try to release
it publicly as IMHO it would be bad for Apache to have two separate logging
toolkits out.
>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...
awww - this is one of the few bits I am happy about ;) docs lack though ... ;)
>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.
yup ;)
>more avalon
>- merge excalibur with avalon again;
-1 for all the reasons already indicated before - but you knew I was going
to do that right?
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