sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radu Cotescu <r...@apache.org>
Subject Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Date Fri, 27 Apr 2018 07:15:44 GMT
Hi Chris,

> On 26 Apr 2018, at 19:26, Chris Millar <cmillar@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



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message