[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364555 ]
Jukka Zitting commented on JCR-309: ----------------------------------- Stefan: > maybe we should add an optional Properties argument to the createWorkspace > signatur. What should it do? The current WorkspaceImpl.createWorkspace signature doesn't have it so we'd need to specify how the given properties will be interpreted and implement that interpretation. We can add JackrabbitWorkspace.createWorkspace(String,Properties) without breaking backwards compatibility also later during the 1.x cycle. I suggest that we do so only when the given properties are actually used. Felix: > IMHO, the InputStream solution is not the best of all solutions, but it is > still far better than nothing. Agreed. We must have at least one officially supported node type registration mechanism in 1.0. The InputStream solution covers at least the basic use case without exposing too much of the Jackrabbit internals. A more integrated tool can always use the internal Jackrabbit interfaces directly to get more control over the registration process, but there would be no guarantees of backwards compatibility for such clients. > Extract the public API interfaces from o.a.j.core to o.a.j.api > -------------------------------------------------------------- > > Key: JCR-309 > URL: http://issues.apache.org/jira/browse/JCR-309 > Project: Jackrabbit > Type: Task > Components: API > Reporter: Jukka Zitting > Fix For: 1.0 > Attachments: jackrabbit-api.patch > > To better document and track the public JCR extensions and component API > provided by Jackrabbit and to allow more room for refactoring within the > Jackrabbit core, we shoud move (or create) the supported API interfaces to a > new org.apache.jackrabbit.api package. > At least the following interfaces should be moved along with any supporting > implementation-independent classes: > * PersistenceManager > * FileSystem > * AccessManager > * QueryHandler > * TextFilter > Possible dependencies to implementation-specific classes should preferably be > abstracted using extra interfaces. > Also the workspace and node type administration methods should be published > as Jackrabbit-specific extensions to the JCR API interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
