Hi, Am Montag, den 06.08.2007, 09:15 -0700 schrieb Steven E. Harris: > Carsten Ziegeler <[EMAIL PROTECTED]> writes: > > > And add the javadoc tags to your source code, and everything else is > > done by the plugin. > > Is there a reason that you chose Javadoc tags over Java annotations?
Yes, we are bound to Java 1.4 right now and therefore cannot make use of any Java 5 features. Furthermore, I had a pressing need for a solution, so using Qdox with Javadoc tags was easier to use than Commons Annotations. That's all. > > > WDYT? > > There are some facets specified in these tags that I'd be reluctant to > include in the source code for the affected classes. Deciding which > classes should be exposed from a bundle as services feels like it should > be part of the bundle-level declarations, not bound to the classes Well, generally, it is the Class Programmer, which has to decide whether to declare a class for declarative services. She also knows about required services (references) and provided services (if at all). Whether the programmer now creates a declaration manually besides the source file or inlined is a matter of notation. The plugin only extracts the tagged information and generates the OSGi specified declaration at compile time. So, full control remains with the programmer while the end product (the bundle) has the declaration in the right place - in OSGI-INF/serviceComponents.xml by default - and referenced with the Service-Components header. One issue of course is extensibility: If component A in Bundle BA is extended by Component B in Bundle BB, we would want to also inherit the declaration of component A for component B without having to duplicate everything. For non-abstract classes, this would be possible by just extending the existing declaration. For abstract classes, this is not possible as those are not actually declared. So we introduced another file, which just contains the relevant information for extension. > involved. Similarly, specifying which services a given class depends > upon (say, by way of a filter) also feels too specific to be bound as > part of the source code. That is true. Therefore, the spec allows configuration to supply this reference functionality with a ServiceName.target property (where "ServiceName" is the name attributed to the reference) containing a filter string to be used to select the actual services to be referenced. See sections 112.3.4 (Selecting Target Services) and 112.6 (Component Properties) for more information on this. > > The plugin looks like a nice solution and it's well thought out. My > criticism is not meant to attack the plugin itself, but more to question > whether it's encouraging specification in the right place or at the > right level. For the record, I have many of the same reservations about > Google Guice. Absolutely agreed. But then, the plugin adds no runtime functionality. It is just to simplify development of standard Declarative Services with support for the MetaType specification and hence the Configuration Admin Service. The only non-standard contents of generated bundles is the additional descriptor file for abstract components. Hope this helps. Regards Felix
