[
https://issues.apache.org/jira/browse/MBUILDCACHE-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713601#comment-17713601
]
LoneDev commented on MBUILDCACHE-54:
------------------------------------
So basically my custom behaviour might fit only some type of projects, correct?
If that's true than it could be worth to implement a special flag to enable or
disable my behaviour, I think.
I tested that change in all my projects and each time a file changes it
contributes to the hash change, so the core module would be rebuilt anyway
leaving no space for runtime errors.
So for my usage it works fine. You can provide an example project which
triggers the issue, would help more to understand the limitation.
> 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)
