[
https://issues.apache.org/jira/browse/MBUILDCACHE-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712992#comment-17712992
]
LoneDev edited comment on MBUILDCACHE-54 at 4/17/23 12:44 PM:
--------------------------------------------------------------
Which is not really good for my project.
I don't really know if my project is structured in an unusual way but the cache
system is useless this way.
Intellij and other IDEs provide refactoring, so if I edit a function signature
in module A it will also edit all references so it edits also module B. This is
will ensure cached hash change for both modules, so module B should not care
about having module A as part of its own cached hash.
I published a fix for that:
[https://github.com/apache/maven-build-cache-extension/pull/69]
was (Author: JIRAUSER299881):
Which is not really good for my project.
I don't really know if my project is structured in an unusual way but the cache
system is useless this way.
Intellij and other IDEs provide refactoring, so if I edit a function signature
in module A it will also edit all references so it edits also module B. This is
will ensure cached hash change for both modules, so module B should not care
about having module A as part of its own cached hash.
What do you think? I might try to work on something and create a pull request
to optionally enable this new behaviour.
> 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)
