Can you elaborate on the differences between HiveMind and Avalon? After a first read, it seems like they both share similar aims...?
Eric Pugh -----Original Message----- From: Howard M. Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 8:23 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL] HiveMind in the sandbox Proposal for HiveMind Package (0) rationale HiveMind is a simple, flexible framework for creating pluggable, configurable, reusable services. By pluggable, we mean that there is a complete separation of service definition and service implementation. By configurable we mean that modules may contribute services and configuration data to each other in a well organized way. It also means that configuration data is pervasive, supplied by many individual modules, rather than centralized in a single file. By reusable we mean that both HiveMind itself, and modules created using HiveMind may be easily recombined and reconfigured for use in disparate applications. HiveMind's basic unit is a module (a single project creating a single module JAR). At runtime, HiveMind builds a registry by accessing a deployment descriptor in each module. Modules can declare service extension points and configuration extension points. Services are expressed in terms of an interface, configurations in terms of a data type. Modules may contribute to service and configuration extension points within themselves or, more frequently, in other modules. A service contribution may be a factory (which creates a "Plain Old Java Object" (POJO) to implement the service), or an interceptor, which provides added functionality to a service implementation by intercepting method invocations. Interceptors are created by a particular kind of HiveMind service (to some degree, HiveMind is recursively defined). Services may also be called upon to create acts factories for objects used by other services. Modules may also contribute configuration extensions; these are objects that are specified and/or created and plugged into a configuration extension point. A signficant portion of HiveMind involves the build time aspects of modules; this includes specialized Maven plugins for creating HiveMind modules using the HiveMind deployment descriptor as the basis for module dependencies. It also includes generation of hypertext documentation identifying all of an application modules, extensions and contributions. The API for HiveMind allows threadsafe, easy access to services and configurations in a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as reading configuration files, is handled by the HiveMind in a consistent, robust, well-documented manner. HiveMind will embrace and adapt the best practices established in the Tapestry project, including line-precise exception reporting (a feature of Tapestry in which runtime objects are related back to the XML specifications from which they were generated, to assist the developer in diagnosing and fixing problems). (1) scope of the package The package shall entail a core library JAR, along with ancilliary artifacts such as Maven plugins and, of course, documentation, all distributed under the Apache Software License. (1.1) interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-digester and commons-logging. It makes use of OGNL (Object Graph Navigation Library) which is available from http://www.ognl.org. OGNL is licensed under modern BSD. HiveMind currently has dependencies on Tapestry. Over time, a goal of HiveMind is to reverse those dependencies, moving common code from Tapestry to HiveMind. (2) identify the initial source for the package The initial codebase is being developed by Howard M. Lewis Ship. Source code is available for review upon request (as a buildable Maven project). (2.1) identify the base name for the package org.apache.commons.hivemind (2.2) identify the coding conventions for this package Coding conventions match those established in the Tapestry project. (3) identify any Jakarta-Commons resources to be created (3.1) mailing list Until traffic justifies, the package will use the Jakarta-Commons list for communications. (3.2) CVS repositories For the time being, the package will use a root branch of the Jakarta-Commons CVS. (3.3) Bugzilla The package should be listed as a component of under the Jakarta-Commons Bugzilla entry. (4) identify the initial set of committers to be listed in the Status File. Howard M. Lewis Ship -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components -and HiveMind! http://jakarta.apache.org/tapestry --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
