Besides, if you don't like the defaults, you can always override them. In your case, since you don't follow this "standard" naming convention, you will have to. Or, we would allow a way for you to plug in your "ImplementationResolver" implementation and you can tell HiveMind how to look for implementation classes that way.
-----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 11:37 AM To: dev@hivemind.apache.org Subject: RE: New convention? Which convention are you saying isn't a best practice? Having the impl subpackage stuff? That is a common approach that many folks take. -----Original Message----- From: Achim Hügen [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 10:14 AM To: dev@hivemind.apache.org Subject: Re: New convention? Sorry, but I prefer the strict separation of interface and implementation. I don't see an advantage over a separate implementation class that follows a naming convention. This syntax is not a best practise I would encourage so IMHO it shouldn't be standard. Achim Pablo Lalloni schrieb: > El Lunes, 31 de Julio de 2006 07:49, James Carman escribió: > >> Yes, *Impl in the same package might even be the first place it looks. >> Then look for an *Impl in the impl subpackage. I normally use the latter >> setup, but many folks do just put the implementation classes in the same >> package as their interface. I'd like to make HiveMind very simple to >> configure with minimal effort. That's why we offer the option to use >> "convention over configuration." >> > > In cases when there will be just a single impl or a "default" one for a given > service we just make it a static inner class of the service interface. > > public interface SomeService { > ... > public static class Default implements SomeService { > ... > } > } > > So if the impl "search path" includes this idiom, it would be great for us as > this is definitely the most frequent case here. > >
