I think SLING-7205 is breaking compatilibity on source files.

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

I think SLING-7205 is breaking compatilibity on source files.

Santiago García Pimentel
Hello,

In a client's project we are recently evaluating an update for our sling based CMS. along many things it updates the sightly java compiler. Since the update I noticed that certain java files generated by Sightly wont compile when you use -data-sly-use with classes with the same name.

for example
        data-sly-use.first="com.adobe.cq.wcm.core.components.models.Page"
        data-sly-use.second="com.client.project.Page"

Before this would create perfectly compilable java files since it would refer to the classes by their FQN every time. Now it generates an import and reference them only by name, causing compilation failures.

Before it would generate a java like this:

        _global_second = renderContext.call("use", "com.client.project.Page", obj());
        _global_first = renderContext.call("use", "com.adobe.cq.wcm.core.components.models.Page", obj());

Now it generates two imports followed by using the class by name

        import com.client.project.Page;
        import com.adobe.cq.wcm.core.components.models.Page;
        ...
        ...
        _global_first= renderContext.call("use", Page.class.getName(), obj());
        _global_second = renderContext.call("use", Page.class.getName(), obj());

Which wont compile.


Changing my code is not difficult, but this seems to me like a compatibility break which should not happen.

WDYT?


Santiago García Pimentel
Sr. Software Engineer
[hidden email]
M. +34687915463

A Cognizant Digital Business | www.netcentric.biz
Follow us on LinkedIn | Twitter