Kris Bravo wrote: >Going to 1.5 will kill my use of Hivemind on a client project btw. They >are still running 1.4.2... in production. > > Same for me. I believe this state of affairs is going to stay like that for a while... I sure would love to use annotations but not if it prevents me from deploying applications in production. Maybe support for annotations could be added for situations when 1.5 is available, falling back to XML configuration in other situations? I'm also not sure if I would like all configuration I have currently in XML to go to annoations. I think some of it actually should live in a configuration file rather than to the source code.
Regards, - Juliano. >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]
