You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2020/05/08 15:28:55 UTC
[feature-model] Different input format for feature files?
Hi,
I keep thinking about how the feature files would look like in a
different format. The main driver is the way repoinit statements look
at the moment. Comments are also a bit awkward, even though possible in
JSON.
I was looking at Jsonnet [1], which is a superset of JSON with lots of
bells and whistles, including comments and multiline strings.
But irrespective of format - Jsonnet, YAML, or something else - what
would it take to add another input format to the feature model? Is it
something can be easily plugged in or would it require a significant
rewrite?
Thanks,
Robert
[1]: https://jsonnet.org/
Re: [feature-model] Different input format for feature files?
Posted by Robert Munteanu <ro...@apache.org>.
On Sat, 2020-05-09 at 09:52 +0200, Carsten Ziegeler wrote:
> I actually start to like Daniels idea - we could easily externalize
> repoinit for maven based projects when reading the project files
> from
> disk. When they get deployed into the maven repository, repoinit is
> inlined. From this point on, usually only tooling is involved, so
> its
> fine if this is ugly json :)
>
> There is a minor downside to it, right now we have to do this in two
> places, the slingfeature maven plugin and the slingstart maven plugin
> as
> that allows to convert feature files to the provisioning model. But
> that's not such a big deal. And eventually we'll get rid of support
> for
> the provisioning model anyway.
+1
Robert
>
> Regards
> Carsten
>
> On 09.05.2020 01:50, Robert Munteanu wrote:
> > On Fri, 2020-05-08 at 18:58 +0200, Carsten Ziegeler wrote:
> > > We had that discussion twice in the past as well as the one about
> > > the
> > > format :)
> >
> > Right, I was not looking for a format change, JSON is in my mind
> > here
> > to stay. Just trying to understand what it would take to get
> > another
> > format as the source of truth.
> >
> > Right now the only option is for it to live the fully outside the
> > feature model tooling. Maybe I'll have time to experiment with such
> > a
> > Maven plugin setup, maybe not. But it's definitely not something
> > that
> > will impact the Sling Feature Model project.
> >
> > > If you have a reference, you need to manage that and make sure
> > > that
> > > you
> > > always transport two files (the feature model and the referenced
> > > repo
> > > init). This can get pretty complicated.
> >
> > Right, I remember that discussion and I think the argument for
> > having
> > self-contained feature definition files is solid.
> >
> > > Now, we could support this in the slingfeature maven plugin only
> > > -
> > > when
> > > reading a feature file; that would be fine. But once that feature
> > > is
> > > written, it will be written with the repoinit inlined.
> > >
> > > We deviate from the specified format there already by not
> > > requiring
> > > an
> > > id in the file, so this would be just another case.
> >
> > I don't have a strong opinion either way. I like self-contained
> > feature
> > files, and dislike how repoinit looks as JSON.
> >
> > Thanks,
> > Robert
> >
> > > Carsten
> > >
> > >
> > > On 08.05.2020 18:52, Daniel Klco wrote:
> > > > Would it be possible to externalize the repoinit files? I feel
> > > > like
> > > > that
> > > > would resolve a lot of the issues if you could instead
> > > > reference a
> > > > repoinit
> > > > file in the native format vs. embedding it into the JSON (which
> > > > I
> > > > agree is
> > > > a pain to read.
> > > >
> > > > On Fri, May 8, 2020 at 11:49 AM Robert Munteanu <
> > > > rombert@apache.org
> > > > > wrote:
> > > > > On Fri, 2020-05-08 at 17:47 +0200, Carsten Ziegeler wrote:
> > > > > > It's documented :)
> > > > > >
> > > > > >
> > > > > https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/features.md#feature-file-format
> > > > > > And yes, integrating a preprocessor in every place where we
> > > > > > today
> > > > > > read
> > > > > > feature files is another major undertaking.
> > > > >
> > > > > I was thinking more about having a Maven plugin running in
> > > > > the
> > > > > build
> > > > > before the slingfeature-maven-plugin starts to do its magic.
> > > > > This
> > > > > way
> > > > > there is no actual change to the sling feature model tooling.
> > > > >
> > > > >
> > > > > > And I think its a bad idea to support more than one format.
> > > > >
> > > > > But yes, a major undertaking and possibly a bad idea.
> > > > >
> > > > > Thanks,
> > > > > Robert
> > > > >
> > > > > > Regards
> > > > > > Carsten
> > > > > >
> > > > > > On 08.05.2020 17:44, Robert Munteanu wrote:
> > > > > > > Ok, probably not worth the effort :-)
> > > > > > >
> > > > > > > Thanks for the information about JSMin-style comments, I
> > > > > > > was
> > > > > > > not
> > > > > > > aware
> > > > > > > of that. I guess the downside is that IDEs/editors will
> > > > > > > complain,
> > > > > > > but
> > > > > > > that's a choice we can make.
> > > > > > >
> > > > > > > Thinking out loud - if we generate the JSON files from
> > > > > > > another
> > > > > > > format
> > > > > > > before passing them over to the feature launcher/analyser
> > > > > > > then we
> > > > > > > would
> > > > > > > be safe. But that's also not very easy I guess.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Robert
> > > > > > >
> > > > > > > On Fri, 2020-05-08 at 17:36 +0200, Carsten Ziegeler
> > > > > > > wrote:
> > > > > > > > It would be a significant effort, basically rewriting
> > > > > > > > everything
> > > > > > > > including all modules, extensions and tooling.
> > > > > > > >
> > > > > > > > Not sure if that is really worth the effort.
> > > > > > > >
> > > > > > > > Repoinit is a little bit of a pain, I agree. But I
> > > > > > > > don't
> > > > > > > > think
> > > > > > > > this
> > > > > > > > minor use case warrants such a dramatic change.
> > > > > > > >
> > > > > > > > For comments, you can use JSmin style comments (like
> > > > > > > > mentioned on
> > > > > > > > jsonnet), so I don't consider this an issue.
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > Carsten
> > > > > > > >
> > > > > > > > On 08.05.2020 17:28, Robert Munteanu wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I keep thinking about how the feature files would
> > > > > > > > > look
> > > > > > > > > like in
> > > > > > > > > a
> > > > > > > > > different format. The main driver is the way repoinit
> > > > > > > > > statements
> > > > > > > > > look
> > > > > > > > > at the moment. Comments are also a bit awkward, even
> > > > > > > > > though
> > > > > > > > > possible in
> > > > > > > > > JSON.
> > > > > > > > >
> > > > > > > > > I was looking at Jsonnet [1], which is a superset of
> > > > > > > > > JSON
> > > > > > > > > with
> > > > > > > > > lots
> > > > > > > > > of
> > > > > > > > > bells and whistles, including comments and multiline
> > > > > > > > > strings.
> > > > > > > > >
> > > > > > > > > But irrespective of format - Jsonnet, YAML, or
> > > > > > > > > something
> > > > > > > > > else -
> > > > > > > > > what
> > > > > > > > > would it take to add another input format to the
> > > > > > > > > feature
> > > > > > > > > model?
> > > > > > > > > Is
> > > > > > > > > it
> > > > > > > > > something can be easily plugged in or would it
> > > > > > > > > require a
> > > > > > > > > significant
> > > > > > > > > rewrite?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Robert
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [1]: https://jsonnet.org/
> > > > > > > > >
Re: [feature-model] Different input format for feature files?
Posted by Carsten Ziegeler <cz...@apache.org>.
I actually start to like Daniels idea - we could easily externalize
repoinit for maven based projects when reading the project files from
disk. When they get deployed into the maven repository, repoinit is
inlined. From this point on, usually only tooling is involved, so its
fine if this is ugly json :)
There is a minor downside to it, right now we have to do this in two
places, the slingfeature maven plugin and the slingstart maven plugin as
that allows to convert feature files to the provisioning model. But
that's not such a big deal. And eventually we'll get rid of support for
the provisioning model anyway.
Regards
Carsten
On 09.05.2020 01:50, Robert Munteanu wrote:
> On Fri, 2020-05-08 at 18:58 +0200, Carsten Ziegeler wrote:
>> We had that discussion twice in the past as well as the one about
>> the
>> format :)
>
> Right, I was not looking for a format change, JSON is in my mind here
> to stay. Just trying to understand what it would take to get another
> format as the source of truth.
>
> Right now the only option is for it to live the fully outside the
> feature model tooling. Maybe I'll have time to experiment with such a
> Maven plugin setup, maybe not. But it's definitely not something that
> will impact the Sling Feature Model project.
>
>>
>> If you have a reference, you need to manage that and make sure that
>> you
>> always transport two files (the feature model and the referenced
>> repo
>> init). This can get pretty complicated.
>
> Right, I remember that discussion and I think the argument for having
> self-contained feature definition files is solid.
>
>>
>> Now, we could support this in the slingfeature maven plugin only -
>> when
>> reading a feature file; that would be fine. But once that feature is
>> written, it will be written with the repoinit inlined.
>>
>> We deviate from the specified format there already by not requiring
>> an
>> id in the file, so this would be just another case.
>
> I don't have a strong opinion either way. I like self-contained feature
> files, and dislike how repoinit looks as JSON.
>
> Thanks,
> Robert
>
>>
>> Carsten
>>
>>
>> On 08.05.2020 18:52, Daniel Klco wrote:
>>> Would it be possible to externalize the repoinit files? I feel like
>>> that
>>> would resolve a lot of the issues if you could instead reference a
>>> repoinit
>>> file in the native format vs. embedding it into the JSON (which I
>>> agree is
>>> a pain to read.
>>>
>>> On Fri, May 8, 2020 at 11:49 AM Robert Munteanu <rombert@apache.org
>>>> wrote:
>>>
>>>> On Fri, 2020-05-08 at 17:47 +0200, Carsten Ziegeler wrote:
>>>>> It's documented :)
>>>>>
>>>>>
>>>> https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/features.md#feature-file-format
>>>>> And yes, integrating a preprocessor in every place where we
>>>>> today
>>>>> read
>>>>> feature files is another major undertaking.
>>>>
>>>> I was thinking more about having a Maven plugin running in the
>>>> build
>>>> before the slingfeature-maven-plugin starts to do its magic. This
>>>> way
>>>> there is no actual change to the sling feature model tooling.
>>>>
>>>>
>>>>> And I think its a bad idea to support more than one format.
>>>>
>>>> But yes, a major undertaking and possibly a bad idea.
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>>> Regards
>>>>> Carsten
>>>>>
>>>>> On 08.05.2020 17:44, Robert Munteanu wrote:
>>>>>> Ok, probably not worth the effort :-)
>>>>>>
>>>>>> Thanks for the information about JSMin-style comments, I was
>>>>>> not
>>>>>> aware
>>>>>> of that. I guess the downside is that IDEs/editors will
>>>>>> complain,
>>>>>> but
>>>>>> that's a choice we can make.
>>>>>>
>>>>>> Thinking out loud - if we generate the JSON files from
>>>>>> another
>>>>>> format
>>>>>> before passing them over to the feature launcher/analyser
>>>>>> then we
>>>>>> would
>>>>>> be safe. But that's also not very easy I guess.
>>>>>>
>>>>>> Thanks,
>>>>>> Robert
>>>>>>
>>>>>> On Fri, 2020-05-08 at 17:36 +0200, Carsten Ziegeler wrote:
>>>>>>> It would be a significant effort, basically rewriting
>>>>>>> everything
>>>>>>> including all modules, extensions and tooling.
>>>>>>>
>>>>>>> Not sure if that is really worth the effort.
>>>>>>>
>>>>>>> Repoinit is a little bit of a pain, I agree. But I don't
>>>>>>> think
>>>>>>> this
>>>>>>> minor use case warrants such a dramatic change.
>>>>>>>
>>>>>>> For comments, you can use JSmin style comments (like
>>>>>>> mentioned on
>>>>>>> jsonnet), so I don't consider this an issue.
>>>>>>>
>>>>>>> Regards
>>>>>>> Carsten
>>>>>>>
>>>>>>> On 08.05.2020 17:28, Robert Munteanu wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I keep thinking about how the feature files would look
>>>>>>>> like in
>>>>>>>> a
>>>>>>>> different format. The main driver is the way repoinit
>>>>>>>> statements
>>>>>>>> look
>>>>>>>> at the moment. Comments are also a bit awkward, even
>>>>>>>> though
>>>>>>>> possible in
>>>>>>>> JSON.
>>>>>>>>
>>>>>>>> I was looking at Jsonnet [1], which is a superset of JSON
>>>>>>>> with
>>>>>>>> lots
>>>>>>>> of
>>>>>>>> bells and whistles, including comments and multiline
>>>>>>>> strings.
>>>>>>>>
>>>>>>>> But irrespective of format - Jsonnet, YAML, or something
>>>>>>>> else -
>>>>>>>> what
>>>>>>>> would it take to add another input format to the feature
>>>>>>>> model?
>>>>>>>> Is
>>>>>>>> it
>>>>>>>> something can be easily plugged in or would it require a
>>>>>>>> significant
>>>>>>>> rewrite?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Robert
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]: https://jsonnet.org/
>>>>>>>>
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [feature-model] Different input format for feature files?
Posted by Robert Munteanu <ro...@apache.org>.
On Fri, 2020-05-08 at 18:58 +0200, Carsten Ziegeler wrote:
> We had that discussion twice in the past as well as the one about
> the
> format :)
Right, I was not looking for a format change, JSON is in my mind here
to stay. Just trying to understand what it would take to get another
format as the source of truth.
Right now the only option is for it to live the fully outside the
feature model tooling. Maybe I'll have time to experiment with such a
Maven plugin setup, maybe not. But it's definitely not something that
will impact the Sling Feature Model project.
>
> If you have a reference, you need to manage that and make sure that
> you
> always transport two files (the feature model and the referenced
> repo
> init). This can get pretty complicated.
Right, I remember that discussion and I think the argument for having
self-contained feature definition files is solid.
>
> Now, we could support this in the slingfeature maven plugin only -
> when
> reading a feature file; that would be fine. But once that feature is
> written, it will be written with the repoinit inlined.
>
> We deviate from the specified format there already by not requiring
> an
> id in the file, so this would be just another case.
I don't have a strong opinion either way. I like self-contained feature
files, and dislike how repoinit looks as JSON.
Thanks,
Robert
>
> Carsten
>
>
> On 08.05.2020 18:52, Daniel Klco wrote:
> > Would it be possible to externalize the repoinit files? I feel like
> > that
> > would resolve a lot of the issues if you could instead reference a
> > repoinit
> > file in the native format vs. embedding it into the JSON (which I
> > agree is
> > a pain to read.
> >
> > On Fri, May 8, 2020 at 11:49 AM Robert Munteanu <rombert@apache.org
> > > wrote:
> >
> > > On Fri, 2020-05-08 at 17:47 +0200, Carsten Ziegeler wrote:
> > > > It's documented :)
> > > >
> > > >
> > > https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/features.md#feature-file-format
> > > > And yes, integrating a preprocessor in every place where we
> > > > today
> > > > read
> > > > feature files is another major undertaking.
> > >
> > > I was thinking more about having a Maven plugin running in the
> > > build
> > > before the slingfeature-maven-plugin starts to do its magic. This
> > > way
> > > there is no actual change to the sling feature model tooling.
> > >
> > >
> > > > And I think its a bad idea to support more than one format.
> > >
> > > But yes, a major undertaking and possibly a bad idea.
> > >
> > > Thanks,
> > > Robert
> > >
> > > > Regards
> > > > Carsten
> > > >
> > > > On 08.05.2020 17:44, Robert Munteanu wrote:
> > > > > Ok, probably not worth the effort :-)
> > > > >
> > > > > Thanks for the information about JSMin-style comments, I was
> > > > > not
> > > > > aware
> > > > > of that. I guess the downside is that IDEs/editors will
> > > > > complain,
> > > > > but
> > > > > that's a choice we can make.
> > > > >
> > > > > Thinking out loud - if we generate the JSON files from
> > > > > another
> > > > > format
> > > > > before passing them over to the feature launcher/analyser
> > > > > then we
> > > > > would
> > > > > be safe. But that's also not very easy I guess.
> > > > >
> > > > > Thanks,
> > > > > Robert
> > > > >
> > > > > On Fri, 2020-05-08 at 17:36 +0200, Carsten Ziegeler wrote:
> > > > > > It would be a significant effort, basically rewriting
> > > > > > everything
> > > > > > including all modules, extensions and tooling.
> > > > > >
> > > > > > Not sure if that is really worth the effort.
> > > > > >
> > > > > > Repoinit is a little bit of a pain, I agree. But I don't
> > > > > > think
> > > > > > this
> > > > > > minor use case warrants such a dramatic change.
> > > > > >
> > > > > > For comments, you can use JSmin style comments (like
> > > > > > mentioned on
> > > > > > jsonnet), so I don't consider this an issue.
> > > > > >
> > > > > > Regards
> > > > > > Carsten
> > > > > >
> > > > > > On 08.05.2020 17:28, Robert Munteanu wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I keep thinking about how the feature files would look
> > > > > > > like in
> > > > > > > a
> > > > > > > different format. The main driver is the way repoinit
> > > > > > > statements
> > > > > > > look
> > > > > > > at the moment. Comments are also a bit awkward, even
> > > > > > > though
> > > > > > > possible in
> > > > > > > JSON.
> > > > > > >
> > > > > > > I was looking at Jsonnet [1], which is a superset of JSON
> > > > > > > with
> > > > > > > lots
> > > > > > > of
> > > > > > > bells and whistles, including comments and multiline
> > > > > > > strings.
> > > > > > >
> > > > > > > But irrespective of format - Jsonnet, YAML, or something
> > > > > > > else -
> > > > > > > what
> > > > > > > would it take to add another input format to the feature
> > > > > > > model?
> > > > > > > Is
> > > > > > > it
> > > > > > > something can be easily plugged in or would it require a
> > > > > > > significant
> > > > > > > rewrite?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Robert
> > > > > > >
> > > > > > >
> > > > > > > [1]: https://jsonnet.org/
> > > > > > >
Re: [feature-model] Different input format for feature files?
Posted by Carsten Ziegeler <cz...@apache.org>.
We had that discussion twice in the past as well as the one about the
format :)
If you have a reference, you need to manage that and make sure that you
always transport two files (the feature model and the referenced repo
init). This can get pretty complicated.
Now, we could support this in the slingfeature maven plugin only - when
reading a feature file; that would be fine. But once that feature is
written, it will be written with the repoinit inlined.
We deviate from the specified format there already by not requiring an
id in the file, so this would be just another case.
Carsten
On 08.05.2020 18:52, Daniel Klco wrote:
> Would it be possible to externalize the repoinit files? I feel like that
> would resolve a lot of the issues if you could instead reference a repoinit
> file in the native format vs. embedding it into the JSON (which I agree is
> a pain to read.
>
> On Fri, May 8, 2020 at 11:49 AM Robert Munteanu <ro...@apache.org> wrote:
>
>> On Fri, 2020-05-08 at 17:47 +0200, Carsten Ziegeler wrote:
>>> It's documented :)
>>>
>>>
>> https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/features.md#feature-file-format
>>>
>>> And yes, integrating a preprocessor in every place where we today
>>> read
>>> feature files is another major undertaking.
>>
>> I was thinking more about having a Maven plugin running in the build
>> before the slingfeature-maven-plugin starts to do its magic. This way
>> there is no actual change to the sling feature model tooling.
>>
>>
>>> And I think its a bad idea to support more than one format.
>>
>> But yes, a major undertaking and possibly a bad idea.
>>
>> Thanks,
>> Robert
>>
>>>
>>> Regards
>>> Carsten
>>>
>>> On 08.05.2020 17:44, Robert Munteanu wrote:
>>>> Ok, probably not worth the effort :-)
>>>>
>>>> Thanks for the information about JSMin-style comments, I was not
>>>> aware
>>>> of that. I guess the downside is that IDEs/editors will complain,
>>>> but
>>>> that's a choice we can make.
>>>>
>>>> Thinking out loud - if we generate the JSON files from another
>>>> format
>>>> before passing them over to the feature launcher/analyser then we
>>>> would
>>>> be safe. But that's also not very easy I guess.
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>> On Fri, 2020-05-08 at 17:36 +0200, Carsten Ziegeler wrote:
>>>>> It would be a significant effort, basically rewriting everything
>>>>> including all modules, extensions and tooling.
>>>>>
>>>>> Not sure if that is really worth the effort.
>>>>>
>>>>> Repoinit is a little bit of a pain, I agree. But I don't think
>>>>> this
>>>>> minor use case warrants such a dramatic change.
>>>>>
>>>>> For comments, you can use JSmin style comments (like mentioned on
>>>>> jsonnet), so I don't consider this an issue.
>>>>>
>>>>> Regards
>>>>> Carsten
>>>>>
>>>>> On 08.05.2020 17:28, Robert Munteanu wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I keep thinking about how the feature files would look like in
>>>>>> a
>>>>>> different format. The main driver is the way repoinit
>>>>>> statements
>>>>>> look
>>>>>> at the moment. Comments are also a bit awkward, even though
>>>>>> possible in
>>>>>> JSON.
>>>>>>
>>>>>> I was looking at Jsonnet [1], which is a superset of JSON with
>>>>>> lots
>>>>>> of
>>>>>> bells and whistles, including comments and multiline strings.
>>>>>>
>>>>>> But irrespective of format - Jsonnet, YAML, or something else -
>>>>>> what
>>>>>> would it take to add another input format to the feature model?
>>>>>> Is
>>>>>> it
>>>>>> something can be easily plugged in or would it require a
>>>>>> significant
>>>>>> rewrite?
>>>>>>
>>>>>> Thanks,
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> [1]: https://jsonnet.org/
>>>>>>
>>
>>
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [feature-model] Different input format for feature files?
Posted by Daniel Klco <dk...@apache.org>.
Would it be possible to externalize the repoinit files? I feel like that
would resolve a lot of the issues if you could instead reference a repoinit
file in the native format vs. embedding it into the JSON (which I agree is
a pain to read.
On Fri, May 8, 2020 at 11:49 AM Robert Munteanu <ro...@apache.org> wrote:
> On Fri, 2020-05-08 at 17:47 +0200, Carsten Ziegeler wrote:
> > It's documented :)
> >
> >
> https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/features.md#feature-file-format
> >
> > And yes, integrating a preprocessor in every place where we today
> > read
> > feature files is another major undertaking.
>
> I was thinking more about having a Maven plugin running in the build
> before the slingfeature-maven-plugin starts to do its magic. This way
> there is no actual change to the sling feature model tooling.
>
>
> > And I think its a bad idea to support more than one format.
>
> But yes, a major undertaking and possibly a bad idea.
>
> Thanks,
> Robert
>
> >
> > Regards
> > Carsten
> >
> > On 08.05.2020 17:44, Robert Munteanu wrote:
> > > Ok, probably not worth the effort :-)
> > >
> > > Thanks for the information about JSMin-style comments, I was not
> > > aware
> > > of that. I guess the downside is that IDEs/editors will complain,
> > > but
> > > that's a choice we can make.
> > >
> > > Thinking out loud - if we generate the JSON files from another
> > > format
> > > before passing them over to the feature launcher/analyser then we
> > > would
> > > be safe. But that's also not very easy I guess.
> > >
> > > Thanks,
> > > Robert
> > >
> > > On Fri, 2020-05-08 at 17:36 +0200, Carsten Ziegeler wrote:
> > > > It would be a significant effort, basically rewriting everything
> > > > including all modules, extensions and tooling.
> > > >
> > > > Not sure if that is really worth the effort.
> > > >
> > > > Repoinit is a little bit of a pain, I agree. But I don't think
> > > > this
> > > > minor use case warrants such a dramatic change.
> > > >
> > > > For comments, you can use JSmin style comments (like mentioned on
> > > > jsonnet), so I don't consider this an issue.
> > > >
> > > > Regards
> > > > Carsten
> > > >
> > > > On 08.05.2020 17:28, Robert Munteanu wrote:
> > > > > Hi,
> > > > >
> > > > > I keep thinking about how the feature files would look like in
> > > > > a
> > > > > different format. The main driver is the way repoinit
> > > > > statements
> > > > > look
> > > > > at the moment. Comments are also a bit awkward, even though
> > > > > possible in
> > > > > JSON.
> > > > >
> > > > > I was looking at Jsonnet [1], which is a superset of JSON with
> > > > > lots
> > > > > of
> > > > > bells and whistles, including comments and multiline strings.
> > > > >
> > > > > But irrespective of format - Jsonnet, YAML, or something else -
> > > > > what
> > > > > would it take to add another input format to the feature model?
> > > > > Is
> > > > > it
> > > > > something can be easily plugged in or would it require a
> > > > > significant
> > > > > rewrite?
> > > > >
> > > > > Thanks,
> > > > > Robert
> > > > >
> > > > >
> > > > > [1]: https://jsonnet.org/
> > > > >
>
>
Re: [feature-model] Different input format for feature files?
Posted by Robert Munteanu <ro...@apache.org>.
On Fri, 2020-05-08 at 17:47 +0200, Carsten Ziegeler wrote:
> It's documented :)
>
> https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/features.md#feature-file-format
>
> And yes, integrating a preprocessor in every place where we today
> read
> feature files is another major undertaking.
I was thinking more about having a Maven plugin running in the build
before the slingfeature-maven-plugin starts to do its magic. This way
there is no actual change to the sling feature model tooling.
> And I think its a bad idea to support more than one format.
But yes, a major undertaking and possibly a bad idea.
Thanks,
Robert
>
> Regards
> Carsten
>
> On 08.05.2020 17:44, Robert Munteanu wrote:
> > Ok, probably not worth the effort :-)
> >
> > Thanks for the information about JSMin-style comments, I was not
> > aware
> > of that. I guess the downside is that IDEs/editors will complain,
> > but
> > that's a choice we can make.
> >
> > Thinking out loud - if we generate the JSON files from another
> > format
> > before passing them over to the feature launcher/analyser then we
> > would
> > be safe. But that's also not very easy I guess.
> >
> > Thanks,
> > Robert
> >
> > On Fri, 2020-05-08 at 17:36 +0200, Carsten Ziegeler wrote:
> > > It would be a significant effort, basically rewriting everything
> > > including all modules, extensions and tooling.
> > >
> > > Not sure if that is really worth the effort.
> > >
> > > Repoinit is a little bit of a pain, I agree. But I don't think
> > > this
> > > minor use case warrants such a dramatic change.
> > >
> > > For comments, you can use JSmin style comments (like mentioned on
> > > jsonnet), so I don't consider this an issue.
> > >
> > > Regards
> > > Carsten
> > >
> > > On 08.05.2020 17:28, Robert Munteanu wrote:
> > > > Hi,
> > > >
> > > > I keep thinking about how the feature files would look like in
> > > > a
> > > > different format. The main driver is the way repoinit
> > > > statements
> > > > look
> > > > at the moment. Comments are also a bit awkward, even though
> > > > possible in
> > > > JSON.
> > > >
> > > > I was looking at Jsonnet [1], which is a superset of JSON with
> > > > lots
> > > > of
> > > > bells and whistles, including comments and multiline strings.
> > > >
> > > > But irrespective of format - Jsonnet, YAML, or something else -
> > > > what
> > > > would it take to add another input format to the feature model?
> > > > Is
> > > > it
> > > > something can be easily plugged in or would it require a
> > > > significant
> > > > rewrite?
> > > >
> > > > Thanks,
> > > > Robert
> > > >
> > > >
> > > > [1]: https://jsonnet.org/
> > > >
Re: [feature-model] Different input format for feature files?
Posted by Carsten Ziegeler <cz...@apache.org>.
It's documented :)
https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/features.md#feature-file-format
And yes, integrating a preprocessor in every place where we today read
feature files is another major undertaking.
And I think its a bad idea to support more than one format.
Regards
Carsten
On 08.05.2020 17:44, Robert Munteanu wrote:
> Ok, probably not worth the effort :-)
>
> Thanks for the information about JSMin-style comments, I was not aware
> of that. I guess the downside is that IDEs/editors will complain, but
> that's a choice we can make.
>
> Thinking out loud - if we generate the JSON files from another format
> before passing them over to the feature launcher/analyser then we would
> be safe. But that's also not very easy I guess.
>
> Thanks,
> Robert
>
> On Fri, 2020-05-08 at 17:36 +0200, Carsten Ziegeler wrote:
>> It would be a significant effort, basically rewriting everything
>> including all modules, extensions and tooling.
>>
>> Not sure if that is really worth the effort.
>>
>> Repoinit is a little bit of a pain, I agree. But I don't think this
>> minor use case warrants such a dramatic change.
>>
>> For comments, you can use JSmin style comments (like mentioned on
>> jsonnet), so I don't consider this an issue.
>>
>> Regards
>> Carsten
>>
>> On 08.05.2020 17:28, Robert Munteanu wrote:
>>> Hi,
>>>
>>> I keep thinking about how the feature files would look like in a
>>> different format. The main driver is the way repoinit statements
>>> look
>>> at the moment. Comments are also a bit awkward, even though
>>> possible in
>>> JSON.
>>>
>>> I was looking at Jsonnet [1], which is a superset of JSON with lots
>>> of
>>> bells and whistles, including comments and multiline strings.
>>>
>>> But irrespective of format - Jsonnet, YAML, or something else -
>>> what
>>> would it take to add another input format to the feature model? Is
>>> it
>>> something can be easily plugged in or would it require a
>>> significant
>>> rewrite?
>>>
>>> Thanks,
>>> Robert
>>>
>>>
>>> [1]: https://jsonnet.org/
>>>
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [feature-model] Different input format for feature files?
Posted by Robert Munteanu <ro...@apache.org>.
Ok, probably not worth the effort :-)
Thanks for the information about JSMin-style comments, I was not aware
of that. I guess the downside is that IDEs/editors will complain, but
that's a choice we can make.
Thinking out loud - if we generate the JSON files from another format
before passing them over to the feature launcher/analyser then we would
be safe. But that's also not very easy I guess.
Thanks,
Robert
On Fri, 2020-05-08 at 17:36 +0200, Carsten Ziegeler wrote:
> It would be a significant effort, basically rewriting everything
> including all modules, extensions and tooling.
>
> Not sure if that is really worth the effort.
>
> Repoinit is a little bit of a pain, I agree. But I don't think this
> minor use case warrants such a dramatic change.
>
> For comments, you can use JSmin style comments (like mentioned on
> jsonnet), so I don't consider this an issue.
>
> Regards
> Carsten
>
> On 08.05.2020 17:28, Robert Munteanu wrote:
> > Hi,
> >
> > I keep thinking about how the feature files would look like in a
> > different format. The main driver is the way repoinit statements
> > look
> > at the moment. Comments are also a bit awkward, even though
> > possible in
> > JSON.
> >
> > I was looking at Jsonnet [1], which is a superset of JSON with lots
> > of
> > bells and whistles, including comments and multiline strings.
> >
> > But irrespective of format - Jsonnet, YAML, or something else -
> > what
> > would it take to add another input format to the feature model? Is
> > it
> > something can be easily plugged in or would it require a
> > significant
> > rewrite?
> >
> > Thanks,
> > Robert
> >
> >
> > [1]: https://jsonnet.org/
> >
Re: [feature-model] Different input format for feature files?
Posted by Carsten Ziegeler <cz...@apache.org>.
It would be a significant effort, basically rewriting everything
including all modules, extensions and tooling.
Not sure if that is really worth the effort.
Repoinit is a little bit of a pain, I agree. But I don't think this
minor use case warrants such a dramatic change.
For comments, you can use JSmin style comments (like mentioned on
jsonnet), so I don't consider this an issue.
Regards
Carsten
On 08.05.2020 17:28, Robert Munteanu wrote:
> Hi,
>
> I keep thinking about how the feature files would look like in a
> different format. The main driver is the way repoinit statements look
> at the moment. Comments are also a bit awkward, even though possible in
> JSON.
>
> I was looking at Jsonnet [1], which is a superset of JSON with lots of
> bells and whistles, including comments and multiline strings.
>
> But irrespective of format - Jsonnet, YAML, or something else - what
> would it take to add another input format to the feature model? Is it
> something can be easily plugged in or would it require a significant
> rewrite?
>
> Thanks,
> Robert
>
>
> [1]: https://jsonnet.org/
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org