You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Maximilian Novikov (Jira)" <ji...@apache.org> on 2023/04/17 06:37:00 UTC

[jira] [Commented] (MBUILDCACHE-54) Project scoped dependency of a module contributes so the hash of the module itself breaking cache logic

    [ https://issues.apache.org/jira/browse/MBUILDCACHE-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712915#comment-17712915 ] 

Maximilian Novikov commented on MBUILDCACHE-54:
-----------------------------------------------

If project B depends on A, a change in A will rebuild all subtrees including project B.  A -> B. It's how it works now.

> 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)