On Tuesday, 13 April 2021 15:08:25 CEST Carsten Ziegeler wrote: > Am 13.04.2021 um 14:35 schrieb Oliver Lietz: > > On Tuesday, 13 April 2021 08:03:02 CEST Carsten Ziegeler wrote: > > > > IMHO Resource versioning is now a common practice is Sling/AEM projects. > > I strongly suggest keeping API and helpers/utils in a single place (as we > > have done it so far) instead of spreading it over multiple modules. Any > > consumer of Scripting SPI is anyways depending on Sling API. > > We are not putting each and every utility api into Sling API. If it is > of general purpose *and* of interest to users of the Sling API, then > yes, it makes sense to consider adding it there. > > But for example utility api for eventing is part of the event api. > > I still fail to see what a general user of the resource api can do with > the ResourceType class? > > It is scripting related, so why not have it part of scripting?
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. Again, I see a value using ResourceType when dealing with Resources in Sling not related to Scripting. 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...? What is the real drawback of having ResourceType in Sling API? Thanks, O. > > We can easily inline org.osgi.framework.Version into the API bundle to > > remove the dependency if required. Commons Lang3 is only used in the test > > and was > > already present: > Sure we can solve the dependency problem, the important point is that we > consider and look at this. > > Regards > Carsten > > > https://github.com/apache/sling-org-apache-sling-api/commit/ > > 02cb7f1bbc4836865afd7e9964d3be1380daf734 > > > > Regards, > > O. > > > >> Regards > >> Carsten > >> > >> Am 12.04.2021 um 18:32 schrieb Radu Cotescu: > >>> Hi Julian, > >>> > >>> The reason for pushing back on this is that ResourceType [1] is more of > >>> a > >>> utility class, rather than an API one. It’s a final class, used to: > >>> > >>> Generate require and provide capabilities with the help of the > >>> scriptingbundle-maven-plugin Set up the servlets for each provided > >>> capability in org.apache.sling.servlets.resolver > >>> > >>> Granted, we can move it into a dedicated package in o.a.s.api, but I > >>> really don’t see the value. Moving it will also make o.a.s.scripting.spi > >>> (providing the rest of the API needed to support bundled scripts) depend > >>> on o.a.s.api. Is it really worth it? > >>> > >>> Regards, > >>> Radu > >>> > >>> [1] - > >>> https://github.com/apache/sling-org-apache-sling-scripting-spi/blob/e14f > >>> 6 > >>> c23df591646d01fb3aaa185e9360cadcaa0/src/main/java/org/apache/sling/scrip > >>> ti > >>> ng/spi/bundle/ResourceType.java#L41> > >>> > >>>> On 12 Apr 2021, at 16:57, Julian Sedding <jsedd...@gmail.com> wrote: > >>>> > >>>> Hi * > >>>> > >>>> I agree with Olli that moving ResourceType later will not happen, > >>>> because it causes too much disruption. I also agree that it is > >>>> generally useful and not inherently linked to scripting. > >>>> > >>>> Why can't we just move it now, before we make our lives harder? If > >>>> o.a.s.scripting.spi should not depend on o.a.s.api, then it would > >>>> still be possible to embed/inline a self-contained class ResourceType. > >>>> > >>>> Regards > >>>> Julian > >>>> > >>>> On Thu, Apr 8, 2021 at 10:56 PM Oliver Lietz <apa...@oliverlietz.de> > > > > wrote: > >>>>> On Thursday, 8 April 2021 15:48:27 CEST Radu Cotescu wrote: > >>>>>> Hi Olli, > >>>>> > >>>>> Hi Radu, > >>>>> > >>>>>>> On 1 Apr 2021, at 21:26, Oliver Lietz <apa...@oliverlietz.de> wrote: > >>>>>>> > >>>>>>> I have a use case for ResourceType not related to Scripting and > >>>>>>> would > >>>>>>> like > >>>>>>> to see it in Sling API (see SLING-9999 for reasons) where it fits > >>>>>>> well. > >>>>>>> > >>>>>>> https://github.com/apache/sling-org-apache-sling-scripting-spi/blob/ > >>>>>>> ma > >>>>>>> ster > >>>>>>> / > >>>>>>> <https://github.com/apache/sling-org-apache-sling-scripting-spi/blob > >>>>>>> /m > >>>>>>> ast > >>>>>>> er/> > >>>>>>> src/main/java/org/apache/sling/scripting/spi/bundle/ResourceType.jav > >>>>>>> a > >>>>>>> > >>>>>>> WDYT? > >>>>>> > >>>>>> I’ve already replied to your concern at [0], but I don’t mind > >>>>>> repeating > >>>>>> what I said: > >>>>>> > >>>>>> “If we really need to use the ResourceType class somewhere else, we > >>>>>> can > >>>>>> move it to the o.a.s.api bundle when the time comes. We can then > >>>>>> deprecate the one from o.a.s.scripting.spi and remove it once there > >>>>>> will be other incompatible changes added by the other interfaces. > >>>>>> Until then, I really don't see the need to spread 5 interfaces over 2 > >>>>>> bundles and increase the dependency footprint for the current > >>>>>> consumers.” > >>>>> > >>>>> And still it does not make sense nor is it consistent. > >>>>> My initial proposal was to have the Bundle API in bundle > >>>>> o.a.s.scripting.api (no additional bundle) but you rejected to not > >>>>> depend on Scripting API. > >>>>> > >>>>> The o.a.s.scripting.spi bundle is fine but the class (not an > >>>>> interface) > >>>>> ResourceType should be in Sling API from the beginning: > >>>>> > >>>>> - it is useful in different contexts not related to Scripting > >>>>> - better visibility in Sling API > >>>>> - most modules depend on Sling API anyways > >>>>> - close to Resource classes (o.a.s.api.resource), similar helpers > >>>>> (e.g. > >>>>> o.a.s.api.resource.path) > >>>>> - BundledRenderUnitCapability depends on ResourceType, moving/changing > >>>>> it > >>>>> later is a major change (we try to prevent such breaking changes in > >>>>> Sling) > >>>>> - it is no effort to do it now, we need a new release of Sling API > >>>>> anyways > >>>>> > >>>>>> Unless you have something already committed to a repository from > >>>>>> which > >>>>>> you > >>>>>> plan to cut a release soon I'd prefer to go ahead without it for now. > >>>>> > >>>>> So for now would mean never, see above. > >>>>> > >>>>> Regards, > >>>>> O. > >>>>> > >>>>>> Cheers, > >>>>>> Radu > >>>>>> > >>>>>> [0] - > >>>>>> https://issues.apache.org/jira/browse/SLING-9999?focusedCommentId=172 > >>>>>> 95 > >>>>>> 320& > >>>>>> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel > >>>>>> #c > >>>>>> ommen t-17295320
