[proposal][osgi][scripting] redesigned scripts deployment and resolution

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[proposal][osgi][scripting] redesigned scripts deployment and resolution

Radu Cotescu-3
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>
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Eugen Stan-2
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>


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Radu Cotescu-3
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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Bertrand Delacretaz
In reply to this post by Radu Cotescu-3
Hi Radu,

On Thu, Apr 26, 2018 at 11:34 AM, Radu Cotescu <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Jason E Bailey
In reply to this post by Radu Cotescu-3
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>
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Karl Pauls
In reply to this post by Bertrand Delacretaz
On Thu, Apr 26, 2018 at 2:53 PM, Bertrand Delacretaz
<[hidden email]> wrote:

> Hi Radu,
>
> On Thu, Apr 26, 2018 at 11:34 AM, Radu Cotescu <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Karl Pauls
In reply to this post by Jason E Bailey
On Thu, Apr 26, 2018 at 3:06 PM, Jason E Bailey <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Bertrand Delacretaz
On Thu, Apr 26, 2018 at 3:21 PM, Karl Pauls <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Karl Pauls
In reply to this post by Eugen Stan-2
On Thu, Apr 26, 2018 at 12:11 PM, Ioan Eugen Stan <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Robert Munteanu-2
In reply to this post by Bertrand Delacretaz
On Thu, 2018-04-26 at 15:26 +0200, Bertrand Delacretaz wrote:

> On Thu, Apr 26, 2018 at 3:21 PM, Karl Pauls <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Karl Pauls
In reply to this post by Bertrand Delacretaz
On Thu, Apr 26, 2018 at 3:26 PM, Bertrand Delacretaz
<[hidden email]> wrote:
> On Thu, Apr 26, 2018 at 3:21 PM, Karl Pauls <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Eugen Stan-2
In reply to this post by Karl Pauls
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 <[hidden email]> 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>
>>
>
>


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Radu Cotescu-3
In reply to this post by Radu Cotescu-3
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


Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Jason E Bailey-2
In reply to this post by Karl Pauls
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 <[hidden email]> 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
> [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Radu Cotescu-3
Hi Jason,

> On 26 Apr 2018, at 17:12, Jason E Bailey <[hidden email]> 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>
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Chris Millar
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 <[hidden email]> wrote:

> Hi Jason,
>
> > On 26 Apr 2018, at 17:12, Jason E Bailey <[hidden email]> 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>
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Bertrand Delacretaz
Hi Chris,

On Thu, Apr 26, 2018 at 7:26 PM, Chris Millar <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Radu Cotescu-3
In reply to this post by Chris Millar
Hi Chris,

> On 26 Apr 2018, at 19:26, Chris Millar <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Roy Teeuwen
In reply to this post by Chris Millar
> 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 <[hidden email]> 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 <[hidden email]> wrote:
>
>> Hi Jason,
>>
>>> On 26 Apr 2018, at 17:12, Jason E Bailey <[hidden email]> 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>

Reply | Threaded
Open this post in threaded view
|

Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution

Robert Munteanu-2
In reply to this post by Chris Millar
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
12