Community
Participate
Working Groups
My work setup is I have an authenticated HTTP proxy, such that when I run an eclipse update, I am required to fill in a username / password form. However, even after logging into the proxy to do an update, I cannot connect to the JIRA repository to associate tasks with issues. Each time I get a 407 "Proxy Authentication Error" ?
Try setting the proxy settings as described here, and let me know if that resolves it: http://wiki.eclipse.org/index.php/Mylar_FAQ#Network_and_proxy_server_troubleshooting
(In reply to comment #1) > Try setting the proxy settings as described here, and let me know if that > resolves it: > http://wiki.eclipse.org/index.php/Mylar_FAQ#Network_and_proxy_server_troubleshooting > My proxy settings are configured there. However, there is nowhere in that section to put my proxy username / password. Eclipse update sites normally prompt for this information when required, but the JIRA connector just fails with a 407 error.
Brock: any words of wisdom regarding Proxy servers and the way that JIRA core services uses them?
it support proxies, but not authenticated proxies. The change should be quite simple, but i wouldn't have any way to test it.
(In reply to comment #4) > it support proxies, but not authenticated proxies. The change should be quite > simple, but i wouldn't have any way to test it. > If you can make the change, I would be happy to test it at my end of things. Please feel free to E-mail me on this matter. Regards, Ben
Brock: if you are able to make this change let me know and I'll put up a dev build for Ben.
*** Bug 162650 has been marked as a duplicate of this bug. ***
Brock: any news on this? Rob: what's our current strategy on the generic connector support for authenticated proxies? Are we just punting on it for now since Eclipse does not support it? I recall testing this way back and the authentication dialog would come up. Is this popup something that we will have lost due to basing everything on httpclient? If so that may mean that we have to add a place to fill the credentials ourselves, since waiting for getting this in Eclipse 3.3 could take too long.
no, I got an email from Ben this morning saying that the patch i tried didn't work. I will have to try again later with debugging options or something. The fix looked something like this: if (System.getProperty("http.proxyHost") != null) { Credentials creds; String proxyUser = System.getProperty("http.proxyUser"); String proxyPass = System.getProperty("http.proxyPassword"); if (proxyUser != null && proxyPass != null) { int domainSplit = proxyUser.indexOf('\\'); String domain = null; if (domainSplit != -1) { proxyUser = proxyUser.substring(0, domainSplit); domain = proxyUser.substring(domainSplit + 1); creds = new NTCredentials(proxyUser, proxyPass, hostname, domain); } else { creds = new UsernamePasswordCredentials(proxyUser, proxyPass); } client.getState().setProxyCredentials(AuthScope.ANY, creds); } }
I have some existing HttpClient code going through the auth proxy, and instead of "AuthScope.ANY", I used: new AuthScope(PROXY_HOST, PROXY_PORT, AuthScope.ANY_REALM) Where you'll have to get the values of "PROXY_HOST" and "PROXY_PORT". I don't know whether this is a critical element, but I know my code works. It might also be useful to install Wireshark (or equivalent tool) to watch the packets. You could monitor the exchange with Bugzilla through the auth proxy to see what the packets should look like.
If this is happening during validation, then the error is coming from Axis, not the custom HTTP code (which the patch was for). Ben, how are you specifying the proxy host and username? Have you tried starting eclipse with -vmargs -Dhttp.proxyHost=<hostname> -Dhttp.proxyPort=<port> -Dhttp.proxyPassword=<password> -Dhttp.proxyUser=<user> you can also verify that the environment variables are correctly set by looking in Help|About then pressing "Configuration Details"
Note that most people would expect to set the proxy details in Preferences, in "Internet"->"Proxy Settings". If those settings don't set the system variables that are being referenced, then the code should be referencing those settings values.
(In reply to comment #11) > > Ben, how are you specifying the proxy host and username? Have you tried > starting eclipse with -vmargs -Dhttp.proxyHost=<hostname> > -Dhttp.proxyPort=<port> -Dhttp.proxyPassword=<password> -Dhttp.proxyUser=<user> > > you can also verify that the environment variables are correctly set by looking > in Help|About then pressing "Configuration Details" > I was previously only running with "-Dhttp.proxyPassword=<password> -Dhttp.proxyUser=<user>" parameters, which gave me a (407) proxy authentication needed error. Adding the -vmargs swtich stopped me from getting this error. But instead I got an "internal error" which looking into my eclipse logs gave me this : !SESSION 2006-11-08 13:08:47.293 ----------------------------------------------- eclipse.buildId=M20060629-1905 java.version=1.5.0_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_GB Command-line arguments: -os win32 -ws win32 -arch x86 !ENTRY org.eclipse.core.jobs 4 2 2006-11-08 12:59:16.203 !MESSAGE An internal error occurred during: "Adding task: "TASK-01"...". !STACK 0 java.lang.NullPointerException at org.tigris.jira.internal.core.service.web.rss.RSSFeedProcessorCallback.isXMLOrRSS(RSSFeedProcessorCallback.java:156) at org.tigris.jira.internal.core.service.web.rss.RSSFeedProcessorCallback.execute(RSSFeedProcessorCallback.java:61) at org.tigris.jira.internal.core.service.web.JiraWebSession.doInSession(JiraWebSession.java:91) at org.tigris.jira.internal.core.service.web.rss.RSSJiraFilterService.quickSearch(RSSJiraFilterService.java:93) at org.tigris.jira.internal.core.service.soap.SoapJiraService.getIssue(SoapJiraService.java:170) at org.tigris.jira.core.service.CachedRpcJiraServer.getIssue(CachedRpcJiraServer.java:439) at org.eclipse.mylar.internal.jira.JiraRepositoryConnector.createTaskFromExistingKey(JiraRepositoryConnector.java:79) at org.eclipse.mylar.internal.tasks.ui.wizards.CommonAddExistingTaskWizard$AddExistingTaskJob.run(CommonAddExistingTaskWizard.java:76) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) As a sidenote, in my Configuration Details panel I have the following: eclipse.vmargs=-Dhttp.proxyUser=username -Dhttp.proxyPassword=password ... http.proxyHost=proxyhost http.proxyPassword=password http.proxyPort=8080 http.proxySet=true http.proxyUser=username http.proxyUserName=username https.nonProxyHosts=localhost https.proxyHost=proxyhost https.proxyPassword=password https.proxyPort=8080 https.proxySet=true https.proxyUserName=username I believe the http.proxyUser comes from what I have set in the command line, and the http.proxyUserName comes from the workspace properties menu.
Brock, do I understand correctly that passing the credentials gathered from the system properties didn't work? What about David's suggestion related to specifying the host/port, any luck there?
(In reply to comment #14) > Brock, do I understand correctly that passing the credentials gathered from the > system properties didn't work? What about David's suggestion related to > specifying the host/port, any luck there? > no, it is working correctly. To pass VM options to eclipse you have to specify them after a -vmargs parameter (for the eclipse.exe launcher only). The problem now is that the server isn't returning a content type for one of the pages. We use this to determine if the server returned the correct page. I can fix the null pointer (by assuming that the page is *not* text/xml), but it will probably not fix the underlying issue. Ben, what container is your Jira running in? It might help to know what version of Jira you are using. It is possible that something has changed in the latest versions. Would it be possible for you to obtain a wire trace of the responses being recieved from the server? If not, i can create a test program for you.
If you have to specify the proxy args on the command line, what is the point of the "Internet"->"Proxy Settings" page in the Preferences, where you set the exact same properties? Note that it's possible that we're seeing an issue with how the 407 protocol is handled between the client and server. It might be necessary to turn on "preemptive authentication" in httpclient. This would be the case if the initial request to the proxy includes request parameters that are not re-sent in the 407 challenge response. Turning on preemptive auth makes it send the proxy auth data on the first request, instead of waiting for the challenge response. If anything, this might be a little more efficient, anyway. If you determine this is necessary (or you want to try it), just use: client.getParams().setAuthenticationPreemptive(true);
David, that preference page does setup the http.proxyUser and http.proxyPassword system properties (if you have webtools installed). The 'standard' Install/Update preference page only allows you to setup the host and port.
Brock, I think either Update Manager or WTP installs proxy auth handler that asks for the proxy password.
(In reply to comment #15) > > Ben, what container is your Jira running in? It might help to know what > version of Jira you are using. It is possible that something has changed in > the latest versions. > > Would it be possible for you to obtain a wire trace of the responses being > recieved from the server? If not, i can create a test program for you. > I am using Enterprise JIRA Version: 3.6.3-#159 (or so it says on the bottom of the main screen). I went to the JIRA_URL/rpc/soap/jirasoapservice-v2?wsdl page and got some XML in response, so I assume RPC services are running. I wouldn't be able to run a wire trace program where I am, as I enjoy the warm fuzzy feeling of employment and wouldn't like to change that in the near future ! Yeah, work are a little strict on the packet sniffing apps policy. But if there is a test program, then I am happy to try that. Comment #18 makes a good point, certainly for a consistent UI perspective if nothing else, that the update manager in eclipse presents a popup window for http proxy logins. As this is a standard eclipse install feature, from my naive position I would imagine leveraging that would be an excellent way of implementing this feature.
Created attachment 53705 [details] Test program Ben, could you please run this program and add the results to this issue? The headers are the most important part, but you may be able to use the HTML section to help diagnose the problem. You will have the fix up the URL to match your system. set the searchString to be the issue key you were looking for and os_username and os_password to be your normal Jira username and password. Don't forget to setup your proxy by running with the -D options
With some embarrassment I have realised that my access to the JIRA server is not going through the authenticated proxy as I had expected, but is actually an internal server. Sorry - seems like my failure was not a proxy authentication problem after all. Thanks to Brocks program I was able to spot the actual problem - our JIRA is setup behind an SSO system, so my attempt to go the the JIRA box is intercepted and replaced with a location.replace javascript call, sending a browser to the SSO login page. Once logged in, a cookie is set allowing further access without interception. I have a suspicision that this might make using the RPC tools somewhat trickier, as I'm not sure if I can automate the SSO without using the web interface. So apologies again, I don't actually have the authenticated proxy between me and the server. Not sure if it's worth closing the bug, or leave it open for anyone who does actually encounter this situation. (In reply to comment #20) > Created an attachment (id=53705) [edit] > Test program > > Ben, could you please run this program and add the results to this issue? The > headers are the most important part, but you may be able to use the HTML > section to help diagnose the problem. > > You will have the fix up the URL to match your system. set the searchString to > be the issue key you were looking for and os_username and os_password to be > your normal Jira username and password. > > Don't forget to setup your proxy by running with the -D options >
I am completely willing to be a test subject for this, as I definitely have an auth proxy going out, but I'll probably need help setting up my testbed. If you only want Wireshark traces from the existing code, or from test versions of the plugin, that's easy for me to do.
David, the fix for this should be in JIRA Core Services 0.9.3 which will install when you update to dev build 0.9.0.v20061124-0730 which (uploading now and available in 15-30 min). You will need to set your proxy settings on the Task Repositories page. We do not have access to an authenticated proxy so we have *not* verified this yet. David, if you or anyone else having this problem could verify that would be great. http://www.eclipse.org/mylar/dl.php When doing so feel free to update the instructions on: http://wiki.eclipse.org/index.php/Mylar_FAQ#JIRA_Connector_troubleshooting
I'm certainly willing to do this, but I'll need instructions. I don't know how to install a dev build, or where to get it from (I saw what looked like a link for it on the Mylar project site, but it seemed to go to the FAQ instead). I assume I'll need to do with this my 3.3M3 installation? Note that I'm currently seeing another issue with connecting to the task repositories. I'm adding this comment in Firefox because I'm unable to synch my tasks in Eclipse. I've tried it both with and without the proxy (turning on or off my VPN). I get different exceptions in each case. With the VPN off (and the "enable proxy" flag in "Internet" turned off), it seems to still think it needs to use the proxy, but it fails to find my proxy host. With the VPN on (and proxy enabled), it gets "javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?".
Update site for the dev build is listed on download page at http://www.eclipse.org/mylar/dl.php I think it will work on Eclipse 3.2 with some exceptions. Anyways, worth to try and you can report issues. :-)
To reiterate, I can't see where on the page given by this link to actually download the dev build. In the box labeled "Developer Builds", the line labeled "Eclipse 3.3M3" has a link, but that only goes to the FAQ page.
(In reply to comment #26) > To reiterate, I can't see where on the page given by this link to actually > download the dev build. In the box labeled "Developer Builds", the line > labeled "Eclipse 3.3M3" has a link, but that only goes to the FAQ page. Don't tell me you install this stuff manually. :-) That page has a link: --- Developer Builds * Eclipse 3.3M3: download.eclipse.org/technology/mylar/update-site/dev ... ---- So, you should use this url (Mik, it is really confusing not to have http:// there, and you may want to add a word or two about using update manager, non-dev update site has nice picture) in Eclipse update manager. Help -> Find and Install...
Sorry, I still don't get it. I tried going to: http://download.eclipse.org/technology/mylar/update-site/dev But it says "No web page found here".
(In reply to comment #28) > Sorry, I still don't get it. I tried going to: > http://download.eclipse.org/technology/mylar/update-site/dev > But it says "No web page found here". In Eclipse, open menu Help / Software Updstes... / Find and Install... Create new update site with above url, select it and run update manager.
Ok, so should I install everything available at that update manager, or just the 2 entries in "Features" (task list and focused UI) and the 3 entries in "Integration" (Bugzilla, JIRA, and Trac)? What about the "Jira Core Services 0.9.3" in the "Tigris.org dependencies" section? I also noticed that the detailed revision number is slightly different than what Mik referred to. Instead of "0.9.0.v20061124-0730", it's "0.9.0.v20061124-1230". Should I care?
(In reply to comment #30) > Ok, so should I install everything available at that update manager, or just > the 2 entries in "Features" (task list and focused UI) and the 3 entries in > "Integration" (Bugzilla, JIRA, and Trac)? What about the "Jira Core Services > 0.9.3" in the "Tigris.org dependencies" section? If you only interested with jira integration you'll need task list, jira and jira core services. Bugzilla could be useful for submitting and monitoring bugs here. Trac is up to you and Focused UI is the feature that does Mylar's magic about filtering out uninteresting stuff. > I also noticed that the > detailed revision number is slightly different than what Mik referred to. > Instead of "0.9.0.v20061124-0730", it's "0.9.0.v20061124-1230". Should I care? Mik just cut another (better) build while you've been struggling with installing the previous one. :-)
Testing of this might be complicated by another issue that I haven't mentioned. The way our firewall works, if I make a plain DNS request for "bugs.eclipse.org" (by storing a repository for that host), it will only work if I'm NOT on the network (with my VPN off, for instance). I have to turn off my VPN when I'm adding a new external update site. However, after I add the update site or the task repository, it can communicate with it when my VPN is turned on. I'm not sure what's all going on here. In Mylar 0.9, I was able to create both the Eclipse.org (Bugzilla) and Spring (JIRA) task repositories with the VPN off, and then after turning on the VPN, I was able to verify the Eclipse.org one, and get the 407 (proxy auth required) error for the Spring one. In this dev release, I was able to verify the Eclipse.org repo the same as in the 0.9 release. In the JIRA connector, I get an error, but not the error I got before. Instead of giving me a 407 error, it gives me a very useful "Unable to connect to server. Please check the URL.". Nothing appears in the log when this message appears. (I have "-debug" on the command line.) I even tried verifying the settings with my VPN turned off. When I verify in this state, it gives me an error dialog with the entire exact contents of "proxy.wamu.net", which is the name of my proxy server. I then tried disabling the proxy settings in Preferences and trying again, but it gives me the exact same error dialog. Please advise.
Fyi I have updated the instructions on using the Update Manager, and added a link to our documentation on downloading/installing in this way. Have you followed the steps in? http://wiki.eclipse.org/index.php/Mylar_FAQ#JIRA_Connector_troubleshooting and http://wiki.eclipse.org/index.php/Mylar_FAQ#Network_and_proxy_server_troubleshooting Eugene, correct me if I'm wrong bug the JIRA Connector is still relying on the -D method of setting the proxy, right?
Yes, as far as I can tell, I've followed those steps. I've now tried changing the eclipse command line to add all the relevant "http*" definitions (it ended up being so long that I had to create a separate batch file for it, instead of just setting the command line in the shortcut). Unfortunately, I now get the exact error message I got before this fix, which was "(407)Proxy Authentication Required".
(In reply to comment #34) > I've now tried changing the eclipse command line to add all the relevant > "http*" definitions (it ended up being so long that I had to create a separate > batch file for it, instead of just setting the command line in the shortcut). I'd use eclipse.ini (sitting in the same folder as eclipse.exe (on windows). Mine has the following: ---- -vm C:\jdk1.5.0_08\bin\java.exe -vmargs -Xverify:none -Xms90m -Xmx300m -XX:MaxPermSize=85m -XX:MaxNewSize=40m ----- So, you could add -Dhttp* stuff in there and then verify from Eclipse - Help -> About -> Configuration Details. That these properties are set. then make sure you don't enabled proxy in Install/Update preferences (I think it may overwrite these system properties)... I'll see if I can install some dummy proxy here to reproduce something.
That's good to know. At least it allows me to run it from the shortcut. When I verify the JIRA repo settings, it gives me an error dialog just saying "(407)Proxy Authentication Required". I ran it through Wireshark (protocol analyzer). With this, I saw the following HTTP header line: POST http://opensource.atlassian.com/rpc/soap/jirasoapservice-v2 HTTP/1.1\r\n As expected, there is no proxy-authorization header.
*** Bug 166468 has been marked as a duplicate of this bug. ***
Eugene: any news on this?
I've tried to find simple proxy that I can install locally, but without luck so far.
(In reply to comment #36) > That's good to know. At least it allows me to run it from the shortcut. > When I verify the JIRA repo settings, it gives me an error dialog just saying "(407)Proxy Authentication Required". > I ran it through Wireshark (protocol analyzer). With this, I saw the following HTTP header line: > POST http://opensource.atlassian.com/rpc/soap/jirasoapservice-v2 HTTP/1.1\r\n > As expected, there is no proxy-authorization header. For some reason it is requested two times. First time without auth and go trough on the second time. I installed squid with basic auth and Jira access is working using following system properties: -Dahttp.proxyHost=<proxy host> -Dahttp.proxyPort=<proxy port> -Dahttp.proxyUser=<proxy name> -Dahttp.proxyPassword=<proxy password> Note that first two properties are also set by settings in Preferences -> Install/Updates. So, latter will overwrite anything you specify in -D properties (including eclipse.ini). You can see that in Help -> About -> Configuration Details. However there are bad news. Neither Bugzilla, Trac or Web connector are working (either with or without these system properties). More over, current Bugzilla and Trac preferences dialogs does not allow to finish configuration if I check "Use install/update settings". But validation fail anyways with error "No bugzilla server found at url" and I don't see any requests in the squid log.
I'm not certain exactly what you mean when you say it's requested two times. You might be referring to what you would see with the normal behavior of the 407 error code. With that, you might see two requests going across. This is why it's good to set the "preemptive authentication" flag in HTTPClient. This causes the proxy auth to be sent on the FIRST request, instead of waiting for the 407 response and sending it on the second request. The "No bugzilla server found at url" error is exactly what I see. It would be worthwhile to run a protocol sniffer (Wireshark) to watch the behavior.
(In reply to comment #41) > I'm not certain exactly what you mean when you say it's requested two times. All I see that squid got two requests. 407 then 200. > The "No bugzilla server found at url" error is exactly what I see. > It would be worthwhile to run a protocol sniffer (Wireshark) to watch the > behavior. There is not much we can do about JIRA, but Bugzilla client is clearly not working with proxies now. Well, I've been testing with the trunk version.
Yes, we do appear to have a major proxy bug with Bugzilla and Trac. I've bumped the priority of bug 166540 and it's the first thing we'll investigate on Monday. However, since JIRA is using the -D mechanism for proxies and its own httpclient, is this bug really dependent?
(In reply to comment #42) > (In reply to comment #41) > > I'm not certain exactly what you mean when you say it's requested two times. > > All I see that squid got two requests. 407 then 200. Ok, then that's exactly what I would expect. If the connection was done with "preemptive authentication", you wouldn't have seen the 407.
(In reply to comment #44) > Ok, then that's exactly what I would expect. If the connection was done with > "preemptive authentication", you wouldn't have seen the 407. David, does that matter? I was able to connect to JIRA trough authenticated proxy, squid in my case.
(In reply to comment #45) > (In reply to comment #44) > > Ok, then that's exactly what I would expect. If the connection was done with > > "preemptive authentication", you wouldn't have seen the 407. > > David, does that matter? I was able to connect to JIRA trough authenticated > proxy, squid in my case. > I don't know if it truly matters in this case. I do know that in a case I was working on in my own code, I saw that HTTPClient didn't handle the 407 protocol perfectly. I was sending some other headers along with the proxy auth, and I saw that it only sent all of the additional headers on the FIRST request (which received the 407), and not on the second request, which ended up being the request that was actually used. As a result, the downstream code failed, as it was missing some required headers. When I turned on preemptive authentication, the problem went away. From what I can see, it doesn't seem like that's what's happening here. There's no question, however, that using preemptive auth is more efficient, as it results in only a single request.
David, I understand. However this would be an improvement that JIRA core services can implement in the future and you can fill an enhancement request in JIRA services issue tracker at http://developer.atlassian.com/jira/ Anyways, as far as I can tell, with correct settings JIRA is working trough authenticated proxy (at least with squid setup I have here). I also fixed mistake on the wiki to reflect the correct system property for proxy user name. http://wiki.eclipse.org/index.php/Mylar_FAQ#JIRA_Connector_troubleshooting Closing this issue as fixed now. Let's discuss other issues in new bugs.
(In reply to comment #47) > David, I understand. However this would be an improvement that JIRA core > services can implement in the future and you can fill an enhancement request in > JIRA services issue tracker at http://developer.atlassian.com/jira/ > > Anyways, as far as I can tell, with correct settings JIRA is working trough > authenticated proxy (at least with squid setup I have here). I also fixed > mistake on the wiki to reflect the correct system property for proxy user name. > http://wiki.eclipse.org/index.php/Mylar_FAQ#JIRA_Connector_troubleshooting > > Closing this issue as fixed now. Let's discuss other issues in new bugs. > I'm confused. You're marking this issue as resolved. If I'm understanding this correctly, you didn't change anything, right? You don't mark a bug as resolved just because you can't repeat it. With 0.9.1, I cannot use the JIRA connector through my proxy. This bug is certainly not fixed.
(In reply to comment #48) > I'm confused. You're marking this issue as resolved. If I'm understanding > this correctly, you didn't change anything, right? I didn't. But since issue was opened at the end of September Brock made several changes to JIRA core services. So, since middle of November Mylar is using an updated version and I just confirmed in my tests that basic functionality is working, hence closing bug since original issue is resolved. > You don't mark a bug as > resolved just because you can't repeat it. With 0.9.1, I cannot use the JIRA > connector through my proxy. This bug is certainly not fixed. I understand that you still have issues there and already suggested to hunt your personal ghosts separately. :-) Let's get all information about your environment in a new issue. So, any information you can provide about type of your proxy, version of jira, used auth schemes, etc, would help us to identify what cause this in your case.
I would like to leave this bug open until we are sure that David's case is abnormal, and if so it should be documented in the following since others might encounter it. Either way we need to clearly communicate any limitations of proxy support for JIRA. http://wiki.eclipse.org/index.php/Mylar_FAQ#JIRA_Connector_troubleshooting Eugene: I guess we need a test JIRA server behind a proxy on mylar.eclipse.org?
(In reply to comment #50) > Eugene: I guess we need a test JIRA server behind a proxy on mylar.eclipse.org? Something like that. You also need to make sure that your client can't connect directly to that jira server. When I was testing locally, I disabled connection on my router, so I am quite confident that basic setup is working. Note that there is an issue with digester auth in httpclient Mylar is using right now, and I won't be surprised if other types of authentication does not work either.
If it matters, the JIRA repo I'm trying to use is at <http://opensource.atlassian.com>. I've said it before, but I'll say it again. It might be useful if someone could help me get my Eclipse environment set up so I can step through the code myself. I have a LiveMeeting subscription, so I should be able to share my desktop with someone else. I also have a conference line, so we should be able to talk on the phone while I'm stepping through this. Someone just has to step up and decide this is worth trying.
Note that http://opensource.atlassian.com is a portal site. Which particular JIRA instance you are connecting to? I've been testing with http://developer.atlassian.com/jira that has slightly newer version of JIRA then most of the sites from the opensource portal. That could be a reason why it didn't work for you.
David: the instructions to get your workspace set up only take a few steps: http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Workspace_setup It would be great if you could try and help isolate this problem.
Yes, I know about the contributor reference. I went through much of that, but it doesn't quite work for me. I'll have to review again what didn't work. I know I was unable to install the "projects-jira.psf" file, but I don't remember what happened. I'll reply again with more information. The other annoyance with this is that this problem is not the only situation where Eclipse doesn't work with the auth proxy. While on the proxy, I'm unable to sync with source repositories, and I have some trouble with the Update Manager. I think it can check for new revisions, but not new features.
(In reply to comment #53) > Note that http://opensource.atlassian.com is a portal site. Which particular > JIRA instance you are connecting to? > > I've been testing with http://developer.atlassian.com/jira that has slightly > newer version of JIRA then most of the sites from the opensource portal. That > could be a reason why it didn't work for you. > I just tried setting up a repo at that URL, and I get the same 407 error that I get with the other JIRA repo.
When I try to import the projects-jira.psf file, I get the following exception. I'll check for updates to the subclipse plugin. I'm running JDK 1.5.0_09. !ENTRY org.eclipse.ui 4 4 2006-12-03 09:59:50.897 !MESSAGE Unhandled event loop exception !ENTRY org.eclipse.ui 4 0 2006-12-03 09:59:50.897 !MESSAGE Name index 0 in LocalVariableTable has bad constant type in class file org/tigris/subversion/subclipse/core/resources/RemoteResource !STACK 0 java.lang.ClassFormatError: Name index 0 in LocalVariableTable has bad constant type in class file org/tigris/subversion/subclipse/core/resources/RemoteResource at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:161) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:499) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:469) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:428) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:411) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:334) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:386) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:161) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:499) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:469) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:428) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:411) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:334) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:386) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.tigris.subversion.subclipse.core.repo.SVNRepositoryLocation.<init>(SVNRepositoryLocation.java:102) at org.tigris.subversion.subclipse.core.repo.SVNRepositoryLocation.fromString(SVNRepositoryLocation.java:465) at org.tigris.subversion.subclipse.core.repo.SVNRepositoryLocation.fromString(SVNRepositoryLocation.java:434) at org.tigris.subversion.subclipse.core.SVNProjectSetCapability$LoadInfo.<init>(SVNProjectSetCapability.java:207) at org.tigris.subversion.subclipse.core.SVNProjectSetCapability.asProjects(SVNProjectSetCapability.java:137) at org.tigris.subversion.subclipse.core.SVNProjectSetCapability.addToWorkspace(SVNProjectSetCapability.java:105) at org.eclipse.team.internal.ui.ProjectSetImporter.importProjectSet(ProjectSetImporter.java:68) at org.eclipse.team.internal.ui.wizards.ProjectSetImportWizard$1.execute(ProjectSetImportWizard.java:50) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:101) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1742) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:113) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
Just checkout projects from svn at: http://jira-dashboard.tigris.org/svn/jira-dashboard/trunk/org.tigris.jira.core http://jira-dashboard.tigris.org/svn/jira-dashboard/trunk/org.tigris.jira.core.soap
(In reply to comment #58) > Just checkout projects from svn at: > > http://jira-dashboard.tigris.org/svn/jira-dashboard/trunk/org.tigris.jira.core > http://jira-dashboard.tigris.org/svn/jira-dashboard/trunk/org.tigris.jira.core.soap > No difference. Exactly the same exception.
Damn it! Use the command line svn client or something. :-) Last Subclipse is available from here http://subclipse.tigris.org/callisto.html There is also Subversive plugin at http://polarion.org/
Ok, I gave up on Subclipse and installed the Subversive plugin (along with the required "ProjectSet" plugin). I think I was able to get all of the JIRA code, although it's hard to tell. There were lots of choices along the way. When I view all the collected plugin projects in my 3.3m3 workspace, I see a red X on /org.tigris.jira.core.mock and /org.tigris.jira.ui. I have a feeling those are both for test classes, so I'm not going to worry about those at this point. In order to run this, I tried creating an Eclipse Application launch config, where in the "Plug-ins" portion of the launch config, I set "Choose plug-ins and fragments to launch from the list", and I selected everything in my workspace. When I run this, it fails to create the Task Repositories view on a CNF Exception for org.eclipse.mylar.internal.tasks.ui.views.TaskRepositoriesView. This is in the /org.eclipse.mylar.tasks.ui plugin project, which I had selected in the plugin dependencies, so I'm not certain why it can't find it. I tried following the instructions in the contributor reference, but I don't seem to see anything there that describes how to run it.
I am starting to have feeling that this part of the conversation should be happening in Mylar dev mailing list mylar-dev@eclipse.org You can subscribe at https://dev.eclipse.org/mailman/listinfo/mylar-dev
Not sure what there is left to do here without the JIRA Core Services move. Eugene, if you have further suggestions please post, otherwise posponing further changes until after 1.0. Eugene: if you could do a quick check to ensure the FAQ is still right given the most recent changes that would be great: http://wiki.eclipse.org/index.php/Mylar_FAQ#JIRA_Connector_troubleshooting
(In reply to comment #63) I don't think we have anything left here. Further work ill require changes in jira core services. The only item left on the agenda, how can we make David to disappear, since only he can see issues with auth proxies (not only for jira)... I have some connections though. :-)
Well, since I'm pretty sure that we do not want to make David disappear since his feedback is valuable I'm marking complete :) David: if you do have any clear steps to reproduce failures please reopen. Proxy configurations are notoriously tricky both on our end and on the network end. Eugene: please confirm whether the instructions in the FAQ sufficient.
(In reply to comment #65) > Eugene: please confirm whether the instructions in the FAQ sufficient. They worked for me, but I made those corrections in that FAQ few days ago.
Great, thanks.
