版本3.0之前的AFAIK Crafter CMS使用Alfresco作为存储库，而后者又使用RDBMS数据库作为存储元数据的底层数据库。它说Crafter CMS 3.0使用git作为存储库。
我的应用程序将涉及大量图像文件和元数据，我假设图像文件存储在文件系统中，元数据存储在Crafter CMS 3.0的底层数据库中。
还有什么特别的原因，CMS 3.0选择不使用JCR / Jackrabbit作为Magnolia和Hippo CMS等存储库吗？
答案 0 :(得分：3)
Crafter CMS是一个解耦CMS，这意味着有一个独立的创作系统和传送系统。对于Crafter CMS，分别是Crafter Studio和Crafter Engine。
直到并包括2.5版本，Crafter Studio使用Alfresco ECM作为其主要内容存储库，正如您所正确指出的那样，从3.0版开始，Git成为持久性存储库。 Crafter Engine始终使用文件系统，从不依赖于RDBMS或ECM。 Solr用于搜索，Solr在创作和传递中运行，内容通过Crafter Deployer在那里编入索引。
值得注意的是，除了Git之外，Crafter Studio 3.0确实利用了一个小的嵌入式RDBMS架构（MariaDB）来维护对象状态和其他与CMS相关的活动。但是，如果需要，可以根据Git状态重建该数据库。
关于图像和基于视频的应用程序：最佳做法是在Crafter中对这些资产进行建模，但依赖于外部存储（如S3，Box，Alfresco通过CMIS - 所有这些都是本机支持的，但都是对于二进制文件，它是可选的）但保留在Crafter CMS中的元数据。这意味着内容元数据在Crafter Engine中可用（通过加载描述符（XML）或查询Solr，通过Groovy，FreeMarker或Java），并且可以转换二进制文件，根据交付需要进行转码。
话虽如此，如果您愿意，您仍然可以直接将内容对象（XML +二进制文件）直接存储到Git中。
因此，尝试在更高级别回答您的问题：Crafter CMS使用XML来存储内容和元数据，此XML可以指向二进制资产（创建关联）。 XML以图形方式建模以生成表单，表单呈现为内容上的叠加，以供内容作者创建内容并最终在Git中生成XML。 XML由Solr通过Crafter Deployer（在Authoring and Delivery中运行）编制索引，并可供Crafter Engine使用（因此您的应用程序使用Groovy和FreeMarker编写（如果您真的需要，可以使用Java）。）
不使用JCR的原因太多，无法在此列出--Git提供了更好的开发人员工作流程，性能，可扩展性，devop支持等。请参阅Crafter Software网站上的#NoJCR录制的网络研讨会，其中介绍了一些推理。另一个直接资源是拱形概述：http://docs.craftercms.org/en/3.0/developers/architecture.html