On Fri, Nov 11, 2011 at 7:42 PM, Carsten Ziegeler <[email protected]> wrote: > 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 :)
I'm thinking JSON because this may end up being the same object structure which is consumed by the UI. Not sure yet... > > 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. Sure, why not? I'm thinking the annotations should be in a separate module and not part of the api or adapters bundle. WDYT? Justin > > 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] >
