Questions surfaced by SLING-9999

[Karl Pauls <ka...@gmail.com>]

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
karlpauls@gmail.com

Re: Questions surfaced by SLING-9999

[Karl Pauls <ka...@gmail.com>]

Sorry, wrong list. Please Ignore.

regards,

Karl

On Mon, Feb 1, 2021 at 1:11 PM Karl Pauls <ka...@gmail.com> 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
> karlpauls@gmail.com



-- 
Karl Pauls
karlpauls@gmail.com