Berin Loritsch wrote:
Berin Loritsch wrote:
Currently the table for the release schedule looks like this:
Phase I | Phase II | Phase III -------------------+------------------+------------------- component | container | cli instrument | event | collections instrument-manager | fortress | datasource logger | sourceresolve | instrument-client pool | xfc | io testcase | | monitor i18n | | naming | | store | | thread | | threadcontext | | xmlutil | | concurrent
One problem with the above - "container" was migrated to the sandbox "lifecycle" package under the org.apache.avalon.lifecycle package name. The excalibur container package should be killed off (only waiting for Fortress to switch over).
I also think that xfc should be pushed out because (a) this framework is intended to be a general tool for interoperability across meta models and that's not complete yet, and (b) I would prefer we move on that when Marcus is back, and (c) this package really needs some "framework" level resolutions concerning attribute naming ect. In addition - we should move this package over to sandbox.
I would like to merge cli, collections, io, and concurrent into one compatibility project. This will require CVS surgery if we care about revision history--or we can just checkin a merged project.
+1
That brings the totals for number of packages to:
Phase I: 7 (i18n has no change so it is already released--6) Phase II: 5 Phase III: 9 (without compatibility, 12)
If I move DataSource and Compatibility up to Phase II, then we have a fairly even release schedule.
+1
Which still leaves the following Excalibur projects that have never been released (to my knowledge)--if there is a link to a public download of any of these, let me know:
cache configuration converter csframework extension jprocess loader policy
Apparently Converter and JProcess were removed on the server with an rm -rf command because my local repository still had them, but they were never updated (it is hard to miss with all those directories flying by in a CVS update). They are in the sandbox.
This begs the question on what should be moved to SandBox. My oppinion:
Cache, Configuration, CSFramework
Configuration has been in use for a long time now in both Phoenix
and Merlin. I don't see this as a sandbox candidate.
I agree with moving Cache and CSFramework to sandbox.
But what about the Cache dependency in Fortress?
As to the others (converter, extension, loader, and policy) I need some feedback from the community at large.
Both loader and policy are used within Phoenix and should probably be moved into the Phoenix tree. Converter was used within Phoenix until recently but the dependency seems to have been removed. I think converter can be moved to sandbox or killed off.
The extension package in used in Phoenix and Merlin. Its working well and I would like to see this in the Phase III schedule.
One problem with the above is that we are releasing Fortress
ahead of lifecycle, monitor, dl-concurrent, and xmlutil. I've
put together an derived schedule that seems to make sense
relative to the operational dependencies and keeps Fortress
under Phase II. I have included a release of the Doug Lea
concurrency package. This is basically the packaging of the
existing sources with a usable manifest, distribution, etc.
I'm assuming that the suggestion to bundle testcase with
component is acceptable, and I'm including the compatibility
bundle as per your suggestion (but shifted out to Phase III). I'm assuming policy and loader can move to Phoenix and xfc to
sandbox. Have included configuration and extension under
Phase III. Have replaced container with lifecycle under
Phase II.
+--------------------+------------------+-------------------| |Phase I | Phase II | Phase III | +--------------------+------------------+-------------------| | component | lifecycle | store | | (testcase) | event | instrument-client | | instrument | datasource | naming | | instrument-manager | sourceresolve | thread | | logger | fortress | threadcontext | | pool | dl-concurrent | extension | | testcase | xmlutil | configuration | | | monitor | compatability | | | | (concurrent) | | | | (io) | | | | (cli) | | | | (collections) | +--------------------+------------------+-------------------+
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]
