We're (at least I'm) talking about HiveMind going forward. The current release would still be "supported" of course.
-----Original Message----- From: Kris Bravo [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 8:13 PM To: hivemind-dev@jakarta.apache.org Subject: Re: HiveMind 1.2 progress Going to 1.5 will kill my use of Hivemind on a client project btw. They are still running 1.4.2... in production. BTW, I'm a committer on the Maven2 Mojo project. If you need any help getting hivemind to build with it, lemme know... Kris On Tue, 2006-02-14 at 23:21 +0100, Achim Hügen wrote: > +1 one for a jdk 1.5 dependency in hivemind 1.2. > I regard annotations as much too useful to prevent extensive use > for the sake of downward compatibility. > > Achim Huegen > > Am Mon, 06 Feb 2006 03:51:54 +0100 schrieb Howard Lewis Ship > <[EMAIL PROTECTED]>: > > > Well, there hasn't been much, we've been focusing on 1.1.1. > > > > I'm not satisified with my attempt to convert to Maven2 (in my branch). > > > > But the experiment is useful, I'm going to take another crack at it, > > on the trunk. I'm going to remerge 1.1.1 changes into the trunk, then > > convert to Maven2 (but leave all the source folder locations as is, > > for the meantime). > > > > On the other hand, I'm getting into crunch mode with a client, so I > > won't be able to do a lot with HiveMind for the next few weeks. > > > > I do have a number of ideas I want to pursue for 1.2: > > > > - <module> attribute to control the default builder factory > > - A streamlined, smarter injection factory > > - <interceptor-sets> ... a way to apply a set of interceptors to many > > services (potentially, across many modules) > > - Some kind of negotiation between the service extention point, > > service lifecycle model, and service implementation builder to handle > > negoation on the lifecycle model (i.e., to allow it to be determined > > via an annotation on the implementation class), and to handle the > > intracacies of event notification support for non-singleton models. > > > > In addition, I want to start introducing an alternate approach to > > creating services, one that invokes Java code to build the service > > implementation. This may be based on annoations and/or naming > > conventions. I see this ultimately as a way to reduce the amount of > > XML in the system, make HiveMind more refactoring friendly, and > > improve startup time for complex environments like Tapestry. > > > > I want to seriously considering bumping the minimum release for > > HiveMind 1.2 up to JDK 1.5, so that we can embrace annotations. > > > > I've been doing some research on using annotations (on service > > interfaces and service interface methods), rather than XML, to drive > > interceptor factory behavior. I'm quite liking it; I've been taking > > my own crack at Hibernate integration, using an @Transactional method > > interceptor rather than XML to indicate how transactions are managed > > for a service method. I'm finding this to be a good template to move > > forward. > > > > Yes, I know I should document these ideas on the wiki. I'm in a hotel > > room right now, not at home. > > > > -- > > Howard M. Lewis Ship > > Independent J2EE / Open-Source Java Consultant > > Creator, Jakarta Tapestry > > Creator, Jakarta 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
