Home » Newcomers » Newcomers » Building Workspace - How to prevent
| Building Workspace - How to prevent [message #204525] |
Thu, 12 April 2007 15:51  |
 Kenneth Evans, Jr.
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi,
I have a large Eclipse workspace (100 or more projects) that I work with on
3 computers (work, home, and laptop) by merely copying the project and
eclipse directories. This works fine. I only have to copy the new and
changed files. The problem is that after loading the new files on another
computer, Eclipse insistes on rebuilding the entire workspace. This causes
all the class files to become newer so that they have to be copied next
time.
This not only makes it take longer to copy the files, but I have to wait for
the workspace to build before the interface becomes responsive.
I am using 3.2.1.
Does anyone have an idea as to why it thinks it has to rebuild everything.
Many of the projects are untouched, do not depend on any other projects, and
the class files are newer than the source files. It should not be necessary
to rebuild these projects.
I have:
General | Editors | Startup and Shutdown: Refresh workspace on startup
unchecked
General | Editors | Workspace: Buiild automatically, Refresh automatically,
and Save automatically before build all checked. Without Refresh
automatically, the Workbench doesn't notice if the file was changed
externally and searches invariably say the file system is out of date. Not
checking Build automatically is really inconvenient, as is Save
automatically before build.
Perhaps I have missed another setting?
Thanks,
-Ken
|
|
|
| Re: Building Workspace - How to prevent [message #204621 is a reply to message #204525] |
Thu, 12 April 2007 22:40  |
Eclipse User |
|
|
|
Originally posted by: eclipse5.rizzoweb.com
Kenneth Evans wrote:
> Hi,
>
> I have a large Eclipse workspace (100 or more projects) that I work with on
> 3 computers (work, home, and laptop) by merely copying the project and
> eclipse directories. This works fine. I only have to copy the new and
> changed files. The problem is that after loading the new files on another
> computer, Eclipse insistes on rebuilding the entire workspace. This causes
> all the class files to become newer so that they have to be copied next
> time.
>
> This not only makes it take longer to copy the files, but I have to wait for
> the workspace to build before the interface becomes responsive.
Something you are touching is triggering Eclipse to assume a rebuild is
needed. It is hard to say exactly what because you are doing something a
bit odd behind Eclipse's back and you are glossing over some details of
exactly what you are copying each time.
Do you not have a CVS server or other source control mechanism in place
you could use to move between the machines? That would be the ideal
choice (note that setting up a CVS server for your own is pretty easy -
spend an hour and you'll be good to go).
It is possible that touching the .project or .classpath files is what is
triggering the rebuild. Are you copying those files?
What exactly are you doing to determine which files to copy each time?
Hope this helps,
Eric
|
|
|
| Re: Building Workspace - How to prevent [message #204733 is a reply to message #204621] |
Fri, 13 April 2007 00:14 |
Kenneth Evans, Jr.
Messages: 77
Registered: July 2009 |
Member |
|
|
Thanks for the reponse. This is on Windows, and I use Robocopy with /PURGE.
Files that are not changed should not be copied and files that are no longer
on the source should be deleted. The .project and .classpath files have old
dates (usually) since they don't change. Thus, it _doesn't_ touch them.
The bottom line is that I should have a mirror image of all the files, and
the situation should be the same as if I restarted Eclipse on the previous
computer. I copy both the eclipse and work directories (actually the
directory above the work directory) to insure any cached settings are
retained. The .java files are (usually) somewhat old. The .class files are
always recreated each time and are new.
Since the .class files are newer than the .java files, there should be no
reason to rebuild.
This is much easier than using a CVS or Subversion server. I don't need an
internet connection or to VPN. There are many files involved that are 3rd
party and not in the repository. Apart from the annoyance of the
rebuilding, it works well, and I have been doing it for a long time. I
recall that it didn't used to rebuild, but maybe I had fewer files and
didn't notice.
In any event, I can do this even with the rebuilding faster than I could
update over 100 projects in different repositories using Subversion.
It is something Eclipse is doing that it doesn't have to do. There is
likely a setting, else I think it is a bug.
-Ken
"Eric Rizzo" <eclipse5@rizzoweb.com> wrote in message
news:evmchm$u6k$2@build.eclipse.org...
> Something you are touching is triggering Eclipse to assume a rebuild is
> needed. It is hard to say exactly what because you are doing something a
> bit odd behind Eclipse's back and you are glossing over some details of
> exactly what you are copying each time.
> Do you not have a CVS server or other source control mechanism in place
> you could use to move between the machines? That would be the ideal choice
> (note that setting up a CVS server for your own is pretty easy - spend an
> hour and you'll be good to go).
> It is possible that touching the .project or .classpath files is what is
> triggering the rebuild. Are you copying those files?
> What exactly are you doing to determine which files to copy each time?
>
> Hope this helps,
> Eric
|
|
|
| Re: Building Workspace - How to prevent [message #204797 is a reply to message #204733] |
Fri, 13 April 2007 14:56 |
| Eclipse User |
|
|
|
Originally posted by: eclipse5.rizzoweb.com
Kenneth Evans wrote:
> This is much easier than using a CVS or Subversion server. I don't need an
> internet connection or to VPN. There are many files involved that are 3rd
> party and not in the repository. Apart from the annoyance of the
> rebuilding, it works well, and I have been doing it for a long time. I
> recall that it didn't used to rebuild, but maybe I had fewer files and
> didn't notice.
>
> In any event, I can do this even with the rebuilding faster than I could
> update over 100 projects in different repositories using Subversion.
>
> It is something Eclipse is doing that it doesn't have to do. There is
> likely a setting, else I think it is a bug.
There is almost certainly no setting, since you are doing something that
Eclipse was not designed to expect or handle (although it is designed to
recover from just about anything by rebuilding). Since you are going
behind Eclipse's back and mucking around with the files that it uses to
maintain its own internal state, I don't even know if I'd classify it as
a bug. I'll hear the argument, but I don't necessarily buy it.
Still, if you can try narrowing it down to determine exactly which file
change(s) is/are triggering the full rebuild, you could report an
enhancement request (or bug) if it turns out your copying has not indeed
modified any of Eclipse's internal state management files. I encourage
you to try to do that in the interest of improving the tool for the
entire community.
Hope this helps,
Eric
|
|
|
| Re: Building Workspace - How to prevent [message #204805 is a reply to message #204797] |
Fri, 13 April 2007 18:50 |
Kenneth Evans, Jr.
Messages: 77
Registered: July 2009 |
Member |
|
|
Eric,
I don't feel I am "going behind Eclipse's back". I am not mucking with the
files. I am copying the complete set of files from one computer to another.
The files it uses to maintain its state should be copied with them. One of
the advantages of Eclipse is that it doesn't use the registry, so this
should work even better than it does with other programs.
I also do the same thing with Visual Studio, DreamWeaver, and several other
programs. It is an intelligent thing to do. Many of us work at home on the
same things we work on at work. In my case, I also give demos on my laptop
and work on it while on travel, so I need the current files there. Simple
copying allows me to maintain one set of files and have everything be the
same on all three, as well as to do that rapidly. It also provides a
backup, both on the portable media and on the previous other two computers.
It takes less than 5 min to do the transfer (and would take even less if it
didn't keep changing the .class files ;-).
And surely you have noticed people invariably do strange and wonderful
things with your software that you never thought of. It is the nature of
people and is a good thing. It is what caused them to invent computers in
the first place.
The problem seems to be that Eclipse "is designed to recover from just about
anything by rebuilding". It needs a little more [artificial] intelligence.
It probably doesn't make a noticeable difference in small setups, but it
becomes expensive with large ones.
The first thing to do would probably be to determine why it thinks it needs
to recover. One would think all of the files involved are the same. Does
it keep track of GUIDs or something? Perhaps there is a small difference in
the clocks. If you understand the internals, you would be in a better
position than I to know that.
One of the reasons for setting "Refresh automatically" is that I kept
getting messages about being "out of sync with the file system" when I did
searches. What causes it to think it is out of sync.
I tried unchecking "refresh automatically". The next time it rebuilt 1363
class files instead of 3314 (determined by searching for *.class with a date
range). BTW, the 3314 seems to be all of the ones in my open projects. In
both cases I only opened Eclipse and let it rebuild. I did not change
anything. I cannot see what distinguishes the 1363 from the rest. I tried
a "Refresh" on one that was not rebuild the second time. That caused it to
rebuild the class files. So it has something to do with refresh. And in
this case doing that was the first change I made, which is "narrowing it
down" about as much as one can.
I can try to verify if any state files were changed. Do I have to do a
diff on the Entire eclipse and workspace or can it be narrowed down. I tend
to trust Robocopy, but you never can tell. One thing it doesn't do right on
Windows is to change filenames that have the same spelling but the case
changed. (It changes the files, though, if needed.) I would not guess I
have a lot of those, and it shouldn't affect the whole workspace.
I don't have any problems with not calling it a bug, but it would be nice if
it didn't rebuild when it doesn't need to, as it doesn't in this case.
Perhaps there needs to be an option to not rebuild class files that are
newer than the source files when doing refresh. It appears as though it is
blindly rebuilding whenever it "thinks" something has changed.
Thanks for looking at it. I am sure we are both interested in improving the
tool for the entire community. I am sorry if I appeared to be attacking.
-Ken
"Eric Rizzo" <eclipse5@rizzoweb.com> wrote in message
news:evo5ne$mga$1@build.eclipse.org...
>
> There is almost certainly no setting, since you are doing something that
> Eclipse was not designed to expect or handle (although it is designed to
> recover from just about anything by rebuilding). Since you are going
> behind Eclipse's back and mucking around with the files that it uses to
> maintain its own internal state, I don't even know if I'd classify it as a
> bug. I'll hear the argument, but I don't necessarily buy it.
>
> Still, if you can try narrowing it down to determine exactly which file
> change(s) is/are triggering the full rebuild, you could report an
> enhancement request (or bug) if it turns out your copying has not indeed
> modified any of Eclipse's internal state management files. I encourage you
> to try to do that in the interest of improving the tool for the entire
> community.
>
> Hope this helps,
> Eric
|
|
|
| Re: Building Workspace - How to prevent [message #204858 is a reply to message #204797] |
Sat, 14 April 2007 16:24 |
Kenneth Evans, Jr.
Messages: 77
Registered: July 2009 |
Member |
|
|
Eric,
After the previous post, I moved the files again. After copying them to the
new computer, I did a diff on the directory that contains my work directory
and on the eclipse directory with the portable media (USB hard drive). They
match exactly, as expected.
It seems likely that Eclipse is using timestamps to determine if files are
"out of sync with the workspace". The clock on this computer (at home) was
8 sec behind pool.ntp.org and also the same behind our server for the
computer from where the files came from. I updated it to be the same before
I started Eclipse.
It still rebuilt 1309 files (with "refresh automatically" unchecked). BTW I
note that with this unchecked it still notices that files have been changed
externally, if they have been, at least when they are open in the active
editor.
The timestamps could still not match to the precision they get written.
This is assuming the mechanism is to look at cached timestamps to determine
if files are "out of sync with the workspace". It would be useful to know
what the mechanism really is. And it would help to know what makes it think
it needs to rebuild; that is, what is its algorithm.
Even with the increased time it takes to copy the unnecessarily-changed
files and the time waiting for the workbench to become responsive, it is
still a good thing to do. Where it has the most adverse impact is when I
use my laptop to show people how good Eclipse is, and they see it not
working well because it is so busy rebuilding. I do this often, and it has
been embarrasing. I guess I need to remember to have started the workspace
before giving demos. Unfortunately, sometimes there isn't time: I pop them
on the laptop and leave for a meeting.
Thanks,
-Ken
|
|
|
| Re: Building Workspace - How to prevent [message #205201 is a reply to message #204805] |
Mon, 16 April 2007 14:13 |
| Eclipse User |
|
|
|
Originally posted by: eclipse5.rizzoweb.com
Kenneth Evans wrote:
> Eric,
>
> I don't feel I am "going behind Eclipse's back". I am not mucking with the
> files. I am copying the complete set of files from one computer to another.
> The files it uses to maintain its state should be copied with them. One of
> the advantages of Eclipse is that it doesn't use the registry, so this
> should work even better than it does with other programs.
To be brief: you are doing manually what a source control tool is
designed to do. CVS and/or SVN are lightweight solutions to your problem
and don't have the issue of you know being able to tell exactly which
files have changed that will trigger a rebuild.
To be lengthy: Eclipse is "intelligent" about its monitoring of the file
system (as evidenced by the "resource is out of sync" messages when you
have touched a file outside of Eclipse and not told it to refresh). By
design it does not (by default) monitor the file system continually;
whenever you change the files behind its back you have to tell it to
refresh.
You need to determine exactly which files are changing in a small
scenario in order for us to understand why the rebuild is happening. You
were right in the assumption that Eclipse uses timestamps to determine
if a file has changed.
Another thing: a rebuild, even of a thousand files, should not be
particularly slow unless you are on an old or over-taxed machine. What
are your processor and memory and disk speed specs? What version of Eclipse?
Still, what you are doing manually might seem natural to you but it is
precisely why SCM tools were invented.. Also remember that (by design)
workspaces (not projects) are specific to a machine and not intended to
be shared. By copying workspace files (I'm not sure it if you are or
aren't) you would be essentially trying to share a workspace across
different machines, something that is not supported.
Hope this helps,
Eric
|
|
|
| Re: Building Workspace - How to prevent [message #205609 is a reply to message #205201] |
Wed, 18 April 2007 03:52 |
Kenneth Evans, Jr.
Messages: 77
Registered: July 2009 |
Member |
|
|
Eric,
I thought I explained why this is better than a source control tool, or
rather is better than using a source control for this purpose. I will do
this whether Eclipse is making it harder or not. It is a sensible thing to
do. Eclipse is building files that don't _need_ to be rebuilt. That is not
a sensible thing to do.
I use both Subversion and CVS and am familiar with both. My computer is
new, has two dual core processors, 3 GB of RAM, and other equivalent
performance. The problem is both in waiting for Eclipse to rebuild and in
waiting to copy the files that didn't need to be changed. The speed for
the second is probably limited by USB thoughput, not my machine. I am also
not stupid as you are implying. I have a PhD in Theoretical Physics.
The thing about sharing a workspace across several machines is nonsense. I
am not sharing these files. They are separate entities on each system. Or
are you telling me copying files from one computer to another is not
supported?Moreover, I _do_ actuually share Linux and Solaris projects on a
common file server, and that works OK even though they are separate OS's.
Actually, now that I think about it, I also am sharing one project on that
same server with Windows, as well. There is nothing wrong or strange about
doing any of these two things. It is a benefit of using Java.
Who is deciding this isn't supported?
And no, that doesn't help. I tried to get information about what Eclipse is
doing, and that might help.
-Ken
"Eric Rizzo" <eclipse5@rizzoweb.com> wrote in message
news:f000b4$lvp$1@build.eclipse.org...
> Kenneth Evans wrote:
>> Eric,
>>
>> I don't feel I am "going behind Eclipse's back". I am not mucking with
>> the files. I am copying the complete set of files from one computer to
>> another. The files it uses to maintain its state should be copied with
>> them. One of the advantages of Eclipse is that it doesn't use the
>> registry, so this should work even better than it does with other
>> programs.
>
> To be brief: you are doing manually what a source control tool is designed
> to do. CVS and/or SVN are lightweight solutions to your problem and don't
> have the issue of you know being able to tell exactly which files have
> changed that will trigger a rebuild.
>
> To be lengthy: Eclipse is "intelligent" about its monitoring of the file
> system (as evidenced by the "resource is out of sync" messages when you
> have touched a file outside of Eclipse and not told it to refresh). By
> design it does not (by default) monitor the file system continually;
> whenever you change the files behind its back you have to tell it to
> refresh.
> You need to determine exactly which files are changing in a small scenario
> in order for us to understand why the rebuild is happening. You were right
> in the assumption that Eclipse uses timestamps to determine if a file has
> changed.
> Another thing: a rebuild, even of a thousand files, should not be
> particularly slow unless you are on an old or over-taxed machine. What are
> your processor and memory and disk speed specs? What version of Eclipse?
>
> Still, what you are doing manually might seem natural to you but it is
> precisely why SCM tools were invented.. Also remember that (by design)
> workspaces (not projects) are specific to a machine and not intended to be
> shared. By copying workspace files (I'm not sure it if you are or aren't)
> you would be essentially trying to share a workspace across different
> machines, something that is not supported.
>
> Hope this helps,
> Eric
|
|
|
Goto Forum:
Current Time: Thu Apr 25 14:43:27 GMT 2024
Powered by FUDForum. Page generated in 0.07979 seconds |
] 
Search
Help
Register
Login
Home
