AEM dependencies - issues with AEM-API | Community
Skip to main content
R
Rey
New Participant
October 16, 2015
Solved

AEM dependencies - issues with AEM-API

  • October 16, 2015
  • 2 replies
  • 1160 views

I think the new approach to add compile time dependencies to an AEM project has some serious drawbacks and should be changed.

While providing a single .jar file containing all dependencies is very easy and handy to use for "manually" built projects, it doesn't fit the usage of build management tools like maven.

Drawbacks:

  • every hotfix, as well as every combination of hotfixes, which changes a version of a library provided by AEM-API, would need it's own version of the AEM-API
  • one might not see from which open-source project certain libraries are. Although a good part of AEM consists of open-source projects, it would be unnecessarily hard to help improving those
  • in a multi-module project, not every module uses every dependency, it is not possible to see which module uses which parts of AEM
  • you cannot automatically download the source.jar of the open-source libraries, because your build management tool and your IDE do not know about the open-source libraries contained in the AEM-API

How the situation could be improved:

  • Providing a dependencies POM, as it was done for version 5.6 and older [1]
  • Providing a version of this POM at least for every service pack
  • Either provide a special version of the POM with every Hotfix, or at least add information about changed dependencies, such that they can be overruled in the dependency management section
  • Don't use custom releases of open-source projects, if possible
  • If custom releases of open-source projects are created and not hosted in the repository of the open-source project, they need to be hosted on repo.adobe.com, including source.jar [2]

What do you think? Am I missing something? Will the situation be improved by Adobe?

[1]: https://repo.adobe.com/nexus/content/groups/public/com/day/cq/cq-quickstart-product-dependencies/5.6.1.1/cq-quickstart-product-dependencies-5.6.1.1.pom

[2]: The following is a dependency of the AEM-API and not publicly available - see http://search.maven.org/#search|gav|1|g%3A%22org.apache.sling%22%20AND%20a%3A%22org.apache.sling.jcr.resource%22

<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.jcr.resource</artifactId>
<version>2.3.7-R1591843</version>

    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 Feike_Visser1

    You always have this fallback: https://helpx.adobe.com/experience-manager/kb/HowToUseCQ5AsMavenRepository.html

    2 replies

    Feike_Visser1
    Feike_Visser1Accepted solution
    Employee
    October 16, 2015

    You always have this fallback: https://helpx.adobe.com/experience-manager/kb/HowToUseCQ5AsMavenRepository.html

    R
    ReyAuthor
    New Participant
    October 16, 2015

    Unfortunately this only solves a small part of the problem and is unnecessary cumbersome. In addition it is not officially supported.

    By using the shown fallback, I get a way to fetch artifacts, which are used in AEM and not published on repo.adobe.com. In my eyes this is a workaround.

    But I think this adds another point to my list of drawbacks. The dependencies against which a AEM project is built should be the same as the once which are provided on the server. As you can see when accessing the maven repository on your local instance, AEM-API is not amongst the available bundles. You can easily test this by accessing your instance, lets say localhost:4502, with localhost:4502/maven/repository/com/adobe/aem/aem-api/6.0.0.1/aem-api-6.0.0.1.pom

    For available artifacts, such as http://localhost:4502/maven/repository/com/adobe/granite/com.adobe.granite.jmx/0.3.0/com.adobe.granite.jmx-0.3.0.pom, this would work.

    Terms & ConditionsAccessibility statement

    Loading footer...