It is *much* more difficult to segment things that way. You have to isolate the annotations code, much like I did with Tapestry 4.0 ... but they way I hope to use annotations in HiveMind 1.2 is much, much more pervasive. So I want to continue supporting XML (some things will always be more sensible there than in annotations) but support annotations in many different ways as well.
On 2/15/06, Knut Wannheden <[EMAIL PROTECTED]> wrote: > Let's assume we decide to add support for configuration through Java > 1.5 annotations. Does that in itself preclude supporting HiveMind 1.2 > in Java 1.3 / 1.4 environments? > > Let me explain. If HiveMind 1.2 *only* depends on Java 1.5 to support > annotations as another means to define the constituents of a module, > then I suppose it should still be possible to use HiveMind 1.2 in a > Java 1.3 / 1.4 environment where only normal XML module descriptors > are used. Does that make sense? > > Or do we want to use other Java 1.5 features in HiveMind 1.2 which > would preclude support for Java 1.3 / 1.4 environments? > > --knut > > On 2/15/06, Juliano Junio Viana <[EMAIL PROTECTED]> wrote: > > > > 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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]
