Jackrabbit implements Java Specification Request 170
http://jackrabbit.apache.org/frequently-asked-questions.html
What is a content repository?
A content repository is an information management system that provides various
services for storing, accessing, and managing
content. In addition to a hierarchically structured storage, common services of
a content repository are versioning, access control,
full text searching, and event monitoring. A content repository is not a
content management system (CMS), although most existing
CMSs contain a custom content repository implementation, often based on the
file system or a relational database.
Hence come with versionning embedded.
Note this section:
What is a Jackrabbit file system?
A Jackrabbbit file system (FS) is an internal component that implements
standard file system operations on top of some underlying
storage mechanism (a normal file system, a database, a webdav server, or a
custom file format). A file system component is any Java
class that implements the FileSystem interface and the associated behavioral
contracts. File systems are used in Jackrabbit both as
subcomponents of the persistence managers and for general storage needs (for
example to store the full text indexes).
But of course yes, you can also use SVN on a file system. Jackrabbit just
offers more choices and has already a lot of knowledge
embedded.
Note that there is already a Jackrabbit effort going on in the
jackrabbit20120501 branch
https://svn.apache.org/repos/asf/ofbiz/branches/jackrabbit20120501
Mostly sustained by Sascha so far...
Jacques
From: "BJ Freeman" <[email protected]>> to add another layer to this, how
about using SVN for versioning, as
well as storage.
The would be managed through the content component.
I am not totally familiar with Jackrabbit.
But maybe the SVN solution would also take care of Jackrabbit requirements.
Jacques Le Roux sent the following on 7/17/2012 1:53 PM:
The next steps for the future will be to move out of the framework
the folders in the "images" application that are specific to
applications (somewhere under runtime seems a good approach).
Some of the application-specific content could be used by other
applications, so it should stay in the resources component. Anything
that is truly application-specific should be kept in the application.
The application-
