Hmmm... Maybe I should start back peddling on being down on James now that all of this comes to light.
I might need to collaborate with HiveMind when it comes time to try my hand at providing an extension layer. (I hope the word extension makes it a magical effort , but more likely than not it will end up looking like a lot of paper clips and masking tape holding together a very fragile structure :) ) So, no hard feelings right James? This sounds do-able? ;) On 7/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
I'm keeping the package names seperate, to facilitate splitting out Tapestry IoC into a standalone project, ala HiveMind. Right now that is not a priority. The way I've been layout out the Tapestry IoC APIs, it should be possible to create a kind of bridge RegistryBuilder that can read HiveModule XML and make those appear (largely) like native Tapestry IoC modules and services. There's a bunch of things that don't line up however: Decorators (service interceptor factories in HiveMind) can now match (i.e., target) multiple services. This makes them more like AspectJ pointcuts. Configurations in HiveMind are standalone. In Tapestry IoC each service *may* have *one* configuration, as an unordered collection, an ordered list, or a map. This turns out to be more than sufficient (you can always create a service that exists to vend out its configuration, and thus simulate multiple configurations per service). Object ordering is more robust in Tapestry IoC: http://tapestry.apache.org/tapestry5/ioc/order.html Tapestry IoC doesn't yet have a number of HiveMind features: - Registry shutdown - Pooled service lifecycle model (just "perthread") - Object providers ( http://jakarta.apache.org/hivemind/hivemind/ObjectProviders.html ) - Symbols Many features of HiveMind won't be needed in Tapestry IoC as they can be more easily accomplished in Java code. Thus "instance:" or "class:" object provider prefixes are useless. On 7/30/06, Benjamin Tomasini <[EMAIL PROTECTED]> wrote: > I have been using HiveMind now for quite a while and have come to depend > on it quite heavily on many projects - some web apps, some not. It's > features have very much improved the quality and modularity of my code. > > What would prevent a user from employing Tapestry IoC as a general > purpose container like HiveMind? Would there be any benefit to building > one monolithic Tapestry jar and a set of segmented jars (something > Spring does) for more targeted use? Or why not keep Tapestry a single > project with sub-modules for IoC and the Web framework? Alternatively, > what about merging Tapestry IoC and HiveMind at some later date? It > could remain as HiveMind, or it could take on the Tapestry IoC name. > The conversations on this list indicate that key principals of both > projects intend to keep some degree of parity anyway. > > Ben > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
