In my gradle java library project, I have a dependency on a local jar file (the artifact is not published anywhere). The dependencies configuration looks like:
dependencies {
api fileTree(dir: '3rdparty', include: '*.jar')
}
When I publish my library to maven local, and then pull it in from another project, the symbols from the jar in the 3rdparty folder aren't available on the classpath, even though it's listed as an api dependency. Is this just a limitation of using jar files directly within library modules or something?
This is a well known limitation on File Dependencies. The Gradle documentation is clear on that
File dependencies are not included in the published dependency descriptor for your project. However, file dependencies are included in transitive project dependencies within the same build. This means they cannot be used outside the current build, but they can be used within the same build.
The reason is simply that those dependencies are not externally resolvable by other projects in contrast to artifacts hosted in a binary repository. Read more about this topic in the Declaring Dependencies userguide.
Related
In my springboot application (kotlin+gradle) I'm trying to use one of my libraries stored in Nexus. This nexus-library needs some dependencies from AWS sdk and other repositories.
Must I configure gradle.build.kts with all the repositories needed to fetch all these extra dependencies?, does it know gradle where are all these dependencies directly from the Jar?, or.....how is this done?
Gradle will use the POM file for the dependency to work out any transitive dependencies, and will attempt to retrieve them from your configured repository. If they are not available directly from there then you'll need to add additional repositories into your Gradle configuration to tell Gradle where it can search for these dependencies.
For Gradle version 6, Gradle will try to resolve a dependency in the following order
Gradle module metadata (a JSON file with .module extention)
Maven metadata (.pom file) or Ivy metadata (.ivy file) depending on Maven or Ivy repository respectively
The artifact(E.g., jar) itself if no metadata is found. This has been disabled but can be enabled through an additional configuration.
See Gradle documentation for more information.
Unlike external dependencies (from Maven, Ivy, etc.) local JAR files usually do not provide a list of transitive dependencies for Gradle. Unless they theoretically do in form of files pom.xml and pom.properties in directory META-INF/maven/<groupId>/<artifactId>. As far as I understand these are the same files Maven uses to provide transitive dependencies for an artifact.
So I wonder if Gradle is somehow able to read these transitive dependencies from a local JAR file as if the local JAR was an external dependency. Only adding the local JAR as dependency seems to ignore the embedded pom.xml.
Use case: I am writing an Plugin API JAR for an internal product which should be used by our developers to develop plugins. The API JAR has some external dependencies (Hibernate Annotations in domain classes, dom4j, stuff like that) and it would be great if the developer wouldn't have to define these dependencies by himself (they could change with newer API version). I also don't want to create a fat JAR containing all dependencies because a) the size! and b) it would not contain the sources of the external dependencies.
Is there a simple way to have gradle automatically generated a pom file listing the jar dependencies (both to published jars of other sibling projects and external) and have it included in the jar and published to a maven repo?
There is a lot of documentation on this subject but I am either missing something or it is as complicated as it seems. Can this not be done automatically?
On mvnrepositry, when you search for a certain module, there's a link to download the binary. For some versions it has a pom.xml file available for download instead of the jar. What are you supposed to do with that pom.xml? It seems like if I specify a version that does not have a downloadable jar, but instead downloadable pom.xml, my maven build will fail. Is what I'm seeing correct?
Modules that only have pom files are maven modules with pom packaging. They are used to aggregate multiple modules into one unit. You can use such a module as a dependency for your maven project. Maven will download the pom file, analyze the dependencies included in that pom file and download those & add it to your automatically.
Even modules that have jars (jar packaging) have a pom file associated with them. This pom file defines the other dependencies that are required for using it. Maven will automatically process and fetch those dependencies (transitive dependencies).
This makes specifying and managing dependency for any project. You will specify the top level modules that your projects directly depends on and other things required will automatically figured out and downloaded. It also makes it easier when you have upgrade to a new version - all the transitive dependencies will get upgraded automatically.
One of the reason that cause this is because of licensing issue.
License for such JARs prohibit public redistribution in such approach. So someone provide only the POM so that you can get the JAR yourself and install it to your local maven repo/ internal repo, together with the POM provided.
I want to include Astyanax into my project. I checkout the code from github and compiled it with "gradlew build". I am not familiar with gradle.
I include the Astyanx jar files manually into my project. When I run it, it complains about missing Jar.
I wonder, where I can download all the dependencies bundle for Astyanax?
Java library projects often don't provide a single download location for their dependencies. Instead, you would typically use a build tool that supports Maven repositories (e.g. Maven or Gradle) for your own project, which would then automatically download required dependencies behind the scenes.
If you do want to get hold of all dependencies for the Astyanax project, try to add the following to its build.gradle:
task copyLibs(type: Copy) {
from configurations.runtime
into "libs"
}
Running gradlew copyLibs should then copy all (compile and runtime) dependencies into the libs directory.