Community
Participate
Working Groups
Sourceforge offers anonymous access through pserver. Unfortunately being behind a firewall with proxy I did not find a possibility how to access Sourceforge pserver via port 80 or 443. Only with a sourceforge user and access to CVS I can use extssh and proxy settings for accessing Sourceforge. Probably I am missing something, or there should be proxy support for pserver connections as well.
Funny you asked... bug 87918 was fixed today. *** This bug has been marked as a duplicate of 87918 ***
This bug should not be resolved as a duplicate of 87918. The submitter complains that there is no way to specify a proxy server for pserver connections. The creation of a proxy port on eclipse.org is irrelevant as there is still no way to point the pserver access at it via HTTP proxy.
SourceForge should describe how to connect to their http (port 80) proxy. If you give me a link to the instructions that describe how to connect to SourceForge, I'll give it a try and let you know if I can get it to work from Eclipse.
I am not sure whether I catch your question right. You can access the SourceForge repository by anonymous pserver access both on port 80 and 443. The problem is ones inhouse proxy which I must use to get through our firewall. Instructions can also be found on: http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#firewall For a test please use the follwing data: user: anonymous password: <none> type: pserver host: cvs-pserver.sf.net port: 443 OR 80 (some firewall tunnel only 443) projectroot: /cvsroot/abbot These data would offer you read access to the abbot project repository. If I want to access this from behind our firewall I have get over the proxy. This is possible with the extssh connection which offers to maintain a proxy and its settings, but not for pserver access. I also wrote a crude plug-in for overcoming the problem but this is a bad workaround: http://prdownloads.sourceforge.net/abbot/com.sap.proxy.ProxyTunnel_1.0.0.zip? download
Since you've alreay written a plugin, perhaps you could create a patch to the CVS plugin to add the support you need? Also, have a look at bug 60552 in case that support can help.
As I have mentioned already the plugin I have written is a crude workaround. One can specify a proxy server and port as well as the remote host and port and a local port. Then a local server is started which listens to the local port and establishes a connection through the proxy to the remote host. The plugin can handle multiple servers, but each server can handle only one connection at a time. This is sufficient for CVS but I think a very crude workaround. What is desirable, is the same functionality as for extssh but for pserver. The plugin I've written does not hook in the CVS environment of Eclipse but provides a tunneling service on its own for any thinkable type of connection which is capable of being tunneled.
I'm sitting behind firewall with a proxy too. I can acces eclipse cvs repositories with standard command line cvs client using CSROOT like this: :pserver;proxy=<host>;proxyport=<port>;proxyuser=<user>;proxypassword=<password>:anonymous@dev.eclipse.org:/home/webtools I would be nice if eclipse cvs client will mirror this functionality.
What CVS version are you using? That does not look like the standard format for the CVS/Root file. It looks like the augmented version usd by WinCVS. In any case, there is no plan to address this item but patches will be accepted.
My client version string is "Concurrent Versions System (CVSNT) 2.0.51d (client/server)" Format for this CVSROOT is defined in manual "CVS--Concurrent Versions System v1.12.12" at http://ximbiot.com/cvs/manual/cvs-1.12.12/cvs_2.html#SEC28
At the current time, we only support the stable release of CVS which is 1.11.x. We do support some of the new features in 1.12 but these were all provided as patches from non-committers who use 1.12.x.
Michael, it would make sense to have generic support for SOCKS server. Given that for users behind firewall socks server either already around or can be created with "ssh -D..." or "ssh over http tunnel + ssh -D..." it would be very reasonable feature to have in Eclipse.
I agree but, unfortunately, we do not have the manpower to address this issue in 3.2. We will accept patches if someone who understands this issue and is experiencing the problem wanted to contribute to the component;-) P.S. Bug 60552 may be related to this as well.
(In reply to comment #12) > I agree but, unfortunately, we do not have the manpower to address this issue > in 3.2. We will accept patches if someone who understands this issue and is > experiencing the problem wanted to contribute to the component;-) > > P.S. Bug 60552 may be related to this as well. Another option was to globally set socks configuration for Eclipse's JVM, but for some reason that didn't work too when I last tried it. See socksProxyHost and socksProxyPort system properties at http://java.sun.com/j2se/1.4.2/docs/guide/net/properties.html
(In reply to comment #12) > I agree but, unfortunately, we do not have the manpower to address this issue > in 3.2. We will accept patches if someone who understands this issue and is > experiencing the problem wanted to contribute to the component;-) I've done some research on this issue and can probably wrap up something generic with support of both socks and http proxy. However I need some advise about the implementation. I guess patch should work in JRE 1.4 and it does not have constructor Socket(Proxy) that support connection over socks and SocksSocketImpl and SocksSocketFactory are always been package protected in JRE. So, I guess we'll need some 3rd party socks implmentation like one included into jsch or JHttpTunnel or others (e.g. jsocks.sh.net under LGPL license). I also wonder if org.eclipse.team.cvs.ssh plugin is still in use?
Yes, we need to support 1.4. Jsch is included in the ssh2 plugin so you can use whatever that library provides. The ssh plugin is still used in those cases where the server supports SSH 1 but not SSH 2. Yes, this is probably rare if non-existant but it still possible so we need to support it.
(In reply to comment #15) > The ssh plugin is still used in those > cases where the server supports SSH 1 but not SSH 2. Yes, this is probably > rare if non-existant but it still possible so we need to support it. I just noticed that there is no extension points declared in itx plugin.xml and can't find how it is being referenced.
It is referenced programatically by the SSH2 plugin.
(In reply to comment #17) > It is referenced programatically by the SSH2 plugin. I see now... Can you explain me what are the conditions of using jsch? It looks like Eclipse is using version 0.1.18 and the latest is 0.1.23 The reason I'm asking is that I thought it would be possible to use some functionality (especially http ad socks proxy implementeations) from jsch, but it looks like it can't be done without some refactoring. For instance both ProxyHTTP and ProxySOCKS5 require Session parameter in their connect method and the only thing they need from that session is SocketFactory. It also seems that Proxy in jsch is quite aside object comparing to the way how it is done in JRE 1.5 and it would be quite nice to make it more transtarent for the socket or socket factory (e.g. borrow design used in JRE 1.5). So, I wonder if these refactorings could be done on jsch code?
Ok. I've added jsch sources from version 0.1.23 into cvs.ssh2 plugin and refactored jsch's Proxy class to accept the socket factory in connect method. It turns out that CONNECT feature is disabled on my http proxy, so I can't test it at the moment. However the good news that SOCKS5 is working for pserver connection! I used settings from Proxy tab on SSH2 connection method, but it would make sense to pull it up as a separate page. Though these settings actually belong to the platform, but it is a separate story... Anyway, with above refactoring, Eclipse plugin changes are quite small. I just had to move PServerConnection and PServerConnectionMethod classes into ssh2 plugin and update plugin.xml's accordingly. Other option would be to put jsch code into cvs.core plugin. Now I wonder if my changes can be integrated into the Eclipse code?
Ymnk is in charge of the Jsch contribution so any changes in the department need to be approved and done by him. I would prefer not to move the basic pserver support into the ssh2 plugin. Would it be possible to have an additional connection method like pserverproxy or something like that? As for contributing the fix to Eclipse, If Ymnk is willing to make the required changes to Jsch and you refactor what you have so the basic pserver support is unchanged (i.e. you add another connection method), then I would be willing to release it. I would ask that you also provide a description of how and when to use it so we can at least have something in our doc that explains what the new connection method is. Without this, it may be the case that, at polish time, the fix would get pulled because there was no doc for it.
Created attachment 28843 [details] PServerConnection with HTTP and SOCKS5 proxy support Here is version of the PServerConnection with HTTP and SOCKS5 proxy support. It is using slightly refactored classes ProxyHTTP and ProxySOCKS5 from jsch library. JSchSession.getProxy() method had been extracted from JSchSession.getSession(ICVSRepositoryLocation location, String username, String password, String hostname, int port, IProgressMonitor monitor) method in order to use the same preferences.
(In reply to comment #20) > Ymnk is in charge of the Jsch contribution so any changes in the department > need to be approved and done by him. It would be a good idea to have jsch sources in Eclipse cvs, so one can contribute some patches. > I would prefer not to move the basic > pserver support into the ssh2 plugin. Would it be ok to have jsch jar or the source code in cvs.core plugin and also promote proxy configuration and UI to the cvs.core plugin? Actually we only need Proxy interface and two implementation classes from Jsch for this purpose. > Would it be possible to have an > additional connection method like pserverproxy or something like that? It would be really much more preferrable to have regular support for proxy then introducing special connection method. The main reason is that it is quite possible that one would need to use proxy temporarily (e.g. from work or during a trip) and be able to turn it off when not needed. With special connection method you'll have to disconnect the project and then checkout and synchronize it again which would be much more painful and pointless. > As for contributing the fix to Eclipse, If Ymnk is willing to make the required > changes to Jsch and you refactor what you have so the basic pserver support is > unchanged (i.e. you add another connection method), then I would be willing to > release it. I would ask that you also provide a description of how and when to > use it so we can at least have something in our doc that explains what the new > connection method is. Without this, it may be the case that, at polish time, > the fix would get pulled because there was no doc for it. Sure, I can write some doco once we find a way to put the code together.
I think I am missing something. I could have some pserver projects in my workspace that need to use a proxy and others that don't. How can we differentiate the two. Also, it is not difficult to switch the connection method for a repository location so the problem you suggested with a separate connection method is not really a problem. As for where the Jsch plugin lives, I do not want to put it into the CVS core plugin. Either it needs to stay where it is or it could be in its own plugin. I am fine with the later but it is Ymnk that would need to make that decision since he is the maintainer of the code.
(In reply to comment #23) > I think I am missing something. I could have some pserver projects in my > workspace that need to use a proxy and others that don't. How can we > differentiate the two. The only case I can think of when you'd need to have proxy for one project and don't have for another one is when second project is in the intranet. That usually resolved using "no proxy for hots" setting (which we don't have at the moment). > Also, it is not difficult to switch the connection > method for a repository location so the problem you suggested with a separate > connection method is not really a problem. Maybe you right, but I still feel uncomfortable with doing that because it would have to change all the **\CVS\Root entries and for a large projects it could be really a lot. I guess you suggesting this because of similarity to pserverssh2 you've just enabled. However I believe pserverssh2 is quite different and support more complicated case: no connect on HTTP proxy, no socks proxy, but cvs server has port redirector/tunnel account on sshd. Also note that pserverssh2 itself may have to use HTTP/HTTPS proxy to get the connection (double proxy), which would be redundant in case if you already have socks around. > As for where the Jsch plugin lives, I do not want to put it into the CVS core > plugin. Either it needs to stay where it is or it could be in its own plugin. > I am fine with the later but it is Ymnk that would need to make that decision > since he is the maintainer of the code. I think it is a good idea to put jsch.jar into a separate plugin. Even without sources it would enable easier reuse for other plugins (e.g. ssh terminals, etc).
Hi, (In reply to comment #18) > it looks like it can't be done without some refactoring. For instance both > ProxyHTTP and ProxySOCKS5 require Session parameter in their connect method and > the only thing they need from that session is SocketFactory. Should Session parameter for connect methods be removed or is it enought to replace it with java.net.SocketFactory?
(In reply to comment #25) > Should Session parameter for connect methods be removed or is it enought to > replace it with java.net.SocketFactory? In the attached PServerConnection2.java (open() method) I've replaced session with com.jcraft.jsch.SocketFactory. I haven't investigated much if java.net.SocketFactory can be used in this place and just wanted to reuse as much code as possible. If you wan't to redesign the API, it is probably worth to look how proxy support is done in Java 5. It is quite transparet to the user because he would always deal with Socket instance and don't have to know about Proxy at all.
Created attachment 29375 [details] proxy properties UI It looks like there was some work on proxy support in Eclipse 3.2M3 (see screenshot). So, I wonder if the same settings can be used by CVS SSH2 and pserver plugins?
I'm running 3.2 M3 but I don't see that preference page. Perhaps you have other plugins loaded that surface that page (actually, it looks like you have a ton of stuff loaded: Mylar, AJDT, etc).
(In reply to comment #28) > I'm running 3.2 M3 but I don't see that preference page. Perhaps you have > other plugins loaded that surface that page (actually, it looks like you have > a ton of stuff loaded: Mylar, AJDT, etc). Damn! You are right. That must be WTP 1.0M8. :-( That makes even more sense to move this into the core...
Folks, is there are any chance that my patch will be incorporated?
We still need to work out the details of when and how to make the Jsch jar a separate plugin. Unfortunately, there is too much going on at the present moment. Hopefully, we will have some cycles to look into it once M4 is done. Once we get that sorted out, we can look at incorporating your patch.
(In reply to comment #31) > We still need to work out the details of when and how to make the Jsch jar a > separate plugin. Unfortunately, there is too much going on at the present > moment. Hopefully, we will have some cycles to look into it once M4 is done. > Once we get that sorted out, we can look at incorporating your patch. Because it takes so long, maybe we can use intermediate solution? Move proxy settings backend and ui panel to core or ui module, then copy required classes (basically Proxy implementation) from jssh to the core and change plugins accordingly. Later when jssh moved into separate plugin these temporary classes can be replaced by ones from jssh...
I suspect there would be some legal issues with what you suggest. I understand your desire to see this happen as soon as possible. Unfortunatley, I'm just too swamped for the rest of the year to even think about this. However, it should happen in M5.
(In reply to comment #33) > I suspect there would be some legal issues with what you suggest. I understand > your desire to see this happen as soon as possible. Unfortunatley, I'm just too > swamped for the rest of the year to even think about this. However, it should > happen in M5. jcsh is BSD-licensed, so it should be ok to derive proxy classes. I can work on required patches if it could help to make it for M4... Ideally it would make sense to have platform-wide proxy configuration UI and standard settings/API (even if connection methods still up to plugins). What would be a good goal for M5, but probably there is already request for this.
What you say about BSD licenses may be true but I am not a lawyer so I would need to check with one before taking any action. Regardless of this, as I already mentioned, I have a pretty busy schedule for M4 and there is nothing that could be bumped to make room for the work required to make this happen for M4. I think the best approach to take is to do whatever we need to do in M5 to make the Jsch a separate plugin and then go from there. Remember, the goal of this work is to make this happen for 3.2.
I should also add that I really do appreciate your effort on this and I also appreciate you trying to push to get this in as soon as possible. I am sorry that I couldn't make this happen for M4 and I will make every effort to make it happen in M5.
Hi, At comment #27, you had referred to 'proxy support in Eclipse 3.2M3' and I have misunderstood that your problem has been resolved thanks to that 'porxy support' and stopped thinking of this issue. Ok, if the refactoring is still required for jsch, I will.
(In reply to comment #37) > At comment #27, you had referred to 'proxy support in Eclipse 3.2M3' and > I have misunderstood that your problem has been resolved thanks to that 'porxy > support' and stopped thinking of this issue. Ok, if the refactoring is still > required for jsch, I will. It turns out that proxy support I've found did come from WTP plugin and not from platform. So, for now CVS plugins still have to handle it on their own. Also, refactoring I've suggested for jcsh makes sense for long term. So, please do this it if you don't mind.
(In reply to comment #36) > I should also add that I really do appreciate your effort on this and I also > appreciate you trying to push to get this in as soon as possible. I am sorry > that I couldn't make this happen for M4 and I will make every effort to make it > happen in M5. Thanks Michael. By the way, do you think it would be possible to have proxy support on a platform level in a 3.2 time frame? Actually some plugins (e.g. Mylar) are using proxy config from update manager plugin... unfortunately there are no settings for socks.
What do you mean by proxy support at the platform level? Do you mean that, since SSH2, update and, eventually, pserver will have proxy support that we should have a single proxy support UI that all these tools use? Or do you mean something else? In either case, it is probably worth logging a separate enhancementr request for it. YOu can log it against Team for now.
(In reply to comment #40) > What do you mean by proxy support at the platform level? I meant global http/socks proxy settings for Eclipse platform, that would be shared by all plugins. > Do you mean that, > since SSH2, update and, eventually, pserver will have proxy support that we > should have a single proxy support UI that all these tools use? Or do you mean > something else? In either case, it is probably worth logging a separate > enhancementr request for it. YOu can log it against Team for now. Right. Here it is (probably duplicated) https://bugs.eclipse.org/bugs/show_bug.cgi?id=119278
The Jsch client is now in a separate plugin. We can work towards adding the proxy support in M6 since there is no API involved.
(In reply to comment #42) > The Jsch client is now in a separate plugin. We can work towards adding the > proxy support in M6 since there is no API involved. Hmm. I thought there is at least one change required in jcsh... I could be wrong. since it was some time ago.
Is there a change required to Jsch? What version of Jsch do we need for your patch to work? Or is there a patch that needs to be applied to Jsch?
(In reply to comment #44) > Is there a change required to Jsch? What version of Jsch do we need for your > patch to work? Or is there a patch that needs to be applied to Jsch? It seems so. See comment #21
What exactly do you mean by "it seems so"? Is the functionality your patch requires available in a later version of Jsch or do changes still need to be applied to Jsch? If it is the former, please state what version of the Jsch client is required. If it is the later, have you supllied JCraft with a patch to add the required funtionality?
(In reply to comment #46) > What exactly do you mean by "it seems so"? Is the functionality your patch > requires available in a later version of Jsch or do changes still need to be > applied to Jsch? If it is the former, please state what version of the Jsch > client is required. If it is the later, have you supllied JCraft with a patch > to add the required funtionality? I thought that change described in #21 is rather trivial. Since jsch code is not in cvs it is not obvious what revision should I create patch for. Heh, this looks like broken phone conversation, especially for such simple change. :-(
I thought that perhaps you has already worked that all out with Yamanaka. I'll assign this to Yamanaka and let the two of you work out what is required on the Jsch side.
(In reply to comment #48) > I thought that perhaps you has already worked that all out with Yamanaka. I'll > assign this to Yamanaka and let the two of you work out what is required on the > Jsch side. I had an impression from his comments that we did, but then he disappeared. So, now I just have no idea where we are and why it is such a big problem for this small change. Maybe we should dump the idea of changin jsch and just copy two required classes? There are are also some piece of UI need to be changed and that is not done in my patch. I mean panel with all the proxy settings. It would be nice to have these settings global for the platform, but it doesn't look it would happend in 3.2...
I apologize if my latest comments have not been all that productive. We've been on overdrive for most of M5 and I think it is getting to me (I'm not as young as I used to be). I don't see the situation improving much in M6 either. I think this is an important issue but unfortunately, due to lack of manpower, we don't have much time to spare to make it happen. What I was trying to find out in my previous comments was how much work is left to do. It sounds like the following things still need to happen: 1) A change to Jsch to provide the required proxy support 2) Additional UI to support proxy configuration From comment 37, it sounds like Yamanaka is willing to make the required changes. My guess is that he is busy with other things (his involvement with Eclipse is strickly voluntary) or perhaps he is unsure of the exact changes you require. Perhaps you could create a patch against the latest Jsch and submit it here or through the JCraft site (it's probably better to do it through the JCraft site to avoid any license issues). As for a Platform proxy settings panel, I'm not aware of any plan to have one in the platform so we'll need one in CVS. We can discuss this more once issue 1) is resolved.
(In reply to comment #18) >For instance both > ProxyHTTP and ProxySOCKS5 require Session parameter in their connect method and > the only thing they need from that session is SocketFactory. For your requests, connect method has been re-defined as public void connect(SocketFactory socket_factory, String host, int port, int timeout) Is it enough? Please refer to http://www.jcraft.com/jsch/jsch-0.1.25-rc5.zip # Please note that 'timeout' is added since 0.1.25.
(In reply to comment #51) > For your requests, connect method has been re-defined as > public void connect(SocketFactory socket_factory, String host, int port, int > timeout) > Is it enough? Please refer to > http://www.jcraft.com/jsch/jsch-0.1.25-rc5.zip > # Please note that 'timeout' is added since 0.1.25. Great! Thanks Atsuhiko. Michael, it doesn't seem this will make to 3.2M5. Does it? If so, then I'll check it on th weekend with the last integration build and can updte patch if you like.
No, this won't make it into M5. We still need to up the Jsch version and we'll need to run with that internally for a while before putting it into the build.
The latest Jscj JAR should appear in tomorrows interation build.
The latest Jsch JAR (0.1.25) is in the build.
Eugene, I haven't has a chance to look at the patch yet. Is it complete? You mentioned that a proxy preference page is still needed? Is the patch usable without that or do we need to wait until we have a proxy preference page? Also, are here changes needed to the attached patch in reponse to the changes in the Jsch plugin?
(In reply to comment #56) > Eugene, I haven't has a chance to look at the patch yet. Is it complete? You > mentioned that a proxy preference page is still needed? Is the patch usable > without that or do we need to wait until we have a proxy preference page? Also, > are here changes needed to the attached patch in reponse to the changes in the > Jsch plugin? I haven't had chance to review patch for last updates, so I am not sure what state it is. As of proxy preference page, I've used the same page and preferences as CVS SSH2 plugin, which is kind of odd. So, I thought that since there is no generic proxy prefs page in Eclipse we need to move proxy/socks config page out of CVS SSH2 Connection Method and put it under CVS node. Hat hasn't been done in this patch.
Created attachment 36040 [details] proxy support for pserver Here is patch for cvs.code and cvs.ui plugins that is using jsch-0.1.25 to implement proxy support. I also created new "CVS / Proxy Settings" page that suppose to be common for all CVS plugins. If you are ok with this I can update cvs.ssh2 plugin and its ui to use this new page and common proxy settings.
Michael, is there a chance for this patch to make to 3.2M6 ?
Hi, (In reply to comment #58) > Created an attachment (id=36040) [edit] > proxy support for pserver > Here is patch for cvs.code and cvs.ui plugins that is using jsch-0.1.25 to > implement proxy support. I have tried this patch, but I had two troubles, * it has included diff for binary file(jsch-0.1.25.jar) and generated file has been broken. * it cannot been applied to the source code in dev.eclipse.org CVS repository, so I need to apply it by eye balls ;-) Anyway, at last, I could successfull apply it to the source code and run patched version. I have not tried its functionality yet because today I'm not behind the proxy fairewall, but tommorow I will be and try it. > I also created new "CVS / Proxy Settings" page that suppose to be common for > all CVS plugins. If you are ok with this I can update cvs.ssh2 plugin and its > ui to use this new page and common proxy settings. Yes, you are right. The preference page 'Team > CVS > SSH2 Connection Method > Proxy' should be disabled and JSchSession class should refer to proxy settings by that new preference page.
(In reply to comment #60) > I have tried this patch, but I had two troubles, > * it has included diff for binary file(jsch-0.1.25.jar) and generated file > has been broken. This is more to indicate that new jar is needed. But it sounds like a bug in either diff or apply patch for cvs... > * it cannot been applied to the source code in dev.eclipse.org CVS > repository, I saw that there was some conflicts with incoming changes. If it helps, I can create patch again ater merging those conflicts.
It is definitely my intention to apply this for M6. Unfortunately, I am swamped at the moment but hope to get it in next week. If you can make sure that the patch is up-to-date, that would be a great help. I am OK with consolidating the proxy page so if you could make that change, that would be really helpful as well. Yamanaka, if you get a chance to try it and have any comments, let me know. I don't have a proper setup to test it so all I can do is ensure that it doesn't break existing funtionality.
Created attachment 36346 [details] proxy support for pserver Updated patch for last cvs code changes.
(In reply to comment #62) > It is definitely my intention to apply this for M6. Unfortunately, I am swamped > at the moment but hope to get it in next week. If you can make sure that the > patch is up-to-date, that would be a great help. I am OK with consolidating the > proxy page so if you could make that change, that would be really helpful as > well. UI part already done in this patch. I can remove duplicated page from ssh2 plugin and make it using new page/settings. Not sure though if I'll have time for this in next few days. So, if Yamanaka can do that it would be great. Also, as Yamanaka pointed out, this patch require jsch-0.1.25.jar. I temporarily put new jar into org.eclipse.team.cvs.core plugin, so you may have to fix plugin dependencies.
Created attachment 36408 [details] proxy support for pserver I have tried the provided patch and confirmed that pserver via HTTP/SOCKS5 works well. Here is a revised patch, which has fixed following problems in previous one, - a problem to load settings by proxy preference. - a problem in setting default values in proxy preferences. - a problem in updating controls on proxy preferences. The revised patch does not include jsch-0.1.25.jar, but cvs.core's META-INF expects com.jcraft.jsch;bundle-version="[0.1.25,2.0.0)"
Created attachment 36410 [details] cvs.ssh2 plug-in refers to new proxy settings If above 'proxy support for pserver' patch is applied, this patch also should be applied. This patch deletes "Team/CVS/SSH connetions/proxy" preference page and allows cvs.ssh2 plug-in to refer to settings by new proxy preference page.
(In reply to comment #66) > Created an attachment (id=36410) [edit] > cvs.ssh2 plug-in refers to new proxy settings > > If above 'proxy support for pserver' patch is applied, this patch also > should be applied. This patch deletes "Team/CVS/SSH connetions/proxy" > preference > page and allows cvs.ssh2 plug-in to refer to settings by new proxy preference > page. > Please: I need them to send me the (org.eclipse.team.cvs.core).jar because I have problems with the proxy to download the sources and to compile them
Created attachment 36422 [details] cvs.ssh2 plug-in refers to new proxy settings striping unrefered and unused code.
Patch released to HEAD with some minor UI modifications to deal with some NPEs.
(In reply to comment #69) > Patch released to HEAD with some minor UI modifications to deal with some NPEs. You are right. There were such problems in my last patch. Thank you for fixinig them and applying patches to CVS repository.
Removed all leftover references to the proxy tab from CVSSSH2PreferencePage. With the change in preference store for the proxy page, we need to provide users with some sort of migration story. I've opened Bug 132697 to track this.
Can someone explain to me how to get jsch plugin to run debug workbench? I see that new jar is now sitting under org.eclipse.team.cvs.ssh2 Any plans to have its code in eclipse cvs?
(In reply to comment #72) > Can someone explain to me how to get jsch plugin to run debug workbench? > I see that new jar is now sitting under org.eclipse.team.cvs.ssh2 > Any plans to have its code in eclipse cvs? As a quick hack, to debug this issue, I have copied com.jcraft.jsch_0.1.25.jar into plugins directory.
Eugene, would it be possible for you to verify that this works properly in the M6 candidate (i.e. one of this weeks integration builds)?
(In reply to comment #74) > Eugene, would it be possible for you to verify that this works properly in the > M6 candidate (i.e. one of this weeks integration builds)? I can certainly try that. Please let me know which integration build should I use.
Thanks. Please use I20060328-0010. It is the M6 test build.
Created attachment 37225 [details] error dialog showing html text I've tested HTTP and SOCKS this build. For socks I've been using SOCKS endpoint created by ssh command like: ssh -D 1080 -v user@host and it is working just fine. When specifying an incorrect repository path connection is termintated with reason: "I HATE YOU". So perhaps error handling code could be improved for this case. For HTTP tunnel, I've used Squid server. Note that connection to port 2401 should be enabled, as well as CONNECT method. For example, Squid config: acl CVS_ports port 2401 http_access deny CONNECT !SSL_ports !CVS_ports with above settings it is working fine. Though errorneous case look little ugly, like on attached screenshot, which was taken when 2401 port were disabled (so you can see access denied error inside html). Perhaps we can detect that error has html code and use html widget to show it, but now it is ok. I haven't tried proxy auth yet. Will have to configure Squid for that. I'll send you an update if I'll manage that. BTW, I also noticed that all connection errors are going to Eclipse .log. We probably discussed that already and I think that they should actually go to CVS console but not to the log.
Thanks, I've created bug 122930 to track your last comment. We should create soem doc and maybe a FAQ entry to capture this information. Feel free to log separate bugs for any particular issue (e.g. html error).
(In reply to comment #78) > Thanks, I've created bug 122930 to track your last comment. It doesn't seem bug number is correct. > We should create > soem doc and maybe a FAQ entry to capture this information. Feel free to log > separate bugs for any particular issue (e.g. html error). I hope there are enough info in my comment to document http proxy configuration and possible option for socks end point. If not, let me know what else is needed.
Sorry, bug is 133930. What is provided is a good start. I'll make sure to get you to review what we write just in case we leave something important out.
This is not a problem about its behavior and functionality, but I can not build recent org.eclipse.team.cvs.ssh2 on CVS repository by build.xml, which is generated from plugin.xml(PDE Tools->Create Ant Build File). At least, I had been able to build older versions. Are there any changes on the build process in these days? Here are outputs on console, Buildfile: C:\Documents and Settings\ymnk\workspace\org.eclipse.team.cvs.ssh2\build.xml properties: init: build.jars: properties: init: @dot: BUILD FAILED Target `cvsssh2.jar' does not exist in this project.
That's odd. I just tried it using the latst integration build and it worked for me. It looks like the build.xml you ran was referencing stale information from somewhere (i.e. all references to cvsssh2.jar where removed).
(In reply to comment #82) > That's odd. I just tried it using the latst integration build and it worked for > me. It looks like the build.xml you ran was referencing stale information from > somewhere (i.e. all references to cvsssh2.jar where removed). It seems it is a local problem. 'eclipse -clean' did not solve this problem, but by deleting workspace\.metadata\.plugin\org.eclipse.debug.core\.launches\org.eclipse.team.cvs.ssh2 build.xml.launch it has been disappeared. Thank you for your prompt reply.
(In reply to comment #77) > with above settings it is working fine. Though errorneous case look little > ugly, like on attached screenshot, which was taken when 2401 port were > disabled (so you can see access denied error inside html). Perhaps we can > detect that error has html code and use html widget to show it, but now it is > ok. The reason for such ugly html lines is that http-proxy included in jsch has not checked HTTP return code; 200 or 403. I will modify jsch to shutdown a connection immediately on such a case. Thank you for your feedback.
(In reply to comment #84) > The reason for such ugly html lines is that http-proxy included in jsch > has not checked HTTP return code; 200 or 403. I will modify jsch to shutdown > a connection immediately on such a case. Do you think status text from http headers will be informative enough? I kind of like current behaviour because it allows to see actual error, such as "Access Denied" reported by proxy server and it is esy to detect presense of html in error text and use html widget to show error text in such cases.
Thanks to everybody who made this feature possible - at last I can check stuff out from SourceForge et al! However one small enhancement might be required: the ability to specify on a per-repository basis whether to use the proxy or not. With the proxy enabled it is impossible to connect to repositories sitting inside my company firewall. Also, regarding the "I HATE YOU" error... I assume that comes from the remote server? It might be worth reporting the message as something like "Server replied: I HATE YOU". We wouldn't want users to think that Eclipse itself is being so unfriendly!
(In reply to comment #86) > Thanks to everybody who made this feature possible - at last I can check stuff > out from SourceForge et al! > > However one small enhancement might be required: the ability to specify on a > per-repository basis whether to use the proxy or not. With the proxy enabled it > is impossible to connect to repositories sitting inside my company firewall. I'd suggest to add a property that would allow to specify hosts that should be contacted directly. Similar to what most web browsers have. > Also, regarding the "I HATE YOU" error... I assume that comes from the remote > server? It might be worth reporting the message as something like "Server > replied: I HATE YOU". We wouldn't want users to think that Eclipse itself is > being so unfriendly! This is response from pserver. Michael suggested to fill separate reports for this and other issues.
(In reply to comment #87) > I'd suggest to add a property that would allow to specify hosts that should be > contacted directly. Similar to what most web browsers have. jsch 0.1.27 will check the response code from http-proxy and if it is not '200', an exception will be thrown with the reason string given by http-proxy. So, ugly html lines whill not be shown. You can try it by the jar file attached on https://bugs.eclipse.org/bugs/show_bug.cgi?id=113521
