Am I missing something, or will this require a Java build and install every time an HTL file is changed?
I *love* the idea of finally having a real solution to versioning scripts. I *love* the idea of not worrying about getting overlaid. I *do not* love the idea of having to build a bundle every time a script changes (if the above is true). This is a non-starter for front-end developers... the primary people writing HTL files. While it's been mentioned several times this is an opt-in feature, I can see a scenario where Adobe adopts this model (via Core Components) and their customers start thinking this is best practice without understanding the development tooling hit they will take. Again, this is assuming what I said is true. I think this would be bad for the Apache Sling community. Now, if sling-ide-tooling moves to be CLI (which I think is underway?), this might be a non-issue. But with the above, and not good tooling around it, we would be moving away from "save and refresh" dev pipelines. It would be, "save, build, install, wait for bundle restart, refresh." On Thu, Apr 26, 2018 at 9:33 AM, Radu Cotescu <[email protected]> wrote: > Hi Jason, > > > On 26 Apr 2018, at 17:12, Jason E Bailey <[email protected]> wrote: > > > > That ability to overlay scripts and the ability to modify or correct a > third party implementation is something I use more then I should. > > > > Saying that, from my initial look through it looks like I would still be > able to overlay, it just wouldn't necessarily be as straightforward as the > previous method. > > You are right - overlaying wouldn’t work. By overlay we understand placing > a script in a search path with a higher priority. I personally find > overlaying a questionable technique, since you have the potential of > breaking all the other consumers of the overlaid resource type without even > knowing. > > However, you now have a very powerful extension mechanism - see item 5 > from the definition of a “sling.resourceType” capability [2]. With this > mechanism you know at deploy time if your extension actually works since > the framework will start your scripting bundle only if all of its > requirements are met. In this case, a resource type you extend is a > required capability, whereas your new resource type is a provided > capability. With the traditional scripting model (scripts deployed in the > repository in the search paths) you’d have to wait until run time to figure > out if your extension worked or not. Extends is similar to > “sling:resourceSuperType”. See an example at [3]. > > Cheers, > Radu > > [2] - https://github.com/apache/sling-whiteboard/tree/master/ > scripting-resolver/org-apache-sling-scripting-resolver#how < > https://github.com/apache/sling-whiteboard/tree/master/ > scripting-resolver/org-apache-sling-scripting-resolver#how> > [3] - https://github.com/apache/sling-whiteboard/blob/master/ > scripting-resolver/examples/org-apache-sling-scripting- > examplebundle.hi/src/main/resources/javax.script/org. > apache.sling.scripting.examplebundle.hi/1.0.0/extends < > https://github.com/apache/sling-whiteboard/blob/master/ > scripting-resolver/examples/org-apache-sling-scripting- > examplebundle.hi/src/main/resources/javax.script/org. > apache.sling.scripting.examplebundle.hi/1.0.0/extends>
