sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Süß <dominik.su...@gmail.com>
Subject Re: [feature model] Format of text section - repoinit and others
Date Wed, 10 Jan 2018 21:27:58 GMT
Hi,

I personally think 1 & 2 have their advantages - externalizing rather
complex repoinit setups with dozens of statements might make sense to keep
the feature model overall better readable. So I would personally opt for
both options.

Cheers
Dominik

On Mon, Jan 8, 2018 at 2:11 PM, Carsten Ziegeler <cziegeler@apache.org>
wrote:

> Hi,
>
> good point, I don't like the second option as I prefer having everything
> in a single file. The third option would introduce a special format per
> extension which then might need special rules/implementation for merging
> two modules or handling inheritance/includes.
>
> Which leaves us with the first option :)
>
> I think parsing this is easy: if it's in array simply concat the values
> and apply newlines in between. In the same way we could write out a text
> value: we split the text by newlines and create an array out of it.
>
> Regards
>
> Carsten
>
>
> Robert Munteanu wrote
> > Hi,
> >
> > While working some more with the feature model I realized that text
> > sections can not contain newlines - this is a limitation of JSON.
> >
> > This makes it very hard to work with repoinit sections. I end up with
> > (literally) 10k characters on a single line. Diffs are going to be
> > interesting with such formats :-)
> >
> > I think it would help adoption a lot if we have a more friendly format
> > for text entries.
> >
> > One option would be to have lines stored as an array, e.g.
> >
> >   "repoinit:TEXT|false": [
> >       "create path (sling:Folder) /libs",
> >       "create path (sling:Folder) /apps",
> >       "create path (sling:Folder) /tmp"
> >   ]
> >
> > Not that nice, but it keeps the file self-contained.
> >
> > Another option would be to keep a secondary text file around and
> > introduce a new field type, file:
> >
> >   "repoinit:FILE": "./repoinit.txt"
> >
> > This has the disadvantage of no longer having the configuration be
> > self-contained, but on the other hand it's a text file, which the
> > repoinit format was built for.
> >
> > The third option - for the sake of being complete - is to have a
> > structured JSON format for repoint, but IMO that's overkill. Something
> > like:
> >
> >   "repoinit": {
> >       "paths": [
> >               "/libs (sling:Folder)",
> >               "/apps (sling:Folder)",
> >               "/tmp (sling:Folder)"
> >       ]
> >    }
> >
> > Thoughts? I think the feature model approach is great, but we need to
> > improve on the usability of text sections.
> >
> > Thanks,
> >
> > Robert
> >
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>

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