AlexanderAshitkin commented on PR #175: URL: https://github.com/apache/maven-build-cache-extension/pull/175#issuecomment-2321747490
@reda-alaoui I am currently trying to better understand this request, and I have some conceptual concerns. To enhance the speed of project optimization, a traditional approach would be to divide the project into smaller modules and allow tests to run in parallel. The propozed `zoned` approach looks out-of-line with the Maven core design, which is per-project granularity. Cache is not a tool in itself, it is a Maven extension, and the request must be evaluted with the the regular Maven in mind - how to achieve the same goal without using the cache, using regular Maven instead. As i see, this change aims to address the following Maven limitations: 1. Lack of plugin level resumption (not consistent with Maven's core - it does not have a concept of Gradle-like tasks) 2. Issues with artifacts staging and promotion (not consistent with Maven's core - it lacks built-in staging concepts. It is more typical to use different cache endpoints). 3. Reactor distribution and scaling (not consistent with Maven's core - single reactor runs as a JVM, and results are shared through the artifacts of sub-projects) In summary, this approach appears unconventional and is chosen because reworking the existing mono-project is more expensive. I see value in this idea because such "mono-projects" are not uncommon, but I need some time to digest it. I will take my time to understand why this is necessary and how to address it consistently. Cheers Alex -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
