avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [proposal] cornerstone cleanup
Date Mon, 09 Jun 2003 06:47:17 GMT

Leo Simons wrote:

> We should remove some stuff from cornerstone.
> The following cornerstone packages are in use by James and some other 
> projects:
>     cornerstone-sockets
>     cornerstone-store
>     cornerstone-connection
>     cornerstone-threads
>     cornerstone-datasource(s)*
>     cornerstone-scheduler
> I think we shouldn't remove these right now (or maybe we should but 
> that's not part of this proposal) 

I am +1 on delivering a release of the above components.

> (*cornerstone-datasource and cornerstone-datasources seem to be mostly 
> identical; we should nuke one, but also not part of this proposal) 

The "datasources" package was created by yours-truly.  It was related to 
James and ensuring that the migration from Component/ComponentManager 
was successful.  The James HEAD is based on the cornerstone-datasources 
package - but I don't know off-hand if there are existing 
cornerstone-datasource dependencies in the James 2.X release.

> I know no users of the following packages (all remaining ones):
>     cornerstone-channels
>     cornerstone-dom
>     cornerstone-event
>     cornerstone-packet
>     cornerstone-rmification
>     cornerstone-sax
>     cornerstone-soapification
> I know of the following alternatives for these:
> cornerstone-channels - no 'direct' alternative, but it is probably
>     better to use a different pattern without using factories.
>     Since this is 5 classes only, I think many applications use
>     an application-specific version
> cornerstone-dom - no 'direct' alternative, I think most programs
>     that pool parsers use a generic pool
> cornerstone-event - excalibur-event provides all functionality and
>     more
> cornerstone-packet - no direct alternative, I think most programs
>     that use java.net.DatagramPacket just hardwire it
> cornerstone-rmification - xml-axis, altrmi, ..., there's lots of
>     remoting packages around. The implementation class has a
>     big "FIXME: INPROGRESS and NOT TESTED" header
> cornerstone-sax - no 'direct' alternative, I think most programs
>     that pool parsers use a generic pool
> cornerstone-soapification - axis to the rescue, of course
> Now is the time to speak up if you are using one or more of the 
> packages mentioned and are willing to volunteer to write documentation 
> and unit tests.
> I propose we remove all these from cvs (ie, 'cvs remove') on the basis 
> that they are not maintained and/or have been superseded by other 
> stuff if someone does not volunteer to maintain these packages. 


I've already undertaken (personally) to make sure we (Avalon) support 
the James dependencies. As far as I can see this is largely a case of 
Excalibur utilities wrapped as formal components (with descriptors).  
Personally I think that a release process of the James dependent 
components is the best starting point - involving (a) setting up maven 
base builds, (b) getting in place validation of clean component 
deployment and decommissioning, and (c) integrating this with a James 
test environment.

Cheers, Steve.


Stephen J. McConnell

Sent via James running under Merlin as an NT service.

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

View raw message