Community
Participate
Working Groups
Build Identifier: I20091210-1301 I'm behind the infamous NTLMv2 proxy. I can configure Eclipse to access the network following the instructions here: http://wiki.eclipse.org/ECF_Filetransfer_Support_for_NTLMv2_Proxies However, my institution additionally changes the username and password frequently. Thus, I'd like to be able to specify the proxy username and password via the command line *every* time I run eclipse. I'm running automated, headless, commands in eclipse using buckminster to checkout/build/publish after a commit, so updating the proxy username and password each time it changes via the GUI is not an option (trust me, it's changed ridiculously frequently). Currently, as far as I can tell, the username and password specified at the command line are only used once, when settings are first "migrated" (actually, I think I lied and they are never used from the command line). Subsequent instantiations of Eclipse use the username and password stored in the preferences and ignore that specified at the command line. I need the proxy settings specified by command line parameters to always be used. (And, it would be convenient to be able to specify all proxy settings at the command line, not just the username and password). (Yes, I know it means that the password is in plain text, but, it's headless, and the environment variables are being updated with the password in the current implementation, anyway.) Looking at the code in org.eclipse.core.net, it looks like a great deal of effort was put in to making sure that the environment variables and the proxy settings via the GUI are synchronized. I would guess that this is because there were a number of posts indicating that users were having problems with the settings and normally they want to use the GUI and not the command line. However, it also results in the command line parameters being ignored. :( I've created a patch that adds a "command line" proxy provider, which I believe will allow me to configure the proxy via the command line for my headless eclipse instances and will still allows users to use the GUI preferences without concern for those preferences being overwritten by the command line settings. The "command line" proxy provider uses the command line parameters only (before they are mangled by other providers or a selection thereof). I'm, of course, open to other solutions. The patch does three things: 1) It adds a "command line" proxy provider 2) It selects the "command line" proxy provider if the "commandLineProxySet" environment variable is true (see: ProxyManager.initialize() ) 3) It provides a dynamic variable that passes the proxy configuration along to subprocesses ("proxy_settings" for use in launch configurations) I know that #2 sort of violates the goal of having users not be surprised by command line parameters, but only "sort of". The proxy information the user enetered manually is never modified, only the settings in the "command line" proxy provider are updated by command line settings, and the "commandLineProxySet" environment variable only selects the command line provider. So, a user that is getting proxy errors could ensure that the right provider is selected. Otherwise, I think that it's not possible to specify different proxy settings from the command line for each instantiation of the same eclipse environment, right now. Feedback welcome! Reproducible: Always Steps to Reproduce: (May not happen the first time for a fresh install, can't remember) 1) specify "-vmargs -Dhttp.proxyUser" on eclipse command line 2) see that the username is not updated in the proxy settings
Let me back-peddle a little :). The patch introduces some problems with visibility and there are still complaints that the system properties will be overwritten with the preferences (maybe this needs to be qualified if the approach is taken?). So, there's still work to be done. But, I wanted to get a pulse as to whether this is the right approach or not before continuing. Two files added: * a patch for org.eclipse.core.net * a zipped project for a new plugin org.eclipse.core.net.variable
Created attachment 155303 [details] plugin that creates a varaiable with proxy settings for use in launch configurations It also tries to pass along the environment settings for org.eclipse.ecf.provider.filetransfer.excludeContributors and ProxyType.PROP_SOCKS_SYSTEM_PROPERTY_HANDLING , but is currently unsuccessful in doing so.
Created attachment 155304 [details] patch to add "command line" proxy provider Adds a "command line" proxy provider and selects the provider if the "commandLineProxySet" environment variable is true (see: ProxyManager.initialize() ). It also exposes some functionality for the proxy_settings variable plugin.
Hi Scott. Thanks for the bug report and the patches. Although the ECF filetransfer is a user of the org.eclipse.core.net proxy API, we are not the developers and maintainers of that API...and we don't have write access to that codebase (it's managed/maintained by the Eclipse platform team). So I'm going to add Pascal, Szymon, and Pawel to this bug...and ask them to take a look at it. Pascal, Szymon, Pawel...please look at this bug request and patches and after you advise about location, I'll move this bug to another category for proxy API work.
There is a bug 257443 for extending proxy API to use a custom proxy provider. It looks like a more general solution than the one proposed on this bug. Please take a look at bug 257443 (it's targeted for 3.6) and say if the the solution proposed there satisfies your needs.
Anyway, it's a Team bug, I'm reassigning it there.
(In reply to comment #5) > There is a bug 257443 for extending proxy API to use a custom proxy provider. > It looks like a more general solution than the one proposed on this bug. > Please take a look at bug 257443 (it's targeted for 3.6) and say if the the > solution proposed there satisfies your needs. Hi Pawel, bug 257443 is both good and bad. It's the right, long-term solution--that's good. However, as noted in comment #18 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=257443#c18 ) a lot of the design of the current implementation for 3.5 is to avoid problems with users proxy settings changing unexpectedly, i.e., the 3.5 design has the goal of informing the user of every single mismatch between preferences and command line settings, always chosing the GUI specified preferences over the command line options. The point of this patch is to preserve that... caution... that was introduced in the original 3.5 design. I think the question is: is it possible to get Eclipse 3.5 to accept command line proxy configurations for headless execution (using my patch, or by backporting the solution from bug 257443 to 3.5)? Or, am I just out of luck when it comes to 3.5 and I need to switch to 3.6? I'd prefer not to do that, but, if it's the only option...
(In reply to comment #7) > Hi Pawel, bug 257443 is both good and bad. I'm not sure why the long-term solution is not appropriate for your case. Your custom provider could delegate to GUI based provider first and if the proxy is not specified there it could delegate to command line provider. > I think the question is: is it possible to get Eclipse 3.5 to accept command > line proxy configurations for headless execution (using my patch, or by > backporting the solution from bug 257443 to 3.5)? Bug 257443 won't be backported to 3.5.x stream. It should be possible to drop just a few plugins from 3.6 to 3.5 to have it running though.
(In reply to comment #8) > (In reply to comment #7) > > Hi Pawel, bug 257443 is both good and bad. > I'm not sure why the long-term solution is not appropriate for your case. Your > custom provider could delegate to GUI based provider first and if the proxy is > not specified there it could delegate to command line provider. I need to be able to unzip eclipse and then run it with the proxy configured using command line parameters. Does/will the proposed fix in 257443 support that for 3.6? Is that what you're saying? > > I think the question is: is it possible to get Eclipse 3.5 to accept command > > line proxy configurations for headless execution (using my patch, or by > > backporting the solution from bug 257443 to 3.5)? > Bug 257443 won't be backported to 3.5.x stream. It should be possible to drop > just a few plugins from 3.6 to 3.5 to have it running though. Ok, I can live with this provided I can do that with a script, completely headlessly. I can install *features* headlessly using buckminster, but what your proposing is to install individual plugins. Where will these be available and how can I get them installed via command line? It also begs the question: If it will work in 3.5, why not just backport it so that updates to the plugins will less likely break what I'm doing? The other part of this bug report (perhaps it needs to be a separate bug report) has to do with having a variable available for use in launch configurations. That's a convenience, but I'd like that considered as a feature for 3.6 :). Essentially, it adds a "proxy_settings" variable for use in the java vm arguments section of launch configurations that would configure the proxy for the launched (java/eclipse) environment.
(In reply to comment #9) > I need to be able to unzip eclipse and then run it with the proxy configured > using command line parameters. Does/will the proposed fix in 257443 support > that for 3.6? Is that what you're saying? You would have to unzip Eclipse, add the plug-in contributing your proxy provider and launch. Should be trivial to script. It's even better if we decide to ship command line provider by default. In such case a command line option would allow you to select the provider most appropriate for you. > Ok, I can live with this provided I can do that with a script, completely > headlessly. I can install *features* headlessly using buckminster, but what > your proposing is to install individual plugins. I don't know Buckminster but in plain Eclipse it's enough to put new plugins in the dropins folder and remove the old ones. > If it will work in 3.5, why not just backport it so that updates to the plugins > will less likely break what I'm doing? Release 3.5.2 is the last service release for Galileo so we have to get it right. And this change is simply to complex and not enough justified. Also, the endgame plan for SR2 doesn't leave much time for testing, see details at http://www.eclipse.org/eclipse/development/plans/freeze_plan_3_5_2.php . > The other part of this bug report (perhaps it needs to be a separate bug > report) has to do with having a variable available for use in launch > configurations. It would be better to track it separately. Please open an enhancement request.
Pawel, thank you so much for your responses and working with me to resolve this issue. I'm very pleased! > > [How do I] install individual plugins. > I don't know Buckminster but in plain Eclipse it's enough to put new plugins in > the dropins folder and remove the old ones. Great, that's doable. > Release 3.5.2 is the last service release for Galileo so we have to get it > right. And this change is simply to complex and not enough justified. Also, the > endgame plan for SR2 doesn't leave much time for testing, see details at > http://www.eclipse.org/eclipse/development/plans/freeze_plan_3_5_2.php . Ok, I understand that now. > > The other part of this bug report (perhaps it needs to be a separate bug > > report) has to do with having a variable available for use in launch > > configurations. > It would be better to track it separately. Please open an enhancement request. Will do. Thank you again! -- Scott *** This bug has been marked as a duplicate of bug 257443 ***
