Im sure this is amazingly simple but its been a long day and the Gradle docs frustrate me at the best of times (I have looked).
I want to include a folder (libs) inside a predefinined artifact (bundleRelease).
This happens to be on android (aar build) and inside a maven-publish block like
...
releaseJar(MavenPublication) {
...
artifact bundleRelease
}
...
using gradle 2.3.
Thanks for any help here :)
EDIT: answered here Include /libs/ folder in aar
Depends on what you want for the syntax but if you want the jar files in the root of the aar
android {
...
sourceSets {
main {
resources.includes = [ '**/libs/*.jar' ]
}
}
If you want the entire folder included then I think this should be what you want
android {
...
sourceSets {
main {
resources.includes = [ 'pathTo/libs' ]
}
}
All that said you probably don't want to package the libs with the aar because if you publish to somewhere like jcenter or mavenCentral then the maven artifact when uploaded will create a pom file that will note its dependencies and gradle will transparently import them for your lib.
Related
First of all, sorry for my poor english.
Goal
I want create multi project containing some custom libraries as subproject with gradle.
For centralized dependency version control, using buildSrc and setting versions (spring-boot, detekt, ktlint etc.)
my-core-project(root)
+buildSrc
+-src/main/kotlin
+--int-test-convention.gradle.kts
+--library-convention.gradle.kts
+library-A
+-src
+--main/kotlin
+--test/kotlin
+-build.gradle.kts
+library-B
+-src
+--main/kotlin
+--test/kotlin
+-build.gradle.kts
+build.gradle.kts
+setting.gradle.kts
buildSrc contains common tasks for libraries(integration test, detekt, etc.)
library-A and library-B are custom libraries based on spring boot.
There is no application module or any main method.
my goal is using method of library-A and/or library-B with another separated project with adding my-core-project to dependency.
Problem
./gradlew build created 3 jar files
my-core-project
+build/libs
+-my-core-project.jar
+library-A
+-build/libs
+--library-A.jar
+library-B
+-build/libs
+--library-B.jar
copied 3 jar files to libs directory under project which actually using these library,
tried adding dependency created jar
with implementation(files("libs/library-A.jar")), class and methods are resolved well.
but with implementation(files("libs/my-core-project.jar")),
class and methods are not unresolved.
when check my-core-project.jar, recognized that any information of sub projects contained.
Here is my setting.gradle.kts and build.gradle.kts of root directory.
# setting.gradle.kts
pluginManagement {
repositories {
mavenCentral()
gradlePluginPortal()
}
}
rootProject.name = "my-core-project"
include(
"library-A",
"library-B"
)
# build.gradle.kts
plugins {
id("java-library")
id("io.spring.dependency-management")
}
group = "com.demo"
version = "0.0.1-SNAPSHOT"
dependencies {
api(project(":library-A"))
api(project(":library-B"))
}
repositories {
mavenCentral()
}
Tried things
In my opinion, my-core-project.jar should be fatJar(uberJar),
so i added FatJar task like this
val fatJar = task("fatJar", type = Jar::class) {
archiveBaseName.set("${project.name}-fat")
from(configurations.runtimeClasspath.get().map { if (it.isDirectory) it else zipTree(it) })
with(tasks.jar.get() as CopySpec)
duplicatesStrategy = DuplicatesStrategy.EXCLUDE
}
tasks {
"build" {
dependsOn(fatJar)
}
}
but cannot resolve class and method,
additionally occurs version conflict with other dependency of projects using this package, due to library-A created as fatJar too.
Question
Is there a simple way packaging/bundling sub-modules into one jar file?
if there are tasks like this already in gradle, prefer to use that.
Modifying fatJar task like "add jar of submodules, not contained dependencies" can solve this problem?(even couldn't try completely newbie to gradle and kts.)
if so, can you show me how to modify task?
tried shadowJar already. that solved version-conflict problem with relocate option. but still couldn't resolve package in library-A
If structure has problem, is there a good practice/example for "bundle of library"?
thanks for reading.
TL;DR
If someone faced this problem, try set archive name shorter than current one.
For someone who faced same problem, sharing some informations.
as result, resolved this problem.(maybe even not problem)
current shadowJar configure is as following
tasks.named<ShadowJar>("shadowJar").configure {
archiveBaseName.set("shorten-name")
archiveClassifier.set("")
exclude("**/*.kotlin_metadata")
exclude("**/*.kotlin_builtins")
}
exclude kotlin_metadata, kotlin_builtins
set shorten name(original project name was 30 long characters)
I have no idea but shorten jar file name has no problem.
Interesting one is, upload in artifactory package with original(long) name worked well.
I don't know Gradle declaring dependency with files has length constraints.
implementation(files("path/to/package"))
And now it works well with original name with local jar package file.
I am very excited about the incubating Gradle's version catalogs and have been experimenting with it. I’ve found that the information in my gradle/libs.versions.toml is accessible in the build.gradle.kts scripts for my app and utility-lib projects.
However, I am unable to use the content of the toml file for buildSrc/build.gradle.kts or the convention files.
The only way that I could build was to hard-code the dependencies into those files, as I did before the version catalog feature.
In the buildSrc folder, I created a settings.gradle.kts file and inserted the dependencyResolutionManagement code for versionCatalogs, which is pointing to the same file as for my app and utility-lib projects.
Based on the Gradle7 docs, it seems that sharing a version catalog with buildSrc and modules is possible… I’d appreciate a nudge into getting it to work with buildSrc, if possible.
Here is a simple sample project, which I created via gradle init: my-version-catalog
Thank you for your time and help,
Mike
With Gradle 7.3.3, it is possible. Note version catalogs are GA since Gradle 7.4
The code snippet assumes Gradle is at least 7.4, but if you need them prior that version, insert enableFeaturePreview("VERSION_CATALOGS") at the beginning of each settings.gradle.kts.
Using buildSrc
buildSrc/settings.gradle.kts
dependencyResolutionManagement {
versionCatalogs {
create("libs") {
from(files("../gradle/libs.versions.toml"))
}
}
}
buildSrc/build.gradle.kts
dependencies {
implementation(libs.gradleplugin.intellij) // <- the lib reference
}
You can even use the version catalog for plugins
gradle/libs.versions.toml
...
[plugins]
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }
jetbrains-changelog = { id = "org.jetbrains.changelog", version.ref = "changelog-plugin" }
jetbrains-intellij = { id = "org.jetbrains.intellij", version.ref = "intellij-plugin" }
hierynomus-license = { id = "com.github.hierynomus.license", version.ref = "license-plugin" }
nebula-integtest = { id = "nebula.integtest", version.ref = "nebula-integtest-plugin" }
build.gradle.kts
plugins {
id("java")
alias(libs.plugins.kotlin.jvm)
alias(libs.plugins.nebula.integtest)
alias(libs.plugins.jetbrains.intellij)
alias(libs.plugins.jetbrains.changelog)
alias(libs.plugins.hierynomus.license)
}
Note for accessing the catalog within scripts, please refer to the below section, the trick is the same.
Using convention plugins and included build
In the main project include a the Gradle project that holds the convention plugins.
build.gradle.kts
includeBuild("convention-plugins") // here it's a subfolder
convention-plugins/settings.gradle.kts
dependencyResolutionManagement {
repositories {
gradlePluginPortal()
}
versionCatalogs {
create("libs") {
from(files("../gradle/libs.versions.toml"))
}
}
}
rootProject.name = "convention-plugins"
The trick to enable convention plugins to access the version catalog is split in two part, add an ugly implementation dependency that locate where the version catalog generated classes are located.
libs.javaClass.superclass.protectionDomain.codeSource.location
Then in the convention plugin refer to the libs extension via Project::the.
val libs = the<LibrariesForLibs>()
This is tracked by gradle/gradle#15383.
convention-plugins/build.gradle.kts
plugins {
`kotlin-dsl`
}
dependencies {
implementation(libs.gradleplugin.kotlin.jvm)
// https://github.com/gradle/gradle/issues/15383
implementation(files(libs.javaClass.superclass.protectionDomain.codeSource.location))
}
And in the actual convention plugin
import org.gradle.accessors.dm.LibrariesForLibs
plugins {
id("org.jetbrains.kotlin.jvm")
}
// https://github.com/gradle/gradle/issues/15383
val libs = the<LibrariesForLibs>()
dependencies {
detektPlugins(libs.bundles.kotlinStuff) // access catalog entries
}
The org.gradle.accessors.dm.LibrariesForLibs class is generated by gradle is somewhere in local gradle folder ./gradle/<version>/dependency-accessors/<hash>/classes
Quick note that older IntelliJ IDEA currently (2022.3) reports alias(libs.gradleplugin.thePlugin) as an error in the editor,
although the dependencies are correctly resolved.
This tracked by KTIJ-19369, the ticket indicates this is actually a bug in Gradle Kotlin DSL gradle/gradle#22797, and someone made a simple IntelliJ IDEA plugin to hide this error until resolved.
Brice, it looks like a can of worms to go down that path, particularly for my situation, where I'm trying to use a libs.version.toml file from an android project, but the custom plugin is of course from a java/kotlin project. I tried creating the libs file by hardwiring the path to the toml file in the custom plugin. It might work if both were java projects, but I never tried that since that's not what I'm after. The ideal solution would be for the plugin to use the libs file from the project it is applied to, but it looks like the version catalog needs to be created in the settings file, before you even have access to "Project", so that's why you would have to hardwire the path.
Short answer. No, but there are other techniques for a custom plugin to get project version data from the project it is applied to.
The maven assembly plugin has an includeBaseDirectory option that (when set to false) avoids having a single top-level directory inside the tar/zip artifact with the same name as the artifact itself.
I'd like to achieve the same result with Gradle, but I don't see how. I'm using a configuration like this:
task distTar(type: Tar) {
compression Compression.GZIP
extension "tar.gz"
}
I don't see any options for the Tar task that do what I want. How can I exclude the base directory in my archive with Gradle?
By reconfiguring the distribution plugin (which gets implicitly applied by the application plugin) you can simply do (in Kotlin DSL):
distributions {
main {
contents {
into("/")
}
}
}
This affects the output in both Tar and Zip formats.
(Disclaimer: This answer is loosely based on this Gradle forum post).
Ok, I figured it out. It was simpler than I thought. To copy the library dependencies into lib at the root of the archive, I use a CopySpec:
task distTar(type: Tar) {
into('lib') {
from libsDir
include '*.jar'
}
}
Similar CopySpecs can be used to copy e.g. bin and conf directories.
We have an old playframework 1.2.x version where we copy all the jars to project/lib so playframework can consume them. We would LOVE to copy all the source jars as well so that when runnig play eclipsify, we can view all the third party source. Is there a way to do this with gradle?
and I mean all the source jars that were downloaded when I ran gradle eclipse as I saw them download the cache locations. We have gradle eclipse calling play eclipsify for us on the one project as well so we can 100% just use gradle.
thanks,
Dean
this is not that straight forward as expected. The following snippet copies the source jars for all dependencies (runtime + compile) of a java project into a specific folder:
task copySourceJars(type:Copy){
def deps = configurations.runtime.incoming.dependencies.collect{ dependency ->
dependency.artifact { artifact ->
artifact.name = dependency.name
artifact.type = 'source'
artifact.extension = 'jar'
artifact.classifier = 'sources'
}
dependency
}
from(configurations.detachedConfiguration(deps as Dependency[]).resolvedConfiguration.lenientConfiguration.getFiles(Specs.SATISFIES_ALL))
into('sourceLibs')
}
The reason we use a lenientConfiguration here is, that we don't want to fail if a source artifact cannot be resolved. There might be a more elegant way, but I havn't looked deeper into that.
hope it helps,
René
Rene answer will download sources jars of direct dependencies, not sources jars of all transitives dependencies.
Here is a task that will do the trick:
task copySourceJars( type: Copy ) {
def sources = configurations.runtime.resolvedConfiguration.resolvedArtifacts.collect { artifact ->
project.dependencies.create( [
group: artifact.moduleVersion.id.group,
name: artifact.moduleVersion.id.name,
version: artifact.moduleVersion.id.version,
classifier: 'sources'
] )
}
from configurations.detachedConfiguration( sources as Dependency[] )
.resolvedConfiguration.lenientConfiguration.getFiles( Specs.SATISFIES_ALL )
into file( 'some-directory/' )
}
One can then do the very same for javadocs jars by changing the classifier to javadoc.
Here eskatos solution translated in Kotlin DSL:
tasks {
"copySourceJars"(Copy::class) {
val sources = configurations.runtime.resolvedConfiguration.resolvedArtifacts.map {
with(it.moduleVersion.id) {
dependencies.create(group, name, version, classifier = "sources")
}
}
from(
configurations.detachedConfiguration(*sources.toTypedArray())
.resolvedConfiguration.lenientConfiguration.getFiles(Specs.SATISFIES_ALL)
)
into(File("some-directory"))
}
}
Currently, our gradle setup is geared to publish to certain maven repositories when a build is done. For a particular customer, I need to zip up the jars, license files, pom.xml, and ivy.xml files, and send it all in a zip. To do this, I just need to define an alternate location to publish it to. All the documentation on the gradle site seems aimed at writing one set of publishing rules, not an alternative set.
I was hoping to simply write a different task which would focus on building this customer-specific zip file. So far, I have it collecting all the jars (which includes source and runnable code) along with the license and notice file. But I haven't cracked the nut on defining a local ivy repository and a local maven repository that is only part of this alt task.
task alt {
dependsOn subprojects*.tasks*.matching { task -> task.name == 'assemble' }
subprojects.each{project ->
if (project.hasProperty('sourceJar')) {
evaluationDependsOn(project.name)
}
}
File altDir = mkdir("$buildDir/alt")
subprojects.each { project ->
if (project.hasProperty('sourceJar')) {
// Extra the module name from the path of the sub-project
String submodule = project.projectDir.absolutePath.split(File.separator).last()
File subfolder = mkdir(altDir.absolutePath + "/${project.group}/${group}.${submodule}/$version")
project.tasks.withType(Jar).each {archiveTask ->
copy {
from archiveTask.archivePath
from("$rootDir") {
include 'license.txt'
include 'notice.txt'
}
into subfolder
}
}
}
}
}
Here's the gradle docs that tells you how to generate the pom. Also if you are looking to install that file to your local repository you could use the mechanism described in this blog entry . Essentially all you have to do
configure(install.repositories.mavenInstaller) {
pom.project {
version '1.0'
artifactId 'your.artifact.id'
groupId 'your.group.id'
}
}
It doesn't look like it possible at the moment to generate the ivy.xml through gradle, but once you have your pom file you could use ivy itself to generate the ivy file described here.
Section 64.5 of http://www.gradle.org/docs/current/userguide/publishing_ivy.html covers "Generating the Ivy module descriptor file without publishing".
The documentation is a little broken (eg inconsistent naming conventions). The following works for me:
apply plugin: 'ivy-publish'
publishing {
publications {
aoeu(IvyPublication)
}
}
This will generate a target generateDescriptorFileForAoeuPublication.