On Monday, August 24, 2020 10:50:40 AM CEST Karl Pauls wrote: > Hi, Hi Karl, hi Radu,
> the bundle.tracker was merged into the resolver mostly for efficiency > reasons - however, it isn't a bad fit there so I wouldn't say that is > a problem. That there is now a dependency from the scripting core to > the resolver is a side-effect of the whiteboard pattern used in this > case and I don't necessarily know about why that would mean we "give > up modularization". It's another case where you are forced to install/run additional bundle(s) and have dependencies to a different domain in Sling. Those cyclic dependencies cause issues - preventing the compilation of meaningful features (feature -> higher level module) is the most obvious here I guess. > That said, however, I can see the point about the increased coupling. > Towards that end, I think there are ways we can improve on that. From > the top of my head, we could either try to make the import optional as > this really is an optional feature or we could try to move the bundled > part out of the core and make it a standalone bridge bundle (I think > that should be possible but we'd have to have a closer look at it). > > Maybe we should create an improvement JIRA issue to track this and > work on it to make the dependency from the scripting core to the > resolver either optional or factored out into an additional "bridge" > bundle? > > And yeah, the old tacker can either be deprecated or maybe be > repurposed (see above). I prefer having uni-directional dependencies and therefore have it in an additional bundle (especially if it's an optional feature). Are you fine with the additional bundle Karl suggested? Thanks, O. > regards, > > Karl > > On Mon, Aug 24, 2020 at 10:29 AM Bertrand Delacretaz > > <[email protected]> wrote: > > Hi, > > > > On Sun, Aug 23, 2020 at 9:33 PM Oliver Lietz <[email protected]> wrote: > > > ...Why was the (standalone) module o.a.s.scripting.bundle.tracker merged > > > into o.a.s.servlets.resolver?.. > > > > That's strange indeed, we now have very similar code at [1] and [2]. > > > > If there was a good reason for that (I don't know about that) we > > should at least mark [1] as deprecated. > > > > -Bertrand > > > > [1] > > https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker > > /tree/master/src/main/java/org/apache/sling/scripting/bundle/tracker > > > > [2] > > https://github.com/apache/sling-org-apache-sling-servlets-resolver/tree/m > > aster/src/main/java/org/apache/sling/servlets/resolver/bundle/tracker
