Another remark on the API: Currently ContentFileParser methods always returns Map<String, Object>. If I understood correctly, the keys are both direct property names of the root resource as well as child resources.
That is not good because in JCR it is perfectly valid to have a node called "parent" having a subnode named "test" and a direct property named "test", but a Java Map only allows one value per key. I committed an ignored test case for that in https://svn.apache.org/r1786694. Currently only the child resource with the name is returned and the property of the same name is just ignored. So I would recommend to come up with some other return type which allows same name child-resources and properties. Probably it would be good to distinguish child resources from properties more strictly. That way we can also rely on types which may be at least for child resources something better than just Object. Thanks, Konrad > On 13 Mar 2017, at 09:48, Stefan Seifert <sseif...@pro-vision.de> wrote: > > i've recently created a new commons sling component which i named "File > System Content Parser", source currently at [1] related ticket is SLING-6592 > [2]. > > it's main goal is to support various serializiation formats of resource > content structures which are commonly used to export and import content > to/from Sling or JCR. it parses the content structures to a simple nested > Maps structure which can then be further processed by other components. it > currently supports Jackrabbit FileVault XML format and the JSON format > supported by Sling JCR ContentLoader. the component is used currently by the > new version of fsresource and sling-mock. the API is quite simple. > > the question is - what should be the final name of this component. > > currently i've choosen the name "File System Content Parser", artifactId > "o.a.s.commons.fscontentparser" because it deals with file formats most > commonly used for serializing resource content to files and importing them > back. konrad started a discussion in SLING-6592 [2] about alternatives > because the API and usecase itself is not limited to be used only in > combination with file system but any source. > > which name do you prefer? > > 1. fscontentparser > 2. contentparser > 3. fileparser > 4. resourcedeserializer > 5. other proposals? > > stefan > > > [1] > https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/fscontentparser > [2] https://issues.apache.org/jira/browse/SLING-6592 > >
