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:
How the situation could be improved:
What do you think? Am I missing something? Will the situation be improved by Adobe?
[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>
Solved! Go to Solution.
You always have this fallback: https://helpx.adobe.com/experience-manager/kb/HowToUseCQ5AsMavenRepository.html
Views
Replies
Total Likes
You always have this fallback: https://helpx.adobe.com/experience-manager/kb/HowToUseCQ5AsMavenRepository.html
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies