2011/11/11 Justin Edelson <[email protected]>: > On Fri, Nov 11, 2011 at 7:16 PM, Justin Edelson > <[email protected]> wrote: >> On Fri, Nov 11, 2011 at 6:42 PM, Carsten Ziegeler <[email protected]> >> wrote: >>> 2011/11/11 Justin Edelson <[email protected]>: >>>> A configuration printer is certainly an option, but I think the devs >>>> I've see run into this problem would be better served by something >>>> more interactive. So let's say both :) >>> +1 >>> >>>> >>>> I'm not opposed to a metadata file, but the reason I prefer the >>>> service property method to a file in META-INF is that we can reuse the >>>> service properties from AdapterFactory implementations. The Web >>>> Console doesn't need to care whether the metadata is provided by a >>>> metadata provider service or an AdapterFactory service (or some other >>>> arbitrary service). See https://gist.github.com/1359911 for an example >>>> of the Web Console plugin I built as a POC. >>> Hmm, I'm not a fan of declaring a service just for the sake to provide >>> meta information :) >>> But we could use the annotations to just generate meta type info, by >>> just using the Component annotation with ds=false. >> >> That's worse IMHO. You convinced me - we should use a sidecar file. > > https://gist.github.com/1359997 > > WDYT?
Looks fine to me - not sure whether json or xml is better, but I'm fine with json :) What about adding support for this to some maven plugin, so we can have an annotation somewhere in the java code and this file gets generated? The maven-sling-plugin looks like a good place to me. Carsten > >> >> Justin >> >>> >>> Carsten >>> >>>> >>>> Justin >>>> >>>> On Fri, Nov 11, 2011 at 6:08 PM, Carsten Ziegeler <[email protected]> >>>> wrote: >>>>> Great idea and I'm definitely +1 on such a web console plugin. Not >>>>> sure if this is a web console plugin or a configuration status >>>>> renderer (we need the last one as well). >>>>> >>>>> I think instead of defining the additional metadata through the java >>>>> annotations with additional classes like the >>>>> JcrNodeResourceAdapterMeta in your example, what about having a meta >>>>> data file in META-INF of the bundle instead. I know its separate from >>>>> the java code though. >>>>> >>>>> Regards >>>>> Carsten >>>>> >>>>> 2011/11/11 Justin Edelson <[email protected]>: >>>>>> Working with new Sling developers, I find that one of the concepts >>>>>> they have trouble with is in the area of Adapters and that it is hard >>>>>> to find out what objects are adaptable to which classes. Although it >>>>>> is possible to document this (see for example >>>>>> http://dev.day.com/docs/en/cq/current/developing/sling-adapters.html), >>>>>> because new Adapters can be dynamically added (or removed) through >>>>>> OSGi services, any documentation is potentially incomplete. >>>>>> >>>>>> What I would like to do is create a new Web Console plugin which >>>>>> displays the list of available adaptation pairs. I'm still thinking >>>>>> about the UI, but you could imagine that a first version would be a >>>>>> select list on the left listing the adaptable classes and a list on >>>>>> the right of the possible adapters for the selected adaptable. >>>>>> >>>>>> For implementations of AdapterFactory, the necessary metadata already >>>>>> exists in the service registry, but for cases where a class implements >>>>>> its own adapters, this metadata needs to be added. >>>>>> >>>>>> In order to do this, I propose the following: >>>>>> 1) The creation of such a Web Console plugin (obviously). >>>>>> 2) The creation of new OSGi Services for classes which implement their >>>>>> own adaptations. For example: >>>>>> @Component >>>>>> @Service(value=Object.class) >>>>>> @Properties({ >>>>>> @Property(name="adaptables", >>>>>> value="org.apache.sling.api.resource.Resource"), >>>>>> @Property(name="adapters", value={ >>>>>> "javax.jcr.Node", >>>>>> "javax.jcr.Item", >>>>>> "java.io.InputStream", >>>>>> "java.net.URL", >>>>>> "java.util.Map", >>>>>> "org.apache.sling.api.resource.ValueMap" >>>>>> }) >>>>>> }) >>>>>> public class JcrNodeResourceAdapterMeta { } >>>>>> >>>>>> 3) The establishment of a new service property, named >>>>>> adapter.condition, which optionally indicates the conditions under >>>>>> which an adaptation can be made. For example, in the case above: >>>>>> @Property(name="adapter.condition", value="If the resource is a >>>>>> JcrNodeResource") >>>>>> >>>>>> The Web Console plugin would need to note that potentially not all >>>>>> adapters are listed, but I believe that if we add the metadata for all >>>>>> the adapters in Sling, that will set a good precedent for downstream >>>>>> projects to follow. If we want, we could also add a note which says >>>>>> "If there's an adapter not listed here, please file an issue with the >>>>>> adapter provider." :) >>>>>> >>>>>> Adding this metadata is not a trivial amount of effort, but it also >>>>>> something I feel will pay dividends down the road. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Justin >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Carsten Ziegeler >>>>> [email protected] >>>>> >>>> >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> [email protected] >>> >> > -- Carsten Ziegeler [email protected]
