On Thursday, 18 February 2021 10:21:05 CET Radu Cotescu wrote:
> Hi,

Hi Karl, hi Radu,

Sorry for coming back late, I was again hit by severe bugs in Akonadi and 
still trying to fully recover.

> If nobody opposes in the next 24 hours, I will ask INFRA to rename the
> repository from [0] to sling-org-apache-sling-scripting-spi and the API
> refactored to be in the org.apache.sling.scripting.spi.bundle package.

+1 This looks like b) from my list of possible options below with reusing 
o.a.s.servlets.resolver.api repo.

How about ResourceType (#3)?

Many Thanks!
O.


> Regards,
> Radu
> 
> > On 15 Feb 2021, at 10:51, Karl Pauls <[email protected]> wrote:
> > 
> > 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 <[email protected] 
<mailto:[email protected]>> 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/t
> >> ree/master/src/main/java/org/apache/sling/servlets/resolver/bundle/tracke
> >> r>> 
> >>> On 1 Feb 2021, at 22:01, Oliver Lietz <[email protected]> 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?>
> >>> <https://issues.apache.org/jira/browse/SLING-9999?
> >>> <https://issues.apache.org/jira/browse/SLING-9999?>>
> >>> focusedCommentId=17275984&page=com.atlassian.jira.plugin.system.issueta
> >>> bpanels%3Acomment- tabpanel#comment-17275984
> >>> 
> >>> Regards,
> >>> O.
> >>> 
> >>>> regards,
> >>>> 
> >>>> Karl




Reply via email to