Berin Loritsch wrote:
It seems that we have some support for the proposal I put forth yesterday. To
that end, we need to come to some idea of what needs to be done.
We have three main steps, so we need some information gathering.
For step 1, quick beta release of Merlin ----------------------------------------
What loose ends need to be tied up before we can do this?
Prerequisites:
1. release of framework 4.1.5
This includes updates to the Version class to handle the -1 version semantics (any version) and updates to configuration to handle equality comparison. Specific release requirements include:
avalon-framework-api-4.1.5.jar avalon-framework-impl-4.1.5.jar
2. release of excalibur-configuration 1.1 (updates to the externalization of a config)
This will clear the way for a beta release of the avalon-sandbox/meta package. I suggest beta because there are possiblities for elimination of the @avalon.extension tag - but that needs a little work (two days) to get it in place and validated.
Suggest a combined release vote on framework 4.1.5, excalibuir configuration 1.1 and avalon meta 1.0 ASAP followed by Merlin 3.0.
Berin - do you think you could take care of managing the framework and configuration releases. I can focus on pulling the Merlin 3.0 content together this weekend.
Ok. I will put together a build and post it in the familiar staging area. The voting will happen after that. Gotta catch up on alot of stuff, so if not today, then I will have the builds done tomorrow.
For step 2, which features need to be incorporated in Merlin? -------------------------------------------------------------
* Embedding Fortress containers
* Configuration validation
* Support for Pheonix's Environment.xml (security policies, logging, etc.)
* Support for the @mx-* tags
* Daemon support (i.e. running as a Windows service or Unix daemon)
This one is already in place.
* Phoenix Client support (i.e. the BlockContext, et. al.)
Next to nothing to do for this.
* Support for Phoenix Assembly.xml files
Possible.
* SAR support
Also possible (assuming a sar is considered as a jar repository implementation).
Excellent. A SAR is a JAR that includes other JARs for the libraries and blocks, as well as the assembly and environment files.
Anything I am missing?
Ok, so I got the complete list?
We may want to do multiple beta releases as we add new functionality so that
we can get feedback from users.
Absolutely yes on this - assume progressive releases with new functionality every month or two.
Since the SAR support looks like it would be fairly easy, we may want that in the second beta.
For step 3, what "exit" criteria do we need? --------------------------------------------
Can we create the exit criteria in the form of JUnit tests?
My exit criteria is a complete avalon containerment framework.
Nice goal, but hardly quantifiable. Anything we can write some JUnit tests against?
For example, fully compatible with Fortress (either by containment or by features) and fully compatible with Phoenix. We can start setting up tests to ensure these things.
I will be happy with a full release once we have the compatibility down. A complete containment framework is a moving goal because we are always learning and evolving. WHat we define as that today will no longer apply in the future.
As long as we have something to build on, while including our legacy container users, all the better.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
