I have a bug in Eclipse. When stepping through the code, when it goes to another class, the editor loses focus and I have to click again on the editor to continue debugging with the keyboard shortcuts.
I've found this thread describing the bug, and a patch to fix it. Is there any way I can apply the patch? I'm guessing it involves having the source code.
Yes you'd need to recompile the module and install it. These days with git SCM and the use of Maven project layouts and tycho plugin it can be easy to rebuild a module (compared to how it was just a few years ago).
Lets see now:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=372941
Patches:
bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/StackRenderer.java
We search on google "git org.eclipse.e4.ui.workbench.renderers.swt" we end up at the URL:
https://git.eclipse.org/c/platform/eclipse.platform.ui.git/
This can be used to checkout the 1 module to build.
Git is available for many linux distribution by default, google you ditro name and "install git" terms for best help. On windows there is https://code.google.com/p/msysgit/ and on MacOSX there is https://code.google.com/p/git-osx-installer/ all these provide a command line environment to use git. You can look at EGit/JGit plugins for Eclipse itself to also do the job. But the instruction below are for the command line method.
git clone https://git.eclipse.org/c/platform/eclipse.platform.ui.git
Now you'll want to find the tagged version of the version you are using. So you need to find it in your eclipse/plugins/** folder of the Eclipse install. The version number maybe in the filename or in the MANIFEST.MF or other *.xml file, the version number usually indicate the date of source and/or build in the number.
It may help to browse around the eclipse.org website link above for the GIT tree to find the version. This is to get the tag or version name / commit-id (like 'abc1234':
# List tags (might see it in the list)
git tag -l
# Look through history, maybe you can work on the date
git log
# Finally once you know the version you want
# checkout the exact version that goes with your eclipse install
git checkout -b mylocalbranch <tag_or_version>
Now you can use Maven to build it.
cd eclipse.platform.ui.git
mvn package
# The full-monty would be: mvn deploy (or 'mvn install')
# But I am not sure if unit and integration tests will work this easily, using
# the 'mvn package' it enough to get you the JAR you need to install in Eclipse.
Now you can look for a .jar in the build/* subdir, you can shutdown you eclipse and place this JAR into the plugins folder, ensure the version number is newer.
If it works update the bug report. Saying it worked for you.
Also consider trying to push it via the github accounts as a new change, crediting the original author.
..
DISCLAIMER: The above is the principal about how you might achieve what you want. It might take less than 5 minutes to complete. But there maybe complications and you'll need to research those (if you get any) independently.
You can also do much of the above with Eclipse itself, a 'git checkout' and a 'build Eclispe plugin module', although for me for this change it would probably take longer maybe 15 minutes (if there are no complications).
I have been working with the same Subversion working copy as a sub-directory of my local server's htdocs folder for months now. I was working in PHPDesigner7 and managing my repository with TortiseSVN. As I am the only one working, I just commit and keep working without any real need for multiple checkouts or updates.
I recently moved from PHPDesigner7 to Eclipse for my every day IDE. I have created a project and used my working copy root as the location. I have been writing all my code in eclipse for about six weeks now, and it seems like it would be much easier to do SVN operations within the IDE. I want to start integrating SVN into my Eclipse workflow, but I want to keep my working copy in the same place it has been. There are a lot of files like Adobe Bridge index files and Docblox configuration files that I do not keep under source control, but are still important to my tools. If I create a new checkout these files will not be present. I also like being able to do local server testing directly from my working copy.
How can I use my existing working copy from within the Eclipse IDE? I have installed Subclipse, but I set my eclipse project up before I decided to try switching SVN management to the IDE. Is it as simple as making my workspace the same as the working copy? I have just been using the Eclipse default workspace. Would I be better off with a fresh Eclipse project? Are there any caveats I need to be aware of when moving from Tortise to Subclipse? I especially wonder if Subclipse does many small commit operations, or if I can continue making fewer heavily commented larger commits? Does anyone prefer the subversive plugin? If so why?
The root directory of your eclipse project should be the root of your working copy. Then you just have to right-click on the project and choose Team - Share Project, and follow the tutorial. At some point Eclipse will ask you if you want to keep the existing .svn files or not. Just choose to keep them.
The workflow in Eclipse is exactly the same as with any other SVN client. You update and commit when you want to. And you may also continue using TortoiseSVN to perform your SVN operations if you prefer. You'll just have to refresh your eclipse project after each operation.
I am having trouble getting rid of Subclipse from my Eclipse configuration.
I made the decision to switch to Subversive due to the m2eclipse project dropping support for Subclipse.
So I uninstalled Subclipse and then installed Subversive using the About Eclipse -> Installation Details -> Uninstall method. Now, when I go to any Team related options/tasks/preferences there are two SVN options available (one for Subversive and one for Subclipse) making life confusing.
Having grepped the workspace .metadata folder for the string subclipse I can see that the configuration is still littered with references to Subclipse:
$ grep -lir "subclipse" .metadata/
.metadata/.plugins/org.eclipse.ui.workbench/workbench.xml
.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.workbench.prefs
.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.team.ui.prefs
.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.debug.ui.prefs
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload17.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload23.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload21.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload19.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/usagedata.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload22.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload14.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload13.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload20.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload18.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload16.csv
.metadata/.plugins/org.eclipse.epp.usagedata.recording/upload15.csv
.metadata/.plugins/org.eclipse.team.ui/dialog_settings.xml
.metadata/.plugins/org.eclipse.team.ui/syncParticipants.xml
.metadata/.plugins/org.eclipse.pde.core/-213569165961.target/.lazy
.metadata/.plugins/org.eclipse.pde.core/-213569165961.target/.state
.metadata/.plugins/org.eclipse.pde.core/-213569165961.target/.pluginInfo
.metadata/.plugins/org.eclipse.core.resources/.projects/jxse-tutorials/.syncinfo.snap
.metadata/.plugins/org.eclipse.core.resources/.projects/jxse-tutorials/.indexes/properties.index
.metadata/.plugins/org.eclipse.core.resources/.projects/BA_NAT_Traversal/.syncinfo
.metadata/.plugins/org.eclipse.core.resources/.projects/barchart-udt/.syncinfo
.metadata/.plugins/org.eclipse.core.resources/.projects/barchart-udt/.indexes/properties.index
.metadata/.plugins/org.eclipse.core.resources/.projects/netty-benchmark/.syncinfo
.metadata/.plugins/org.eclipse.core.resources/.projects/netty-benchmark/.indexes/properties.index
.metadata/.plugins/org.eclipse.core.resources/.projects/jxta/.syncinfo.snap
.metadata/.plugins/org.eclipse.core.resources/.root/73.tree
.metadata/.plugins/org.eclipse.core.resources/.snap
.metadata/.bak_0.log
All of the projects above are now disconnected from SVN. Obviously some of the references such as usagedata are not important, I am more worried about the XML files though. Is it safe to manually go through and delete all tags/properties related to Subclipse? I feel that approach may be unwise though.
Does anyone know of a way to eliminate all traces of Subclipse without losing my workspace? Also any tips on what I might have done wrong? Should I have manually disconnected all of my SVN projects before making the switch to Subversive?
I had exactly the same problem. The reason is when you uninstall via eclipse, it doesn't delete the jar files from the plugin folder, the steps I did.
Go to folder eclipse/plugins for
avoiding any potential damage (just deleting wrong jars and get errors in other apps) list the jars from subclipse.
$ cd eclipse/plugins
$ ls |grep org.tigris.subversion
and then if it lists the following
$ ls |grep org.tigris.subversion
org.tigris.subversion.clientadapter_1.6.12.jar org.tigris.subversion.subclipse.doc_1.3.0.jar org.tigris.subversion.subclipse.tools.usage_1.0.1.jar
org.tigris.subversion.clientadapter.javahl_1.6.15.jar org.tigris.subversion.subclipse.graph_1.0.9.jar org.tigris.subversion.subclipse.ui_1.6.17.jar
org.tigris.subversion.subclipse.core_1.6.17.jar org.tigris.subversion.subclipse.mylyn_3.0.0.jar
Remove them by piping xargs rm to the command
$ ls |grep org.tigris.subversion|xargs rm
Restart your eclipse and you'll only see the correct svn version.
PS: the .metadata you display comes from the workspace, it only affects to the projects you got from svn, it won't do any change in eclipse.
I have an SVN repository checked out and have an Eclipse project set up around it. When Eclipse builds it seems to be unsetting the svn:ignore '*' inside the output directory and also causing the source files to be copied into the output folders. Removing the directory and updating a new one from the repository fixes it until Eclipse builds again but it is annoying to have to do that every time I want to commit.
I have Eclipse set up to ignore .svn directories as described here:
http://www.damonkohler.com/2009/07/make-eclipse-ignore-svn-directories.html
Example svn status:
S classes
...
? classes/dojo/Main$1.class
? classes/dojo/Main$2.class
! classes/dojo/Preferences.java
! classes/dojo/Deck.java
...
The best way to handle this is to install a Eclipse Plugin for SVN usage like subclipse or Subversive.
Are .svn and .svntemp checked in Window->Preferences->Team->Ignored Resources?
Is this like in this thread?
It looks like you use external build process which copies existing .svn folders from the source folders to the corresponding output folders (I think in this way because built-in Eclipse builder ignores team private resources like .svn).
This mean that in order to avoid the problem you should exclude .svn folders from your build process.
I've got a working copy checked out with svn; furthermore, I've created a new project in Eclipse that has the root of the working copy as the project's location. I want to be able to do stuff like compare versions from Eclipse. I have Subclipse 1.4.8, but that doesn't seem to give me what I want. Am I doing something wrong?
i have an svn working copy that also is a project in eclipse. after installing the subclipse plugin i had the same problem, the working copy was not recognized as such.
i just managed by chance to get it recognized as an svn working copy by renaming the project in question and then renaming it back to its old name. not very nice, but it did the trick :-)
There is an option when creating a new project, to use an existing source directory:
New project/ new Java Project / Create project from existing source.
Use that, tell it where your source lives, and it should automatically detect if it's a SVN working copy.
I guess this is not possible with Subclipse as it's given in its documentation that, you can only import an existing svn-managed folder under one condition, according to the doc:
"The only requirement is that your
working copy has to also be a valid
Eclipse project."
So, if you have a working copy that is not a complete eclipse project, Subclipse will not connect it to SVN.
You can right click on the root node of your project and select: Team / Share project
Then you choose SVN, let the default settings and it should work fine!
I am answering this after a long time of the question being asked. I ended up here because I was facing the same problem.
My solution was to create an empty .svn folder at the root folder of the project (in the latest version of svn client tortoise all meta-data is at the root folder). Then did an eclipse refresh and voila it did the trick. I am running subclipse core - 1.8.4.
One step that seemed to work for me, that no one has explicitly mentioned yet: I closed and then re-opened the project. I tried the "rename" trick, above, and that didn't work, but perhaps the poster of that answer also closed the project - they didn't detail exactly what steps they went thru to rename it. (I found you don't have to close the project to rename it, but perhaps they did.)
< /rob>
In my case, I couldn't use an existing copy because I checked out the code using a newer version of Subversion on the command-line and Subclipse 1.4 couldn't recognize it. Upgrading and going through the improved "Share Project" menu resolved the problem.
I got this tip from the forums here:
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2380064
I had the same issue and here are the details of the fix.
My Eclipse is "Helios Service Release 1".
I had an SVN checkout on my filesystem, I went to New Java Project, unchecked Use default location, chose the location, went to next step, chose the source folder and said Finish.
The project came up with no disk icon on it. As per few forum posts, right-clicked on the project, went to Team > Share Project, chose SVN, clicked Next, and the option was only to share the files to the SVN Repository for the first time.
I said Cancel, and the option is to make changes to the SVN plug-in settings. Went to Window menu, chose Preferences, browsed Team> SVN. Chose the SVN Connector tab, changed the SVNKit 1.2.3 to SVNKit 1.3.5 and said OK.
Then, right clicked on the project, said Team> SVN, on the next screen, chose the option Use Project Settings and clicked Finish. The disk button came to the project and the SVN URL got displayed on it.
Add the repository to your list of repositories in subclipse by choosing Window->Show View->Other... and choose SVN->SVN Repositories. Put in all the necessary info to connect to the repository.
Next, right click the repository and choose "checkout". If the project doesn't already have an eclipse .project file, you can create a new project from the source. If it already has a .project file, it will import that .project and use that as your eclipse project locally.
It will definitively not work if you use a different version of svn to checkout, that the one that is supported by Eclipse. I had this problem as I used svn 1.6 to checkout but I had an older eclipse version that had only 1.5. Subclipse has its own build-in svn client (Actually, in two flavors if I am not mistaken).
Check that the subclipse version matches the svn client that you used to checkout. You can check the plugin version number for subclipse (Help -> About -> Click on subversion logo) and match it against svn --version
This worked for me:
1) Go to the 'SVN Repository Exploring' perspective and add a folder somewhere above your working copy
2) Close and open the Eclipse projects.
This should then be enough to get them recognized by Subclipse.
I have encountered a similar situation were existing projects would not get associated with the Subversive plugin. Unfortunately, none of the previous suggestions helped (renaming projects etc.). What has helped is removing projects from Eclipse by deleting them -- just the projects from Package Explorer and not the actual directories and files on disc (the deletion prompt has a special checkbox for that, which is unchecked by default) -- and reimporting the deleted projects as existing projects back.
Of course, as mentioned in some of the answers here, the relevant SVN repositories need to be registered with Eclipse before reimporting the projects. Otherwise, there would no repositories to re-associate the projects with.
When you open a versioned project (i.e., a project in SVN working copy) in Eclipse, that was never previously used with Subclipse, you need to perform these steps:
Right-click the project in Project Explorer.
Select Team | Share Project.
At this point Subclipse will tell you that "The project is already configured with SVN repository information". Click Next.
Subclipse automatically recognizes this project as versioned and all the features of the SVN plug-in should become available.