Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!news2.arglkargh.de!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Prevent Eclipse from IO access to source code on *any* GUI interaction Date: Tue, 08 Jan 2013 23:30:47 +0100 Lines: 52 Message-ID: References: <50eb3ae3$0$9515$9b4e6d93@newsspool1.arcor-online.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net w83u1/Wh+Jb9txPbWFNHqgQnQPPJqyAHIRFzaKU3qlrs79/h8iauYhzFohwU9nA9w= Cancel-Lock: sha1:cLaoFXzXXvtjsIKtx9E1KnBgEZg= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <50eb3ae3$0$9515$9b4e6d93@newsspool1.arcor-online.net> Xref: csiph.com comp.lang.java.programmer:21224 On 07.01.2013 22:15, Marcel M=FCller wrote: > I am working with Eclipse Juno in a cross platform development. The > source code is on a NFS server, which is not that fast. NFS has also other issues (file locking, timestamps - might be dependent = on the NFS version used) which make it a sub optimal choice for=20 development and building in my experience. > Unfortunately Eclipse seems to access the source files over and over, I= > guess to verify whether they are modified or removed in the file system= =2E > This causes GUI interactions like moving files from one editor to > another to become incredibly slow. It sometimes takes seconds until the= > green highlight responds to mouse movements. And often I create new > editors accidentally. Other actions like changing the current file are > affected too. > > Is it possible to avoid these kind of access? I do not need the up to > date checks. Especially not /that/ often. You can tweak that a bit via settings but I am afraid not to a level=20 which would make working on an NFS share comfortable. > Using a local workspace speed up the things at least by a factor 10. Bu= t > this also increases the compile time on the remote machine by a factor > 10, which is definitely undesirable. That I don't really understand. Wouldn't you check out your files on=20 the remote machine from some kind of version control system and build=20 there? You're not placing only build artifacts on the NFS mount, do you?= If you do not want to go down the route of distributed version control=20 (which you should for a whole lot of other reasons) you could have your=20 workspace local and rsync it when doing the build to the remote machine. = Then start the build there. But this is really a crutch. Kind regards robert --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/