Hi Am 04.07.2013 um 10:28 schrieb Bertrand Delacretaz:
> Hi Carsten, > > On Thu, Jul 4, 2013 at 8:56 AM, Carsten Ziegeler <[email protected]> wrote: >> ...For now I'm against committing this to trunk, as previously mentioned I >> would prefer having a build time annotation. If this is not possible, then >> the annotation and the AdapterProvider should be in the same package as >> there is no use case for using one without the other.... > > Yes, I was actually wondering about putting the annotation and > AdapterProvider in the org.apache.sling.adapter bundle instead of > sling.api. I was proposing it to be in another package. Reconsidering this to be a runtime annotation and thus be kind of some special API it would indeed make sense to have it in the o.a.s.api.adapter package. > > That's slightly inconsistent with having the AdapterFactory in the > sling.api bundle, but we can rightly consider these new interfaces as > being adapter extensions, WDYT?. I'd keep the annotation in the Sling API bundle. > > OTOH I don't like @Adapter being a build-time only annotation - by > doing this you either tie people to Maven, or have to provide > build-time extensions for all common build tools (Maven, ant > command-line etc) which is a lot of work for such a simple feature. If > you want to create a build-time tool in addition why not, but I don't > want to make this build-time only. If you compare with declarative > services, the build-time plugin is very useful but you can also > perfectly work without it. Actually, that is not entirely true: The single point of truth in providing the method names would be the service registration property. The annotation would be synthactic sugar for build tools. > >> >> One solution for a build time annotation would be to define a server >> registration property for a AdapterProvider containing the method names... > > That's much more complicated to write than just an @Adapter annotation > on a method. Plus that would not only be the method names but the fully signatures to cope with method overloading ! > > Am 04.07.2013 um 08:56 schrieb Carsten Ziegeler: > >> One solution for a build time annotation would be to define a server >> registration property for a AdapterProvider containing the method names and >> at build time the value of this property would be generated by using the >> annotation. This would be similar to the bind/unbind methods of DS. The problem is with method overloading: In DS there is a defined algorithm to find the named method in case of method overloading. In this case we want to explicitly name a method. So we would have to define the actual method signature in the property, which would be cumbersome when not using the tooling. Regards Felix
