Hi, If nobody opposes in the next 24 hours, I will ask INFRA to rename the repository from [0] to sling-org-apache-sling-scripting-spi and the API refactored to be in the org.apache.sling.scripting.spi.bundle package.
Regards, Radu > On 15 Feb 2021, at 10:51, Karl Pauls <karlpa...@gmail.com> wrote: > > So, looking at this proposal by Radu, > > it sounds to me like this is addressing what Olli wanted and just > needs a decision on whether we want a new scripting.spi bundle or > rather only have the scripting.api bundle. > > Olli, what are your thoughts - would you be fine with the separate > bundle provided it is renamed to scripting.spi (and the package in > question is renamed to scripting.spi.bundle)? > > Regards, > > Karl > > On Mon, Feb 8, 2021 at 11:49 AM Radu Cotescu <r...@apache.org > <mailto:r...@apache.org>> wrote: >> >> Hi Olli, >> >> Which of the two options below do you prefer? >> >> 1. The API from o.a.s.servlets.resolver.api bundle [0] gets moved to the >> o.a.s.scripting.api bundle, in the o.a.s.scripting.api.bundle package. That >> means that we’ll have the following import chains: >> >> o.a.s.scripting.api >> o.a.s.scripting.core >> o.a.s.servlets.resolver >> >> 2. Alternatively, we can extract the API from [0] into a new scripting >> bundle - o.a.s.scripting.spi - in the o.a.s.scripting.spi.bundle package, >> with the following import chains: >> >> o.a.s.scripting.bundle.api >> o.a.s.scripting.core >> o.a.s.servlets.resolver >> >> Either way, we’d ask INFRA to either delete the repository from [0] (option >> 1 above) or rename it (option 2 above) and the Servlets Resolver would >> depend on a Scripting API bundle (the one we already have or a new one). >> >> Thanks, >> Radu >> >> [0] - >> https://github.com/apache/sling-org-apache-sling-servlets-resolver-api/tree/master/src/main/java/org/apache/sling/servlets/resolver/bundle/tracker >> >>> On 1 Feb 2021, at 22:01, Oliver Lietz <apa...@oliverlietz.de> wrote: >>> >>> On Monday, February 1, 2021 1:17:23 PM CET Karl Pauls wrote: >>>> Hi, >>> >>> Hi, >>> >>>> we have a discussion going on at SLING-9999 that needs some resolving. >>>> >>>> As far as I can see, there are the following proposals in the issue: >>>> >>>> #1 move the o.a.s.servlets.resolver.bundle.tracker package to another >>>> artifact #2 rename the package to something else >>>> #3 split up the package to move the ResourceType class to sling api >>>> >>>> As far as the positioning goes, I guess my summary would be: >>>> >>>> On the one hand, to not have the scripting bundles depend on the >>>> servlets.resolver (#1 above) and on the other hand (#2), would it be >>>> better to have the package name include "scripting" (I’m not sure we >>>> have to discuss #3 right now as that seems to be orthogonal)? Please >>>> correct me if I'm missing something (we could work with optional >>>> imports as well but that isn't the nicest way to handle dependencies). >>>> >>>> One option to achieve #1 is to introduce a servlets.api bundle. I guess the >>>> idea behind that one is that this way, the servlets.resolver doesn’t >>>> require the scripting.api and the scripting doesn’t require the >>>> servlets.resolver (just this new api bundle). >>>> >>>> Another way to do it is to move the package to scripting.api. Which >>>> solves it as well with the downside of having the servlets.resolver >>>> require the scripting.api. Granted, if #2 is taken into account >>>> (renaming the package to be the in scripting namespace) it makes >>>> sense. >>>> >>>> Ultimately, I guess the question for this list to get consensus on is: >>>> >>>> Do we want the servlets.resolver to have a dependency on scripting.api >>>> or do we rather introduce a new servlets.resolver.api bundle - with a >>>> possible tie-breaking subquestion of do we think the bundle.tracker >>>> api package should stay in the namespace it is in right now or should >>>> it move to the scripting namespace? >>>> >>>> Personally, I think the package namespace is a slightly better fit for >>>> the servlets resolver rather than the scripting and consequently, >>>> would go with the servlets.resolver.api bundle as a reasonable >>>> compromise. >>> >>> >>> #1 move the o.a.s.servlets.resolver.bundle.tracker package to another >>> artifact >>> >>> Package o.a.s.servlets.resolver.bundle.tracker contains the new Bundle API >>> for >>> _Scripts_. >>> >>> The API is a new dependency for Scripting Core, Scripting HTL, Scripting JSP >>> and Servlets Resolver. >>> >>> To provide its full functionality Servlets Resolver requires the optional >>> dependency Scripting Core. Therefore it makes sense to move the package out >>> of >>> Servlets Resolver to not have a cyclic dependency. >>> >>> As Karl said optional imports are not a nice way to handle dependencies. >>> >>> >>> #2 rename the package to something else >>> >>> See dependents (mostly scripting) above. >>> >>> The classes in the package reference or deal with Script(ing) and not >>> Servlets >>> Resolver, see [1]. >>> >>> I see the API/SPI therefore in a "scripting" package (without tracker as it >>> is >>> an implementation detail) and matching bundle: >>> >>> a) o.a.s.scripting.api.bundle (bundle o.a.s.scripting.api) >>> >>> b) o.a.s.scripting.spi.bundle (new bundle o.a.s.scripting.spi) >>> >>> c) o.a.s.api.scripting.bundle (bundle o.a.s.api) >>> >>> d) o.a.s.spi.scripting.bundle (bundle o.a.s.api) >>> >>> >>> #3 split up the package to move the ResourceType class to sling api >>> >>> ResourceType is generic and can be used in different contexts not related to >>> Scripting or Servlets Resolver. >>> >>> Therefore it makes sense to move it into package o.a.s.api.resource.type in >>> Sling API bundle. >>> >>> >>> [1] https://issues.apache.org/jira/browse/SLING-9999? >>> <https://issues.apache.org/jira/browse/SLING-9999?> >>> <https://issues.apache.org/jira/browse/SLING-9999? >>> <https://issues.apache.org/jira/browse/SLING-9999?>> >>> focusedCommentId=17275984&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment- >>> tabpanel#comment-17275984 >>> >>> Regards, >>> O. >>> >>> >>>> regards, >>>> >>>> Karl >> > > > -- > Karl Pauls > karlpa...@gmail.com <mailto:karlpa...@gmail.com>
