> 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
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
