Stephen McConnell wrote:
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?).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).
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 so.it sucks just a little. It's perfectly useful and has been in use in many places for a long time :D- Cornerstone (this badly needs a release I guess)Yes and no. Cornerstone (complete) sucks big time.
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.
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.It is in sandbox because its not released code. It needs to released. That's all.If it is sandbox code, it shouldn't be a fortress dependency.Container: <-- moved to Sandbox, Fortress need to be synchronized
I agree totally - and as such this should go under Phoenix as a demonstration.I think it's totally silly to not want to provide demos/examples.
It should not be packaged as a released product because that's missleading.
ok.
I'm guessing it should be relatively easy to resolve this one. Will take a look later.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!
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".not much. By my estimate that's because incubator is shaping up, not because altrmi is shaping up :D-1- altrmi 0.9
get stable first on Excalibur, then look at what is happenging with AltRMI under incubator.
What is the timeframe/schedule for getting a release of AltRMI?
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 :DI'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).how much work is this, how much does this impact our builds? What's maven's vector of change atm?1. Get in Maven acrosss the board.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
