avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [A4] release plan thoughts
Date Fri, 31 Jan 2003 02:52:26 GMT


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:mcconnell@apache.org
http://www.osm.net




---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message