> >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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
