https://gradle.com/ logo
Join Slack
Powered by
I'm working on an internal enterprise plugin to le...
# plugin-development
j
I'm working on an internal enterprise plugin to lessen the amount of configuration we have to do in our projects, and to make the configuration and version control of dependencies more maintainable. However, I'm running into a "problem". We have an internal maven repository, so in new projects' 
settings.gradle.kts
file they need to add the internal maven repository, which is fine, but I would like my consumers not to be required to add 
gradlePluginPortal()
and 
mavenCentralMirror()
(link to custom maven central mirror). My initial thought is to create a far jar that contains all the dependencies the Gradle plugin needs, but I'm unsure how to make the 
java-gradle-plugin
and the 
com.gradle.plugin-publish
plugins use the fat jar and not the normal jar? Any ideas? edit: 
build.gradle.kts
file in 🧵
Untitled.kt
Untitled.kt
a
j
The documentation mentions that it is possible to shadow jars using the 
com.github.johnrengelman.shadow
gradle plugin. So I added the plugin, and I was no longer able to reload the gradle project in IntelliJ, receiving the following message: `Please configure the 
shadowJar
task to not add a classifier to the jar it produces`. So I added this:
Copy code
tasks.named("shadowJar", Jar::class.java) {
  archiveClassifier.set("")
}
Now the module is able to reload and publish to maven local, but when trying to import it I receive "Plugin [id: 'my-enterprise-plugin', version: 'UNVERSIONED'] was not found in any of the following sources:" This worked before adding the shadow plugin, but not after.
m
You can create a fatJar without the shadow plugin by adding the 
runtimeClasspath
files manually.
Something like this:
Copy code
tasks.register("fatJar", Zip::class.java) {
  from(configurations.getByName("runtimeClasspath").elements.map { it.map { zipTree(it) } })
  from(kotlin.target.compilations.getByName("main").output.classesDirs)

  archiveClassifier.set("fat")
}
Wildly untested
But if you don’t need to relocate (which shouldn’t be needed in your case), I found it’s often easier to do by hand
Another solution is to mirror the dependencies in your internal repo
v
I would avoid building a fat jar, especially if it is just to avoid repository declarations. Assuming your plugin is a project plugin, one way to mitigate could be: • Write another plugin in another project (can be in the same build) • This is a settings plugin with no external dependencies • It adds the two other repositories to the plugin repositories • Apply the settings plugin and apply the project plugin
2 Views
Open in Slack
PreviousNext
Powered by