Expand my Community achievements bar.

SOLVED

AEM dependencies - issues with AEM-API

Avatar

Level 1
Level 1

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...

[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...

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

1 Accepted Solution

Avatar

Correct answer by
Employee
2 Replies

Avatar

Correct answer by
Employee

Avatar

Level 1
Level 1

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.grani..., this would work.