As soon as you have more than one file, packaging becomes a problem. How do you easily distribute such a model, which files are needed, how do you find them after unpacking etc.
Keep in mind, that repoinit is a Sling proprietary mechanism which is not of general interest for an OSGi feature model. So I don't want to complicate the general model for a small use case. And one option should really be enough Carsten Dominik Süß wrote > Hi, > > I personally think 1 & 2 have their advantages - externalizing rather > complex repoinit setups with dozens of statements might make sense to keep > the feature model overall better readable. So I would personally opt for > both options. > > Cheers > Dominik > > On Mon, Jan 8, 2018 at 2:11 PM, Carsten Ziegeler <[email protected]> > wrote: > >> Hi, >> >> good point, I don't like the second option as I prefer having everything >> in a single file. The third option would introduce a special format per >> extension which then might need special rules/implementation for merging >> two modules or handling inheritance/includes. >> >> Which leaves us with the first option :) >> >> I think parsing this is easy: if it's in array simply concat the values >> and apply newlines in between. In the same way we could write out a text >> value: we split the text by newlines and create an array out of it. >> >> Regards >> >> Carsten >> >> >> Robert Munteanu wrote >>> Hi, >>> >>> While working some more with the feature model I realized that text >>> sections can not contain newlines - this is a limitation of JSON. >>> >>> This makes it very hard to work with repoinit sections. I end up with >>> (literally) 10k characters on a single line. Diffs are going to be >>> interesting with such formats :-) >>> >>> I think it would help adoption a lot if we have a more friendly format >>> for text entries. >>> >>> One option would be to have lines stored as an array, e.g. >>> >>> "repoinit:TEXT|false": [ >>> "create path (sling:Folder) /libs", >>> "create path (sling:Folder) /apps", >>> "create path (sling:Folder) /tmp" >>> ] >>> >>> Not that nice, but it keeps the file self-contained. >>> >>> Another option would be to keep a secondary text file around and >>> introduce a new field type, file: >>> >>> "repoinit:FILE": "./repoinit.txt" >>> >>> This has the disadvantage of no longer having the configuration be >>> self-contained, but on the other hand it's a text file, which the >>> repoinit format was built for. >>> >>> The third option - for the sake of being complete - is to have a >>> structured JSON format for repoint, but IMO that's overkill. Something >>> like: >>> >>> "repoinit": { >>> "paths": [ >>> "/libs (sling:Folder)", >>> "/apps (sling:Folder)", >>> "/tmp (sling:Folder)" >>> ] >>> } >>> >>> Thoughts? I think the feature model approach is great, but we need to >>> improve on the usability of text sections. >>> >>> Thanks, >>> >>> Robert >>> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] >> > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
