I'm producing plugin's for eclipse - but for some reason when I build a new version of the plugin - the update site isn't noticing it.
The build process says that the plugins should be at version 1.1.0.201209191506, but when I access to install I'm shown these versions:
The XML file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<site>
<feature url="features/supportStructuresForCSFEditing -_1.1.0.201209191506.jar" id="supportStructuresForCSFEditing -" version="1.1.0.201209191506">
<category name="plancomps"/>
</feature>
<feature url="features/supportStructuresForCSFEditingTest -_1.1.0.201209191506.jar" id="supportStructuresForCSFEditingTest -" version="1.1.0.201209191506">
<category name="plancomps"/>
</feature>
<category-def name="plancomps" label="plancomps"/>
</site>
and this happens if I'm installing from local or from the web - any idea what might be happening? Or diagnostic tricks I could try?
EDIT - there have been restarts of the machine - and attempts from machines that have never seen the plugin's before - all have shown the old versions. :(
I'd check two things.
1) I think that due to a bug, sometimes features are removed from category (if you use GUI to update your site). So you might be looking at your plug-ins in your category, when latest version is at top level or vice-versa.
2) Eclipse caches current state of update site. So you need to restart, to make it show newer versions.
Most likely, your cache is not being updated. p2 will often cache update site content information. It looks like you are using old style update sites and that you do not have a content.xml(or .jar) and a artifact.xml(or .jar), which is not really supported any more and may make it harder to delete the cache.
Here are somethings you can try:
Help -> Install new software -> Available software sites -> (Select your update site) -> Reload
Delete and re-add your update site
Restart eclipse with the -clean option to clear out the configuration area
But, really you should be making sure that you are creating artifact.xml and content.xml (or .jar) and creating proper update sites.
Okay, so coming back to this I have a reason and a workaround.
Eclipse's caching is pretty aggressive. But something I was doing wasn't helping and I thought I'd share.
When I was building a new version of the plugin, I was deleting the previous one (which made sense to me, generally the previous one was an internal buggy thing and I could have always reconstructed it from the svn). However when I started leaving the previous versions in, the update site started working much more as expected.
I imagine the issue is already solved for the OP, but I thought I'd share:
I just spent 2+ hours fighting with a very similar problem and finally managed to solve it. I'm not sure whether my solution can be applied to this case. My case was like this:
I created some plugins and uploaded them to a software site I had also created.
In a default.target file I added the plugins from that software site.
I realized there was an error in one of the plugins, created it again, uploaded it to the software site, and clicked "Update" for that site in my default.target.
The plugin never got reloaded. Even when I deleted the update site, eclipse "magically" still saw it and pretended to update from there when I clicked update. Fun fun fun.
I tried all kinds of things and this is the only one that worked for me in the end (I'm going to assume that you have a default.target as well):
Remove the plugins that aren't being updated from your default.target.
Exit eclipse (at least the instance for the problematic workspace).
Backup your workspace, or at least default.target and <pathToYourWorkspace>\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\. It may be difficult to revert the following changes if you need to.
In <pathToYourWorkspace>\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\:
Open artifacts.xml and delete all references to the plugins that aren't being updated. Note that there may be multiple references to each plugin; for example in my case I have one with 'classifier='org.eclipse.update.feature' and one with classifier='osgi.bundle' (I'm using OSGi).
Open subdir features and delete the folders corresponding to the plugins that aren't being updated. (Sorting by date may help. Btw, in my case the "date modified" for those jars showed that they had only been downloaded the first time and never updated again)
Open subdir plugins and delete the jars corresponding to the plugins that aren't being updated. (Sorting by date may help. Ditto)
Open eclipse again, with the options -clean and -data <pathToYourWorkspace> so that it cleans the workspace.
Add the plugins to default.target.
If there are still problems try selecting the plugins or update site and clicking "Update", and/or restarting eclipse.
This almost drove me crazy. I hope this helps someone.
I think you first use a fresh copy of eclipse to add a plugin,if that plugin is already installed.Copy eclipse.zip in new folder,unzip it ,run eclipse and then start using update site to do this please
Help-->Install new software-->"paste update site url"-->It will catch updates-->click ok-->accept license-->"continue process"-->It gives a warning press Ok " now you are success in updating.
Note:An internet connection should be properly available.
Related
I have been struggling with a very weird issue that has suddenly popped up on the latest version of Eclipse Classic (4.2.2).
Everytime I try creating or refactoring a class or subclass in any of my projects (all Java) in my Eclipse workspace I get an error at the very top of my class that says
A class file was not written. The project may be inconsistent, if so try refreshing this project and building it
Again, this happens when I create new classes. And even when I rename current classes, then undo the renaming, its totally fine, but changing a single character in the name causes this error to happen for that specific class.
I have Auto Build on, and I tried multiple times to clean and refresh every project as well as restart Eclipse entirely.
I have literally no idea how to even start figuring out how to fix this. The solutions i've found through search didn't help, so i'm hoping I might find any clues here.
I had the same problem and here's how I solved it in the end:
It turned out that the disc space on the drive where workspace resides was full.
Silly mistake but worth checking.
In my case, this was caused by the fact that the build output directories were owned by a different user, and Eclipse could not write into them.
I had the same issues, the following worked for me:
Right click eclipse then running "as an Administrator"
Click Project > Clean.
Clean your workspace by starting eclipse from the command line with the -clean argument :
eclipse -clean
See also How to run eclipse in clean mode? and what happens if we do so?
I solved this problem by running Eclipse as root.
I had the same issue on Mac OS X. I had a maven project.
Try running the following command on Terminal. This looks like an access issue.
sudo mvn clean
Provide password for admin user.
Then open Eclipse and refresh your project.
We are using Eclipse here too and have to handle a workspace with more than 200 plug-ins. Every now and then people have similar problems with their workspace and inconsistencies reported in a weird way by Eclipse.
What people here usually do is (next step only in case previous step didn't help):
- trying to ContextMenu->Team->Clean/Refresh the whole workspace
- creating a new workspace and check out all necessary files from the repository
- reinstalling Eclipse to a new directory
From my experience after using the Eclipse IDE on a daily basis for many years, it doesn't make very much sense to waste too much time with these issues, unless they aren't solved by one of the steps above. It takes too much time to struggle with these things, while starting from scratch is done in an hour or less (and usually fixes the issue).
If your Eclipse still behaves strangely it might make sense to go through your installed plug-ins. Not all external plug-ins follow the Eclipse guidelines and can seriously harm the performance and operational consistency of your Eclipse installation (E.g. Sonar Plug-in, Toad Plug-in, ...)
In my case this kind of error caused due to disk space got full and it got resolved by just freeing disk space where eclipse have been installed.
That is c/d/e drivers.
I come up with the same error, and in my case, this is because the permission of the project/bin directory is not recursively 775
I fixed it by:
Remove the project/bin directory: sudo rm -rf project/bin
Switch to Eclipse, rebuild the project: Project->Clean...
Then no errors.
Try to launch Eclipse as Administrator.
In my case such error was caused by a question mark in a quoted method name (I use geb+spock combination for automated testing).
So this method name will throw an error "Do you want something?"()
And this will not "Do you want something"()
It may not be the best response but to fix it, I've just delete the error marker.
Had the same issue. but cleaning the project and restart eclipse didn't help and disk space was not the issue. Solved the issue by copy the code to notepad(just to not lose it) and then delete the class, recreate it and paste the code back in again.
I solved it changed the owner of the project files. I changed from root(old owner) to user my current(user that i use with eclipse).
Just changed and saved java file to recompile the class. Then error disappeared.
I was try run
Project->Clean...
And Rebuild. My problem was resolved
For linux (Debia) and working on Spring boot project (maven):
$ sudo mvn clean
Then open Eclipse and File -> Refresh.
I had same issue, it is something similar but this post didn't help in my case. I have many inner classes which is causing the compiler to create class names with all inner class names together that is creating class name more than 255 character file limit on NTFS! read it in some other blog. I thought it will be helpful to post here.
Ex : classA$InnerClassB$......InncerClassZ.class in target folder it won't generate the class if it exceeds this limit. Try renaming your inner class name shortened. In my case i have to add InnerclassZ as its exceeding its not generating class and Eclipse complaining.
A class file was not written. The project may be inconsistent, if so try refreshing....
I shortened InnerClassZ to IClassZ fixed the issue.
I had the same issue and it got fixed by running eclipse in administrator mode
Eclipse Shortcut-->Right click-->More-->Run as Administrator
I've been throught that error once when I used wsdl2java to extract java classes from a wsdl, it turns out that all classes were created in the same "class", causing end classes with long names (error - File name too long). When I organized and rename some classes the error disappeared.
I had this issue. I did the following, it resolved.
Open Eclipse in Administrator mode; Right click on eclipse.exe "Run as administrator"
Clean all projects.
#Denny's answer put me on the right track, though in my case it was the target directory. I deleted it for some reason and something automatically recreated with owner root. Changing the directory owner was not enough as it contained files that were also owned by root. So make sure to really remove the complete content of the directory and to change the owner.
In my case current user didn't have access to this project dir
Before giving a try to the above solutions. Just cleaned the project and it worked.
I am having a small problem with plugins not staying installed with Coda 2.2 for Mac on OSX 10.6. Every time I close Coda and open it back up and then click on plugins half of them are gone even though the are in the plugins folder for the application. I have to close Coda and uninstall and reinstall the plugin then open it back up. That is only good until I close it then it starts all over again. Is there anything I can do or is there something I am overlooking that is causing this to happen?
-Thanks
I've been working with Panic support and we've discovered there's an issue with certain plugins. Most likely, it's only one that's problematic. For me, it was WVCPs plugin. Removing that from the plugin folder allows all other plugins to work fine.
I found it helpful looking at the Console app for messages from Coda and one by one dropped the plugins back into the plugins folder until I found the one that caused an error about incompatible architecture.
You can ignore the error about two plugins implementing the same class, that seems to be a mutual exclusion sort of warning but still allows the other plugins to work.
One other plugin had a different error but again, appears to work fine so probably it was just a warning.
This is probably your best solution until Panic push out an update, which I am assured is on the way.
Hope that helps!
I've been using Eclipse a lot recently, and haven't had any problems with it. Last night, I was working on it perfectly fine. However, this morning, whenever I load it up, the program stops working half way the loading splash screen (before the actual workspace opens up). The information says "Loading Workbench" and just stays there forever. When I click on it multiple times, I get a message saying that Java(TM) Platform SE binary is not responding.
Google hasn't been a ton of help, and seems to just give a lot of responses about Minecraft. I'm slightly confused as to where I need to start looking, since nothing had changed since I successfully used it last. No updates to Java or Eclipse or anything else. Thanks for the help, and let me know if you need any more information!
I was actually able to fix it by just renaming my WorkSpace to WorkSpace1. Apparently it got corrupted somehow, and with the rename Eclipse was able to recreate a new one. Here's the link that helped me out:
http://spacetech.dk/eclipse-failed-java-was-started-but-returned-exit-code-805306369.html
Two things to check when you have problems with Eclipse:
First, always check the .log file, located in the .metadata directory (<workspace path>/.metadata/.log) of your workspace (not the Eclipse installation directory). Keep in mind that this is a hidden file under Linux or Mac OS. It usually contains the exception that is causing the crash. I usually delete any existing .log file before firing up Eclipse, just to make sure I am looking at the relevant log entries (the file will be recreated at startup).
If #1 does not help, you can try deleting the .metadata directory altogether. It will be recreated on startup (this is basically what you did by changing the workspace). In my experience with Eclipse, I noticed that some files can get corrupted inside .metadata, making Eclipse act weirdly. Keep in mind that this directory contains customizations you made in Eclipse and its plugins for the workspace and you might need to make them again.
Hope this helps.
Eclipse tends to be weird sometimes. If you move stuff around outside of the directories it was initially installed in, it usually won't load. I don't know if that's what you did, but your best bet is to back up your workspace, and reinstall eclipse. I'm sure that will do the trick.
Try a reinstall if possible or else, check the eclipse error log, which would be present at'/.metadata/.plugins/org.eclipse.ui.workbench/log'.
This will help you knowing the problem.
I have taken the org.eclipse.equinox.p2.examples.rcp.prestartupdate project and adapted it for use in my RCP application. I then setup an update repository that gets updated as part of my nightly build.
When I open my application it goes through the motions like it is updating - it finds the update site, generates an uninstall and install operand for each bundle correctly and says that it finished with no errors. The problem is that the plugins never actually get installed in the plugins folder even though the profile gets updated (a subsequent run states there are no updates). Next time my build runs it correctly identifies there are updates, but the same thing happens again.
I have spent days debugging and the only thing that looks out of the ordinary (not that I fully understand what is going on) is that during the final configure phase none of the TouchpointData objects have any instructions so it doesn't look like configure is doing what it should.
I really have no clue where to look next and would like to see if anyone else has any ideas.
Update:
I finally figured out what was going on.
The problem started when I built my product without the generating the metadata repository. When building through Eclipse I didn't check the "Generate metadata repository" in the export product wizards because I didn't need a p2 repository, just the product. The problem is that without checking that button the product does not install as P2 enabled causing side effects such as not generating a profile among other things.
I tried to compensate for this by manually creating a profile in code which I have since found out is a really bad idea. My original problems were created because my profile wasn't set up correctly.
Once I started exporting the product with "Generate metadata repository" checked the update started correctly installing the new plugins.
The problem I have now is that although the plugins are being installed correctly, the executable is getting trashed and I cannot launch my application any more. I am building my update site through Hudson and the binary folder which is present when I use the Eclipse Export Product wizard is missing. I am assuming that is what is going wrong now.
Any ideas why the binaries would not be building in my headless PDE build?
Figured this out also. I had assumed that all I needed was the individual launcher plugins for the platforms I wanted to build on. Since I was trying to understand the process I was copying over plugins one by one to the build server. It turns out to include the platform specific binaries in the build you need to have the org.eclipse.equinox.executable feature from the delta pack. Once I added that to the build the binaries started showing up in the output. With the binaries the update mechanism works exactly as intended.
I had assumed that all I needed was the individual launcher plugins for the platforms I wanted to build on. Since I was trying to understand the process I was copying over plugins one by one to the build server. It turns out to include the platform specific binaries in the build you need to have the org.eclipse.equinox.executable feature from the delta pack. Once I added that to the build the binaries started showing up in the output. With the binaries the update mechanism works exactly as intended.
I am getting a lot of errors when starting RAD7. The server doesn't respond to class changes. Sometimes the server won't start. Sometimes RAD will not acknowledge modules that I added to the server. It is kind of buggy.
I know there is metadata in the workspace, are there safe ways to clean the metadata or RAD in general?
Where RAD = Rational Application Developer
Another tip is to remove all projects in your Servers view in Eclipse, stop your server, start your server, open the admin console of your server and see that everything is gone in there as well. If you still see configured apps, remove them in the admin console. Shutdown server, start again and check for a clean startup. This ensures that your Eclipse server plugin and the server are in sync. Now you can add your projects to the server again; maybe this will improve the stability.
If not, a more drastic measure is to remove your server config in Eclipse (don't remove the server itself) and add it again in the Servers view.
You can also try to disable automatic publishing. You can go to Preferences->Server and uncheck the "Automatically publish..." If you are using WAS you additionally can double-click on your server in the Servers view, and go to the "Automatic Publishing" section and check "Never publish automatically". This might give you more control over when stuff gets published to your server, although it sometimes has a mind of its own and keeps publishing automatically in some cases.
eljenso has posted a good half of the answer. For the server not picking up resources, verify you are publishing. Right click the server and hit publish (I personally leave auto-pub off) The admin console / uninstall ear / then re-adding the ear is another way to go, however in RAD I've never needed to do this. In WID you need to do this as the publish is hopelessly broken in that God-forsaken tool.
RAD fixes:
Another half of the puzzle that you haven't touched on is making sure your project workspace is all up to date. Sometimes you will get bleeding (build errors) even though you know it's crabbing about nothing. When this occurs, close all the projects, optional step: shut down rad and re-open rad, re-open projects, refresh all projects, then do another build/clean.
ClearCase fixes:
If you happen to be using clearcase you're really in a world of hurt when things bleed for no reason. Before you do what I listed above, you'll need to do an update, restore (yes I'm aware update is supposed to do what a restore does and more - but it doesn't because it operates off of cached data, so it only updates what it thinks it needs to update. Unfortunately the caching algorithm is flawed), then refresh. This will guarantee all the files have been pushed to your file system properly, now you need to do the aforementioned step to make RAD pick up the [possibly new] file changes that just got pushed to your file system.
If you're working with a large project and you have RAD + clearcase, sit back and relax, it's going to be a while to let that restore finish. It's best to try just update, refresh + RAD fixes and see if that fixes the problem first. Restore should be your last ditch effort on a large project. (If you have a small project just do everything every time).
Eclipse can take a -clean parameter on startup. Perhaps this is what you are looking for?
If you really need to wipe all of the workspace meta, deleting the .metadata directory within the workspace should do the trick. Note that this wipes out settings, workspace layout, and even which projects are available (you will need to re-import all of your old projects, despite the fact that they are still in the workspace dir).
If you need to purge your metadata settings, try just deleting .metadata/.plugins/org.eclipse.core.resources first! That saved me quite a bit of trouble...