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.
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.
I wonder if anyone is using codenameone with lombok in Eclipse. I've googled, but all I could find is an old question of mine.
A tiny success
I've tried it, took a demo project, modified nothing and opened it in my Eclipse configured for Lombok. When compiling, I got the same stacktrace as here. I've added
/usr/lib/jvm/java-8-oracle/lib/tools.jar
to the path under Preferences -> Installed JREs -> Edit -> JRE system libraries (which may be a pure non-sense) and it didn't help.
Then I've replaced compiler="modern" by compiler="extJavac" in build.xml and it compiles. I can even use Lombok annotations and they compile and work in the simulator.
The problem
I'm afraid, this was the simple part. I guess, for submitting, I need to replace the source code by the output of delombok. I've tried to submit it as is and nothing happened (no error, no response).
Has anyone done it already?
Any tips?
You shouldn't change the classpath but if the bytecode has access to the properties then it should "just work". If you look at the build.xml file you will notice that it has targets for every one of the supported platforms and before the target occurs you will see a compilation target that packages the JAR that's sent to the servers.
Steve wrote a post about porting other languages to Codename One. This is simple by comparison.
It actually works! All I had to do was to
add the path to lombok.jar to the Java Build Path1
in the javac call of the jar task
replace compiler="modern" by compiler="extJavac"
add the path to lombok.jar to the classpath
1 This is not recommended as the dependency is unavailable on the build server, but that's exactly right. Lombok is a compile-time only dependency and the build seems to be based on the dist.jar, where Lombok has already done its job.
One year later: There was a problem with my old setup, so I installed everything anew and it seems to work. Just note that there are three javac tasks in the build.xml.
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.
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 using NetBeans 6.8 on Windows 7. I upgraded from WinXP and NetBeans 6.7. Now my existing java web app project is no longer able to import/find the packages I've developed - I receive a 'Package ,blah. does not exist' and yet the packages do exist, worked fine in NetBeans 6.7 and the project still compiles and runs OK.
I've tried changing the Java Platform/JDK from 1.6.0_10 back to JDK 1.5.0_22 but I still receive errors package does not exist.
All other 'standard' libraries and packages are able to be imported and used OK ... eg Struts, Hibernate
I have fixed this problem many times by clearing the NetBeans cache.
1) Close NetBeans
2) Go to "C:\Users\.netbeans\6.8\var\cache
3) Delete everything that is in this directory
4) Open NetBeans and wait for it to re-scan your projects
At this time, this has fixed my problem. I do need to do this every once and a while, but if I don't change anything in the project's structure, the issue does not come back, and I can develop in peace!
Hope it helps someone in need.
Solution was to create a new empty web application, check the existing project out from SVN, regenerate the build-impl.xml & configure the library references.
All is now importing and referencing OK
I do not have an explanation as to why the problem occurred the first time this project was created
I had the same issue with Netbeans 7.0.1. Suddenly after some work I could not compile my project anymore, because a major package "does not exit" anymore. All my projects settings (build properties, project properties, dependencies ) seemed ok for me.
The only (bad) solution I could find is, to copy the relevant module to a new name, remove the old and re-create the module again by copy/paste of packages. Now it works again.
regards
I have seen the error when I had the same jar installed twice - as compile library and as a test library.
As the result, many of packages became invisible.
After removing the jar from compile libraries everything become visible.
In the project Properties, under "Libraries", "Compile" tab. Do an "Add jar/folder" of the "src" directory if it's a regular Java project. If it's JSF, use "src/java" instead.
just change s by S in System.out., is simple but i think is your problem