This message was deleted.

Hi Fran 👋 . That’s an interesting approach. The important thing should be modifying the

.module

file (Gradle basically ignores the

pom

if the .module is there). Looking at your

module-c-2.0.module

I see that it points at

module-c-1.0.jar

as artifacts. Which seems like the adjustment worked. (I am curious, how do you do that?) I am not sure why it is not working. Can you share the error, or a complete example? Your Zip contains module-c, but there are dependencies to

module-b

which are not in the ZIP.

@Jendrik Johannes, thank you for the answer. 🙂 I had to modify a project a bit in order to be more clear what’s wrong. So the project dependencies graph look like in the picture. I provided the zipped project and also m2 repository which I used (with changed

module-c-2.0.pom

and

module-c-2.0.module

pointing to the

module-c-1.0.jar

. If you unpack it and add it to your maven repository and go to project and run

./gradlew build

you should get this message:

> Task :module-d:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':module-d:compileJava'.
> Could not resolve all files for configuration ':module-d:compileClasspath'.
   > Could not resolve org.example:module-c:2.0.
     Required by:
         project :module-d
      > Could not resolve org.example:module-c:2.0.
         > inconsistent module metadata found. Descriptor: org.example:module-c:1.0 Errors: bad version: expected='2.0' found='1.0'

Is there a way for this to be solved? Btw, I manipulated these

module-c-2.0.pom

and

module-c-2.0.module

files manually for this purpose. It’s not yet done dynamically. I wanted to have a small poc first to see if this concept would work.

Thanks for the full example. I think this is the problem with your modification: You should not modify the

<version>2.0</version>

tag in the top of the POM (in fact, do not modify the POM at all). You should also not modify the

"component": { "version": "2.0" }

in the .module file. This is, because in you approach the new version -

2.0

- is still a new version for Gradle. That’s why you can’t mess with that part of the metadata. And you get the error you shared. What you want to modify is only the artifact (the Jar file) that belongs to the “new” version. Essentially, you only need to replace all occurrences of:

"name": "module-c-2.0.jar"

->

"name": "module-c-1.0.jar"

"url": "module-c-1.0.jar" -> "name": ../1.0/"module-c-1.0.jar"

Note that the

../<version>/

part in the ‘url’ following the repository layout. (It’ relative to the location of the metadata.)

Thanks for the hint but unfortunately it doesn’t seem to work for me. When I do the changes I get the following error:

Execution failed for task ':module-d:compileJava'.
> Could not resolve all files for configuration ':module-d:compileClasspath'.
   > Could not find org.example:module-c:2.0.
     Searched in the following locations:
       - file:/Users/fran.dragomanovic/.m2/repository/org/example/module-c/2.0/module-c-2.0.pom
       - <https://repo.maven.apache.org/maven2/org/example/module-c/2.0/module-c-2.0.pom>
     Required by:
         project :module-d

I attached the modified .m2 repository just to be sure I did the right thing.

The error message indicate that the component ‘org.examplemodule c2.0’ is not found at all. Look at the locations. It only searched in “mavenLocal()” (.m2). Did you add the local repo? The

zip

you send looks correct and it works for me.

Jendrik thank you loads! 🤗 It did work in the end. I was referencing .m2 repo where I had everything “modified correctly”, but it didn’t work. Then I created a new local maven repo pointing to some other location where I had unzipped content which I sent to you. So basically the same content like in .m2. And this worked like a charm! I hope I’ll be able to meet you in person one day to buy you a beer 😃🍻

Ah ok. General tipp: avoid using

.m2

unless you absolutely need it for integration with Maven. I think

.m2

is treated like a remote repo (from the caching perspective) so you would need to run

--refresh-dependencies

if you change things in there. Local file repos are treated differently (metadata is not cached as Gradle assumes it may change).

Ok, thanks! That’s really good to know. I will keep that in mind from now on. As for Gradle support, you will most certainly be the person to go 👍😉