Vault 5.0.4.18845 / Eclipse 4.2.0 refresh trouble
Moderator: SourceGear
Vault 5.0.4.18845 / Eclipse 4.2.0 refresh trouble
I am a long-time Vault Standard user through the Windows Vault GUI client and Visual Studio 2005. I am now trying to deploy Eclipse 4.2.0 and Vault Standard Eclipse plugin 5.0.4.18845 (exactly matching our vault server version) on a Fedora 17 virtual machine.
I can get Eclipse projects defined and imported from the vault server. But then Eclipse eventually wants to do an automatic refresh at a subsequent Eclipse startup. The Eclipse platform splash appears with a status of "Loading Workbench". A "Progress Information" dialog window appears that says "Refreshing". And a vault login window is also present with my userid, password and vault server listed.
But unfortunately I cannot interact with the vault login window at all. I cannot modify the fields, nor does clicking the Cancel or OK buttons have any effect. I can drag the login window around but that's about it.
As a result, Eclipse stays hung because I can never log in to vault. The only way out is to kill Eclipse, but if I re-run, the same thing will happen again.
This is my first attempt at using Eclipse and so undoubtedly there are many subtleties of which I am still clueless, but the login window behavior seems bug-like. Is there a fix or workaround? Is there any way to tell vault to never prompt for login and just rely on saved credentials?
Thanks...
I can get Eclipse projects defined and imported from the vault server. But then Eclipse eventually wants to do an automatic refresh at a subsequent Eclipse startup. The Eclipse platform splash appears with a status of "Loading Workbench". A "Progress Information" dialog window appears that says "Refreshing". And a vault login window is also present with my userid, password and vault server listed.
But unfortunately I cannot interact with the vault login window at all. I cannot modify the fields, nor does clicking the Cancel or OK buttons have any effect. I can drag the login window around but that's about it.
As a result, Eclipse stays hung because I can never log in to vault. The only way out is to kill Eclipse, but if I re-run, the same thing will happen again.
This is my first attempt at using Eclipse and so undoubtedly there are many subtleties of which I am still clueless, but the login window behavior seems bug-like. Is there a fix or workaround? Is there any way to tell vault to never prompt for login and just rely on saved credentials?
Thanks...
Re: Vault 5.0.4.18845 / Eclipse 4.2.0 refresh trouble
How did you perform the Vault plugin install Eclipse?
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support
Re: Vault 5.0.4.18845 / Eclipse 4.2.0 refresh trouble
From my rough notes:
Install the SourceGear Vault plugin:
Help -> Install New Software
Work with: http://download.sourcegear.com/Vault/5.0/Update
Click the “Add” button.
Expand the available plugins under “Uncategorized” and choose Vault Eclipse Plugin. Make sure the plugin version matches the Vault version that QSS runs.
Click the “Next” button.
Review the install details, then click the “Next” button.
Click to accept the license agreements, then click the “Finish” button.
Click the “OK” button to accept unsigned content.
Click the “Yes” button to restart Eclipse.
I am also using the Aptana Studio 3 plugin, installed using the same steps but with a different "Work with:" URL.
The Vault 5.1-based plugin suffers from the same refresh login problem. The Vault 6.0-based plugin fails with other issues, and I'm assuming it's too far up-level from my 5.0-based Vault server.
I am using the Eclipse that's part of the Fedora 17 distro.
Install the SourceGear Vault plugin:
Help -> Install New Software
Work with: http://download.sourcegear.com/Vault/5.0/Update
Click the “Add” button.
Expand the available plugins under “Uncategorized” and choose Vault Eclipse Plugin. Make sure the plugin version matches the Vault version that QSS runs.
Click the “Next” button.
Review the install details, then click the “Next” button.
Click to accept the license agreements, then click the “Finish” button.
Click the “OK” button to accept unsigned content.
Click the “Yes” button to restart Eclipse.
I am also using the Aptana Studio 3 plugin, installed using the same steps but with a different "Work with:" URL.
The Vault 5.1-based plugin suffers from the same refresh login problem. The Vault 6.0-based plugin fails with other issues, and I'm assuming it's too far up-level from my 5.0-based Vault server.
I am using the Eclipse that's part of the Fedora 17 distro.
Re: Vault 5.0.4.18845 / Eclipse 4.2.0 refresh trouble
I'll need to run a test. You have several variables here that haven't been tried. Our last testing was with Indigo. (Edit: I had just said Helios a little bit ago. My mistake...I meant Indigo.)
There are a lot of Eclipse plugins and only a few have been tried. I am not familiar with Aptana.
I'll post back after getting Juno first.
There are a lot of Eclipse plugins and only a few have been tried. I am not familiar with Aptana.
I'll post back after getting Juno first.
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support
Re: Vault 5.0.4.18845 / Eclipse 4.2.0 refresh trouble
I am having better success with an alternate approach. Rather than running Aptana Studio 3 as a plugin under Eclipse 4.2.0, I have downloaded the so-called "standalone" version of Aptana (http://www.aptana.com/products/studio3/download, linux, 64-bit) which appears to be a stripped down Eclipse 3.7.2 bundle. I then install the Vault 5.0.4.18845 plugin into that bundle.
Every time I launch Aptana, I get prompted for Vault credentials, despite checking the "remember password" checkbox each time. But at least I can interact with the Vault dialog and Aptana/Eclipse goes on to connect to Vault and complete initialization.
This is probably a better approach for me because I am only interested in Aptana's support for Ruby on Rails development and I don't need all of the other I'm-sure-it's-wonderful cruft that comes with the Fedora Eclipse package.
But the Vault plugin is clearly unusable on Eclipse 4.2.0. I leave it as an exercise for SourceGear to determine which release between 3.7.2 and 4.2.0 where things go wrong.
Every time I launch Aptana, I get prompted for Vault credentials, despite checking the "remember password" checkbox each time. But at least I can interact with the Vault dialog and Aptana/Eclipse goes on to connect to Vault and complete initialization.
This is probably a better approach for me because I am only interested in Aptana's support for Ruby on Rails development and I don't need all of the other I'm-sure-it's-wonderful cruft that comes with the Fedora Eclipse package.
But the Vault plugin is clearly unusable on Eclipse 4.2.0. I leave it as an exercise for SourceGear to determine which release between 3.7.2 and 4.2.0 where things go wrong.
Re: Vault 5.0.4.18845 / Eclipse 4.2.0 refresh trouble
I ran some tests with Vault 5.0.4 and the latest Eclipse Juno with no additional plugins installed and haven't run across any issues.
I checked into an Aptana plugin and their site says that it's only supported up to Eclipse 3.3. I think the route you took is the best way to go with Aptana.
I checked into an Aptana plugin and their site says that it's only supported up to Eclipse 3.3. I think the route you took is the best way to go with Aptana.
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support
Re: Vault 5.0.4.18845 / Eclipse 4.2.0 refresh trouble
Thanks for looking into this.
I've been using Aptana and the Vault plugin every day this week, and it generally seems to work well, but there are a couple of rough edges.
First, if a long period of time passes in Aptana since my last Vault activity, the next time Vault activity occurs will result in a long hang (5 minutes?) and then a timeout message saying it was unable to contact the Vault. Retrying the Vault operation or just forcing a Vault login will be successful. But Aptana can go unresponsive during the minutes-long hang waiting for the timeout to end, which is annoying. I usually end up killing Aptana and restarting. Is there anything I can do to either prevent this loss of vault connectivity, or if not, shorten the timeout waiting period to something saner like 30 seconds or so?
The other rough edge is when using Vault to show file content differences (Vault pending changes, right-click on checked out file, click show differences) between the baseline and working copies. Most of the time when I do this the entire file is incorrectly considered as one giant difference. I.e. if I click the Vault button to go to the next difference, it tells me I'm already at the last difference when I am sitting at the top of the file and there are genuine differences below. If I scroll the difference viewer the genuine differences will show up highlighted...but manually looking for highlighting in dual panes is tedious and error-prone.
Instead if I use the built-in Aptana/Eclipse compare with local history feature, that works reliably for clicking through the differences, but the local history copies correlate with file saves rather than checkins, so I'm not technically comparing against a Vault baseline which could have been modified by somebody else while I had the file checked out (low probability, but it does sometimes happen here where multiple people work on the same file at the same time).
So if you have any magic suggestions for being able to click through the individual baseline vs. working differences in the Vault compare window, that would be greatly appreciated.
I've been using Aptana and the Vault plugin every day this week, and it generally seems to work well, but there are a couple of rough edges.
First, if a long period of time passes in Aptana since my last Vault activity, the next time Vault activity occurs will result in a long hang (5 minutes?) and then a timeout message saying it was unable to contact the Vault. Retrying the Vault operation or just forcing a Vault login will be successful. But Aptana can go unresponsive during the minutes-long hang waiting for the timeout to end, which is annoying. I usually end up killing Aptana and restarting. Is there anything I can do to either prevent this loss of vault connectivity, or if not, shorten the timeout waiting period to something saner like 30 seconds or so?
The other rough edge is when using Vault to show file content differences (Vault pending changes, right-click on checked out file, click show differences) between the baseline and working copies. Most of the time when I do this the entire file is incorrectly considered as one giant difference. I.e. if I click the Vault button to go to the next difference, it tells me I'm already at the last difference when I am sitting at the top of the file and there are genuine differences below. If I scroll the difference viewer the genuine differences will show up highlighted...but manually looking for highlighting in dual panes is tedious and error-prone.
Instead if I use the built-in Aptana/Eclipse compare with local history feature, that works reliably for clicking through the differences, but the local history copies correlate with file saves rather than checkins, so I'm not technically comparing against a Vault baseline which could have been modified by somebody else while I had the file checked out (low probability, but it does sometimes happen here where multiple people work on the same file at the same time).
So if you have any magic suggestions for being able to click through the individual baseline vs. working differences in the Vault compare window, that would be greatly appreciated.
Re: Vault 5.0.4.18845 / Eclipse 4.2.0 refresh trouble
Do you have the same problem with compares if you Diff against the current copy in Vault instead of your baseline version?
What is the file extension of the file?
I think we might have to take the Diff offline so that I could take a look at a couple of your files. Could you send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread?
What is the file extension of the file?
I think we might have to take the Diff offline so that I could take a look at a couple of your files. Could you send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread?
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support