McClain Looney <email@example.com> wrote on 07/08/2004 01:49:53 PM:
> 0.9.8 is out, has a fix for a the rename package bug
Nevermind. I found it in the preferences.
Have you noticed any of the problems I have posted on the dev@ list in the
last week or so? Specifically these weird "refresh"-type problems? I
have never had problems with this with CVS, and it is the one complaint I
have with Subclipse. It makes it hard to do plugin development.
To recap, the problem is that changes to the .classpath and plugin.xml
files (perhaps others) do not seem to "register" with Eclipse when the
files are updated by Team -> Update. The file contents and info is
updated, but Eclipse does not recognize the changes.
For example, load a plugin project in two workspaces. On one of them,
open the project properties and change the Java Build Path to use some new
JAR files. Then commit the modified .classpath file.
Now go to your other workspace and do an update. Then open the project
properties and check the Java Build Path. The changes will not be shown
even though they are in the file.
You get similar problems with the plugin.xml file. I do all of our builds
so I am always the one that increments our plugins version number.
Whenever I do that and people update they have problems with their runtime
workbench because Eclipse reports the plugin as out of synch. That is
because it still has the old version number internally, but sees the new
version number in the file.
I have poked around the code to see if I could spot the problem, like
perhaps you were not using WorkspaceModifyOperation but as far as I can
tell the code looks right. I am just wondering if you have seen this
problem. We experience it on Eclipse 2.1.3 and 3.0 on all workstations
100% of the time. This is on Windows with 1.0.5 and Windows Apache server
Received on Fri Jul 9 04:03:47 2004