well, the enum value is released as part of the public API, so we cannot change it now without breaking the API. it makes sense to update the Javadoc to document what exact format is expected here (you can do it directly).
if we later want to add other formats we have to create new enum values. my primary concern was to support the format that is used by default by the package manager files (this extended docview), and I assume this format will not change. not sure if there is a pressing need for the other formats. stefan >-----Original Message----- >From: Konrad Windszus [mailto:[email protected]] >Sent: Thursday, March 23, 2017 2:16 PM >To: [email protected] >Subject: Re: [VOTE] Release Apache Sling JCR Content Parser 1.0.0 > >@Stefan: I see that you just closed >https://issues.apache.org/jira/browse/SLING-6592 and that this has >obviously been released. >Can you still quickly comment on my feedback given below? Do you want me >to open a dedicated ticket in JIRA for that, so that we can fix that in >a new version? > >Thanks, >Konrad > >> On 21 Mar 2017, at 12:08, Konrad Windszus <[email protected]> wrote: >> >> I am not sure that JCR_XML is a good name for the Extended DocView >format supported by FileVault >(https://github.com/apache/sling/blob/trunk/bundles/jcr/contentparser/sr >c/main/java/org/apache/sling/jcr/contentparser/ContentType.java#L37, ) >> I would rather prefer something like VAULT_EXT_DOCVIEW >(https://issues.apache.org/jira/browse/JCRVLT-132). >> In the future we may want to support JCRs DocumentView and SystemView >in addition. >> So I would prefer if we would rename that enum value. >> Sorry for noticing so late. >> >>> On 21 Mar 2017, at 11:42, Carsten Ziegeler <[email protected]> >wrote: >>> >>> +1 >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> [email protected] >> >
