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).
That needs to change. No released product can depend on a sandbox project. If Merlin and Fortress are going to share lifecycle extensions we need to draw a line in the sand, and move "lifecycle" up to Excalibur--finalizing the API. Otherwise they will have differing APIs which is defeats the whole purpose.
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.
Ok. However, I do want to provide a tool to handle ECM to Fortress conversions. If that can happen with XFC, great--all the other things that it has to address can be put on hold as we delve into making everything interoperate with Merlin/Phoenix.
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.
I wasn't aware of that. We could push Configuration to Phase III.
But what about the Cache dependency in Fortress?
That is only for testing, we can use a different component to test with.
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) | +--------------------+------------------+-------------------+
This looks acceptable, but I wonder why you moved Monitor and XML Util to Phase II? Is there a scheduling thing you are trying to maintain? Monitor and XML Util are not really used by Fortress--except maybe in the testing.
The reason I chose the set of components for Fortress Testing is because they had *weight*. They were heavy components that are tied to system resources, and it was more of a real test of comparative speeds of Fortress and ECM.
Really the tests in Fortress need to excercize the internals of Fortress--so we can get rid of the comparative test--it will make things a little easier.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
