Sorry, wrong list. Please Ignore. regards,
Karl On Mon, Feb 1, 2021 at 1:11 PM Karl Pauls <[email protected]> wrote: > > 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. > > regards, > > Karl > > -- > Karl Pauls > [email protected] -- Karl Pauls [email protected]
