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> 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?> > > focusedCommentId=17275984&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment- > > tabpanel#comment-17275984 > > > > Regards, > > O. > > > > > >> regards, > >> > >> Karl > -- Karl Pauls karlpa...@gmail.com
