So, you say: if I will be the release manager and but some candidates somewhere, noone will stop the release? That would be great!
There is nothing new here - that's how it was in the past - that's how it is today. If you want to make something happen - just do it. Don't be preoccupied with the idea of having everyone on board - you won't. But you are welcome to think about issues that are raised. Yes - I have some issues. Sure - it would probably help me if I had more information about the real Cocoon/Avalon dependencies, and more information about ECM/Fortress specific component plans. I also think there are some improvements that should be undertaken before a release.
excalibur-component
This is the deprecated ECM utility. A variant of ECM is used in the Cocoon project. There are no plans for the evolution of this product here in Avalon. Fortress is for all intensive purposes ECM/2. Before considering the release of ECM - can you provide details on the reason for the release? Are there bug fixes? Do any of the changes impact Fortress?
excalibur-store
This component is a small persistence utility. It provides a memory store, a file store, and a store based on JISP 2.5.1 (license details concerning 2.5.1 are not clear but JISP 3.0 is GPL). Aside from the javadoc there is no supporting documentation and IMO would benefit a lot from some simple usage docs. There is some work to be done to bring a few classes in line with @avalon tag spec but based on an initial inspection of the code this looks like a strait forward exercise.
excalibur-sourceresolve
This component is pure ECM specific. It is badly documented - in fact the only documentation is the javadoc and that is insufficient for someone to actually jump in and use the product in anything other then a ECM specific scenario. This situation is different to the majority of Excalibur code. I would be opposed to releasing this component as is but would be ok with the bundling of the component with a Fortress release.
excalibur-xmlutil
A utility that provides simplified wrappers for XML parsers, transformers and XPath evaluators. In its current form the package is dependent on excalibur-store, sourceresolver (and by implication ECM/Fortress). However, these dependencies are limited to about 3 source files. With a little refactoring the general XML utility code could be made into a container independent utility. With independence from store and core utilities could be moved to avalon/util and the remaining ECM specific content managed as a ECM specific resource (possibly bundled with Fortress).
fortress-container and fortress-tools
Primary issues to be addressed before a release is to get the basic @avalon tag support in place. For example, Fortress tools uses a non-standard tag for component naming which is 100% redundant relative to the meta tag spec. Cleaning up the tag compliance will then make the release of components such as excalibur-store a non-controversial exercise.
excalibur-logger
No problem with a maintenance release of this package. There was action by Berin to break things out into api/impl separation but that was never completed.
Currently both the maven and ant based builds for all of the above products are broken - some housekeeping to be done here to get respective packages in order before the subject of content release is pertinent.
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]
