Hi, I might be missing something but isn't much of this already covered with the existing JCR RepositoryFactory interface and our implementations thereof?
I don't see a need to move around stuff, we just need a utility method (which usually happen to be static ;) ) that turns a defined set of URLs into a parameter map that is consumed by the RepositoryFactory implementations. Those implementations can all be discovered using the standard Java Service Provider mechanism. There is no need to declare dependencies for that. e.g. to access a repository on the file system, the utility method had to translate the URL file:///my/repo/home into a map with: - org.apache.jackrabbit.repository.home -> file:///my/repo/home - org.apache.jackrabbit.repository.conf -> file:///my/repo/home/repository.xml with this map content, the org.apache.jackrabbit.core.RepositoryFactoryImpl will provide a repository instance. and btw. that's a TransientRepository, so you don't even have to care about life cycle :) for all the other RepositoryFactory implementations you probably don't need life cycle anyway because you only *connect* to an already running repository and don't start it. regards marcel On Tue, Oct 20, 2009 at 17:11, Jukka Zitting <[email protected]> wrote: > Hi, > > The current jackrabbit-jcr-client component contains a > RepositoryFactory implementation that can choose between different > Repository implementations based on given parameters. Currently it > depends on the SPI implementations encoded in the > Jcr2spiRepositoryFactory class in jackrabbit-jcr2spi and on the > RepositoryFactoryImpl class in jackrabbit-core. However, the > jackrabbit-jcr-client POM only declares those as test dependencies, so > a client application needs to explicitly add the required > implementation dependencies. > > Some thoughts on this: > > 1) Is there a reason why this generic RepositoryFactory implementation > couldn't go to jackrabbit-jcr-commons? We obviously want to keep the > implementation dependencies optional, so having the class in > jcr-commons would not affect the dependency set. And since all of our > repository implementations (core, jcr2spi + spi2dav, etc.) already > depend on jcr-commons, a client would not need any extra dependencies > to use this functionality. > > 2) It looks to me like the functionality inside the > Jcr2spiRepositoryFactory class could/should be merged with the > jcr-client RepositoryFactoryImpl. > > 3) How about using URIs as a simple configuration mechanism? A file: > URI pointing to a repository directory would start a normal > jackrabbit-core repository using a repository.xml from within the > directory (or a custom one specified in a URI parameter). A http: URI > would point to a DAV(ex) endpoint or possibly a HTML page with an > appropriate <link/> tag pointing to the endpoint. People are already > familiar with URIs, so documenting and communicating such > configurations would be easy. > > 4) In addition to the RepositoryFactory implementation, I propose a > simple wrapper Repository class that simply takes a URI like above as > a constructor argument. This would make it really easy to connect to a > repository: > > Repository local = new GenericRepository("file:///path/to/repository"); > Repository remote = new GenericRepository("http://localhost:8080/";); > > The GenericRepository class would simply use the RepositoryFactory API > under the hood. > > BR, > > Jukka Zitting >
