Hi, 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".
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). 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/master/src/main/java/org/apache/sling/servlets/resolver/bundle/tracker -- Karl Pauls [email protected]
