[
https://issues.apache.org/jira/browse/MBUILDCACHE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878174#comment-17878174
]
ASF GitHub Bot commented on MBUILDCACHE-104:
--------------------------------------------
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
> Allow multiple cache entries per checksum
> -----------------------------------------
>
> Key: MBUILDCACHE-104
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-104
> Project: Maven Build Cache Extension
> Issue Type: New Feature
> Reporter: Réda Housni Alaoui
> Priority: Major
> Labels: pull-request-available
>
> I have the following use case: a CI pipeline with a compile step *then*
> multiple parallelized test steps. Tests are split in 3 groups. Each test
> group execution specify the group via maven-surefire-plugin:test property
> 'groups'.
> Maven phase for compilation: process-test-classes
> Maven phase for tests: verify
> The compilation should use remote cache as much as possible and end up
> populating it.
> Each test execution should either use the populated cache ending with
> process-test-classes phase or a cache representing the result of the
> execution of the current test group (value for 'groups').
> The issue I have is that this extension can only store a single cache entry
> per input checksum. But I need to persist the build result of each test group.
> The easiest solution I can think of is having 4 cache zones. The first for
> the compile phase (the default zone), the 3 remaining for each test group.
> I need the compile phase to read/write from/to the default cache zone.
> I need each test group to read from its own cache zone then the default cache
> zone, *in this order*. At the end, it should write to its own cache zone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
