Loading...

hivemind-dev@jakarta.apache.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: HiveMind 1.1 wrapping up Achim Hügen Fri Nov 04 12:23:01 2005

I started experimenting with an annotation based container earlier
this year. While it is great fun and looks promising it isn't
really compatible with hiveminds approach.
This week I made a first release and would be happy to share
my ideas and give some inspirations for annotation support in hivemind.

The project is called annocon and is to be found here:
http://annocon.sourceforge.net

Forgive me for cheating on hivemind ;-)

Achim Huegen


Am Wed, 26 Oct 2005 19:46:34 +0200 schrieb Howard Lewis Ship <[EMAIL PROTECTED]>:

I picture annoations as offering defaults and being optional, with
fallbacks to other techniques such as today's XML.

A parallel idea I discussed much earlier was a "module class" that
would be responsible for defining and constructing services ... again,
using a mix of naming convention and annotation.  Or, perhaps, just
annotation if we pull HiveMind forward to JDK 1.5.

On 10/26/05, Johan Lindquist <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I agree with Stefan about annotations and the like - tying configuration
so close to source files just doesn't feel right.

For all it is worth, I would say stay away from 1.5 for at least another
release - too many people are still on 1.4 and it would just slow the
uptake of people using HiveMind until they catch up.

Cheers,

Johan

Liebig, Stefan wrote:
>>And yet ...
>>
>>Still thinking about reducing XML in favor of code (annotations and
>>conventions).
>
>
> How about defining "hivemoduls" with configuration classes according to and/or
> using a set of HiveMind-APIs?
>
> To some degree annotations seem to be a good solution. However, with the current > HiveMind it is possible to ´implement´ a service from jdk classes or third
> party classes. Those classes can not be annotated!
>
> I would prefer techniques that have no need to adapt the POJOs, either thru
> following some conventions or thru annotating them.
>
>
>>What happens if we start to require JDK 1.5 for HiveMind 1.2?  It
>>means Tapestry 4.1 may need 1.5 as well. I'm OK with that.
>
>
> yes!
>
>
>>Imagine a builder that used annotations on the implementation class
>>to determine what to inject and how.
>>
>>Image a convention of tacking "Impl" onto the service id to form the
>>default implementation class.
>>
>>--
>>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]

- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDX4bmHS6c76+IdrwRAv91AJ9drH/RA/9kDgyJad9CUyrdQNI69QCaAiKI
F2l+jFy6QvnpYdaKSYnEPFU=
=ILNF
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
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]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]