I just noticed that one of our e4 RCP application keeps unbundling resources (eg, jars and icons) into a sub-folder in the configuration/org.eclipse.osgi, at every single run of the application. Consequently, the configuration folder quickly grows out of control.
Any idea what could be causing that?
Edit: it appears the issue might be specific to Windows. I cannot replicate on Ubuntu (GTK) or MacOS. All platforms are 64-bit ones.
The issue came from the bundles.info configuration file in org.eclipse.equinox.simpleconfigurator/. For deployment reasons, we had removed our bundle (the main app bundle) from there. While the OSGi of Eclipse Luna seemed to handle this just fine, unpacking the resources and assets, it seems that Mars and above do not like that, and Equinox attempted to unpack resources at every single run.
Related
I am having slight difficulties as of late with my eclipse installation. Necessary Background information: We decided to use a specific version of the Spring Tool Suite (3.8.1 to be precise) with a specific set of plugins as our common developing environment.
So what we did is this, we fetched the 3.8.1 STS, modified the default config so work with our gradle plugins and then repacked that so it could be easily distributed in our network.
After this, we installed the plugins in one of the clients and then pushed the plugins and dropins folder onto our network share as well, so we could easily update the plugins without having to repack the entire thing every time we decide on a plugin upgrade.
This worked fine on almost all machines, except one, but we this that has something to do with the fact that the user in question has a second version of the Spring Tool Suite on his Computer.
However, roughly 2 days ago, I had to reset my installation because I carelessly updated too many modules and was unable to use the installation history to revert to the previous setting.
After I removed my current installation and purged the workspace, I reinstalled, reimported my projects and tried to work. This went fine until I tried to open a Spring Bean Configuration xml file with the provided Spring config editor - My IDE showed just an empty tab without title or content. After that, I tried to open the same file with any other internal XML editor, all showed the same - an empty tab. When creating a new Java Project, all XML Files are opened and displayed correctly though. But as soon as I try to open an XML file with the Spring Config Editor, I cannot open XML files in that project at all - except with a regular text editor.
Plus, sometimes my workspace gets addled by that so it generates an error and prevents eclipse from even starting.
Does anyone have any idea why this could be happening and what to do against it?
More Specs:
STS Version: 3.8.1
Eclipse Version: Eclipse Neon
Plugins: (all fetched on Jan 11, 2017)
Buildship Gradle Integration
Minimalist Gradle Editor
EclEmma & JaCoCo
SonarLint
Eclipse Metrics
Thymeleaf Content Assist
JBoss Community Plugins
A solution here was to use STS -clean, as that cleanes the data one most often misses.
in this case, it was workspace metadata that seems to have caused the error.
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.
I have a web project working in eclipse juno using tomcat 7 on one machine. I exported this project to subversion, and imported it into a fresh workspace of eclipse juno on another machine which also has tomcat 7 installed. To fix errors, I then set up the runtime "Apache Tomcat v7.0" on the second machine, and selected Projects/Clean/Clean all.
Now, my project has a list of libraries that includes "Apache Tomcat v7.0 [Apache Tomcat v7.0]", under which are listed all the jars in my tomcat installation, including servlet-api.jar, which eclipse is able to tell includes the package javax.servlet.http. However, I have hundreds of compiler errors from my source of the form "The import javax.servlet.http cannot be resolved" etc. Short of deleting and recreating the project (which might fix the second machine, but I worry that it will stop the project working on the original machine) what can I do to fix this?
Correction: the machines are running eclipse juno, not indigo as I previously stated.
If you did a refresh on the tree and a clean/build and the errors still exists, it must be the case, that they are not within the build path (check .classpath file).
So even though you may have checked it before, you should go there again and see if they are on the build path and maybe delete it and include them again.
Additionally, maybe this article about the specific problem helps.
Turns out that this is a fairly simple and annoying but otherwise harmless eclipse bug -- it seems as though the list of libraries that constitutes a particular runtime is cached when the project is loaded, and doesn't get updated if the library list changes (e.g. because the runtime didn't exist when the project was imported, but was created afterwards). Restarting eclipse causes it to reload the list, after which a project clean gets rid of the errors.
I want to create a java webstart product that includes all of the contents of my current eclipse installation - standard eclipse java edition with some extra plugins that I have developed/downloaded.
There are a number of tutorials showing how to do this for an eclipse RCP application, but I don't want to create an RCP specifically for this purpose (I also tried to do it and never really managed to configure the app to look just like my workbench).
So, is this even possible? Any pointers?
Update: I followed this article, but after deploying my application in the web server and running the jnlp, the jars were downloaded but nothing happened. I tried changing the eclipse.product property to other "possible" values, but didn't help.
Do you really need the web start software?
Since eclipse doesn't requires installation, and the plugins are installed in the same directory of eclipse why don't you zip your eclipse once you have it configured, and redistribute it as a zip. Even eclipse itself is distributed as zip.
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.