You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2006/02/06 03:51:54 UTC
HiveMind 1.2 progress
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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: HiveMind 1.2 progress
Posted by Jean-Francois Poilpret <jf...@hcm.vnn.vn>.
If you are searching for a "new breed" of build system, you might consider
taking a look at the EL4ANT project (el4ant.sourceforge.net).
Although based on ant, it seems quite powerful and much extensible in a much
easier way than pure ant.
I have just started migrating HiveMind Utilities build system to it, it is
highly probable that HMU next version 0.6.0 will be using it.
Cheers
Jean-Francois
-----Original Message-----
From: Massimo Lusetti [mailto:mlusetti@gmail.com]
Sent: Monday, February 06, 2006 3:45 PM
To: hivemind-dev@jakarta.apache.org
Subject: Re: HiveMind 1.2 progress
On 2/6/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> 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).
I got twisted feeling by this since i want it (I've switched almost
all my project to maven2) but I'm really scared by the way eclipse
handle maven2 multi-project.
As already said, i hope this will enlight my way to handle that.
> - A streamlined, smarter injection factory
Would you mind argument this a little more...
> - <interceptor-sets> ... a way to apply a set of interceptors to many
> services (potentially, across many modules)
Sounds really useful!
> I want to seriously considering bumping the minimum release for
> HiveMind 1.2 up to JDK 1.5, so that we can embrace annotations.
Definitely a +1 by me.
Regards
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: HiveMind 1.2 progress
Posted by Massimo Lusetti <ml...@gmail.com>.
On 2/6/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> 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).
I got twisted feeling by this since i want it (I've switched almost
all my project to maven2) but I'm really scared by the way eclipse
handle maven2 multi-project.
As already said, i hope this will enlight my way to handle that.
> - A streamlined, smarter injection factory
Would you mind argument this a little more...
> - <interceptor-sets> ... a way to apply a set of interceptors to many
> services (potentially, across many modules)
Sounds really useful!
> I want to seriously considering bumping the minimum release for
> HiveMind 1.2 up to JDK 1.5, so that we can embrace annotations.
Definitely a +1 by me.
Regards
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: HiveMind 1.2 progress
Posted by Geoff Longman <gl...@gmail.com>.
Dunno how you see the implementation details but I for one would be
happier with annotations in HM 1.2 if using annotations were: an
alternative to some xml, or: a way to do something you couldn't do
before in xml.
That way one could drop in the HM 1.2 jars in and it the app would
still work as before with it's, unmodified, 1.1.1 hivemodule file.
To get the new features one would have to use the new annotations and
optionally one could strip stuff out of the old xml by using some more
new annotaions. Of course once you do that you can't use the file with
the old 1.1.1 jar but that's ok - it's a concious decision by the
programmer.
This would also make Tapestry people's live easier by not forcing them
to change thier modules.
my 2 cents.
Geoff
On 2/16/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> 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 <kn...@gmail.com> 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 <ju...@logicstyle.com> 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
> > > >><hl...@gmail.com>:
> > > >>
> > > >>
> > > >>
> > > >>>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: hivemind-dev-unsubscribe@jakarta.apache.org
> > > >>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> > > >>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Blog: http://jroller.com/page/glongman
Feature Updates: http://spindle.sf.net/updates
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: HiveMind 1.2 progress
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <kn...@gmail.com> 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 <ju...@logicstyle.com> 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
> > >><hl...@gmail.com>:
> > >>
> > >>
> > >>
> > >>>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: hivemind-dev-unsubscribe@jakarta.apache.org
> > >>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: HiveMind 1.2 progress
Posted by Knut Wannheden <kn...@gmail.com>.
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 <ju...@logicstyle.com> 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
> >><hl...@gmail.com>:
> >>
> >>
> >>
> >>>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: hivemind-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: HiveMind 1.2 progress
Posted by Juliano Junio Viana <ju...@logicstyle.com>.
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
>><hl...@gmail.com>:
>>
>>
>>
>>>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: hivemind-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: HiveMind 1.2 progress
Posted by James Carman <ja...@carmanconsulting.com>.
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:kris.bravo@corridor-software.us]
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
> <hl...@gmail.com>:
>
> > 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: hivemind-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: HiveMind 1.2 progress
Posted by Kris Bravo <kr...@corridor-software.us>.
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
> <hl...@gmail.com>:
>
> > 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: hivemind-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: HiveMind 1.2 progress
Posted by Achim Hügen <ac...@gmx.de>.
+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
<hl...@gmail.com>:
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org