On Wednesday, 14 April 2021 07:21:06 CEST Carsten Ziegeler wrote: > Am 14.04.2021 um 00:09 schrieb Oliver Lietz: > > I don't get the eventing example. Resources are a substantial part of > > Sling > > and defined in Sling API. Sling API bundle already contains several utils > > around Resource (and HTTP Request/Response and Scripting). Resource and > > Resource Type are very general and not necessarily bound to Scripting. > > Eventing is optional and a complete different story. > > Fair enough, eventing wasn't maybe the best example. > > > Again, I see a value using ResourceType when dealing with Resources in > > Sling not related to Scripting. > > While I agree that resource and resource type are the core concepts of > Sling and beling in the API, the discussed ResourceType class still does > not look like that to me. I'm still missing a use case for this. > > > If the intended use is Scripting only why not renaming it to ScriptType in > > Scripting SPI and adding a copy as ResourceType to Sling (Resource) > > API...? > > :) I guess the last thing we want is code duplication.
That was a bad joke. Some of my concerns are around code duplication and (re)implementations of existing functionalities. Often seen in AEM projects because developers are not aware what is already available in Sling, ACS AEM or wcm.io modules. > > What is the real drawback of having ResourceType in Sling API? > > Avoiding unnecessary dependencies, coherent apis and avoiding that they > > just get a dumping place for useful sounding things. I'm not saying that > this is the case here, but still I fail to see why this needs to be part > of Sling API. So in general we agree but disagree on the usefulness of ResourceType in different contexts. > For example, this class introduces a dependency on the OSGi Version > class as part of the API - so users of the Sling API are then required > to also have the OSGi framework api - which I think should be avoided. > So by putting this into the Sling API all users are punished to have > this extra dependency. And embedding that class will sooner or later > result in problems (we had a similar situation in the feature model - > where the dependency makes sense as the feature model is about OSGi). > > How about we go with a compromise? We move that class to a separate > package but leave it in the current bundle? If it turns out to be useful > for each and every Sling developer, we can move the package to Sling API > - without being incompatible. Sounds good! Do we agree on dedicated package org.apache.sling.api.resource.type? Thanks! O. > Regards > Carsten > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
