You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2018/01/08 13:11:15 UTC
Re: [feature model] Format of text section - repoinit and others
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
Re: [feature model] Format of text section - repoinit and others
Posted by Carsten Ziegeler <cz...@apache.org>.
As soon as you have more than one file, packaging becomes a problem. How
do you easily distribute such a model, which files are needed, how do
you find them after unpacking etc.
Keep in mind, that repoinit is a Sling proprietary mechanism which is
not of general interest for an OSGi feature model. So I don't want to
complicate the general model for a small use case.
And one option should really be enough
Carsten
Dominik Süß wrote
> 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 <cz...@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
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [feature model] Format of text section - repoinit and others
Posted by Dominik Süß <do...@gmail.com>.
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 <cz...@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
>