Specific AEM6 multimodule-content-package-archetype? | Community
Skip to main content
J
Julio_Baixauli
October 16, 2015
Solved

Specific AEM6 multimodule-content-package-archetype?

  • October 16, 2015
  • 1 reply
  • 1051 views

Hi masters!

 

Related to AEM6 documentation in [1], do you know if there’s an AEM6 specific multimodule archetype for AEM6? I mean, are there a specific ‘-DarchetypeVersion’ and ‘cqVersion’ for AEM6?

Also, I’ve discovered there’re other CQ/AEM project archetypes, like [2]. Have you ever work with them? Which one do you recommend? And the same question applies to this archetype: do you know if there’s a specific version of cqblueprints.com archetype for AEM6?

I think this question is important to start a new AEM6 project, because the dependencies should be very different between both AEM versions (5.6.1, as in the documentation, and AEM6). Check [3] for this point.

 

[1] http://docs.adobe.com/docs/en/aem/6-0/develop/how-tos/ht-projects-maven.html

[2] http://www.cqblueprints.com/setup/maven.html

[3] http://experiencedelivers.adobe.com/cemblog/en/experiencedelivers/2014/05/aem6-maven-dependencies.html

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Ove_Lindström

Hi,

The CQ Blueprint and AEM6 Maven archetypes and dependencies has no connection. The Blueprint is more of a concept than a truth. In our project, we are using the CQ Blueprint aproach with service-, api and taglib bundles and diffrente content packages for diffrent things as views, configurations and even down to specific components having their own view/service bundles just to isolate them from the rest of the code. At this moment we have over 100 releasable modules, setup in roughly the way described in your [1].

However, the [1] is not suitable for large project but should be used as an inspiration for a part of the delivery (IMHO). We have a top-pom that takes care of the repository setup, the pluginManagement, the dependencyManagement and other things that are shared by all our "projects". If you need to, it is really easy to create your own artifact that produces the structure and the poms that you need to suit your project.

I would recommend to keep the autoInstall and autoInstallPublish targets and always install on all server nodes rather than replicating them from author to publish.

Also, what we have done, is having all server configurations in a specific module, that uses the Maven filter functions and some cool scripting to produce server specific artefacts. Nothing goes into a server, dev, test or production, without coming from the version controll system.

/O

1 reply

O
Ove_LindströmAccepted solution
October 16, 2015

Hi,

The CQ Blueprint and AEM6 Maven archetypes and dependencies has no connection. The Blueprint is more of a concept than a truth. In our project, we are using the CQ Blueprint aproach with service-, api and taglib bundles and diffrente content packages for diffrent things as views, configurations and even down to specific components having their own view/service bundles just to isolate them from the rest of the code. At this moment we have over 100 releasable modules, setup in roughly the way described in your [1].

However, the [1] is not suitable for large project but should be used as an inspiration for a part of the delivery (IMHO). We have a top-pom that takes care of the repository setup, the pluginManagement, the dependencyManagement and other things that are shared by all our "projects". If you need to, it is really easy to create your own artifact that produces the structure and the poms that you need to suit your project.

I would recommend to keep the autoInstall and autoInstallPublish targets and always install on all server nodes rather than replicating them from author to publish.

Also, what we have done, is having all server configurations in a specific module, that uses the Maven filter functions and some cool scripting to produce server specific artefacts. Nothing goes into a server, dev, test or production, without coming from the version controll system.

/O

Terms & ConditionsAccessibility statement

Loading footer...