I know Java pretty well and am an experienced C/Python programmer, but I may have some fundamental misconceptions when it comes to Gradle.
I'm developing in the terminal and vim, it's just who I am. I have Apache Derby set up on my system: downloaded, environment variables set, etc. I wish to use this in my Java project which I'm building with Gradle, but I don't know how to include it in the dependencies other than from the Maven repository.
If I do:
testCompile group: 'org.apache.derby', name: 'derby', version: '10.5.3.0'
My understanding is that this downloads it from the Maven repo again. Am I going about things the wrong way by wanting to use my system Derby, or is there a way to point Gradle to it? If this question is riddled with misconceptions I would appreciate them being put straight.
Thanks.
+1 for using vim/terminal, that is cool! 😎
Gradle is extremely flexible and will do whatever you ask - although there are best practices, see below. You can have a libs/ folder with all your libraries in it, and point Gradle to it:
dependencies {
implementation fileTree('libs') { include '*.jar' }
}
This will add all JARs in the libs/ folder to your classpath. Gradle calls this a file dependency. The libs folder does not have to be in your project directory, so yes, you can point to your system-wide libs, too.
However.
Gradle has a very advanced caching mechanism, which will minimize network usage and even balance this with local storage requirements. It will also reliably share downloads between projects. You want to use this.
Also, many Java libs have dependencies of their own ("transitive dependencies"), often quite a lot of them, resulting in whole trees of dependencies. Since the transitive closure of all of them will end up on your classpath, there can be conflicts, which Gradle will resolve for you. You will not want to perform manual dependency resolution.
Plus, your project will be easier to compile for others because Gradle will make sure the dependency is loaded and present. Whereas a "system derby" would need to be installed in some other way before running Gradle.
File dependencies have a myriad of other problems as well, so I would urge you to have Gradle handle this for you and use the syntax from your question:
dependencies {
implementation group: 'org.apache.derby', name: 'derby', version: '10.5.3.0'
}
Here's a little more info on so-called "configurations", like testCompile and implementation to help you choose the right ones.
All of this will work perfectly with Vim and terminal. So well in fact that I often call Gradle from a terminal while developing in IntelliJ. 😊
Related
Apologies if this question has already been asked, the barrier to entry with Gradle seems very high and I'm not sure what to search for.
My Kotlin project depends on various artifacts to offer the Kotlin runtime, such as kotlin-stdlib-jdk8-1.2.60.jar, for example.
The Kotlin library is being loaded by a raw Java application.
I need to inform the Kotlin library JAR that I am distributing to look in the /kotlin directory (relative to the directory in which it will be placed) for its runtime libraries and any other dependencies. From what I have seen, I need to add this to the runtimeClasspath or similar but I am unsure how.
Thanks for any help.
If your jars are public for the world, you would only need to declare them in your build.gradle (module, not project) like
implementation 'com.squareup.retrofit2:converter-scalars:2.3.0'
Gradle would pick them up, no need to store them in your project.
I'm building a java application with Intellij-idea, Gradle and Mongo. I created a new Gradle project and I was having some trouble importing mongodb-java-driver inside my project. I modified this piece of code inside build.gradle:
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.11'
compile 'org.mongodb:mongo-java-driver:3.4.1'
}
But was unable to use Mongo with Java. My External Libraries didn't have any Mongo jar. Then I saw here that I should add the application plugin to my build.gradle. I searched on the official docs that this plugin "will automatically add run task that will execute the specified main class with all the runtime dependencies automatically put on the classpath:" as the answer linked above stated. But this didn't solved my problem.
Then I added the idea plugin, since I saw here that "The IDEA plugin generates files that are used by IntelliJ IDEA, thus making it possible to open the project from IDEA". I didn't think that would help me but was worth a try. Unfortunately, this didn't helped either.
After this I saw here that I should synchronize my project. Since I created this from zero and didn't import any complete project from outside I didn't understand why I should synchronize it. While it was synchronized, I saw Intellij was downloading mongo-java-driver. After that, I still was unable to use Mongo. I had to add the downloaded jar to my project class path, as this was one of the suggested corrections given by Intellij.
I've come from Eclipse/Maven and I'm discovering how Intellij/Gradle behave. So my question is what is strictly necessary to use mongodb-java-driver on Intellij/Gradle and why I had to synchronize my project? Is this the correct way of using Gradle? Always building and synchronizing after?
I have some questions about Gradle.
What is the difference between buildscript.dependencies and
dependencies ?
What is the difference between classpath and compile?
What does apply plugin: mean?
Just check their docs, they have described it well. But here is it:
1:
If your build script needs to use external libraries, you can add them
to the script's classpath in the build script itself. You do this
using the buildscript() method, passing in a closure which declares
the build script classpath.
This is good for external dependencies (for example from internet repos which are in buildscript part too.)
2:
Docs with table and descriptions for each.
compile will get dependencies during compiling. (for example you can set 'runtime' and these dependencies will be used during runtime, or testCompile will be used only during compiling tests). This is very important! Read their docs. Of course you can try to compile everything everytime, but this is really bad idea. Good example are JUnit tests, you need JUnit only during compiling tests co then you use compileTest:
testCompile "junit:junit:X.YZ"
3:
It means that you applied plugin :) You apply java, or when you need spring or spring boot, then you simply can tell Gradle, hey Gradle, I am going to using this, so aplly it. More here.
I suggest you download the full Gradle distribution, only because it provides a PDF version of the User Guide (I don't know of any other way to get the user guide PDF). Read it from top to bottom, skipping chapters that are clearly irrelevant to you. You will get answers to all of these questions, and more that you haven't asked yet.
However, I'll give you some brief answers.
Q1: Gradle has dependencies for the build script, and dependencies for the code you're building. They are separate.
Q2: Classpath is a runtime notion used by Java, which Gradle utilizes in different ways. Compile is a "configuration" which you can add dependencies to, which affects the eventual runtime classpath.
Q3: "apply plugin" is applying a Gradle plugin. Read the user guide.
A bit of background about my knowledge level: I'm currently trying to learn how to build a project with gradle. So far I don't have much experience with build tools (almost none). I do understand the general idea and have seen ant and maven files before but never written them myself. Until now I just used other peoples build scripts or configured my builds using Eclipse. So I might be on a completely wrong track here, if so please point me in the correct direction.
Also, I sadly don't have much experience building jars by hand.
I have an Eclipse project which I want to compile into a jar. Required library jars are on my local file system. I managed to make gradle use these via
dependencies {
compile fileTree(dir:'lib', include:'*.jar')
}
in addition I have my source files in src/main/java and just use apply plugin: 'java' in the build.gradle file. Trying to build the project with gradle build seems to do the right thing, as far as I can tell.
However, the library is supposed to be used in a web project running on a tomcat and makes use of some libraries that are supplied by tomcat, as far as I understand. E.g. I'm using javax.servlet.http.HttpServletRequest.
The project works fine in Eclipse, but there I have the tomcat library added to my Eclipse build path. When I check in Eclipse I can see that javax.servlet.http.HttpServletRequest is part of the servlet-api.jar which is part of the Tomcat library.
Now, when I build the project I get build errors because the java compiler cannot find the class because I didn't specify the servlet-api.jar in the dependencies. I guess I could download it somehow (or learn how to specify it as an external dependency to make gradle download it from some repository) but I am not sure whether that would be correct.
Is there a way to tell gradle to use the same library that Eclipse uses? Or some other general way to tell it about all the tomcat jars, the same way I can simply add the complete Tomcat library in Eclipse?
Or do I actually need another copy of these jars somehow and have to specify each one individually?
Also, do I need to add these library jars to my build-result library jar? As far as I know I need to add any jar I depend on to the resulting jar as well. But then again, I have read somewhere that some libraries are supplied by tomcat itself so they would have to be part of any war deployed on it.
I'm afraid, I'm confused by the combination of how to build a jar-file to be used in a war-file to be deployed on a tomcat using gradle and I don't know from which of these parts my problems originate. I hope someone reading this can help me untangle my thoughts and point me in the right direction or at least tell me how to add the jars included in the Tomcat library to my gradle dependencies.
With Gradle, whenever you add files or directories as dependencies, they are not treated as full-fledged artifacts (with group, name and version), but rather as simple files containing classes. It means that Gradle will not perform any conflicts resolutions on them, or pull transitive dependencies.
For you, just to get started, I recommend just to add tomcat dependency. Make sure it is the same version as the one in Eclipse.
apply plugin: 'war'
repositories {
mavenCentral()
}
dependencies {
providedCompile 'org.apache.tomcat:tomcat-catalina:7.0.47'
}
Also, look into Eclipse Integration Gradle project as a long-term solution.
Perhaps the reason I stalled learning Java until now is because I HATE how Java handles external libraries. I'm stuck keeping them in one place, adding them individually, fixing problems with versioning and every time I move/rename them, and copying and writing the classpath over and over each time I release a Java application.
There has to be an elegant solution to all of this. I keep all of my libraries (regardless of task, platform, or other) in their own little folder inside a "lib" folder in my development folder, kind of like this:
Dev
-lib
+JS-jQuery
+Flex-Degrafa
-Java-Xerces
+Xerces-1.2.3
+More libraries
I can use either Netbeans or Eclipse for Java dev, but none of them provide a very streamlined (and not to mention idiot-proof) way of managing all of these.
A nudge in the right direction or an online article/tutorial on this would be greatly appreciated.
You can either use Ant + Ivy or Maven to manage your library dependencies.
If it is only dependency management you're after and you're happy with the rest of your build process, I would use Ivy, as it can unobtrusively manage your dependencies, leaving your existing build process intact. There is a plugin for Eclipse called IvyIDE that contributes your dependencies via a classpath container.
Maven 2 has a steeper learning curve but provides a much richer set of functionality for building your projects and Eclipse integration through m2eclipse or IAM.
Personally I use Maven as I have a large number of projects to work with and Maven is particularly suited to efficient development across lots of projects.
Have a look at the introductory documentation to see what works for you.
Ivy Tutorial
Maven Getting Started Guide
Netbeans 6.7.1's Maven support is quite good and comes out of the box with the IDE.
The Eclipse addon was frustrating enough that I gave Netbeans another try.
A third choice besides ChssPly76's options is to use Ant with the Maven Ant Tasks. I don't know if I'd call any of these solutions particularly "elegant," but they do spare you the need to manage your own lib/ directory and classpath variables.
If you're working on Linux you can install Java libraries with APT or RPM.
Otherwise, I normally check precompiled JARs into a lib directory in my project's version control repository and make sure the names of the JAR files include full version information. E.g. lib/foo-1.5.6.jar, not lib/foo.jar.
To avoid having to manually set the classpath before running your app, you can set the classpath in the Manifests of the JARs themselves to define the dependencies of each JAR file. The JVM will follow all the dependencies when loading classes.
Maven is often more trouble than it's worth, but the ability to open a maven project directly into IDEs such as IntelliJ is excellent. For example, IntelliJ will download all dependencies and have them available without having to run a build first, or an mvn command and then a project refresh. It also isn't necessary to re-generate the project every time a dependency is added. I work with a number of Eclipse developers who switched to IntelliJ for this alone.
However, one shortfall of Maven is that many libraries (or versions of libraries) are not available on public repositories. Therefore it is often necessary to set up a local repository such as archiva. In ant, it would just be a matter of adding it to the lib directory in the repository.
Maven can also attack when you need to do something that maven doesn't directly support via a plugin. What would normally be a few lines of ant can often turn into a morning's worth of work.
Finally, buildr is an excellent way of using Maven's dependency management and plugins, while also supporting ad-hoc tasks.