Noel J. Bergman wrote:
You should be able to decide beforehand if you want mailets not to be dependent on avalon, and have tests in the build process to check it. Also compiling in phases (mailet api first, then mailet(s), then james, then mailet(s)) can help a lot, with no need to split communities or repositories.The container module does not exist, there is only one "avalon" module. There we will have framework and container. Yes, it will use Avalon Components, and those would be in a single module, core and non-core.Right now you're dealing with a similar issue to what we're addressing in James. We have a sub-projected called the Mailet API. But the problem is that we didn't specify sufficient capabilities in the Mailet API domain, and so we have non-portable mailets that are not only tightly coupled with James, but are tightly coupled with Avalon components. So now we're in the process of revising the Mailet API.
Correct.* Avalon Frameworks * Avalon Container * Avalon Components The Frameworks define the core contracts, the Container provides the overall environment, the Components are the building blocks. If someone had a motivation for building another Avalon Container, they ought to be able to cleanly take Frameworks and Components, and do it. Right? The container is just the implementation of the specification.
One "avalon" module, with framework and container, that are built *separately* one after the other. One project, two deliverables.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
