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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
25 matches
Mail list logo
