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.
Related
I have just updated the IDE, plugin version and library dependencies, and now I can't build my project. SBT throws java.lang.NoClassDefFoundError: sbt/TrackLevel when executed. I also can't run ./sbt clean since it attempts to load the project and fails with the same error.
I changed my sbt.version in build.properties to 0.13.17 and ide build my project all fine.
That can happen for various reasons, usually because of some mismatched versions or leftover caches. Surprisingly often, sbt can't gracefully handle updating plugins, let alone itself and it's the reason I waste hours every time I decide to refresh my project and bump up versions.
Attempt 0: Check known version incompatibilities
You know, just in case. Pay attention to the plugin/dependency you've just updated and whether anything is mentioned in its changelog. Keep this in mind while going through the Attempt 1.
Attempt 1: Update dependencies
This is a good chance to update all (other) dependencies and plugins (of course, if that doesn't break your project but it shouldn't be the case unless you're already using deprecated methods). Doing so might resolve the issue, so look up library dependencies you're referencing in your build.sbt, plugins from project/plugins.sbt and sbt version itself in project/build.properties and bring them up to their latest versions (consult Google and appropriate repositories, e.g. http://mvnrepository.com).
If you're still using activator or play commands to build your project, grab the Java/Scala seed or one of the templates from Play donwload page, extract and copy sbt (if you intend building it on Linux), sbt.bat (if you intend running it on Windows) and sbt-dist directory into your project and feel free to delete any references to activator from your project. Try executing ./sbt and see if it works.
Attempt 2: Delete project caches
Since you're still reading this, chances are updating dependencies didn't really do the job. Well, at least now you have a refreshed project.
Remove target/. Remove project/target/. Remove project/project/target/. Curse whomever came up with those cache names and their paths. (Protip: holding shift while hitting delete will skip the recycle bin and delete the files permanently.) Attempt to built the project again and hope everything is okay now.
Attempt 3: Delete global build caches
In case it didn't do the job, as a last resort we're gonna remove all the caches and start fresh. Repeat step 2 in case previous failed build left something behind.
Navigate to your home folder. Remove .ivy and/or .ivy2. Remove .sbt, or in case it contains some configuration you want to retain rename it to e.g. .sbt.old and restore specific files afterwards. It could take a while since those directories could contain dozens of thousands of files. (You could delete all IDE caches here, but I've never encountered that being the issue - it will rebuild the whole project on next launch anyway since you've destroyed most of which it relies on already)
Go back to your project folder and rerun ./sbt. That could take a few minutes since it will download all dependencies (including sbt and Play themselves) and put them in place. After that, you will have fresh project, as if you've build it from source on a clean machine.
In case it still doesn't work, you can safely assume it's either mistake in your build files (triple check them again) or a bug in the build system.
I am new to enterprise application developement and trying to create a REST server with Spring REST, JPA taking to mySQL database and Javascript on the client side. As I see loads of opensource libraries doing specific task, I started off with using 'maven project' with different 'arch type' (which is nothing but predefined POM with relevent libraries as I understand) provided by Eclipse. But I often run into version mismatch issues, in many cases found specific solution to that perticular libraries in StackOverflow or other sites.
Hence I started looking for a information these version dependancies such as, this version of JPA works with that version of Hibernate library and so on. I checked maven repository of major libraries, I did not find such information so far.
My queries are:
Where can I find these information about the versions dependancies?
Are these pre defined POM in eclipse reliable? Who owns them, where can I get last modified dates on these maven 'arch types'? (I find the ones I choose having fairly old version of libraries).
If I have to start off on my own creating a Maven dependacies, where will I get information about what are the dependent libraries, for example, if I need spring MVC, for sure it needs java servlet library. I am worried becuase the maven 'spring-mvc-jap' arch type whooping 50 libaries as dependancies.(Coming from embeded domain, I find to too hard to digest :D). So not sure if it is the right way.
Please correct if I am missing anything in my understanding.
You can find this information, if you are using maven and some IDE you can go to the dependancy and make click un > and this will show the librarys used for this dependancy or if you want to use the console you have http://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html this will show the same that the IDE.
After normally in the documentation of the library used, you can find some doc about the dependancy about this.
Other solution is get the .jar and use 7zip to see the POM and know the dependancy used.
And for finish my answer if the IDE tell you that you dont have x dependancy normally you have to add this because any of the other dependancy used have it (they used only for the compiling task), but sometime somes projet change a lots of code between the version .a to .b so you will have some problem using the version .b, at this moment i didnt find one good and easy way to fix this, only using the way that i told you (only if i found some problem in the compilation)
3> I am not sure how it works in eclipse but in IntelliJ IDEA when you start using some class without proper dependency IDEA suggest you to add proper dependency automatically. The same approach should be in eclipse.
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 having two nb-projects.
One nb-project(a) has the other nb-project(b) as a library dependancy.
Now both nb projects compile/build fine, but the hints for (a) are out of sync.
This interferes when i want to run/debug saying 'one or more projects were compiled with errors'
I've tried
opening/closing both projects and recompiling
scan for external changes'
clean-build, removing the 'compile on save' flags for both projects etc.
en/disabling 'Build Jar after compiling' for the jtools project.
Removing the :
./netbeans/6.8/var/index
directory only made things worse for the nb-project(a)..
Now exclamation marks for all imports of packages from nb-project(b)
But still compile/build worked fine.
Even unit-tests within the same netbeans project in(b) didn't even recognize the root-package ?!
After some strugling its a bit better, but hints are still not correct in (a).
Now in (a) it says one method doesn't exist in project(b), but i've looked it up in the build-jar of (b).. it's there !?
Any ideas how to get the hints back on track?
Thanks
I've seen something like this when I upgrade a library but neglect to remove an earlier incompatible version from a path visible to NetBeans. Older JARs carelessly left in an extension directory are particularly troublesome, especially if they alias new entries you've added elsewhere. Also, review the Tools > Libraries dialog entries for duplicates and errors. Finally, check each project to be sure it's using the required libraries.
There are three ways to create dependencies in NB. You can add a project, add a library, or add a jar/folder. Only the "Add Project" button tells NB that the dependency is mutable. The other choices (Library and Jar/Folder) expect the jar will never change.
Try deleting the dependency on project(b), then add it back using the Add Project button.
I only use the Add Library for stable, third-party libraries (apache commons for example). I only use the Add Jar/Folder for third parties libraries I know I won't use anywhere else. Such as vendor libraries for communicating with a particular device.
I'd like to set up eclipse with a bunch of plugins and DB connection configurations, etc and re-zip it up so my team-mates and new starters can all be working on the same platform easily.
It seems that installing plugins is fine, but when I add in custom jars (e.g. ivy2, ojdbc, etc) they all save with full, absolute paths which probably dont exist on others machines (particularly if they unzip in a different location to me).
Anyway, I'm hoping that this idea is not silly and am working if this sort of process is documented somewhere or if anyone has any tips in general.
Thanks,
I would recommend against requiring all developers to place eclipse in the same location. There are times when some developers may want to try an alternate version of eclipse to explore a technology that requires a different set of plugins or a different eclipse base version.
Let developers install eclipse where they would like.
However, for jars that you need to run plugins (external dependencies that you need to configure for proper plugin usage):
Hardwire a directory for those jars (as opposed to the entire eclipse dir), like c:\eclipse-helpers or something.
To deal with third-party library dependencies (in the code you're developing), you have a few good choices:
Create project(s) to hold the third-party libs and check them into your source version control system (which you are using, right?). You can then add the libs to the build path(s) of the project(s) - make sure you mark them for export in the "order and export" tab of the build path page. You can then simply add these third-party projects as project dependencies.
Reference the third-party jars as CLASSPATH variables when adding them to the build path of your projects. This allows other developers to store the dependencies in different locations. Perhaps define a CLASSPATH variable (in eclipse's Window->Preferences->Java->Build Path->Classpath Variables) called THIRD_PARTY_JARS; each developer can map it to a different path where they want to hold their deps.
Reference the third-party jars as a "user library" (Window->Preferences->Java->Build Path->User library). This is similar to classpath variables, but acts as an explicit set of jars.
Include the third-party jars directly in your projects. Use this option only if you need the deps in a single location.
Although not exactly in line with the direction of the question, you could use Yoxos OnDemand. It allows you to "roll-your-own" Eclipse distro and download it as a zip. They add in their own perspective where you can add more plugins (direct from their repo), or update the plugins that you have.
Although I've never used the feature, you can make make your own stacks and name them, allowing anyone to go to the site later and download it (with the most up-to-date versions of the plugins). Also, dependencies for plugins are resolved automatically if need be.
In eclipse - in many places it's possible to use workspace relative paths or system environment infos to reference external files, too.
Another option could be to place your jars into a workspace project so that every team member can check it out from cvs/subversion/whatever and start working. Working like this ensures a reproducible environment for server builds or for desktops even after years.
Talking about Yoxos...
it provides "Workspace Provisioning" as well. This means you can attach Eclipse Preferences, checkstyle configurations and Mylyn setups additionally to your list of needed tools/plugins for your IDE to your yoxos profile.
This means your team could share a profile and would be able to start working with the same setup regardless of their OS or whatever. (Its possible to use multiple profiles at once, too.)
We did a similar thing with our development environment (it needed both Eclipse and our own plug-in which, in the early stages, had to run in a known location).
We just put it in c:\eclipse_<projName> and made that a requirement for the team. That's probably the easiest solution for you.
It's your team, you can dictate this as a requirement. Unless your team members are absolute idiots, they'll work with you.
I found Yoxos really good and it does very good work in determining dependencies.
Its really a good tool and worth giving a look.
I just started using git to manage my eclipse install. I did a write-up. The approach might work for you, and it's probably worth looking at.
If developers all don't have the same paths on their machine, instead of adding independent JAR files you could create what Eclipse calls a "library" and include a bunch of jars in that. Then another developer just has to change the location of the library and it'll pick up all the jars in there.