> 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("[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]
