This document describes how to set up an AEM project based on Apache Maven .
Apache Maven is an open source tool for managing software projects by automating builds and providing quality project information. It is the recommended build management tool for AEM projects.
Building your AEM Project based on Maven offers you several benefits:
1. An IDE-agnostic development environment
2. Usage of Maven Archetypes and Artifacts provided by Adobe
3. Usage of Apache Sling and Apache Felix tool sets for Maven based development setups
4. Ease of import into an IDE; for example, Eclipse and/or IntelliJ
5. Easy integration with Continuous Integration Systems
Experience Manager API Dependencies
What is the UberJar?
The "UberJar" is the informal name given to special Java Archives (JAR) file provided by Adobe. These JAR files contain all of the public Java APIs exposed by Adobe Experience Manager. They include limited external libraries as well, specifically all public APIs available in AEM which come from the Apache Sling, Apache Jackrabbit, Apache Lucene, Google Guava, and two libraries used for image processing (Werner Randelshofer's CYMK JPEG ImageIO library and the TwelveMonkeys image library). The UberJars only contain API interfaces and classes, meaning that they only contain interfaces and classes which are exported by an OSGi bundle in AEM. They also contain a MANIFEST.MF file containing the correct package export versions for all of these exported packages, thus ensuring that projects built against the UberJar have the correct package import ranges.
Why did Adobe create the UberJars?
In the past, developers had to manage a relatively large number of individual dependencies to different AEM libraries and when each new API was used, one or more individual dependencies had to be added to the project. On one project, the introduction of the UberJar resulted in 30 separate dependencies being removed from the project.
Starting with AEM 6.5, Adobe provides two UberJars: one that includes deprecated interfaces and one that removes those deprecated interfaces. By referencing one explicitly at build time, customers are sure to understand if they have a dependency on deprecated code.
The second Uber Jar strips away any deprecated classes, methods, and properties so customers can compile against them and understand if the custom code is future proof.