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
cziege...@apache.org
