Edit: This question is solved. For some reason there indeed was another version of the Lucene files in the plugins directory of Eclipse.
I'm trying to use Lucene in an Eclipse plugin. It's methods are supposed to be called from another plugin.
It works great as long as I run the project as a Java Application. But when I try to call a method from the other plugin, I get the following error:
java.lang.NoSuchMethodError: org.apache.lucene.store.FSDirectory.open(Ljava/nio/file/Path;)Lorg/apache/lucene/store/FSDirectory;
Of course the method does indeed exist as it runs perfectly fine as a Java Application. Therefore I guess I have to do something plugin-specific to make it work.
I added the necessary Lucene-jars (lucene-analyzers-common-5.3.1 and lucene-core-5.3.1) to the dependencies of my plugin. I also added org.apache.lucene.store to the Exported Packages of my plugin (as suggested by Eclipse so the plugin which calls the method can catch the LockObtainFailedException). That's everything I've done regarding Lucene.
Can someone tell me what I forgot / don't know about? (If it's not obvious, I am completly new to Eclipse plugins)
Edit:
I've also tried to add the jars directly to the plugin which is calling the Lucene-method (by adding the paths to Bundle-ClassPath in the manifest). Didn't change anything.
I've also read that such a problem may occur due to another version of Lucene being somewhere in my classpath. I made sure that's not the case.
For some reason there indeed was another (older) version of the Lucene files in the plugins directory of Eclipse. These were the problem. I deleted them and removed the version tag in the manifest.
Related
I have a scratch file using guava collections, and I get some weird errors that I have to assume is due to the editor and the actual run environment assuming different versions of the guava collections:
Exception in thread "main" java.lang.IllegalAccessError: tried to access method com.google.common.collect.Range.<init>(Lcom/google/common/collect/Cut;Lcom/google/common/collect/Cut;)V from class
com.google.common.collect.Ranges
at com.google.common.collect.Ranges.create(Ranges.java:80)
at com.google.common.collect.Ranges.closedOpen(Ranges.java:114)
at Scratch.main(scratch_2.java:69)
Not that I can actually know that for sure because I also can't figure out how I'm supposed to see which version the scratch file is pulling in. I've removed guava from my project's deps ENTIRELY and the scratch file still works... WHY? Where is the library coming from??? The scratch run config is completely empty of anything that would dictate this:
And yet it still runs just fine. I discovered that if I delete the guava entries from my local ivy cache, it won't run anymore. If I then add guava back to my project's deps, it ends up in my ivy cache again, and then even if I remove guava from the project deps the scratch file is fine again. So does the scratch file just pick a random version or something? The ivy cache, which is at ~/.ivy2/cache/com.google.guava, looks like this:
But there's also that "jars" folder that has a guava-12.0 for some reason:
And again, I have no idea which version is being used, or why the cache has so many different versions of it. Any ideas?
One way that proved to be the simplest to me was to select "use classpath of an existing project module" (which has dependencies configured) in the run configuration dialog. This is useful if you want to pull out a piece of functionality from your project to play with in isolation but still use the configured dependencies.
I had a similar issue in PyCharm that I just fixed - so your mileage may vary here. It terms out that there was a Python virtual environment attached as the default to the project window (I had had multiple projects open in the same window - but evidently the first one became the default).
I dug into the list of interpreters, found the one I wanted and edited its properties, specifically Associate this virtual environment with current project.
I checked that box for the virtualenv that had the libraries I was looking for and this fixed the compilation errors in the editor itself.
So, I've been searching SO for hours and hours and I'm completely running into the brick wall here.
My problem's quite simply: I've got a (pretty big) project that I'd like being built with Maven (so I can automate it all a bit). Everything works fine so far except for one major problem.
I've got a dependency called "java-plugin" - I don't know exactly the origin or the author, but it was in the dependencies of a dependency of mine - I added it to our own Nexus third party repository with the name the original jar was given.
This plugin gets added from my Nexus without any problems, but it has the following structure:
- netscape
-- javascript
JSException.class
JSObject.class
JSUtil.class
-- security
ForbiddenTargetException.class
ParameterizedTarget.class
Principal.class
Privilege.class
PrivilegeManager.class
PrivilegeTable.class
Target.class
UserDialogHelper.class
UserTarget.class
- sun
-- plugin
...
-- plugin2
...
- com.sun.java.browser.plugin2
...
What's the problem? As long as I was working in an Eclipse based project, I placed my JDK as the "last" one on my classpath. Now it's Maven and apparently Maven places the JDK first. In my JDK I have the jfxrt.jar (part of Java FX). This one also contains a netscape.javascript.JSObject object (and also a netscape.javascript.JSException object). It doesn't contains a netscape.javascript.JSUtil object on the other hand. So Maven picks up the JSObject and the JSException from the JDK library, and the other classes he picks up from my own java-plugin dependency.
Of course both classes are not the same. Of course now I get compilation errors as the java-plugin dependency contains a 'getWindow' method in the JSObject class where the JDK library doesn't.
The ideal situation would be to exclude jfxrt.jar from Maven, but I have absolutely no idea on how to do that. Any other solution would do too, as long as I could get this one to build with Maven. Note: I'd rather not want to use the "endorse" mechanism in Java if possible, as that would require uploading this library to several different servers over and over again and would cause huge delays in deployment (as we'd always have to sent the file to our support team for yet another upload).
Thanks!
EDIT
So, my plugin dependency is something which is also in the JDK - even better! I don't need my java-plugin, I've got enough with my JDK which includes plugin.jar automatically (it's in my ${java.home}/lib/plugin.jar).
Now I have this situation:
As you can see, the jfxrt.jar comes first, before the plugin.jar. I can see why Maven, or Java more generally, stops looking as soon as it finds the first netscape.javascript.JSObject (which is in jfxrt.jar). But I really need it to load the second JSObject class (which unfortunately happens to be in the same package and with the same name). How the hell am I supposed to do this? And why did this work without a charm in Eclipse, when I wasn't using Maven, and why doesn't it work in IntelliJ, together with Maven?
Thanks in advance!
Ok, so I figured it out. Apparently this was much more of an IntelliJ issue than it was of a classpath issue.
So IntelliJ automatically adds the full JDK (including all jars in /jre/lib) to the classpath - first, before all the Maven dependencies. So that caused my project to be going weird: I had a netscape.javascript.JSObject in jfxrt.jar, in plugin.jar and in my Maven plugin (these jars were added in this order). The first JSObject that was found was the one in jfxrt.jar, which caused the problem.
It worked in Eclipse as there, I could alter the classpath order and had added my Maven plugin BEFORE the JDK - so the order became java-plugin.jar (first one, correct JSObject class), jfxrt.jar, plugin.jar.
It would have worked when I'd use an older JDK - this jfxrt.jar was only added in JDK7.
It works on Jenkins, if I still have my java-plugin.jar from Maven, because Jenkins does not automatically add the JDK libraries (only the core). That was how I cleared it out:
I removed my own java.plugin.jar and replaced it by a dependency on plugin.jar.
<dependency>
<groupId>com.sun.jdk</groupId>
<artifactId>plugin</artifactId>
<version>${version.java-plugin}</version>
<type>jar</type>
<scope>system</scope>
<systemPath>${java.home}/lib/plugin.jar</systemPath>
</dependency>
I still had the problem in IntelliJ, but arrived to remove the jfxrt.jar from the imported JDK libraries in IntelliJ itself - which does change the .iml file but of course not anything that would be of use for Jenkins. (You can edit these settings by right clicking on the External Libraries > < 1.7> folder in the Project Browser, and then clicking Open Library Settings).
Once jfxrt.jar was removed, everything worked. I reasoned that this wouldn't change anything in Jenkins, but on the other hand, then the problem maybe wouldn't even exist on Jenkins. So I simply tried and commited my code to SVN to build it on Jenkins.
Magically, it works now on Jenkins too. I tried and removed my dependency on plugin.jar, then I get the classical "could not find symbol" compilation error on Jenkins - while I don't get that error in IntelliJ, due to the automatically importing of the JDK on the classpath.
Long story short: By editing my project settings in IntelliJ I got it working locally, by simply trusting Maven I got it working on Jenkins, the way it should.
I am having trouble setting up the build path of my java project. I am currently in a Co-Op IT position so I am somewhat new to all this. My background is mostly in C++ and I am learning java on the fly. I am also somewhat new to Eclipse (Kepler service release 1).
I am working on a bug on an existing program and need to get the program to build so I can work on it. When I add all of the external .jar files that I know for a fact are the right ones, I am getting this error on two of them :
"Archive for required library: '(location of file)' cannot be read or is not a valid ZIP file"
Two of the other full time guys on my team have gotten the program to run with those exact same .jar files, one running Eclipse Indigo and the other running the same Kepler version as myself. I also was able to open the two .jar files manually and everything appears to be there. After every trial trying to fix this, I have refreshed, cleaned and restarted eclipse. The two other full time guys said they have never seen this error. I would like to get some insight on this from anyone who has any similar experiences so that I don't have to use up much more of their time.
I Had this issue, just fixed by deleting .jar files from Libs directory then copy->paste original Jars again. Then do a complete clean -> rebuild
I got this problem, took help from following link solution
which basically says to
1. delete the corresponding maven download folder
2. maven>update project in eclipse
In my case I deleted hibernate folder, since i was getting error related to hibernate-validator.jar
I had the same error here. What I did to resolve the problem was close and reopen the project.
I got the same problem and found out the root cause is the JDK in my linux shell is set to 1.6, but in the eclipse, the JRE is 1.7.
Using Eclipse without m2e features (Standard Edition) helped me.
Similar problem with Spring toolsuite
Just came across this link that shows a way to get unblocked.
In preferences dialog box go to
Java->Compiler->Building
and change Incomplete build path to "Warning" (from default "Error")
This can be done globally (for all projects), or on a project by project basis.
Check the jar's file permissions/ownership.
I had the same issue on eclipse installed on Linux and fixed it by setting the file permissions right.
In my case ..worked after removing this from spirngrest-servlet.xml file.
<prop key="net.sf.ehcache.configurationResourceName">/Sysehcache.xml</prop>
I think it had to do with default location of maven repository of jar files.
Been at it for 3 days. finally solved it.Hope it helps anyone.Just look for similar think in your spirngrest-servlet.xml file. Good luck.
I just tried the following and it worked:
Close eclipse as there might be some files eclipse is accessing and you won't be able to delete.
Delete all the libraries installed in the maven repositories folder: ".m2/repository"
Open eclipse and update your project(Alt+F5).
What did we just do? : This is possible that the existing libraries in the local repository are erroneous and maven tries to open which it fails in. We have now deleted the already existing library and with the project update, Maven will download the library again which should resolve the issue.
i fixed this by just deleting everything inside of the /Users/username/.m2/repository folder. not the repository folder itself. and then running a mvn clean package in the project folder
I've found a lot of articles/questions dealing with this problem, but there was no answer that worked for me yet.
I'm using GWT 2.5 with the eclipse plugin. eclipse version is Juno with Java7.
Everytime I start the app it first tells me that log4j was not configured properly (no appenders...) and also my HBaseAdmin can't connect to HBase (which is running).
All of the answers tell me that I have to put the resources into WEB-INF/classes directory. In order to do that automatically I added the files into the root src directory. But still nothing.
Maybe it's worth mentioning that I don't use maven (b/c all the other projects are no maven projects either, and there is no time to introduce maven at the moment)
Thank you for any hints what might be missing.
EDIT:
somehow I don't get any warning anymore, but I didn't do anything except restarting over and over. Thus this should be working now. But, Zookeeper now throws
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
I divided the gwt app up to the UI part, the executing implementation of the service is a seperate project, also the model is seperate. I first just added the required libraries to the projects that really need them. Know I also added them to the main GWT app, but that didn't help either. Any ideas?
LoggerFactory classes you are using is from slfj-api-1.6.1.jar . Try adding that jar into your WEB-INF/lib and classpath. Also we usually use it conjunction with slf4j-log4j12-1.6.1.jar .
Note: We are using version 1.6.1 as indicated by GWT sample examples available with gwt downloads.
I'm writing an eclipse plugin. This plugin uses a few local jar files, and additionally has a few dependencies on other plugins.
I'm using the Google Code Search API from jar files, and it works fine; but after I add the plugin dependency org.eclipse.zest.dot.ui to my project, the Google Code Search API does no longer work - on calling new CodeSearchService("my_ID"), I'm getting the following run-time error:
Analysis failed: java.lang.NoSuchMethodError exception raised.
com.google.common.collect.ImmutableSet.buider()Lcom/google/common/collect/ImmutableSet$Builder;
I have carefully checked and reproduced this: if the plugin appears in the dependency list, the CodeSearchService can no longer be used; if it doesn't, it works perfectly. The actual project code does not change, only a dependency is added.
This is very strange to me, as I don't see how adding a plugin dependency should suddenly make some methods disappear. Has anyone encountered anything similar, and can share any insights about this problem and a possible solution? I'm not even sure if this issue is specific to these two libraries or not.
The org.eclipse.zest.dot.ui bundle pulls in dependencies that depend on the Google Collections, so my guess is that the Google Code Search API requires a different version of these, and is now trying to use the other version. Not sure how to solve this, but you could try to update both to the latest version (see http://wiki.eclipse.org/Zest#Zest_2.x for the newest org.eclipse.zest.dot.ui bundle).