On Monday 09 February 2004 11:34, Albert Kwong wrote: > 1. If an abstract class is used to handle > lifecycle methods for components, the subclass does > not necessary has these two methods, and thus it would > be impossible to declare component dependencies. (of > course empty service() or compose() methods may be > declared, but that's like cutting toes to fit the > shoes).
I think part of the answer is that "many" Avalon developers are generally against inheritence, and don't think it is a good idea to subclass components from a general superclass. Having the "empty" (more like, super.service() ) is a price considered reasonable for these "undesirable" patterns. > 2. Wouldn't it be better to have the option of > putting the dependency declaration under class level > javadoc, so that all major avalon related tags are > collected together? The rationale for having it at service(), is that the component class is most of the time quite large, and you don't have in view (during editing) the declared "key" and "type" that you use in your lookup. I am definately against having them in the class level javadoc only. Whether to allow them there, is a difficult question. Answer; If class level declares DepA, DepB, DepC and service method declares DepA, DepC and DepD, what is the resulting Dependency declarations? Error? > 3. If it is a must-have requirement to have > @avalon.dependency under these methods only, wouldn't > it be nice to document it somewhere? (Or maybe I have > missed it?) http://avalon.apache.org/merlin/starting/tutorial/dependencies/auto.html Maybe not very visible, but the Getting Started with Merlin is definately a must read line by line. > I have been pulling my hair for a few days because > maven avalon:meta wouldn't generate the xinfo files > correctly due to this setup. I am sure others like me > would face the same problem. We will really > appreciate if this problem can be solved. That was unfortunate. We do want the user experience to be smoother, especially when coming in the first time. One such effort to improve simplicity-of-use is that we are working on an Eclipse plug-in, MerlinDeveloper, which will help a great deal with all of this detail. As for your inheritence, I would be curious if you have a rational use-case that needs to be accommodated for. (I am one of those that is very negative to inheritence, as it have given me more grief than relief over the years.) Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
