avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Merlin] Pre-release checklist
Date Tue, 12 Aug 2003 11:55:51 GMT


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:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message