sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <>
Subject Re: How to manage repoinit language + implementation evolutions?
Date Tue, 02 Oct 2018 05:46:44 GMT
Can’t we stay BC and just introduce a new command that has the new behavior
and keep the old one as is?

Something like:


or similar would be consistent with the service user delete at least.

It seems like a lot of hazel down the line to break the language and
introduce a version management just because of this issue. Just introduce
new command(s) and keep the old one(s) around (potentially with a warn)
seems nicer to me.



On Tuesday, October 2, 2018, Carsten Ziegeler <> wrote:

> Bertrand Delacretaz wrote:
> > Hi,
> >
> > We have a concrete case in SLING-7960 where a repoinit bug needs
> > fixing in a way that won't be fully compatible with the existing
> > implementation.
> > The difference is minor but still means it's a good time to define
> > how we'll handle language evolutions.
> > The problem is that the DELETE USER statement currently also deletes
> > system users, and that's wrong considering that there is also a DELETE
> > SERVICE USER statement. So fixing that bug will change the behavior of
> > existing repoinit scripts that use those statements.  Here's a
> > suggestion on how to handle this evolution, by optionally marking
> > repoinit scripts to require a specific language + implementation
> > version. I think those should be expressed as OSGi capabilities.
> >
> > 1) Repoinit scripts can optionally include a statement like
> >    REQUIRE VERSION language=1.0, jcr=1.2
> Why do we need two things here (version and jcr)?
> > 2) If that statement is not included, versions default to the
> >    currently released ones, before the SLING-7960 bug fix.
> > 3) Java code that executes the repoinit statements is made aware of
> >    those versions
> > 4) For the SLING-7960 code, the behavior is how it was before fixing
> >    this bug, unless REQUIRE VERSION points to a newer jcr module
> >    version  This is just initial ideas, what do people think?
> I guess this could work, however, there is one important additional
> thing to consider. Today you can concatenate several repoinit statement
> blocks to create one large repoinit instruction set. This is done by all
> the tooling around repoinit, provisioning model, feature model etc.
> With a optional version statement at the top, simply chaining repoinit
> blocks is not possible anymore. The tooling would need to check whether
> a version statement is there, if not put one there for our first
> version. And the parser would need to accept version statements anywhere
> in the repoinit text where that version is then used for all following
> statements until another version is mentioned
> Regards
> Carsten
> > -Bertrand
> --
> Carsten Ziegeler
> Adobe Research Switzerland

Karl Pauls

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