Hi,

I've recently opened a pull request for SLING-5787 [0] in order to get a
chance to discuss the API change from the topic before committing the code
to trunk.

The main driver for the modularisation was SLING-5788 - a Sightly Maven
Plugin. In this context I also wanted to make the Sightly compilers
(front-end and back-end) independent of the Apache Sling API and the OSGi
environment.

What this means is that the RenderContext interface (the one that imposed
the API change) should not provide access to a ResourceResolver any more.
In addition to that I also added a new method
- RuntimeObjectModel#getObjectModel - that would allow any implementer to
provide a customised runtime for Sightly scripts, where objects can be
coerced / transformed according to the implementer's wish. For more details
see [1] and [2].

The affected consumers are the RuntimeExtensions that need to be changed a
bit, as these rely on a RenderContext. The good news is that with Sightly
this shouldn't affect developers using Sightly for their component scripts,
as the RuntimeExtensions are provided either by Sling or by AEM.
Unfortunately I cannot think of a backwards compatible way of imposing
these changes.

Do you find this major API change problematic or should we go on and apply
the patch?

Thanks,
Radu

[0] - https://issues.apache.org/jira/browse/SLING-5787
[1] -
https://github.com/apache/sling/blob/trunk/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/render/RenderContext.java
[2] -
https://github.com/raducotescu/sling/blob/SLING-5787/bundles/scripting/sightly/java-compiler/src/main/java/org/apache/sling/scripting/sightly/render/RenderContext.java

Reply via email to