[
https://issues.apache.org/jira/browse/JCR-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797620#action_12797620
]
angela commented on JCR-2453:
-----------------------------
> What about existing classes like
> o.a.j.webdav.observation.ObservationConstants?
as far as i know there is no JCR constant in there... it's a custom extension
of webdav that isn't defined
by either of the dav-rfcs.
If you want to move the jcr-remoting specific stuff to the webdav project they
should at least be
renamed from JCR-something to Jackrabbit-something or Day-something and put
into a different *Constants
class in order to make sure that those constants have nothing to do with
standard webdav.
i really don't want JCR to appear in the dav library... it's hard enough to
explain why jackrabbit, which is known
as reference implementation for JCR, provides it's own webdav library. we
definitely should avoid anything that
introduces additional confusions. no jcr strings within the dav-library...
> Break the spi2dav dependency to jcr-server
> ------------------------------------------
>
> Key: JCR-2453
> URL: https://issues.apache.org/jira/browse/JCR-2453
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-server, jackrabbit-spi2dav,
> jackrabbit-webdav
> Reporter: Jukka Zitting
> Attachments: JCR-2453.patch
>
>
> Currently the spi2dav component has a dependency on the jcr-server component,
> which is troublesome due to the extra transitive dependencies and which
> strictly speaking should not be necessary from an architectural point of view.
> The dependency exists mostly for sharing a number of JCR-specific WebDAV
> constants. I'd like to push those constants down to jackrabbit-webdav as they
> are essentially just shared strings and as jackrabbit-webdav already contains
> a number of constants used by JCR extensions.
> In addition to constant values, code in the following classes is shared
> between jcr-server and spi2dav: JcrValueType, NamespacesProperty,
> NodeTypesProperty, SearchResultProperty, SubscriptionImpl, ValuesProperty.
> The shared code in JcrValueType and SubscriptionImpl is mostly just about
> mapping constant value mappings and could fairly easily be moved to
> jackrabbit-webdav. The Property classes are a but trickier, but it looks like
> it would be possible to split the code to separate server- and client-side
> classes for jcr-server and spi2dav.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
