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