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