Leo Simons wrote:
Stephen McConnell wrote:how about fixing the wrapper classes "to get things working properly" (regardless of where they go exactly, they're needed)? What is the exact problem?
From memory - its the ComponentSelector wrapper that does not wrap components returned from the ServiceSelector as instances of Component - i.e. a Component proxy is needed. The solution I put in place uses Proxy but that locks us into 1.3 of the JVM which (as par as I understand is not something we want to do to the Framework).
I took a look. I'm changing my mind. The component proxy material should not go into framework because doing it right ties us to either one of CGLIB or JDK1.3, which is not acceptable for framework. Instead, it should become an excalibur library (perhaps put into an existing one like container?).
I agree (except not container - that was moved to sandbox and is dead pending updates in Fortress).
I've also been looking into the Framework changes. It appears that additional methods were added to the DefaultConfiguration and ConfigurationUtil classes and the Excalibur Configuration package is tied to these - also, Excalibur Logger seems to be tied to these classes. In other words - it looks like a 4.1.4. release of Framework is required - basically containing the configuration updates.
On a related subject - LogKit is depedent on Framework. is dependent on Logkit, etc. It appears that this is linked to LogKit extension of the AvalonFormatter. Does anyone have any additional knowlege about this particular circular dependency?
- Cornerstone (this badly needs a release I guess)Yes and no. Cornerstone (complete) sucks big time.
it sucks just a little. It's perfectly useful and has been in use in many places for a long time :D
No so.
The James depdency on cornerstone is a nasty mess. Changes have been made to Cornerstone components that have broken the James implementation. Result - there is a cornerstone.jar in James from back in June that is not maintainable in its current form.
this has to do with us screwing up dependency management (read: GUMP). It doesn't mean the components as such are all terrible (for example, I use connection, sockets, and schedule quite a bit).
No problems with the individual components - because these we can move into a management state. The problem concerns the single cornerstone.jar file which is far from a managed state. As the excalibur projects get released we will be able to handle Cornerston compoennt at an individual level and come out of that progressively with a set of manageable components.
Container: <-- moved to Sandbox, Fortress need to be synchronized
If it is sandbox code, it shouldn't be a fortress dependency.
It is in sandbox because its not released code. It needs to released. That's all.
It went into sandbox from somewhere for some reason. That reason needs to be addressed, regardless of what it is/was, before we can release anything.
OK - I'll fire off a seperate email on that.
I think it's totally silly to not want to provide demos/examples.
I agree totally - and as such this should go under Phoenix as a demonstration.
It should not be packaged as a released product because that's missleading.
ok.disagree. I don't need RMI Instrumentation in fortress. If we can get instrument to compile (should be easy enough) without needing altrmi then things are fine, right?
Instument isn't the problem - Instrument Manager is (as far as I can see).
But your on the right track!
I'm guessing it should be relatively easy to resolve this one. Will take a look later.
- altrmi 0.9
-1
get stable first on Excalibur, then look at what is happenging with AltRMI under incubator.
not much. By my estimate that's because incubator is shaping up, not because altrmi is shaping up :D
What is the timeframe/schedule for getting a release of AltRMI?
there isn't any, AFAIK. I guess the primary authors are busy with lots of stuff and there's not enough of a "business need" to get AltRMI released. Can't say, really. Codewise, it's sorta ready I think. I now think we should handle altrmi independently of the "avalon-wide release".
1. Get in Maven acrosss the board.
how much work is this, how much does this impact our builds? What's maven's vector of change atm?
I've been using Maven as part of experimenting with relase control. The really big plus ius the ability to formally publish jars and jave builds locking into relased products (as opossed to our current process of validating against CVS).
we can do that right now. I can try and set aside an hour or two to set up gump definitions that reference released projects instead of cvs (we talked about that over on the gump list, it's perfectly feasible). Or maybe Ken has some free time :D
Results will be interesting - I'm already seeing problems here via Maven based builds. I'ts kind of fun - go build something like Excalibur Logger - fails, up the dependency version for framework to 4.1.4 - succeeds, etc.
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
