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/ > > > > > > >
