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