[
https://issues.apache.org/jira/browse/MBUILDCACHE-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713378#comment-17713378
]
Alexander Ashitkin edited comment on MBUILDCACHE-54 at 4/18/23 4:18 AM:
------------------------------------------------------------------------
This is a wrong assumption. If the Core changes, each submodule must be rebuilt
because the runtime dependency changed. Even though the scope is ‘provided’,
the library update potentially changes runtime behavior and tests must be
rerun. Compilation also might be affected by the core change even in the
provided scope
If there are some files, which do not contribute to the runtime behavior, they
could be filtered out from the checksum by patterns and it will make the Core’s
hash more stable.
Also, there could be optimizations implemented - like do not rebuilt submodules
if only the core tests changed.
But in general the current logic is correct and should not be changed this way.
was (Author: alex_ashitkin):
This is a wrong assumption. If the Core changes, each submodule must be rebuilt
because the runtime dependency changed. Even though the scope is ‘provided’,
the library update potentially changes runtime behavior.
If there are some files, which do not contribute to the runtime behavior, they
could be filtered out from the checksum by patterns and will make the core hash
more stable.
Also, there could be optimizations implemented to tweak such a behavior - like
do not rebuilt submodules if only the core tests changed.
But in general the current logic is correct and should not be changed this way.
> Project scoped dependency of a module contributes so the hash of the module
> itself breaking cache logic
> -------------------------------------------------------------------------------------------------------
>
> Key: MBUILDCACHE-54
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-54
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Affects Versions: 1.0.0
> Reporter: LoneDev
> Priority: Major
>
> I have a maven project structured this way:
> * Core
> ** module1
> ** module2
> ** module3
>
> Each submodule has Core as dependency, because they need to access some stuff
> in the Core module.
> {code:java}
> <dependency>
> <groupId>dev.lone</groupId>
> <artifactId>Core</artifactId>
> <version>1.0</version>
> <scope>provided</scope>
> </dependency> {code}
> The issue is that when I edit the Core the hash of the modules changes too
> because their hash is made of their dependencies too.
> What I'd expect is the hash of the submodules (module1, module2, module3)
> won't get modified if the dependency Core has some files edited.
> I'd expect only the hash of the Core dependency change triggering the build
> for only the Core module.
> Right now the build process is triggered for every module if a single file of
> the Core is edited because its hash changes.
> This makes the caching system useless in my project.
> I think a solution would be to correctly exclude a dependency from the hash
> of the module if the dependency is a module of the current project.
> I thought this already was the current logic by reading your code, but seems
> somehow it's not.
>
> I found that out by enabling debug using `-X` maven argument and noticed that
> the dependency hash was changing for one of the two dependencies in the log,
> but the others remained the same.
> Example:
> {code:java}
> [DEBUG] Hash calculated, item: file, hash: aed7a7726072b1f2
> [DEBUG] Hash calculated, item: file, hash: af38807c7b6d4d82
> [DEBUG] Hash calculated, item: file, hash: 7b2b9b026b4247b0
> [DEBUG] Hash calculated, item: file, hash: 5d3e80058614177e
> [DEBUG] Hash calculated, item: file, hash: f656e74567358a0e
> [DEBUG] Hash calculated, item: file, hash: 24836dacb4dec612
> [DEBUG] Hash calculated, item: dependency, hash: ceaa4062fafc0392
> [DEBUG] Hash calculated, item: dependency, hash: 933c5b7ec84b6afa ### <----
> this {code}
> This is strange since checking your code it should automatically exclude a
> dependency from the module hash if the dependency itself is a module of the
> project, right?
> Here the relevant code I found in your repo:
> calculateChecksum()
> [https://github.com/apache/maven-build-cache-extension/blob/241ebce428e6ee4f9d2c8ad43e65d44d9eaf947e/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L206]
> call to getMutableDependencies()
> [https://github.com/apache/maven-build-cache-extension/blob/241ebce428e6ee4f9d2c8ad43e65d44d9eaf947e/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L211]
> getMutableDependencies()
> [https://github.com/apache/maven-build-cache-extension/blob/241ebce428e6ee4f9d2c8ad43e65d44d9eaf947e/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L644]
>
> Call to normalizedModel()
> [https://github.com/apache/maven-build-cache-extension/blob/241ebce428e6ee4f9d2c8ad43e65d44d9eaf947e/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L209]
>
> normalizedModel() and call to normalizedModelInner()
> [https://github.com/apache/maven-build-cache-extension/blob/241ebce428e6ee4f9d2c8ad43e65d44d9eaf947e/src/main/java/org/apache/maven/buildcache/DefaultNormalizedModelProvider.java#L62]
>
> normalizedModelInner() and call to normalizePlugins()
> [https://github.com/apache/maven-build-cache-extension/blob/241ebce428e6ee4f9d2c8ad43e65d44d9eaf947e/src/main/java/org/apache/maven/buildcache/DefaultNormalizedModelProvider.java#L95]
>
> normalizePlugins() and call to isPartOfMultiModule()
> This is what I think could be changed to fix the issue. Basically call
> `return;` instead of `copy.setVersion(NORMALIZED_VERSION);`
> [https://github.com/apache/maven-build-cache-extension/blob/241ebce428e6ee4f9d2c8ad43e65d44d9eaf947e/src/main/java/org/apache/maven/buildcache/DefaultNormalizedModelProvider.java#L113]
>
> isPartOfMultiModule()
> [https://github.com/apache/maven-build-cache-extension/blob/241ebce428e6ee4f9d2c8ad43e65d44d9eaf947e/src/main/java/org/apache/maven/buildcache/DefaultMultiModuleSupport.java#L85]
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
