https://gradle.com/ logo
Join Slack
Powered by
Looking for some help with my build (Java project ...
# community-support
k
Looking for some help with my build (Java project using .kts, not groovy) See first reply
I want to shade a library (snakeyaml) into module B (with relocation) I’m using the shadow plugin and I was able to get module B’s jar to compile properly The hard part: module B also has an abstract class with methods that take some snakeyaml objects (e.g. MappingNode) Then I’m trying to include B as a dependency in module A I’m new to gradle, especially the type of dependencies (api, shadow, implementation) I can’t seem to get module A to see the abstract class in B with the relocated classes. It sees the raw file with unmapped packages I can’t seem to depend on B such that it acknowledges the relocation that happens on compile I’d like B to be independently compiled, so I have the relocation configuration in B If anyone can help with this, it would be greatly appreciated
c
When I’m doing things like this I’m not actually using the ShadowPlugin, but instead using it’s shading task but with a custom plugin layered around it. I’m looking at the ShadowPlugin again now to see what it does when used as a plugin.
Okay… I think you can get what you want with the stock shadow plugin by modifying the attributes of the module B dependency in module A:
Copy code
implementation(project(':module-b')) {
  attributes {
    attribute(Bundling.BUNDLING_ATTRIBUTE, project.objects.named(Bundling, Bundling.SHADOWED))
  }
}
Something like that.
Sorry - that is pseudo-Groovy… but the translation to Kotlin should be trivial.
k
Ok sweet, I’ll be able to test this in about an hour Thanks for the help (I’ll send an update here if it works)
c
Copy code
implementation(project(":module-b")) {
    attributes {
        attribute(BUNDLING_ATTRIBUTE, objects.named<Bundling>(SHADOWED))
    }
}
Verified in a simple two module project that this works (Kotlin code this time)
❤️ 1
v
You can even omit the 
<Bundling>
, the type is inferred from the first argument already.
👍 1
k
I'm close but not quite there. Once I changed the module-b dependency to 
implementation(yaml)
I was able to resolve the correct 
MappingNode
location, however the abstract class from module-b is giving errors when extended from module-a.
TestProject.zip
When the abstract method is fulfilled, IntelliJ IDE expects 
org.yaml.snakeyaml.nodes.MappingNode
when the only one available is 
com.kamikazejam.kamicommon.snakeyaml.nodes.MappingNode
The zip file above generates the correct module-b jar file (with yaml shaded and relocated) But has issues with the 
Test
class from module-a
c
The build is correct Gradle… it’s IntelliJ thats having issues. The 
TestProject.module-b.main
dependency in the screen should not be there, and if if you look at the classpath being used by Gradle it only includes the shadowed jar.
k
I see, however when I try to remove that dependency, IntelliJ lets me know that it might not save because it's being imported from Gradle. I can remove it, and it works temporarily, but the next time I refresh Gradle it appears again.
IntelliJ appears to be importing that module-b.main dependency from the modified dependency (with the attribute) in 
build.gradle.kts
I hate it, but I think this is the only thing I can do (see Solution 2) https://github.com/Jake-Moore/GradleDependOnRelocatedShadow
v
If the only problem is the wrong dependency in the IJ module configuration, you could also use the 
idea-ext
plugin to fix exactly that.
k
Oh really? Do you have an example The correct dependency is there, right below the bad one, I just need to remove the explicit module-b.main dependency, and leave the one below it
It’s been a long day, and despite having a half working solution I’d welcome that idea-ext fix Currently I can’t even refresh grade without recompiling stuff 😅
v
I mean using the callbacks you can define for the idea-ext plugin with which you can modify the XML directly.
5 Views
Open in Slack
PreviousNext
Powered by