I would like to programmatically set/create a breakpoint in another file at an arbitrary line number in Eclipse. I would love to see a generic solution, but I guess I have to rely on the Eclipse JDT plugin for it. How can I do that? I tried something like:
JDIDebugModel.createLineBreakpoint(resource, typeName, lineNumber, -1, -1, 0, false, null);
But I have two problems with it:
I have to include a whole lot of libraries to my build path to make it work, e.g. /usr/local/eclipse/plugins/org.eclipse.core.resources_3.9.0.v20140514-1307.jar. If I add them, they require other ones etc. I probably have to add all Eclipse plugins/libraries to make it work.
How do I get a proper resource in order to give it to the method above? Giving a null value will most probably not work. But all implementations of IResource are internal...
I also thought about directly communicating with the JDI, but I could not get it going in combination with the Eclipse debugger (here is a great, but german resource for it).
If it is not possible from arbitrary code, would it be possible from within an Eclipse plugin? This would also be an option, though not preferable.
I could not find any solution for it and hope to get some help here. Thanks in advance!
Most Eclipse plugins can only be run in the Eclipse environment because they rely on the Eclipse/OSGi plugin infrastructure being initialized properly.
Since JDIDebugModel.createLineBreakpoint requires an IResource object it can only be used in the Eclipse IDE (or an RCP based on the IDE) with a workspace.
So, yes, you can use this in a Eclipse plugin which would have to be installed in to Eclipse or an Eclipse RCP.
Related
Just starting working on an existing project at work and wanted to use Visual Studio Code as my IDE (I have used it for a recent Rails project and loved it, so wanted to try with Java).
However, whenever I try to open one of the projects I receive a ton of different errors including:
When importing java.io, java.util, or anything similar, the error:
"The import of java.io (or java.util) cannot be resolved"
Existing classes have an error:
"The implicit super constructor is undefined for default constructor. Must define explicit constructor"
Other random "cannot resolve to a type" errors.
All of these seem to stem from some sort of setting error I have with VS Code but can seem to find what it is. I have already uninstalled and reinstalled the RedHat plug-in that enables the Java language for VS Code.
I have tried setting the java_home setting in the extension to the direct location of the install but that didn't work. Tried uninstalling and reinstalling java and that also didn't work.
My operating specs are as follows:
OS: macOS Sierra
VS Code version 1.15.1
JDK version 1.8.0.144
Any idea on what may be causing this? Do you think it may be an error in how I have VS Code set up or if it's an error (or rather incompatibility) with how the existing project is set up?
I ran into a similar issue. The solution was to remove everything from VS Code's workspace storage directory, which was located at $HOME/Library/Application Support/Code/User/workspaceStorage/.
I found this solution here: https://github.com/redhat-developer/vscode-java/wiki/Troubleshooting#clean-the-workspace-directory
Update: This can now be done from within VS Code as of Language Support for Java(TM) by Red Hat Version 0.33.0. Open the command palette and type "java clean" (see official description in link).
As already mentioned previously, you require to clean the project, but that is a bit difficult thing because every folder is a Guid, and you do not know which one to clear, thus requiring you to delete everything. Starting with 0.33.0 version of the plugin you can automatically do that from within the IDE as well, use CTRL + Shift + P and type, java clean, and IDE will show you the suggestion tip for, Java: Clean the Java language server workspace. Upon selection, agree and restart the IDE. It will clean the language server workspace for you.
Another approach can be, the Maven tools within the IDE. If you have this plugin installed, you can use the side bar and utilize the Maven project helper options to perform actions like, clean, install, and package etc. For example, here is the project I am having and the options this shows,
That can be used, graphically, to manage your Maven-based projects. Also, this would work with the Java Extension Pack, not sure yet as to how it would behave with other extensions.
For me: CMD + Shift + P
Then type "Java: Clean Java language Server Workspace"
Note: This will reload/restart vscode as well.
Update:
This appears to not fix it anymore for me. In my case I am using a gradle project, and needed to set the rootProject.name in the settings.gradle to be the same as the folder name that the project is in.
I faced this issue after creating a whole Java project in one computer and then trying to run it on another computer.
After doing everything said in the other answers, what really made VS Code compile was to open each single project java file in VS Code and save it (a simple Ctrl + S). Maybe there is a simpler way of doing it, but that is what worked for me and I hope this helps anyone stuck in this issue.
Press ctrl+shift+p
then search 'java clean' and click 'java: clean java language server workspace' then click restart IDE.
I found another simple trick at least to get rid of "cannot be resolved to a type" errors which were coming from older workspaces and wrong project files I guess?. I just ran an empty main(), with the body commented out, while still keeping my local package / import commands at the start - no errors. After commenting in again, the project compiled without errors. Perhaps this refreshing effect might also help in this context?
I had to clean this folder to get it working on Windows
%APPDATA%\code\Local Storage
I've come back to project after a long diversion, and upgraded tooling. This means Netbeans 12.5, Java 17, Gradle 7.3… at least allegedly. For some reason, despite setting the Gradle version to 7.3, it appears to build with 7.0.
Per the image below, setting the Gradle version to 7.3 doesn't seem to be picked up. (That is immediately after hitting Apply.) It still tries to build with 7.0. And – for some indeterminate reason – it can't.
Restarts don't help; I can't get the configuration to be picked up. (Searches for reference to similar issues provide 5-year-old answers that are no longer relevant.) I've even tried deleting the 7.0 distribution; to no avail, it comes right back.
Can anyone provide guidance on getting this to work properly?
Netbeans 12.6 fully supports Java 17 and Gradle 7.3. Gonfiguring the Gradle wrapper for 7.3 gets picked up correctly, eliminating all errors I was experiencing.
Don't bother with gradle in Netbeans. It's a horrible, buggy disaster and 12.6 just seems to want to up the ante.
Netbeans does NOT support gradle in a meaningful way for normal users.
You now get complex multi-projects whether you want them or not.
When creating a Java Application you don't get a choice at what the Main class is called. It will be App with app.java and you will like it.
If you try to rename app.java to something useful. It will not change "Class App" to "Class Useful" it will instead change it to "ClassUsefulp". It will not rename the test file and you will be left with several syntax errors that you can have fun cleaning up.
No, you cannot rename the subproject itself. That will continue to be the extremely descriptive and useful "app" subproject. The IDE will not provide you a way to rename that.
There is no meaningful, intuitive way to create/delete/modify subprojects.
If your gradle version is somehow out of sync there is still no useful way to reset/recreate the gradle wrapper other than creating a whole new project and moving your source code over to the new project.
Oh, so you gave in and accepted the multi-project structure. You noticed that if you go through the multi-project creator GUI then you can create multiple subprojects. Yeah, good luck with that. They won't have gradle build.scripts or wrappers. You won't be able to build your awesome creation.
Want to use command line arguments? Forget it. There is no "run" element in the project properties. You cannot create different run configurations.
Want dependencies? Or any other project configuration? It's all manual editing of gradle files. There's no GUI to assist non-gradle-wizards.
Yeah. you can probably work around a lot of this by dropping to a command line shell and editing the gradle scripts/files manually and running gradle commands manually. A) you're going to need to be a gradle wizard, and B) why are you using an IDE in the first place? you've got gradle, you've got vi available. Bathe in the nostalgia because you'll have to anyways.
Do you like the idea of gradle? Do you use Netbeans? Stick with Ant, or Maven if you need external dependencies; you'll thank me later.
I checked out a new version of my project from svn and now Java has made the easy thing difficult. I don't know what is wrong and I can't even build the project. What should be done? The code should compile, it's just not being picked up by the IDE.
And I couldn't run it with Java 7 but that might be a different question, now I can't even run it with Java 6 since Eclipse has made the easy thing difficult. Did I do something wrong when I checked out the project from svn? I use xp-dev.com
You checked out the entire repository instead of just one tag. You wanted to check out trunk.
Right click on your src directory that contains your packages and specify Build Path -> Use as source folder and it will set things up properly for you.
Total Maven newbie, trying (along with the rest of a sizeable team) to convert a monstrous pile of legacy code from ant over to Maven. It's working reasonably well, but I'm having the following problem.
I have a project, let's call it Core, that at runtime needs to load some files checked in under some different projects, let's call them Resources A and B. The Core code is started in a certain working directory, let's call it core/runtime, and there's a properties file it reads in order to determine what to load from Resources A and B, complete with the relative path to the resources in question, e.g.
resource.ham=../../resources-a/files/ham.rsrc
resource.eggs=../../resources-b/files/eggs.rsrc
(Yes, I'm aware this is sick and wrong and we should be loading resources as resources, from a JAR via a classloader and maybe some sort of container or dependency injector or whatever. Not my idea, not my current problem, not on the table to be fixed now.)
(Seriously, please don't bother suggesting we fix the underlying problem. We know we need to fix the underlying problem. We knew we needed to fix the underlying problem before we switched to Maven, and before we switched to Maven the stupid hack actually worked. I know it makes you feel good, but it's not helpful. This is a ten-year-old codebase with tens of thousands of classes and believe me, there are plenty of more important things wrong with it.)
This relative-path hack is only an issue in Eclipse, during development; in the actual deployed application the files live somewhere completely different and are loaded in a somewhat more sensible way.
Anyhow, this all worked fine when these were vanilla Eclipse projects, so the directories in question had paths like:
c:\workspace\core\runtime
c:\workspace\resources-a\files
c:\workspace\resources-b\files
However, now that these are checked out as Maven projects, the directories are now something like:
c:\workspace\core\runtime # Inexplicably unchanged
c:\workspace\maven.8675309\resources-a\files
c:\workspace\maven.6345789\resources-b\files
Questions:
Can I make these maven.7762323 directories go away?
If not, is there some way in Eclipse to get the path to a project directory, and then pass that as a system property in a launch configuration, or something like that?
Any solution has to be one I can check into SVN so the other developers on my team can use it out of the box.
Update
Okay, I figured out where the maven.[number] directories come from: When you select a parent directory in the SVN repository and say "Check out as Maven project", you get a maven.[number] directory corresponding to the parent, with all the actual projects as subdirectories. It would be very convenient, if only the code was actually all in the same parent directory, or even in the same SVN repository.
Can I make these maven.7762323 directories go away?
Where do they come from? What do you mean exactly by checked out as Maven projects?
(EDIT: As the OP wrote in a comment, these directories come from m2eclipse that allows to check out maven projects from SVN. I don't use this feature so I dont know much about it. However, after some googling, my understanding is that these names are kind of temporary and m2eclipse should rename them at the end of the checkout. Maybe something something went wrong with eclipse during the checkout. I'm not sure actually.)
If not, is there some way in Eclipse to get the path to a project directory, and then pass that as a system property in a launch configuration, or something like that?
Eclipse has a {build_project} variable that could be used in the arguments of a runtime configuration. Maybe {workpsace_loc} would be more appropriate in your case. The whole list is available with a description in the Arguments tab of a runtime configuration.
(EDIT: I'm still not sure I get the real goal but I have the feeling that using svn:externals could help.)
Okay, solution was to use {workspace_loc:project name} variables to set a handful of project directories as system properties, and use those to infer everything else. Now if I can just figure out how to get the ridiculous system for loading plugin JARs to work with Maven...
Background:
Here at the office my group uses a common linux environment where we do our code development. Our code is kept in CVS. The latest releases of our various libraries are kept in a specific directory (ie /data/group_projects/lib). Our Makefiles/Ant builds all specify what libraries are needed. We use autoconf to create the makefile after checkout for most C/C++ projects. We've just got Eclipse (3.4) installed and are planning to incorporate it into our workflow.
Problem:
So, when I check out a project from CVS through the Eclipse interface and then I have to set up all of the library paths (and include paths for C/C++). For some of our projects, this could be a lot of work. Is there a good way to save these paths along with the code when I check it back into CVS?
Ideally, when the next person checks out the code in Eclipse, the paths (and anything else they might need) will automatically be set up and they will be able to compile straight away.
Efforts:
I know that the include/lib path info is kept in a .cproject or a .classpath file (C/C++ or Java respectively). I thought I could export this info through Export -> Preferences. The resulting epf file doesn't have any path data in it unfortunately. I tried directly adding the .cproject file to one of my projects (so I could then put it into CVS) but Eclipse really doesn't seem to want me to do that.
I am quite new to Eclipse (esp using CDT), but maybe the necessary path info can be pulled out of build.xml/Makefile automatically by Eclipse? There seems to be a bit of a disconnect in Eclipse between the buildfile/makefile and the jar/include files that the IDE uses for checking your code as you type it. Maybe I am missing something?? I'm planning to put some serious time into researching Eclipse over the next few days so hopefully the inner workings will become much more clear to me.
I've asked the guys here at the office but no one is much of an Eclipse guru. My searches haven't turned up much . . I did see a suggestion to add all external jars to Java -> Build Path -> User Libraries under Eclipse Preferences. For us, each user would have to set this up once but afterward all of our java libraries would be available to whatever project we decided to check out. Unfortunately, it doesn't seem as though I can do the same thing for CDT.
What would you suggest? Am I missing a setting or function of Eclipse? Or am I going about this the wrong way? Please let me know what you think. I'd really appreciate it. Thanks!
You simply need to share the .project, .cproject and .classpath files through CVS. You can do this from the cvs command line, or select then 'Team/add file to version control'.
You don't need to add these files to the project explicitly: they are inherently part of it.
Obviously, if you do this, you need to make sure they are location-independent.
See:
eclipse wiki
Safari books
I've done this in Eclipse, and it's not too hard. You have to check in the .project and .classpath files. There are one or two places where Eclipse doesn't correctly automatically check out the files when you want to edit them, so when you get a read-only error you have to go manually do it, but for the most part it works.
The paths need to be all relative.
If relative paths is a problem, you can also take advantage of workspace variables in Eclipse. The developer sets their workspace variables appropriately on their machine (e.g., OPENGL_INCLUDE_PATH ), and then in the builder you can set the environment to pass that path along.