I'm trying to share a dependency between multiple jars. My solution to this would be to include the dependency as a .jar in each one and then load the most up to date one at runtime (in order to not have multiple identical shaded versions, and to include resources from that dependency).
Essentially, I'm trying to make the compiled jar include dependency.jar as a resource - how can I achieve this with gradle? Or is there a better way of accomplishing this? I don't want to pull the latest version of the dependency .jar from a remote server as this has to work offline.
The easiest way of adding a dependency to your project without Gradle accessing a remote repository is to simply add the file as a dependency directly:
dependencies{
implementation(files("/path/to/myJar.jar"))
}
If you only want to stay offline you can run Gradle with the "offline" command line switch when you are offline. See the documentation.
To share across multiple modules you can declare the same file dependency in each module's build file.
Any attempt to compare versions between modules and/or load a JAR at runtime sounds excessively difficult to me.
Related
I want to use the Google Firebase Messaging library in my Android Project. But my laptop just works offline and has not any access to the internet. I want to download FirebsaeMessaging library with all it's dependencies then add those files as aar library files to my project. First I want to get list of all dependencies of that library. How can i do this without internet? Thanks.
There are two approaches in general:
You download the complete dependencies with your online system, copy them into a libs folder and then create a project where you dependent on every jar in that libs folder.
You create a maven based project, build the project so that every dependency is copied to your local repository and copy the .m2 (local repository) to your offline machine. In case you want a gradle based project, #lance-java already posted a solution to that.
The first approach has the advantage that you have an isolated project with no dependency to the internet. Everything is in your project and explicit. You would have to check in your dependencies into your source control system like in good old times.
The second approach is good, if you are working in a team on that project. The export of your dependencies hat nothing to do with the project setup itself. Every programmer would find a "normal" project setup and dependency management.
If guess, that you want to go for the 1. way. If so, I would suggest to use ivy to download the complete dependency tree. Put the ivy-X.Y.Z.jar into your project beside a script that lists all dependencies - some sort of poor mans dependency management.
Example:
$ java -jar ivy-2.5.0.jar -dependency com.google.firebase firebase-admin 6.8.1 -retrieve "libs/[artifact](-[classifier]).[ext]"
This command would download the complete dependency tree for com.google.firebase:firebase-admin:6.8.1 and store the jars without version into the libs folder.
You could use my dependency-export plugin to export dependencies to a directory using maven directory conventions. You can then use the directory as a local repository for building offline.
As of Gradle version 6.1 the dependency cache is portable meaning that you can copy the dependency cache from one machine to another and the second machine should be able build offline. Perhaps this is what you want?
See this issue
One of the 3rd party libraries used in my company is supplied to us as a zip file with tens of jars in it. The library releases a new version every two weeks, so I am looking for a solution that does not require a lot of manual effort each time a new release is out. I have recently started using Maven for dependency management and I have found it very difficult to deal with this particular 3rd party library. Should I...
add each individual jar to a company-internal repository (e.g. with Nexus) and then declare each one of them as a dependency to any new projects using this library? This is a laborious process and I can't imagine doing this for every new release.
create a jar of jars to add to our repository? If so, how do I create it? The Maven shade plugin would require that I mavenise the library first, right?
any better suggestions?
Your first option is the best practice. I'm not sure why it should be laborious.
create a simple script to upload the various jars to nexus
use a property in your pom to specify the third-party version so all deps can be changed with a simple property change in the pom
Should be all of 5 minutes to add a new release to your build pipeline.
Alternative: convince the third-party to setup a maven repository for their customers to use!
Its possible, but complicated (but only a 1 time effort) and probably a misuse of what maven's meant for:
Upload zip file to your local maven repo with a specific groupid:artifactId
Create a sub-module that has dependency on this zip file. Tis sub module should be used only for creating the uber jar
Use maven-dependency-plugin unpack goal to unpack the zip file into a directory
Use maven antrun unzip to unzip the jars to a dir
Use maven antrun zip to jar the files into a uber jar
Use maven-intall-plugin to install uber jar to your local repo and use as a dependency.
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.
I'm getting below error in STS:
The type org.springframework.core.env.EnvironmentCapable cannot be resolved. It is indirectly referenced from required .class files
This sounds like a transitive dependency issue. What this means is that your code relies on a jar or library to do something - evidently, you depend on Spring framework code. Well, all that Spring code also depends on libraries and jars.
Most likely, you need to add the corerctly versioned org.springframework.core jar to your classpath so that the EnvironmentCapable class can be found when your IDE attempts to build your project.
This might also be a jar collision issue as well, although that sounds less likely. When an application experiences jar collision (also known as "dll hell"), the compiler is finding multiple jars and classes with the same fully-qualified name. For example, let's say you added Spring to your classpath, along with the entire Tomcat server library. Well, those two jars may contain the same exact named classes, maybe the same version, maybe different versions. But either way, when the compiler looks for that EnvironmentCapable class, it finds two (in this contrived example) - one in the Spring jar and one in the Tomcat jar. Well, it doesn't know which one to choose, and so it throws a ClassDefNotFoundException, which would/could manifest itself as the error you experienced.
I faced same error while i work with spring security on spring-security-config.i jsut deleted that jar in maven repo and gave maven->update Project in eclipse.
it is resolved.Please try it once.
From command line, run "mvn clean install", you'll see project failed and you'll see artifacts in the logs that cause such a problem.
After that, remove artifacts from .m2/repository, then maven update from eclipse.
To avoid jar collision, make sure you declare your dependency versions under the properties tag in the aggregate pom.xml, and use the property name as a placeholder throughout the project. For example 4.2.5.RELEASE in the parent pom, and then in the child modules just use ${spring.version} instead of 4.2.5.RELEASE. This way you can avoid having two different versions of the same library on the classpath.
Also it is recommended to be consistent with the version of spring dependencies. Use the same version for spring-core, spring-web etc.
If you are using maven, then you can use the maven enforcer plugin to ensure dependency convergence, and avoid further issues with transitive dependencies.
I hope I can keep this question specific enough, my team at work is currently debating the best way to manage our dependencies for a huge project (150+ dependencies ~300mb).
We have two main problems
Keeping all the developers dependencies the same so we are compiling against the same files
Ensure the project (once compiled) is comliped against the same dependencies
The two ideas that have been suggested are using a BirJar (all dependencies in one file) and just adding a version number to it and using a shared folder and pointing everyone's machines at the same place.
Or making including all the dependencies in the jar when we compile it (a jar, of jars, of jars) and just have a project that "has no dependencies"
Someone also mentioned setting up an internal version of Ivy and pointing all the code to pull dependencies from there.
What are the best practices regarding massive dependency management?
Why don't you use Maven and its dependency management ?
You can specify each dependency, its particular version and its scope (compile-time, for testing, for deployment etc.). You can provide a master pom.xml (the config file) that specifies these, and developers can override if they need (say, to evaluate new versions).
e.g. I specify a pom.xml that details the particular jars I require and their versions (or range). Dependent jars are determined/downloaded automatically. I can nominate which of these jars are used for compilation vs. deployment etc. If I use a centralised repository such as Nexus I can then build my artefact (e.g. a library) and deploy that into Nexus, and it'll become available for other developers to download in exactly the same manner as 3rd party libs etc.
Incase you dont like/want to follow the Maven project structure...
If you already use Ant, then your best bet is to use Ivy for dependency management.
http://ant.apache.org/ivy/
It provides a rich set of ant tasks for dependency manipulation.
from : Ant dependency management