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 <[email protected]
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
[email protected]
