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
