I know that Avalon has decided to focus on Merlin. I have no problems with that, and I wish you all the best in that endeavor. I thought that the exact direction of Fortress was still up in the air--beyond no longer supporting it.
I think is is really important to separate out here the following:
(a) fortress codebase (b) fortress/ecm semantics (c) fortress/ecm migration
fortress codebase -----------------
I have three concerns with the fortress codebase.
(i) get is into a stable sustainable state - meaning that it
builds cleanly and is validatable via gump (ii) that the code base is accessible for the purpose of a fork
in the context of a hypothetical user base that could form a
viable community around which this product can be maintained (iii) a reference point for a semantic adapter based on merlin
technology, enabling binary support for ecm and fortress
componentsfortress/ecm semantics ----------------------
Putting in place fortress and ecm semantic support based on the Avalon platform is no big deal from a technical point of view. It is totally feasible to provide a facility that is itself a container of ecm and/or fortress components. The principal question is if this is a worthwhile exercise. I put together an initial cut on an ECM facility a few weeks ago and posted a note to avalon dev and cocoon - feedback zero - i.e. as far as I can tell there is not interest in perusing this avenue. As a consequence I've deleted the ecm facility. Personally I think this direction is the right direction but its only going to happen if the community wants it to happen.
fortress/ecm migration ----------------------
Irrespective o9f interests in delivering an ecm/fortress facility - there remains an outstanding requirement for the delivery of an ecm/fortress migration strategy. Based on experience with the Turbine Fulcrum project .. this is reasonably strait forward for non-pooled components. The main problem areas concern Selector semantics - however, this can be address using the finder facility. Today this means on-list collaboration - and form that we'll get in place the docs for general migration. My guess is that this will be demand driven ... i.e. don't wait for it to happen - if you need it push for it!
If that is the case, I would like to host it over on D-Haven, or perhaps something like it that is compatible.
No problem with the codebase being hosted somewhere else -assuming that your presuming an independent package namespace.
While I know there should be no issue with the latter course, the first one does require a "buyout" so to speak with Avalon.
Personal preference is to do it right - re-cut Fortress based on the enabling Avalon technologies and in the process provide a viable migration path. Niclas has already said he's ready to cut the meta-integration, I'm ready to deal with the repo-synchronization. All we really need is an ECM/Fortress expert (hint, hint).
Cheers, Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
