Berin Loritsch wrote:
Stephen McConnell wrote:
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.
Also excalibur-i18n-1.1
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.
Have just taken a look at the framework candidate - loooks like its built using Jelly (as distinct from Maven classic). I'm going to do some test with some simple classic boring regular maven project.xml setups for framework (sorry Leo).
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.
Keep in mind that there is an issue here in that jars inside jars cannot be included in classic classloaders. Instead you have to either (a) write a new classloader implementation - like they did for Tomcat, or (b) restrict the usage of the sar to a file based environment in which you unpack the sar aand refernce to unpackaged sub-jars as direct files - but in doing so, potentially cause problems for web-apps.
We also need to think about sar as a functional description versus sar as a speciofication. My impression is that the notion of packaging a deployment unit is the subject of interest. So I'm looking at this largely in tems of replicating functionality, not necessarily format.
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.
Deployment packaging - probably. SAR format - don't know - that's a subject for discussion.
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?
Releases should not be made on the grounds of unit tests - instead - does a release serve sufficient value to justify a release. That a decision you take at the time of promposing a release.
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.
We could do that .. ;-)
But we arn't under contract. As people with experience jump in and do things, so the code base will evolve. I'm not too interested on trying to set release preconditions unless someone wants to give me a healthy contract to back it up. In reality - there will be things we will want to do - for example, I've been thinking about how to autogenerate a block.xml from an assembly.xml, and a Merlin config.xml targets file from a Phoenix configuration.xml. From what I can see its all feasible. Am I going to commit to doing it - no. Will it happen - probably. Is it a release precondition ... not for me.
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.
Its the moving goal that is interesting. In fact I think I've pushed this point before - that Merlin is much better viewed as a process from which content in incorporated and content is generated. I'm totally ok with the idea of eternal beta for Merlin providing Merlion as a process is producing usefull lumps of released content to enable the creation the the containment framework.
As long as we have something to build on, while including our legacy container users, all the better..
Yep - absolutely agree.
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]
