The scenario. I write LibraryA which needs to use a newer version of a library (Caffeine in this case, and specifically v2.6.2). I will build and upload this artifact to our build artifactory
LibraryA is intended to be used by other teams (unknown to me) in an older Spring Boot 1.5 environment . The issue is that Spring Boot internally uses an older version of Caffeine 2.3.5 (although to me , it could use a newer one).
What I see is at runtime, the older version dominates the newer version resulting in class not found exceptions in my lib
Is there a way, I can force my library to always use the newer desired Caffeine version . This would be easy to do if I had control over the code using my library but I'd like to accomplish this within the scope of my library. I tried all the dependency resolution strategies in the gradle documentaion but they are always overridden by the invoking (spring-boot) application
You should use package relocating from gradle shadow plugin.
In your case you just add following to your build:
shadowJar {
relocate 'com.github.benmanes.caffeine', 'shadow.caffeine'
}
Related
While I worked on a Micronaut project und tried to solve some problems, like dynamic versioning of dependencies and creating a multi module micronaut project with Gradle. I found in some code examples of the build.gradle this dependency:
annotationProcessor platform("io.micronaut:micronaut-bom:2.0.0")
But I could not find any official documentation referring to it. What does it do? Can it help me with versioning my dependencies?
The Micronaut BOM (Bill Of Material, further reading) declares all the framework dependencies of a specific Micronaut release. In your example it is the BOM of Micronaut release 2.0.0.
By declaring the as a platform dependency you don't have to worry about Micronaut about the versions of supported JARs, since they already are defined in the BOM.
For example if you decide to use the Caffeine Cache with Micronaut you simply declare it as a dependency but omit the version number.
dependencies {
implementation("io.micronaut.cache:micronaut-cache-caffeine")
}
That way you make sure that you are using well tested dependencies with your Micronaut release.
why is it an `annotationProcessor?
An update since the following question came up.
Uuh. Nice. So its a collection of dependencies with the best working versions for my specific micronaut version? Cool. And why is it a annotationProcessor?
annotationProcessor is Gradle related and is called a dependency configuration. When using the java Gradle plugin you have out of the box dependency configurations such as implementation or api.
With a dependency configuration you configure the dependencies for e.g. an annotation processor by using the configuration annotationProcessor. implementation is used for your compile time dependencies. And if you want to expose the dependencies to other modules that use your module you might want to use api instead of implementation.
I am working on a spring boot Gradle application that has a dependency on spring-ldap. The issue is, I need to use our firm's custom dependency for ldap operation which has an older spring-ldap version bundled in it: org.springframework.ldap:spring-ldap-core:1.3.0.RELEASE but the spring-boot dependency comes with the newer version: org.springframework.ldap:spring-ldap-core:2.3.3.RELEASE.
By default Gradle promotes to the newer version of the dependency but even If I force to use any one from these dependency versions, it is throwing runtime MethodNotFound exception at a different location as both dependencies have different method names which are being used by both parent dependencies.
It seems that I need both dependencies in order to run the application and use them from different parent dependencies like:
Spring boot autoconfigure -> spring-ldap-core:2.3.3.RELEASE
Firm's dependency -> spring-ldap-core:1.3.2.RELEASE
What is the best available solution for this?
Suppose I've created spring boot project with version 2.3.5.RELEASE(Project_1) and other user utility library using spring-boot version 2.3.0.RELEASE(Project_2).
if I Project_2 as dependency in Project_1, will it cause any issues as both project uses different versions of spring-boot?
If the library has a hard dependency on version-specific spring boot functionality, then sure, it will cause an issue. Just like with any dependency.
I have a RESTful web service application in java deployed on google app-engine which uses jersey 1.18.6.
I want to use postmark java client to send transactional emails from it.
When I integrated it, i was seeing the following exception:
javax.ws.rs.core.Response$Status$Family.familyOf(I)Ljavax/ws/rs/core/Response$Status$Family
From what I could find, I think this error was because of there were two different (and probably incompatible) version of jersey being used ,1.18.6 for jersey-server, jersey-guice and jersey-bundle and 2.25.1 for jersey-client (by postmark).
Then I tried to make the jersey version 1.18,6 throughout, so in the my main project pom, while including the dependency for postmark, I excluded the jersey-client (by added exclusions header) and separately added jersey-client dependency in my main project .
But then I got the following error:
java.lang.NoClassDefFoundError: javax/ws/rs/core/MultivaluedHashMap
This is I think the class MultivaluedHashMap is present only in jax-rs 2.x versions (which is compatible with jersey 2.x versions)
So my questions are:
Is there a version of postmark java client library which uses jersey 1.x instead of jersey 2.x?
If no then what options do I have other than migrating my main project from jersey 1.x to jersey 2.x. I don't want to do that since we will have to migrate not just the jersey dependencies but I think some other things like guice, shiro etc. which would be time consuming. Also it doesn't really seem optimal to modify multiple existing dependencies just to include one additional module.
There isn't. The very first commit of the project's pom.xml already used Jersey 2.25.1
as Mureinik mentioned above, when we worked on the library, our plan at Postmark was to use newer library versions, since they are better options in long run.
On our Github page Rupert made good suggestions, from which I find separate ClassLoader a good choice. I will play a bit with the library code in next couple of days on compatibility, however we are always in favour of using newer libraries for our codebase.
please check out my latest comment on Github issues page for possible solution for using older Jersey version https://github.com/wildbit/postmark-java/issues/11
It should be pretty easy to port the library to Jersey 1.x by porting only the HttpClient class on your side.
When using the spring plugin for struts 2, is it possible to use the latest version of spring or are you stuck with the version referenced in the plugin? For example in my project I am using struts 2.3.16.3 and its spring plugin automatically uses spring 3.0.5 . So if I add spring 4.1 to my pom as a dependency then there are multiple versions of spring added to the classpath.
You shouldn't have more than one Spring library in your classpath - disaster will be bound to happen. I guess you can either exclude the spring dependency in that plugin or set its version to the one you want.
The main problem with this approach is moving between major versions (3.x to 4.x) - if Spring is respecting Semantic Versioning incompatibilities will exist between the two versions and it is possible (or likely) that struts2-spring-plugin is using something that changed.
Edit: Comment below reports successful usage of struts2-spring-plugin and Spring4.