[Sightly] API change for org.apache.sling.scripting.sightly.render

[Radu Cotescu <ra...@apache.org>]

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

Re: [Sightly] API change for org.apache.sling.scripting.sightly.render

[Radu Cotescu <ra...@apache.org>]

Hi Robert,

Yeah, I kind of rushed into getting things done.

The gist is this:
* we have some new API in org.apache.sling.scripting.sightly.compiler [3]
that allows for compiling Sightly scripts and getting an Abstract Syntax
Tree as a result
* most of the API that was previously exported by
org.apache.sling.scripting.sightly is now exported by
org.apache.sling.scripting.sightly.compiler.java
[4]; the package org.apache.sling.scripting.sightly.render [5] is now
exported with version 2.0.0 because RenderContext has changed in a
backwards incompatible way

If [5] is going to affect anyone I guess we can provide them with a
compatibility bundle, but I don't think that there were other Sightly
implementers.

Cheers,
Radu

[3] -
https://github.com/apache/sling/tree/trunk/bundles/scripting/sightly/compiler/src/main/java/org/apache/sling/scripting/sightly/compiler
[4] -
https://github.com/apache/sling/tree/trunk/bundles/scripting/sightly/java-compiler/src/main/java/org/apache/sling/scripting/sightly
[5] -
https://github.com/apache/sling/tree/trunk/bundles/scripting/sightly/java-compiler/src/main/java/org/apache/sling/scripting/sightly/render



On Fri, 17 Jun 2016 at 21:50 Robert Munteanu <ro...@apache.org> wrote:

> Hi Radu,
>
> On Wed, 2016-06-15 at 14:38 +0000, Radu Cotescu wrote:
> > 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 code changes have been comitted, so this only serves as a kind
> request for future reviews:
>
>   please separate style changes from functional changes
>
> Your pull request has an impressive change count : +8,009 −5,465 , but
> I notice lots of style changes - javadoc formatting, diamond operator
> for generics, license header tweaks - which make it hard to review the
> core of the pull request.
>
> Thanks,
>
> Robert
>

Re: [Sightly] API change for org.apache.sling.scripting.sightly.render

[Robert Munteanu <ro...@apache.org>]

Hi Radu,

On Wed, 2016-06-15 at 14:38 +0000, Radu Cotescu wrote:
> 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 code changes have been comitted, so this only serves as a kind
request for future reviews:

� please separate style changes from functional changes

Your pull request has an impressive change count : +8,009 \u22125,465 , but
I notice lots of style changes - javadoc formatting, diamond operator
for generics, license header tweaks - which make it hard to review the
core of the pull request.

Thanks,

Robert