I am using Eclipse CDT (4.2 Juno) on both Windows 7 and Ubuntu 14.02. I have sucessfully installed Eclipse Plugin for TFS. And it works well on Windows 7 machine. I created repository on codeplex. Now I installed TFS plugin on Ubuntu Eclipse CDT. Everything went OK. But when I tried to import projects from repository, problem arise.
What I see as a problem is that TFS plugin on Ubuntu Eclipse CDT pick up mapping (local directory) from Windows 7 machine, and then it tries to place (import) files under that directory. Path which it tries to create (and what is causing java null pointer exception) looks like this:
Importing $/cplusplus/ArrayDemo (this is server path and this is OK) to /home/nenad/C:/Nenad/workspaceplus/cplusplus/ArrayDemo (this is local path and this is totally wrong)
That is completely malformed path. I need to import that (and all of the others) projects under /home/nenad/workspace/cpp4d5ed on my linux machine.
How can I resolve this issue?
Try deleting the Workspace and make new mapping.
Related
Install Netbeans 12.6 on a Windows 10 machine. I was able to install the CodenameOne plugin with no problem. When creating a project I get the following error message:
Cannot invoke "org.openide.filesystems.FileObject.getFileObject(String)" because "folder" is null
I've been surfing the internet and can't find a way to fix it.
Thank you for your support.
This approach is no longer supported. The plugin is only used for legacy applications and no longer works in newer IDEs due to breaking changes in almost all IDEs.
Starting with Codename One 7.x we moved to maven projects which don't require the plugin and can be created in https://start.codenameone.com/
I have followed the instructions in the manual and it mentions as important:
"Before opening the project in NetBeans, you need to copy the contents of the tools/netbeans directory into the root project directory. These files are required by NetBeans to build, run, and debug the project correctly. "
But I can't find this folder in netbeans version 12.6.
I'm trying to install Eclipse Neon on a 64 bit Windows 7 computer. I download the file "eclipse-inst-win64.exe" and run as administrator. Immediately I get the following error:
The Eclipse Installer executable launcher was unable to locate its companion shared library.
Note the "Installer" keyword. When searching on Google and StackOverflow, I find solutions only for when receiving this error launching Eclipse itself after it is installed. The solutions that worked for people in those situations usually involve editing the "eclipse.ini" file and removing absolute paths or references to uninstalled plugins. However, Eclipse has never been installed on this computer, therefore an "eclipse.ini" file does not exist and the installer does not appear to create one in any obvious place before throwing this error. There does not appear to be any "companion shared library" downloads on the Eclipse website. Any ideas on what could be going on?
Download and install the JDK and then try to install Eclipse again.
According to http://wiki.eclipse.org/Eclipse/Installation:
Eclipse 4.6 (Neon) was released on June 22, 2016. See Neon schedule.
Consider using the Installer. Please see 5 Steps to Install Eclipse.
A Java 8 JRE/JDK is required to run all Neon packages based on
Eclipse 4.6, including the Installer. The reasoning behind
requiring Java 8 are discussed here.
I found another reason for this error message. I got it when I tried to install Eclipse from the compressed installer. I extracted the installer into a folder and ran it from there. It then installed.
Try to extracted all the installer files before you run the installer.
I have Eclipse installed on a removable drive that I take between my desktop and laptop. I have an old installation (Mars) that I installed ages ago by unzipping files. I have a newer installation (Neon) that I installed using the new Eclipse installer.
After upgrading both my computers to Windows 10 Anniversary Edition, both Eclipse installations continue to work when the drive is connected to the desktop machine. When I connect the drive to the laptop, however, the new Eclipse installation (Neon---the one installed using the installer) will not start and says:
The Eclipse executable launcher was unable to locate its companion shared library.
However the old installation (Mars---the one installed from unzipping an archive) still runs just fine.
What is the problem with the Neon installation on the laptop and how do I fix it?
Update: I looked in the eclipse.ini file, and there is a --launcher.library reference to a C:/Users/user/.p2/pool/plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.400.v20160518-1444. The laptop (which is failing) has only org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.300.v20150602-1417. But the desktop (where it is working) has both org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.300.v20150602-1417 and org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.400.v20160518-1444.
So maybe somehow Eclipse updated its Equinox Launcher when the drive was attached to the desktop. Then when I attached the drive to the laptop, it referenced the updated launcher plugin, but the laptop didn't have the updated launcher.
This is a fine kettle of fish. I had no idea Eclipse was installing things in the user directory, outside the Eclipse installation directory. I guess that's one of the drawbacks of this newfangled launcher: it's not possible to use Eclipse on a shared drive.
How can I get Eclipse to install the launcher on the shared drive rather than in the system user home directory? Can I avoid this altogether if I install directly from zip files? How did Eclipse update this launcher in the first place without my knowing about it?
Update: Now I see that Eclipse also installed a org.eclipse.equinox.launcher_1.3.200.v20160318-1642.jar in the local plugins directory (that is, relative to the executable on the drive). Why is Eclipse putting some things on the removable drive relative to the executable (as they should be), and other things in the system user directory (where I don't want them)? This is a mess. So much for having a self-contained Eclipse installation like I did for over a decade.
By default, Eclipse installer does use a shared "bundle pool" so that if you have multiple different Eclipse instances running, the various plugins they're using are only downloaded once. This usually saves network bandwidth and disk space.
However, this bundle pool may probably be unable to work properly if the installation and bundle pool are on different drive (Especially if one of them is shared by multiple machines). You can report this limitation to http://bugs.eclipse.org .
As a workaround, for such custom installations, I would recommend that you skip the Eclipse installer, and get good old packages that will work just like Mars, everything in their own directory: https://www.eclipse.org/downloads/eclipse-packages/
I am using Eclipse (version Juno) with the TFS Plugin. When I click Source Code Explorer I get this error message:
Plug-in "com.microsoft.tfs.client.common.ui.vcexplorer" was unable to
instantiate class
"com.microsoft.tfs.client.common.ui.vcexplorer.versioncontrol.VersionControlEditor".
I saw this Eclipse plug-in development Unable to instantiate class due to java.lang.NoClassDefFoundError: but am not sure if it is the fix for this TFS plugin or what it really means:
put the project of the missing file as dependency in the plugin
configuration file too.
I've seen this exact error before on my box. In my case this file had gone missing due to its long path and filename:
"...plugins\com.microsoft.tfs.client.common.ui.vcexplorer_10.1.0.201101271439\com\microsoft\tfs\client\common\ui\vcexplorer\versioncontrol\ VersionControlEditor$VersionControlEditorRepositoryUpdatedListener.class"
You can see how this can get somewhat long. I'd suggest checking if you have all the files perhaps comparing it with an installation on a shorter path. Hope this helps.
I hope this can help somebody that researches this error. I was able to fix the problem on a virtual machine (Windows Server 2012 R2) running on a Windows 7 desktop with Eclipse Mars 4.5.0 and TFS plugin 14.0.1.
Plug-in "com.microsoft.tfs.client.common.ui.vcexplorer" was unable to
instantiate class
"com.microsoft.tfs.client.common.ui.vcexplorer.versioncontrol.VersionControlEditor".
I installed Eclipse and the TFS plug-in on both the desktop Win 7 and the virtual machine. It worked perfect on Win 7 but on the virtual machine running Windows Server the error came up.
My first step to solve this was by following moerketh advice and moved that specific file from Win 7 to Server 2012.
...plugins\com.microsoft.tfs.client.common.ui.vcexplorer_10.1.0.201101271439\com\microsoft\tfs\client\common\ui\vcexplorer\versioncontrol\
VersionControlEditor$VersionControlEditorRepositoryUpdatedListener.class
It did remove the error but did not show the folders in the server. In other words, I couldn't see the folders I am trying to map to.
Next, I decided to copy all files in the folder as shown below and paste it to the same folder in the virtual machine.
...plugins\com.microsoft.tfs.client.common.ui.vcexplorer_10.1.0.201101271439\com\microsoft\tfs\client\common\ui\vcexplorer\versioncontrol\
VersionControlEditor$VersionControlEditorRepositoryUpdatedListener.class
Restarted Eclipse, and then the TFS folders showed.
I've just bought a new computer x64 and intalled windows 7 and Eclipse Helios x64. When I tried to install subclipse it didn't work... after a few times trying to install it and getting stuck when eclipse was trying to check the dependences, I did get to install it but it simply didn't work.
When I chenged the perspective to SVN Repository I got an error. Anyway, I downloaded Eclipse Helios x86 and also got stuck on the dependeces checking part. But after a while trying it was installed and now it works.
But the thing is that I want to install eclipse helios x64 since I have a x64 computer.
Did anybody have the same or a similar problem? How did you solve it?
Thanks.
I'm using Eclipse64 with a working SVN plugin.
But I changed the SVN Client interface from "Java HAL" to "SVNKit" which works much better. I installed this module via Yoxos and then switched in the preferences Team > SVN > SVN interface to SVNKit.
If you want to stick to JavaHL way of accessing the repository, you can also install the 64 bits version of JavaHL.
Referenced here - look at the paragraph saying Windows 64-bit. It will redirect you to slik subversion client
You can install the whole client (I could not install only javahl with the custom install)
To make sure it is taken into account, edit your eclipse.ini file and, after the -vmargs line, add -Djava.library.path=C:\programs\slik (or if you already have an item for the jni path, add your own path).