Hi As it seems you are renaming packages, just a question from the side line. I haven't followed the discussion closely, but I always wondered why the package name contains the term "bundle"? Is it because the scripts are "bundled"? Wouldn't "precompiled" be more expressive and maybe also a little more generic? Maybe we want to provide precompiled scripts in a way that cannot be considered "bundled" in the future.
I'm not hung up on any particular outcome. Just providing feedback that to me the term "bundle" doesn't intuitively make sense. Regards Julian On Thu, Feb 18, 2021 at 10:21 AM Radu Cotescu <r...@apache.org> wrote: > > Hi, > > 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. > > Regards, > Radu > > > On 15 Feb 2021, at 10:51, Karl Pauls <karlpa...@gmail.com> 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 <r...@apache.org > > <mailto:r...@apache.org>> 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/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?> > >>> <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 > >> > > > > > > -- > > Karl Pauls > > karlpa...@gmail.com <mailto:karlpa...@gmail.com>
