You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Radu Cotescu <ra...@apache.org> on 2018/04/26 09:34:20 UTC
[proposal][osgi][scripting] redesigned scripts deployment and
resolution
Hello Sling devs,
Karl and I have been working for the past weeks on a new scripting prototype that we've now pushed to the Whiteboard [1]. The module is an add-on that allows developers to deploy scripts through bundles, with the following core features:
standalone module that doesn't require any changes in Sling's current APIs
bundles that provide scripts are wired to this add-on and then the add-on registers servlets on behalf of the scripting bundles (one servlet / script)
resource types can now be versioned (they're expressed as OSGi capabilities)
resource types can have explicit dependencies to other resource types, and everything is controlled by the wiring provided by the OSGi framework
For the full details please check the documentation provided at [1]. We're very interested in your opinions about this module, since we’d like to integrate it into the next Sling Starter release.
Thanks,
Radu and Karl
[1] - https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver <https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver>
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Radu Cotescu <ra...@apache.org>.
Hi,
What do you mean here? Can you give me a simple example of how such a node would look like?
Thanks,
Radu
> On 26 Apr 2018, at 12:11, Ioan Eugen Stan <ie...@netdava.com> wrote:
>
> If that is so, I
> might suggest a solution where we can add Require/Provide to a JCR node
> of a special type and that might be deployed as a bundle. I imagine that
> such a node will mostly nly Require and not Provide a lot of things
> since it's goal would be to render Pages.
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Ioan Eugen Stan <ie...@netdava.com>.
Thank you for your explanations Karl.
I think having both is a great thing. For once, you can explore using
the traditional, versioneless way. Once you solve the problem fast and
dirty you can move to the more elegant way of vearsioning the scripts.
So your solution could be an upgrade path for traditional scripts. I
think it is important if developers are informed about their choices here.
Regards,
On 26.04.2018 16:29, Karl Pauls wrote:
> On Thu, Apr 26, 2018 at 12:11 PM, Ioan Eugen Stan <ie...@netdava.com> wrote:
>> Hello Radu,
>>
>> I've read the project description and I like the direction in which you
>> are going. I believe being able to add constraints to code will make
>> things more clear.
>>
>> I do wish to ask something: I like the idea described in Sling in 15 min
>> [1]. I believe it's a very powerful way of developing pages and working
>> only on layout. Is this something that is going to go away?
> I doubt it :-)
>
>> Will I be forced to push scripts only via a bundle?
> No, for now this is a pure add-on that will not impact anything but
> allow you to push scripts via bundles as well (in which case you get
> the ability to version your scripts and have them have dependencies).
>
>> If that is so, I
>> might suggest a solution where we can add Require/Provide to a JCR node
>> of a special type and that might be deployed as a bundle. I imagine that
>> such a node will mostly nly Require and not Provide a lot of things
>> since it's goal would be to render Pages.
>>
>> I hope I understood correctly the issue and I'm not barking up the wrong
>> tree :).
> I think the point here is that while the current way of having scripts
> in the repository is great for some things, it has drawbacks in some
> other areas (mostly when it comes to deployment and maintainability).
> This is an attempt to marry the two by still allowing you the former
> and providing an optional solution for the latter while maintaining
> full interoperability.
>
> regards,
>
> Karl
>
>> Regards,
>>
>> [1]
>> https://sling.apache.org/documentation/getting-started/discover-sling-in-15-minutes.html
>>
>>
>> On 26.04.2018 12:34, Radu Cotescu wrote:
>>> Hello Sling devs,
>>>
>>> Karl and I have been working for the past weeks on a new scripting prototype that we've now pushed to the Whiteboard [1]. The module is an add-on that allows developers to deploy scripts through bundles, with the following core features:
>>> standalone module that doesn't require any changes in Sling's current APIs
>>> bundles that provide scripts are wired to this add-on and then the add-on registers servlets on behalf of the scripting bundles (one servlet / script)
>>> resource types can now be versioned (they're expressed as OSGi capabilities)
>>> resource types can have explicit dependencies to other resource types, and everything is controlled by the wiring provided by the OSGi framework
>>> For the full details please check the documentation provided at [1]. We're very interested in your opinions about this module, since we’d like to integrate it into the next Sling Starter release.
>>>
>>> Thanks,
>>> Radu and Karl
>>>
>>> [1] - https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver <https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver>
>>
>
>
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Karl Pauls <ka...@gmail.com>.
On Thu, Apr 26, 2018 at 12:11 PM, Ioan Eugen Stan <ie...@netdava.com> wrote:
> Hello Radu,
>
> I've read the project description and I like the direction in which you
> are going. I believe being able to add constraints to code will make
> things more clear.
>
> I do wish to ask something: I like the idea described in Sling in 15 min
> [1]. I believe it's a very powerful way of developing pages and working
> only on layout. Is this something that is going to go away?
I doubt it :-)
> Will I be forced to push scripts only via a bundle?
No, for now this is a pure add-on that will not impact anything but
allow you to push scripts via bundles as well (in which case you get
the ability to version your scripts and have them have dependencies).
> If that is so, I
> might suggest a solution where we can add Require/Provide to a JCR node
> of a special type and that might be deployed as a bundle. I imagine that
> such a node will mostly nly Require and not Provide a lot of things
> since it's goal would be to render Pages.
>
> I hope I understood correctly the issue and I'm not barking up the wrong
> tree :).
I think the point here is that while the current way of having scripts
in the repository is great for some things, it has drawbacks in some
other areas (mostly when it comes to deployment and maintainability).
This is an attempt to marry the two by still allowing you the former
and providing an optional solution for the latter while maintaining
full interoperability.
regards,
Karl
> Regards,
>
> [1]
> https://sling.apache.org/documentation/getting-started/discover-sling-in-15-minutes.html
>
>
> On 26.04.2018 12:34, Radu Cotescu wrote:
>> Hello Sling devs,
>>
>> Karl and I have been working for the past weeks on a new scripting prototype that we've now pushed to the Whiteboard [1]. The module is an add-on that allows developers to deploy scripts through bundles, with the following core features:
>> standalone module that doesn't require any changes in Sling's current APIs
>> bundles that provide scripts are wired to this add-on and then the add-on registers servlets on behalf of the scripting bundles (one servlet / script)
>> resource types can now be versioned (they're expressed as OSGi capabilities)
>> resource types can have explicit dependencies to other resource types, and everything is controlled by the wiring provided by the OSGi framework
>> For the full details please check the documentation provided at [1]. We're very interested in your opinions about this module, since we’d like to integrate it into the next Sling Starter release.
>>
>> Thanks,
>> Radu and Karl
>>
>> [1] - https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver <https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver>
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Ioan Eugen Stan <ie...@netdava.com>.
Hello Radu,
I've read the project description and I like the direction in which you
are going. I believe being able to add constraints to code will make
things more clear.
I do wish to ask something: I like the idea described in Sling in 15 min
[1]. I believe it's a very powerful way of developing pages and working
only on layout. Is this something that is going to go away?
Will I be forced to push scripts only via a bundle? If that is so, I
might suggest a solution where we can add Require/Provide to a JCR node
of a special type and that might be deployed as a bundle. I imagine that
such a node will mostly nly Require and not Provide a lot of things
since it's goal would be to render Pages.
I hope I understood correctly the issue and I'm not barking up the wrong
tree :).
Regards,
[1]
https://sling.apache.org/documentation/getting-started/discover-sling-in-15-minutes.html
On 26.04.2018 12:34, Radu Cotescu wrote:
> Hello Sling devs,
>
> Karl and I have been working for the past weeks on a new scripting prototype that we've now pushed to the Whiteboard [1]. The module is an add-on that allows developers to deploy scripts through bundles, with the following core features:
> standalone module that doesn't require any changes in Sling's current APIs
> bundles that provide scripts are wired to this add-on and then the add-on registers servlets on behalf of the scripting bundles (one servlet / script)
> resource types can now be versioned (they're expressed as OSGi capabilities)
> resource types can have explicit dependencies to other resource types, and everything is controlled by the wiring provided by the OSGi framework
> For the full details please check the documentation provided at [1]. We're very interested in your opinions about this module, since we’d like to integrate it into the next Sling Starter release.
>
> Thanks,
> Radu and Karl
>
> [1] - https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver <https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver>
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Karl Pauls <ka...@gmail.com>.
On Thu, Apr 26, 2018 at 2:53 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi Radu,
>
> On Thu, Apr 26, 2018 at 11:34 AM, Radu Cotescu <ra...@apache.org> wrote:
>> ...The module is an add-on that allows developers to deploy scripts through bundles...
>
> Thanks for this, interesting!
>
> IIUC it is then possible for a script coming from the repository and
> another one coming from your module to be "mounted" to the same
> resource type, HTTP method etc.
Yes, just like today it can come already from the repository and a servlet.
> Is there a deterministic choice of which scripts "wins" in such a
> case? Maybe that concern is outside of your module and belongs to the
> general script/servlets resolving mechanism - I forgot how that's
> handled there.
Thats the nice part about it. This is a pure add-on that uses only the
normal sling resource type handling. As such, it is fully compatible
with what is available today.
In your case, as you already guessed, that is purely part of how sling
handles the case of two providers for the same resource type.
> Also (and as usual ;-) I am a bit skeptical about the module's name -
> I think we already have a scripts resolver, and your new module is
> more specific than that. How about naming it "bundled scripts
> extension", "script bundler" or something like that that's more
> specific?
Yeah, the name could be improved (I'm well-known for being terrible at
naming things :-)
regards,
Karl
> -Bertrand
--
Karl Pauls
karlpauls@gmail.com
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Radu,
On Thu, Apr 26, 2018 at 11:34 AM, Radu Cotescu <ra...@apache.org> wrote:
> ...The module is an add-on that allows developers to deploy scripts through bundles...
Thanks for this, interesting!
IIUC it is then possible for a script coming from the repository and
another one coming from your module to be "mounted" to the same
resource type, HTTP method etc.
Is there a deterministic choice of which scripts "wins" in such a
case? Maybe that concern is outside of your module and belongs to the
general script/servlets resolving mechanism - I forgot how that's
handled there.
Also (and as usual ;-) I am a bit skeptical about the module's name -
I think we already have a scripts resolver, and your new module is
more specific than that. How about naming it "bundled scripts
extension", "script bundler" or something like that that's more
specific?
-Bertrand
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Radu Cotescu <ra...@apache.org>.
Hi Stefan,
> On 27 Apr 2018, at 23:29, Stefan Seifert <ss...@pro-vision.de> wrote:
>
> i think running scripts directly from the bundle without having to import it into the repository is a big advantage for complex projects.
> i hope this capability mechanism squales well when you have thousands of scripts in your system.
The only extra object we have, compared to a script in the repository, is a servlet registration. However, there are two major advantages that this architecture brings in terms of performance / flow:
we’ve eliminated repository look-ups for script resolution, reducing the pressure on Oak for things that are not actually content
there’s no need to maintain an external ScriptCache [4], with 3 ways of invalidation; if the ScriptCache is not needed we again optimise the flow in a Sling application by not needing yet another ResourceChangeListener / EventHandler
>
> on questions concering scripts & java classes accessed from the scripts (e.g. HTL script accessing a sling model):
> - in the current scenario it's required to export all model classes via OSGi to be able to use them from the HTL script
> - is it possibe with this new approach to keep them private to the bundle, and still use them from the scripts included and served from this bundle?
>
> stefan
True. This was more or less my decision, in order to unify the behaviours of the JavaUseProvider [5] and SlingModelsUseProvider [6]. If at some point we decide to use this new scripting add-on we can obviously enhance the SlingModelsUseProvider to use the script’s bundle class loader for trying to load a model. At the same time some of the scripting engines might need to also be adapted to work better with this way of resolving scripts.
Regards,
Radu
[4] - https://github.com/apache/sling-org-apache-sling-scripting-core/blob/master/src/main/java/org/apache/sling/scripting/core/impl/ScriptCacheImpl.java <https://github.com/apache/sling-org-apache-sling-scripting-core/blob/master/src/main/java/org/apache/sling/scripting/core/impl/ScriptCacheImpl.java>
[5] - https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/master/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/use/JavaUseProvider.java <https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/master/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/use/JavaUseProvider.java>
[6] - https://github.com/apache/sling-org-apache-sling-scripting-sightly-models-provider/blob/master/src/main/java/org/apache/sling/scripting/sightly/models/impl/SlingModelsUseProvider.java <https://github.com/apache/sling-org-apache-sling-scripting-sightly-models-provider/blob/master/src/main/java/org/apache/sling/scripting/sightly/models/impl/SlingModelsUseProvider.java>
RE: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Stefan Seifert <ss...@pro-vision.de>.
i think running scripts directly from the bundle without having to import it into the repository is a big advantage for complex projects.
i hope this capability mechanism squales well when you have thousands of scripts in your system.
on questions concering scripts & java classes accessed from the scripts (e.g. HTL script accessing a sling model):
- in the current scenario it's required to export all model classes via OSGi to be able to use them from the HTL script
- is it possibe with this new approach to keep them private to the bundle, and still use them from the scripts included and served from this bundle?
stefan
>-----Original Message-----
>From: Radu Cotescu [mailto:radu@apache.org]
>Sent: Thursday, April 26, 2018 11:34 AM
>To: Sling Dev
>Cc: pauls@apache.org
>Subject: [proposal][osgi][scripting] redesigned scripts deployment and
>resolution
>
>Hello Sling devs,
>
>Karl and I have been working for the past weeks on a new scripting
>prototype that we've now pushed to the Whiteboard [1]. The module is an
>add-on that allows developers to deploy scripts through bundles, with the
>following core features:
>standalone module that doesn't require any changes in Sling's current APIs
>bundles that provide scripts are wired to this add-on and then the add-on
>registers servlets on behalf of the scripting bundles (one servlet /
>script)
>resource types can now be versioned (they're expressed as OSGi
>capabilities)
>resource types can have explicit dependencies to other resource types, and
>everything is controlled by the wiring provided by the OSGi framework
>For the full details please check the documentation provided at [1]. We're
>very interested in your opinions about this module, since we’d like to
>integrate it into the next Sling Starter release.
>
>Thanks,
>Radu and Karl
>
>[1] - https://github.com/apache/sling-whiteboard/tree/master/scripting-
>resolver <https://github.com/apache/sling-whiteboard/tree/master/scripting-
>resolver>
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Radu Cotescu <ra...@apache.org>.
Hi,
Since the initial message created quite a stir and since I was offline when the reactions started coming up, I owe you some clarifications.
> There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.
The naming of the module might not be the most accurate; we’re going to have to think about it together if the module is ever going to “graduate” from the whiteboard. The thing is that the code does some script resolution, manages servlet registrations, manages request dispatches, etc.
As mentioned before the module is an add-on. It doesn’t change anything in Sling and installing it on an instance doesn’t cause any side effects. In order for this module to actually do something, bundles providing scripts have to be wired to it (by explicitly requiring one of the resolver’s capabilities) and on top of that these script bundles have to also provide a “sling.resourceType” capability plus scripts packed according to some conventions. When these conditions are met, then the resolver will register Sling servlets for the “sling.resourceType” capabilities it finds. Therefore, to answer Bertrand’s question, if two identical resource types will be registered from different places (e.g. repository scripts / servlets) the Sling engine is the one deciding which to use, based on the existing conventions.
What Karl and I have done is indeed a redesign of how scripting could work, but given that the module is an add-on one could still deploy scripts in both ways on an instance. We’ve done our best to document how things work with the add-on, so playing a bit with the provided examples [1] might clear some of the concerns / answer some of the questions.
However, please feel free to dissect the code and its purpose.
Regards,
Radu
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Chris,
On Thu, Apr 26, 2018 at 7:26 PM, Chris Millar <cm...@apache.org> wrote:
> ...customers start thinking this is best practice without understanding
> the development tooling hit they will take....
Good point, I think before declaring this new extension best practice
people should make sure they have the appropriate tooling.
-Bertrand
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2018-04-26 at 11:26 -0600, Chris Millar wrote:
> 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."
We'll eventually make the tooling work. And yes, we are (slowly) moving
away from an Eclipse-centric model to a set of tools that works in
Eclipse, CLI and hopefully IntelliJ.
Robert
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Radu Cotescu <ra...@apache.org>.
Hi Chris,
> On 26 Apr 2018, at 19:26, Chris Millar <cm...@apache.org> wrote:
>
> 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."
Nobody said we should blindly switch to exclusively using the add-on. Regarding tooling, while “save and refresh” works ok during the development stages, in production you want to make sure that your scripts actually work when deployed, not when they are already executed. I’m pretty sure that bndtools do provide some magic to hot-update a bundle and we could rely on this during development.
Currently the code Karl and I wrote is in the Whiteboard, and for a good reason: it’s an experiment; its purpose is to provide a glimpse into what could be done and how; it’s more or less a conversation starter. It needs a bit more tooling, but if you check the examples you’ll see that it’s pretty easy to deploy a script bundle (mvn clean sling:install).
I’m happy to see all these reactions and the number of replies we got. It means we’re on to something here.
Cheers,
Radu
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Apr 27, 2018 at 11:37 AM, Karl Pauls <ka...@gmail.com> wrote:
> ...It should be easy enough
> to create a "bridge" bundle that monitors folders in the repository
> and processes their content on change the same way the provided maven
> plugin does...
+1, that logic doesn't sound too complicated.
-Bertrand
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Karl Pauls <ka...@gmail.com>.
I agree with Carsten, this seems to be an implementation detail.
That said, this doesn't mean it is not important provided we would
think it can't be resolved in a reasonable way.
However, towards that end, I think that in the first place, it should
be easy enough to takle via tooling and in the second place, we could
even make it reasonable the same experience. It should be easy enough
to create a "bridge" bundle that monitors folders in the repository
and processes their content on change the same way the provided maven
plugin does. Subsequently, it would turn around and install/update a
surrogate bundle with the script and the metadata.
That way, you'd be back to where you've been before namely, save a
script, refresh, done.
The benefit too of such a bridge would be that it'd be yet another
add-on (to the add-on) - hence, if you don't install it in production
you don't have to worry about it (and provide the scripts via bundles)
while during development (or a funky - "we rewrite ourselfs
dynamically" - production) you can just install that bridge and work
on the scripts from the repository like today (just have to follow the
new layout).
regards,
Karl
On Fri, Apr 27, 2018 at 9:40 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> I think some comments here are *combining* the expected user experience
> with an expectation of how this is implemented or realized. While I
> totally understand and accept the reasoning behind this, I don't agree
> with combining those two.
>
> I think we all agree that the user experience should be something like
> you save your script and it's (nearly) immediately effective. What
> happens between that save and the script author verifying the change is
> imho irrelevant for the script author.
>
> The Sling IDE is already supporting such a workflow for developing a
> bundle: You change your java code, hit save and the bundle is
> automatically and instantly updated without any additional action of the
> developer. I think as long as we have a similar workflow for a script
> author it doesn't matter whether the script gets compiled, put into a
> bundle, is transferred through hyperspace or whatever. As long as this
> process is very fast and nearly not noticeable. And ideally such a
> workflow should not be tied to a special tooling, so supporting a save
> in any editor would be ideal.
>
> The proposed add-on solves some problems and if enhanced could
> potentially solve some other problems as well. I think it has a lot of
> potential. And I agree that the script author experience needs to be
> enhanced.
>
> Regards
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Karl Pauls
karlpauls@gmail.com
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Carsten Ziegeler <cz...@apache.org>.
I think some comments here are *combining* the expected user experience
with an expectation of how this is implemented or realized. While I
totally understand and accept the reasoning behind this, I don't agree
with combining those two.
I think we all agree that the user experience should be something like
you save your script and it's (nearly) immediately effective. What
happens between that save and the script author verifying the change is
imho irrelevant for the script author.
The Sling IDE is already supporting such a workflow for developing a
bundle: You change your java code, hit save and the bundle is
automatically and instantly updated without any additional action of the
developer. I think as long as we have a similar workflow for a script
author it doesn't matter whether the script gets compiled, put into a
bundle, is transferred through hyperspace or whatever. As long as this
process is very fast and nearly not noticeable. And ideally such a
workflow should not be tied to a special tooling, so supporting a save
in any editor would be ideal.
The proposed add-on solves some problems and if enhanced could
potentially solve some other problems as well. I think it has a lot of
potential. And I agree that the script author experience needs to be
enhanced.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Roy Teeuwen <ro...@teeuwen.be>.
> 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.
Completely agree with that Chris, we just got to a stage that we can get the frontend developers easily involved.
- Create HTML files
- Use for example Adobe Brackets or other sync tools to get those files into Sling / AEM
I also see that it says "scripts can be overlaid freely through the search path override or through the special sling:resourceSuperType property, complicating a developer's understanding of the script resolution mechanism". Why is this a bad this thing? I think this is one of the strong features of Sling. Making for example a base-page and then using resourceSuperType to make all the more specific pages through overlaying some specific HTL files.
> On 26 Apr 2018, at 19:26, Chris Millar <cm...@apache.org> wrote:
>
> 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 <ra...@apache.org> wrote:
>
>> Hi Jason,
>>
>>> On 26 Apr 2018, at 17:12, Jason E Bailey <je...@apache.org> 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>
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Chris Millar <cm...@apache.org>.
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 <ra...@apache.org> wrote:
> Hi Jason,
>
> > On 26 Apr 2018, at 17:12, Jason E Bailey <je...@apache.org> 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>
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Radu Cotescu <ra...@apache.org>.
Hi Jason,
> On 26 Apr 2018, at 17:12, Jason E Bailey <je...@apache.org> 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>
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Jason E Bailey <je...@apache.org>.
In the README three items are listed as the drivers around this add-on.
The item that concerned me was
* scripts can be overlaid freely through the search path override or through the special sling:resourceSuperType property, complicating a developer's understanding of the script resolution mechanism
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.
- Jason
On Thu, Apr 26, 2018, at 9:21 AM, Karl Pauls wrote:
> On Thu, Apr 26, 2018 at 3:06 PM, Jason E Bailey <ja...@24601.org> wrote:
> > I honestly have mixed emotions on this :) I can appreciate the need behind it, but the "problems" that you are fixing are some of the features that attracted me to Sling in the first place.
>
> Not sure I understand your concern correctly. Nothing is really
> changing in regard to how sling is working. You just put your
> resourceType on a resource and that is it. Likewise, you don't have to
> know (or care) about this when you dispatch from your own code. You
> just include/forward like you do today. Furthermore, you can still
> just provide your script via the repository (as it is right now - with
> no changes whatsoever).
>
> Only if you are creating scripts that you provide in this bundled
> fashion it impacts you and even then, it will for the most part be
> unnoticeable (plus give you the benefit of being able to version your
> scripts).
>
> However, I might be missing what your concern is...
>
> regards,
>
> Karl
>
> > I'm looking forward to putting it through it's paces.
> >
> > --
> > Jason
> >
> > On Thu, Apr 26, 2018, at 5:34 AM, Radu Cotescu wrote:
> >> Hello Sling devs,
> >>
> >> Karl and I have been working for the past weeks on a new scripting
> >> prototype that we've now pushed to the Whiteboard [1]. The module is an
> >> add-on that allows developers to deploy scripts through bundles, with
> >> the following core features:
> >> standalone module that doesn't require any changes in Sling's current
> >> APIs
> >> bundles that provide scripts are wired to this add-on and then the add-
> >> on registers servlets on behalf of the scripting bundles (one servlet /
> >> script)
> >> resource types can now be versioned (they're expressed as OSGi
> >> capabilities)
> >> resource types can have explicit dependencies to other resource types,
> >> and everything is controlled by the wiring provided by the OSGi
> >> framework
> >> For the full details please check the documentation provided at [1].
> >> We're very interested in your opinions about this module, since we’d
> >> like to integrate it into the next Sling Starter release.
> >>
> >> Thanks,
> >> Radu and Karl
> >>
> >> [1] -
> >> https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver
> >> <https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2018-04-26 at 15:26 +0200, Bertrand Delacretaz wrote:
> On Thu, Apr 26, 2018 at 3:21 PM, Karl Pauls <ka...@gmail.com>
> wrote:
> > ...Nothing is really
> > changing in regard to how sling is working....
>
> Also, this is new module is optional, and even if installed it has
> IIUC no impact on existing logic and script resolution - so I think
> it's a different way of doing things but does not remove anything
> from
> how Sling works today.
The confusion might come from the fact that the title is 'redesigned
script deployment and resolution', which can be seen as a replacement
for current status, rather than an add-on.
Robert
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Karl Pauls <ka...@gmail.com>.
On Thu, Apr 26, 2018 at 3:26 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Thu, Apr 26, 2018 at 3:21 PM, Karl Pauls <ka...@gmail.com> wrote:
>> ...Nothing is really
>> changing in regard to how sling is working....
>
> Also, this is new module is optional, and even if installed it has
> IIUC no impact on existing logic and script resolution - so I think
> it's a different way of doing things but does not remove anything from
> how Sling works today.
Exactly.
This is underlined by the fact that it only uses mechanisms provided
by sling. In other words, there is nothing preventing you from using
the add-on in an exiting sling right now without updating any of the
exiting sling bundles.
regards,
Karl
> -Bertrand
--
Karl Pauls
karlpauls@gmail.com
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Apr 26, 2018 at 3:21 PM, Karl Pauls <ka...@gmail.com> wrote:
> ...Nothing is really
> changing in regard to how sling is working....
Also, this is new module is optional, and even if installed it has
IIUC no impact on existing logic and script resolution - so I think
it's a different way of doing things but does not remove anything from
how Sling works today.
-Bertrand
Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Posted by Karl Pauls <ka...@gmail.com>.
On Thu, Apr 26, 2018 at 3:06 PM, Jason E Bailey <ja...@24601.org> wrote:
> I honestly have mixed emotions on this :) I can appreciate the need behind it, but the "problems" that you are fixing are some of the features that attracted me to Sling in the first place.
Not sure I understand your concern correctly. Nothing is really
changing in regard to how sling is working. You just put your
resourceType on a resource and that is it. Likewise, you don't have to
know (or care) about this when you dispatch from your own code. You
just include/forward like you do today. Furthermore, you can still
just provide your script via the repository (as it is right now - with
no changes whatsoever).
Only if you are creating scripts that you provide in this bundled
fashion it impacts you and even then, it will for the most part be
unnoticeable (plus give you the benefit of being able to version your
scripts).
However, I might be missing what your concern is...
regards,
Karl
> I'm looking forward to putting it through it's paces.
>
> --
> Jason
>
> On Thu, Apr 26, 2018, at 5:34 AM, Radu Cotescu wrote:
>> Hello Sling devs,
>>
>> Karl and I have been working for the past weeks on a new scripting
>> prototype that we've now pushed to the Whiteboard [1]. The module is an
>> add-on that allows developers to deploy scripts through bundles, with
>> the following core features:
>> standalone module that doesn't require any changes in Sling's current
>> APIs
>> bundles that provide scripts are wired to this add-on and then the add-
>> on registers servlets on behalf of the scripting bundles (one servlet /
>> script)
>> resource types can now be versioned (they're expressed as OSGi
>> capabilities)
>> resource types can have explicit dependencies to other resource types,
>> and everything is controlled by the wiring provided by the OSGi
>> framework
>> For the full details please check the documentation provided at [1].
>> We're very interested in your opinions about this module, since we’d
>> like to integrate it into the next Sling Starter release.
>>
>> Thanks,
>> Radu and Karl
>>
>> [1] -
>> https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver
>> <https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver>
--
Karl Pauls
karlpauls@gmail.com
Re: [proposal][osgi][scripting] redesigned scripts deployment and
resolution
Posted by Jason E Bailey <ja...@24601.org>.
I honestly have mixed emotions on this :) I can appreciate the need behind it, but the "problems" that you are fixing are some of the features that attracted me to Sling in the first place.
I'm looking forward to putting it through it's paces.
--
Jason
On Thu, Apr 26, 2018, at 5:34 AM, Radu Cotescu wrote:
> Hello Sling devs,
>
> Karl and I have been working for the past weeks on a new scripting
> prototype that we've now pushed to the Whiteboard [1]. The module is an
> add-on that allows developers to deploy scripts through bundles, with
> the following core features:
> standalone module that doesn't require any changes in Sling's current
> APIs
> bundles that provide scripts are wired to this add-on and then the add-
> on registers servlets on behalf of the scripting bundles (one servlet /
> script)
> resource types can now be versioned (they're expressed as OSGi
> capabilities)
> resource types can have explicit dependencies to other resource types,
> and everything is controlled by the wiring provided by the OSGi
> framework
> For the full details please check the documentation provided at [1].
> We're very interested in your opinions about this module, since we’d
> like to integrate it into the next Sling Starter release.
>
> Thanks,
> Radu and Karl
>
> [1] -
> https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver
> <https://github.com/apache/sling-whiteboard/tree/master/scripting-resolver>