我找到了两个关于如何为 AEM 项目构建 Maven Artifact 的示例:
<<artifact>>
|- <<artifact>>-bundle (OSGi services bundle)
|- <<artifact>>-content (Adobe defaults to /apps/<<artifact>>
<<artifact>>
|- <<artifact>>-view (components, templates, clientlibs, design nodes)
|- <<artifact>>-config (JCR node configurations)
|- <<artifact>>-services (OSGi)
|- <<artifact>>-taglib
|- <<artifact>>-all
|- <<artifact>>-content (/content/<<artifact>> nodes)
我更喜欢使用第二个;它看起来更干净,并且可以避免设计师和开发人员在开发过程中发生冲突。例如,Adobe 原型(prototype)不区分用户内容(
/content/<<artifact>>
和 /etc/designs/<<artifact>>
)和开发者内容(/apps/<<artifact>>
和 /etc/clientlibs/<<artifact>>
)。我找不到任何关于 Adobe 推荐第一种样式的可靠信息,但也许我遗漏了一些东西,而 Adobe 推荐的模式是正确的做法。有AEM经验的人可以在这里称重吗?
最佳答案
这个问题有点危险,因为它鼓励意见而不是事实,而事实并非如此。无论如何,我尝试详细说明我的经验。
Adobe 原型(prototype)适用于简单项目,在大多数情况下就足够了。不要被名称后缀 -content
所迷惑.它包含 /apps/artifact
因此,组件(包括 JSP、dialog.xml 等)以及通常还有 /etc/designs/artifact
.它不包含内容;而且我看不出有任何理由这样做,因为内容不是代码。
另一方面,cqblueprint 对于小型项目来说过于分散,但对于大型项目来说是有意义的。虽然如上所述,我看不到 -content
的用途。部分。
我基于 Adobe 创建了自己的原型(prototype),其中包含以下部分:
<<artifact>>
|- <<artifact>>-core (OSGi services bundle)
|- <<artifact>>-config (environment specific configurations of Adobe and custom OSGi services)
|- <<artifact>>-ui (/apps/artifact, /etc/designs/artifact, etc.)
凭借经验,您可能会找到另一种方式来构建适合您风格的 CQ/AEM 项目。或者,如果您计划集成像 NEBA 这样的框架或 Slice他们可能带有自己的项目结构。
关于maven - AEM/CQ Maven 项目结构——多个 JCR 节点子模块,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25878240/