I have recently updated Elastic Search from 0.90.0 to 1.3.2 and now I'm getting a conflict with a Lucene version used by another dependency. The scenario look as follows:
jar A uses Lucene 4.9.0
jar B uses Lucene 3.3.0
The point is that I'm getting a java.lang.VerifyError because B code is overriding a final method of a Lucene's class which is not final at 4.9.0 version.
I've tried this with no success:
compile ('A')
compile ('B')
compile ('org.apache.lucene:lucene-core:4.9.0') {
excludes(B)
}
compile ('org.apache.lucene:lucene-analyzers-common:4.9.0') {
excludes(B)
}
I don't know what more to do, any clues on this?
Thanks!
Assuming you want the latest version of Lucene, your exclusions are actually backwards.
Your declaration of B should look something like this:
compile ('B') {
excludes "lucene-core", "lucene-analyzers-common"
}
Include any other lucene jars that might conflict in that list as well.
If you aren't specifically utilizing any lucene libraries (aside from the elasticsearch plugin) in your code, you can remove the explicit Lucene declarations.
I don't know enough about Lucene to tell you whether 4.9.0 is backwards compatible with 3.3.0, but this solution should at least make sure that 4.9.0 is what is on your project's classpath, and not 3.3.0
Related
We are using a Jenkins Shared Library to centralize some code for all our (scripted) pipelines. Now we factored out some Groovy code into a .jar library (written in Kotlin, compiled to be Java 8 compatible). We published this library to our in-house maven repo and now want to use it in our Shared Libary.
We are using #Grab to load our library and up until that point it works like a charm. However we are getting NoSuchMethodError's. We pinpointed it down a bit, we are using OkHttp in our Kotlin lib. OkHttp internally uses Okio. When we call methods that internally call OkHttp-Code from our pipeline, everything is fine. However when the OkHttp-Code call Okio internally, we get a NoSuchMethodError.
We already checked the published .jar file, it contains the classes with the methods that seem to be missing. Does anybody have an idea what the issue could be?
While we are at it, we can't access environment variables set on Jenkins in our Kotlin library, is there a way we can fix this?
We figured it out. The problem was, that a Jenkins plugin used an older version of okio internally. Because plugins and shared libraries somehow share the same classpath, okio did not get loaded and the version from the plugin got used, therefore the class was not present.
We fixed this by repackaging all dependencies in our .jar, so package names would not interfere and we can make sure that our specified dependencies are being used.
Looking the dependencies here you have a few problems:
OKHttp - seems to expect some Android libraries
okio - depends on the Kotlin runtime
Any calls to these will result in method not found errors unless you find a way to make them available without causing problems in Jenkins
My goal is to use the hosebird client provided by Twitter to stream tweets in my Grails project.
I'm really not sure how I will approach this, but I first tried including it in the dependencies in my BuildConfig.groovy like this:
dependencies {
compile 'com.twitter:hbc-core:2.2.0'
}
And then, when I tried to mimic the example code, FilterStreamExample.java, in my TwitterService.groovy, GGTS (the IDE) just shows me errors as I write these lines of code:
import com.google.common.collect.Lists
import com.twitter.hbc.ClientBuilder
import com.twitter.hbc.core.Client
import com.twitter.hbc.core.Constants
import com.twitter.hbc.core.endpoint.StatusesFilterEndpoint
import com.twitter.hbc.core.processor.StringDelimitedProcessor
import com.twitter.hbc.httpclient.auth.Authentication
import com.twitter.hbc.httpclient.auth.OAuth1
Obviously, this makes me unable to run the code because of the compile time error. It just tells that the error is something "Groovy was unable to resolve".
Can you tell what am I missing?
Is it just a groovy syntax error that I'm not noticing? I'm new to Groovy so please bear with me.
OR
Is the problem here is in the inclusion of the library in the dependencies?
My first aim is to be able to use the library this way as I have told it above (the BuildConfig way) before trying to make jars and put it in the src/java. Who knows, the compile time error will appear too. I just want to know if the current obstacle in the approach I did is easy to fix.
GGTS and STS don't parse BuildConfig.groovy - they get all classpath information from Grails. When you update BuildConfig.groovy with a new plugin or jar dependency, right-click on the project node in the tree on the left and select Grails Tools | Refresh Dependencies and GGTS will rebuild its classpath based on the current state of the app.
I'm trying to put paper elements in my angularDart app, so I have put in my pubspec.yaml the following dependencies:
dependencies:
angular: ">=1.0.0 <2.0.0"
paper_elements: ">=0.5.0 <0.6.0"
And then when I try to pub upgrade I get the following:
Pub: Upgrade Dependencies: Incompatible version constraints on
html5lib:
- angular 1.0.0 depends on version >=0.10.0 =0.11.0 <0.13.0
I'd really like to use the 1.0.0 (at least) version of angular Dart, however I was wondering if there was a way to satisfy both libs' dependencies. (and how does someone get to know what the correct dependencies' versions are)
Note that I tried doing the same with Polymer and facing the same problem (with a different dependency), so a general way of working around this would help, instead of just giving version numbers.
Just use dependency overrides.
dependency_overrides:
html5lib: 0.12.0
There is no way to satisfy both when their constraints have no common set.
It's at your own risk when one of them doesn't work properly with the specified version.
I'm installing and configuring Polymer and i get to this:
Unable to find a suitable version for polymer, please choose one:
1) polymer#master which resolved to ced408df76 and is required by core-component-page#a431519835, highlightjs-element#a2c5fc08d0, marked-element#761922b4a2
2) polymer#0.2.4 which resolved to 0.2.4 and is required by core-ajax#0.2.4, core-bind#0.2.4, core-collapse#0.2.4, core-doc-viewer#0.2.4, core-elements#0.2.4, core-firebase#0.2.4, core-icon#0.2.4, core-icons#0.2.4, core-iconset#0.2.4, core-iconset-svg#0.2.4, core-input#0.2.4, core-layout#0.2.4, core-layout-grid#0.2.4, core-layout-trbl#0.2.4, core-list#0.2.4, core-localstorage#0.2.4, core-media-query#0.2.4, core-menu-button#0.2.4, core-meta#0.2.4, core-overlay#0.2.4, core-range#0.2.4, core-selection#0.2.4, core-selector#0.2.4, core-theme-aware#0.2.4, core-tooltip#0.2.4, core-transition#0.2.4
3) polymer#~0.2.4 which resolved to 0.2.4 and is required by project
Prefix the choice with ! to persist it to bower.json
I'm still learning about and i dont know which one i should choose and why this problem happend. Can anyone explain me this tree options?
Thanks..
The recommended way to install Polymer 0.2.4 is through Bower. We’ve
chosen Bower because it removes the hassle of dependency management
when developing or consuming elements.
from http://www.polymer-project.org/docs/start/getting-the-code.html
I'd go with
2) polymer#0.2.4 which resolved to 0.2.4 and is required by
...
This happened because when bower went to install a version of polymer it was presented with three options and didnt know which one to choose from. Many packages have a stable release and a development version, which you want is up to yourself. You can usually check up the packages on github or there websites to find which package might suit you best
My lib directory only has 1 jar. xml-apis 2.8.1. When I remove it, everything compiles. This is the error I get:
java.lang.LinkageError: Class org/xml/sax/SAXParseException violates loader constraints
Any idea what's going on?
The xml-apis classes are included in the JRE. This issue is also known as being part of the "jar hell" problem, and - in the JVM space - typically occurs with XML libraries being included multiple times in the classpath, i.e. from the JRE rt.jar, by the application server or as a dependency of third-party libraries. This leads to LinkageError exceptions as the one provided above.
This is one example that describes how to solve this issue in Grails 1.3.7.