Some background: I'm using Eclipse 3.7 (for RCP developers) to work on a few plug-ins that are part of a large (hundreds of plug-ins) RCP application built using Maven with Tycho. I've set up the target platform and the run configuration, and everything builds fine and seems to run fine except...
The changes I make to plug-ins I have in my workspace are not taking effect. In particular, when I debug the application near the changes I've made, the running version of the class is clearly not synchronized with the source code I'm seeing.
I have "Launch with: all workspace and enabled target plug-ins" chosen in the run configuration. If I change it to "plug-ins selected below", the workspace plug-ins are checked in favor of the same plug-ins from the target platform, but my changes are still being ignored at runtime.
Google hasn't been very helpful, and the solutions to similar problems reported by others on SO (e.g. reload the target platform) haven't solved my problem.
Related
I recently upgraded from Eclipse Kepler to Luna. A plugin I had been working on is now showing build errors without any source being changed.
Here is an extract from my MANIFEST.MF,
Require-Bundle: org.eclipse.core.runtime;bundle-version="3.7.0",
org.eclipse.ui;bundle-version="3.7.0",
org.eclipse.ui.ide;bundle-version="3.7.0",
org.eclipse.core.resources;bundle-version="3.7.0",
org.eclipse.ui.forms;bundle-version="3.6.0",
org.eclipse.wst.sse.ui;bundle-version="1.3.0",
org.eclipse.jface.text;bundle-version="3.8.100",
org.eclipse.ui.workbench.texteditor;bundle-version="3.8.101",
org.eclipse.ui.views;bundle-version="3.6.0"
None of the core or ui bundles are resolved. I don't think Eclipse could even run without them and their equivalent .jar files are present and readable and haven't been modified as part of the upgrade, so they are not actually missing. When I try to add dependencies on the Dependencies tab the problem bundles do not show.
Eclipse was upgraded by the Arch Linux package manager. I mention it for completeness but believe it is likely identical to any other upgrade mechanism. I also tried creating a new plug-in project but the same happens, I guess this means it's a global setting. I'm relatively new to PDE and so far haven't had a need to change any settings.
From the preference page (Preferences > Plug-in Development > Target Platform), try Removing the Running Platform target definition, Applying, and then Restoring Defaults. Maybe it's just stale and pointing to the jars that it doesn't know Arch has changed about.
This is my first attempt at creating an Eclipse plug-in. I've created one, along with a feature and update site. I set the target platform as my local Eclipse installation. When I run/debug the plugin from within the development environment everything works fine.
Now, my colleague installed the plug-in from the update site that I hosted. When he starts using any of the functionality exposed by my plugin he gets runtime exceptions.
He sees null pointer exceptions which didn't occur when I ran my plug-in project from my development environment.
I have a wizard that's part of my plug-in. When he close it he gets a "Unhandled event loop exception", and the wizard doesn't close. I didn't have this issue when I was running/debugging my plugin in my development environment.
Now I'm confused as to why the same plug-in is behaving differently in the production environment, as against the dev environment and when I was debugging it from my IDE. The target platform in both cases is the same Eclipse version. What could be the reasons?
And how do I debug the plug-in in a production environment? Is there a remote debugging capability for debugging the plug-ins on the production environment?
Any suggestions would be really useful!
To remote debug your plug-in, first add debug arguments to your target Eclipse .ini file
-vmargs
-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044
before launching it.
Then open another Eclipse instance with a workspace containing your plug-in project.
Open Run > Debug Configurations..., select Remote Java Application and create a new configuration.
As Project, browse and select your plug-in project.
Also fill in your connection properties (host of target Eclipse and port 1044).
Launching the newly created debug configuration allows you to debug your plug-in the same way you debug locally.
Now I'm confused as to why the same plug-in is behaving differently in
the production environment, as against the dev environment and when I
was debugging it from my IDE. The target platform in both cases is the
same eclipse version. What could be the reasons?
This is a classic: Eclipse plugins and RCP applications do indeed behave differently between PDT (the Eclipse IDE) and the exported product.
In your case, a NullPointerException thrown from the exported version but not from Eclipse is 9 times out of 10 an image or other resource files (properties, etc.) that is loaded by your code but is not listed in the build.properties of your plugin.
Anyway, you'll need to check the logs to retrieve the stacktrace and hunt down its cause. Such logs could be found in your friend's workspace under le .metadata/.log file
From your development workspace as it stands now, use the "Debug As -> Eclipse Application" menu item to startup a test workspace. When it starts up, you'll have two workspaces running: the original development workspace and the new test workspace. You can set breakpoints in your plugin code in the development workspace and run your plugin in the test workspace.
When your plugin execution in the test workspace gets to one of your breakpoints, execution will pause and you can use the Debug view in your development workspace to look at variables, set more breakpoints or anything else you want to do to debuf your plugin.
See the Apache Wiki for Developing with Eclipse.
Under Windows 10 with Tomcat running as a windows service I started:
tomcat8.5\bin\Tomcat8w.exe
& added in the Java tab as the first entry in Java Options to enable remote debugging:
-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n
I do C++ embedded development for the NetBurner platform. They have plug-ins that customize Eclipse and in addition to a build tool-chain they add a Launch Group under the Run Configuration area. Everything was working fine under Indigo (32 bit) when I decided to install Subclipse (big mistake). As soon as the install finished I could no longer run my existing configurations successfully. When I went into the Run Configurations area I noticed the Launch Group I used to use was missing. Here is what it looked like earlier yesterday:
Here's what it looks like today:
Things I've tried
First I uninstalled the Subclipse plugins using the
Help->About->Installation Details and then selecting them one at a
time, Uninstalling and restarting after each uninstall. No change.
Then I unpacked the original Eclipse Indigo/CDT 32 bit download to a
fresh folder. Copied over the NetBurner plugins from the zip I got
from the manufacturer. No change.
Launched with different Workspaces, no change.
Launched a Galileo version, it uses older plug-ins, and it still
works.
Copied older plug-ins into Indigo, the older NetBurner launcher
shows up (but it doesn't really work with Indigo)
Removed the older plug-ins put in the newer ones, old NetBurner
launcher went away new launcher does not show up.
Tried removing the
{Workspace}.metadata.plugins\org.eclipse.debug.core.launches - no
change.
Interestingly even though launches has many .launch files that should show up under Run Configuration, nothing shows up.
One other strange (possibly relevant) thing is that icon for the NetBurner Perspective went away, now it just has <NetBurner> as the text and a generic perspective icon.
I can still cross-compile and build for the NetBurner (i.e. the build toolchain still works), it's just the ability to use run configurations that seems to be missing.
I'm out of ideas, does anyone know of some global setting that sits outside the workspace and outside the Indigo installation folder that could be causing this?
I'm running on Win 7 64 bit ultimate, I run the 32 bit version of Indigo because the 64 bit doesn't appear to work with the NetBurner plug-ins. I've also disabled the two Mylyn tasks under General->Startup and Shutdown (they seemed to cause many Permgen memory crashes). This is the same setup I had working flawlessly yesterday.
Update
I also noticed that only 3 of the 4plug-ins are showing up in the Installation Details plug-in pane. The nbeclipse.core_2.6.0.jar is in the eclipse plugin directory but not showing as loaded. So I guess I know now the problem is the plug-in isn't loading but I don't know why or how to get it to load, or what subclipse could have changed that would cause this.
I suspect that the Subclipse installation may have caused an update to some other plugin(s) that it depended on (keep in mind the transitive nature plugin dependency resolution; if you're installing plugin A and it requires a certain version of Plugin B that you don't have, Plugin B will be installed or updated to that version). In doing so, maybe the NetBurner plugin can no longer load because its declared dependencies are no longer met (ie, it depended on an earlier version and does not tolerate a later version).
You can use the OSGi Console to help determine why a plugin is not loading. Here are a couple of references that should help:
http://grep.elasticpath.com/community/techblog/blog/2010/05/27/eclipse-plugins-and-the-osgi-console
http://www.vogella.com/articles/OSGi/article.html#osgiconsole
By the way, you can not just copy plugins into an Eclipse installation and expect them to work. For several versions now, Eclipse has not supported that ability. You must use Help > Install New Software or File > Import > Install > From Existing Installation to install plugins. Ask the vendor if they have an update site to install from; like I said above, simply dropping things into Eclipse's plugins folder is not supported any more, it won't work. Other than the vendor providing an update site, the only other option is to use the dropins folder, as described here.
I'm sorry for a pretty vague title, didn't want to turn it into a paragraph.
So, I am using Eclipse Platform 3.7.1 (the one with absolutely no plugin preinstalled), the latest version so far, and I have discovered that by taking advantage of its -configuration option, I can choose which plugins are running and which are not. It was going well enough until I started installing the plugins.
But allow me to explain my setup first, I am using Ubuntu linux by the way. Using only one eclipse installation, my installation is arranged in the following order:
Installation:
~/bin/opt/eclipse
eclipse (executable binary)
~/bin/eclipse -> opt/eclipse/eclipse
Configurations:
~/.eclipse/configuration
web-php
android
java
Installing JDT and ADT while running eclipse and using the android configuration directory posed no problems. So I moved on to the php configuration and tried to install PDT (the JDT and ADT plugins were not activated here, so far so good). The problems came along after the installation, not only was I not able to use PDT, I noticed in the Installation Details that JDT, ADT, PDT were installed but not activated. Instead, they were all activated in the android configuration. To make it worse, when I chose the Java configuration, I could not even use JDT.
My expectations however were when using:
eclipse -configuration ~/.eclipse/configuration/android
was that only the JDT and ADT were activated and when using:
eclipse -configuration ~/.eclipse/configuration/web-php
only the PDT is activated
Regarding the java configuration however, it's probably another problem altogether but if there was help on how to activate a plugin installed from another configuration, I'd deeply appreciate it.
Also, see Single Eclipse install with multiple Configurations and Workspaces
In a p2 world there are extra steps to isolate bundles from each other. You need not just a different configuration directory, but a different p2 profile.
Have a look at the config.ihi in each of your configurations. There are two ways that Eclipse identifies the plugins to use, the ..updateconfigurator, which simply uses all of the plugins in the plugins folder, and the ..simpleconfigurator which uses the bundles.info file in that's in the org.eclipse.equinox.simpleconfigurator folder (which is maintained by the p2 installer). Make sure this file is what you expect.
And also, you might want to start with the -clean option if you are using the updateconfigurator to have it rescan all of the plugins (otherwise it remembers in some hidden cache).
Make sure when you installed everything that you had your -configuration set to the right place for the different things you installed.
I hope some of this points you in the right direction.
We have an Eclipse RCP product, which means it depends on a number of Eclipse plugins (for the UI etc). We have set up a reference Eclipse ("target") to supply the latter.
Our product also depends on a number of third party plugins. Is there a standard location for these to be put?
We have a few of our third-party plugins in the /plugins of the target Eclipse, but this seems wrong to me. The third party plugins change more frequently than, or at least in a different timeframe to, our reference Eclipse.
I tried putting some third party plugins in a separate project in the workspace (under version control), but the PDE headless build did not seem to find them - even though I used the pluginPath property in the headless build.properties.
This is Eclipse 3.4.2. I am aware than the handling of target platforms has changed somewhat in 3.5.
Most of the comments I've seen see on the web about this seem to assume that you're writing a plugin to be added to a standard Eclipse installation. We're not, it's a completely separate product.
For my RCP applications I created a customized target platform directory for it to use (e.g. rcpapptarget). Under that directory I unzip the following packages:
eclipse-RCP-SDK-3.4.2-win32.zip
eclipse-3.4.2-delta-pack.zip
Then I add what ever other eclipse or third party plug-ins that my application will need. For example:
the latest GEF all .zip file
jay libs EclipseCallBasic_1.1.0 plug-in
derby distributed plug-in
additional eclipse plug-ins needed for help support, cheatsheets, updates etc.
I then setup a workspace for developing that RCP application and point the workspace's "Target Platform" to use that customized target platform directory. I do all my development using that target platform and my headless builds use it too.
To set the target platform choose the Window | Preferences command and then select Plug-in Development | Target Platform from the preference tree. Set the "Location" to point to the directory you created.
There isn't a standard that I know of for where 3rd part plugins should go. You can define an external extension location and store your party plugins/features there. This also allows you to reuse the plugins in multiple Eclipse installs if you wish.
You add an Extension location by going to
Ganymede onwards: Help->Software Updates->Available Software->Add Site->Local
Older versions: Help->Software Updates->Manage Configuration->Add Extension Location
For Ganymede onwards, the extension locations work a bit differently (IIRC the plugins are copied to the standard Eclipse install, which kind of defeats the point),there is however a new concept called dropins that you might find useful.