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

2018-04-30 Thread Radu Cotescu
Hi Stefan, > On 27 Apr 2018, at 23:29, Stefan Seifert 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 y

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

2018-04-27 Thread Stefan Seifert
included and served from this bundle? stefan >-Original Message- >From: Radu Cotescu [mailto:r...@apache.org] >Sent: Thursday, April 26, 2018 11:34 AM >To: Sling Dev >Cc: pa...@apache.org >Subject: [proposal][osgi][scripting] redesigned scripts deployment and >resolutio

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

2018-04-27 Thread Bertrand Delacretaz
On Fri, Apr 27, 2018 at 11:37 AM, Karl Pauls 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

2018-04-27 Thread Karl Pauls
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

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

2018-04-27 Thread Carsten Ziegeler
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 somet

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

2018-04-27 Thread Robert Munteanu
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, "sa

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

2018-04-27 Thread Roy Teeuwen
> 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 e

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

2018-04-27 Thread Radu Cotescu
Hi Chris, > On 26 Apr 2018, at 19:26, Chris Millar 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 devel

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

2018-04-27 Thread Bertrand Delacretaz
Hi Chris, On Thu, Apr 26, 2018 at 7:26 PM, Chris Millar 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 ap

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

2018-04-26 Thread 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

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

2018-04-26 Thread Radu Cotescu
Hi Jason, > On 26 Apr 2018, at 17:12, Jason E Bailey 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 ov

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

2018-04-26 Thread Jason E Bailey
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 me

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

2018-04-26 Thread Radu Cotescu
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 m

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

2018-04-26 Thread Ioan Eugen Stan
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 t

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

2018-04-26 Thread Karl Pauls
On Thu, Apr 26, 2018 at 3:26 PM, Bertrand Delacretaz wrote: > On Thu, Apr 26, 2018 at 3:21 PM, Karl Pauls 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

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

2018-04-26 Thread Robert Munteanu
On Thu, 2018-04-26 at 15:26 +0200, Bertrand Delacretaz wrote: > On Thu, Apr 26, 2018 at 3:21 PM, Karl Pauls > 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 logi

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

2018-04-26 Thread Karl Pauls
On Thu, Apr 26, 2018 at 12:11 PM, Ioan Eugen Stan 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 i

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

2018-04-26 Thread Bertrand Delacretaz
On Thu, Apr 26, 2018 at 3:21 PM, Karl Pauls 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 bu

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

2018-04-26 Thread Karl Pauls
On Thu, Apr 26, 2018 at 3:06 PM, Jason E Bailey 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

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

2018-04-26 Thread Karl Pauls
On Thu, Apr 26, 2018 at 2:53 PM, Bertrand Delacretaz wrote: > Hi Radu, > > On Thu, Apr 26, 2018 at 11:34 AM, Radu Cotescu 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 scrip

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

2018-04-26 Thread Jason E Bailey
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 Co

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

2018-04-26 Thread Bertrand Delacretaz
Hi Radu, On Thu, Apr 26, 2018 at 11:34 AM, Radu Cotescu 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

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

2018-04-26 Thread Radu Cotescu
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 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

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

2018-04-26 Thread Ioan Eugen Stan
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 developin

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

2018-04-26 Thread Radu Cotescu
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