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.
+1
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 mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
