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