Recently, the sshd_config file on our SVN server had to be modified due to security reasons and now we cannot connect to SVN via Eclipse using SSH. The only key exchange methods and MAC methods offered by the SVNKit Trilead library have been removed as options from the sshd_config file and cannot be put back.
I've found this resource at the SVNKit site https://support.tmatesoft.com/t/svn-e210002-svnkit-doesnt-connect-to-remote-repository/2480/15 which is much the same issue I'm experiencing.
Stacktrace
Caused by: java.io.IOException: Key exchange was not finished, connection is closed.
at com.trilead.ssh2.transport.KexManager.getOrWaitForConnectionInfo(KexManager.java:92)
at com.trilead.ssh2.transport.TransportManager.getConnectionInfo(TransportManager.java:231)
at com.trilead.ssh2.Connection.connect(Connection.java:769)
... 40 more
Caused by: java.io.IOException: Cannot negotiate, proposals do not match.
at com.trilead.ssh2.transport.KexManager.handleMessage(KexManager.java:413)
at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:765)
at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:480)
at java.base/java.lang.Thread.run(Thread.java:834)
I've been trying to manually patch the Trilead library but have been unsuccessful. There aren't many comments in the classes and pretty hard to follow.
If anyone has any idea of how to address this issue or even another way to SSH into SVN from Eclipse it would really be appreciated. I've been trying to figure this out for almost two weeks. This is the first time I've asked a question on StackOverflow. Thank you all in advance.
Related
I can't update NetBeans, I always get "Unable to connect to the Update Center".
I already checked the windows firewall settings:
I also checked the proxy, I get a green checkmark:
What else can I try?
I am using NetBeans 8.2 (Build 201609300101)
Proxy settings were NOT the problem for me.
I'm running NetBeans 11.0, and see that there are 4 default "Update Centers" configured. Having nothing to do with Proxy settings, I discovered that the "NetBeans Plugin Portal" URL was failing https://netbeans.apache.org/nb/plugins/11.1/catalog.xml.gz, and the last time this site was successfully checked was on 4/20/21.
My solution was to deselect that Update Center, and added the 11.0 archive site instead:
http://plugins.archive.librebeans.org/catalogue/11.0/catalog.xml
Now I can update/install plugins as expected. Maybe this is the solution for you too.
there is a number of similar questions from long ago (e.g. this one), and the suggestions are mainly about misconfigured proxy.
in my case, looking at the IDE log file revealed the following stack trace:
INFO [org.netbeans.modules.autoupdate.services.InstallSupportImpl]: Timeout while opening connection to http://bits.netbeans.org/dev/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/nbms/enterprise/org-netbeans-modules-websvc-metro-lib.nbm
java.util.concurrent.TimeoutException
at java.util.concurrent.FutureTask.get(FutureTask.java:205)
at org.netbeans.modules.autoupdate.updateprovider.NetworkAccess$Task$1.run(NetworkAccess.java:111)
Caused: java.io.IOException: Timeout while opening connection to http://bits.netbeans.org/dev/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/nbms/enterprise/org-netbeans-modules-websvc-metro-lib.nbm
at org.netbeans.modules.autoupdate.updateprovider.NetworkAccess$Task$1.run(NetworkAccess.java:131)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
INFO [org.netbeans.modules.autoupdate.services.InstallSupportImpl]: Cannot access http://bits.netbeans.org/dev/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/nbms/enterprise/org-netbeans-modules-websvc-metro-lib.nbm
java.io.IOException: Cannot access http://bits.netbeans.org/dev/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/nbms/enterprise/org-netbeans-modules-websvc-metro-lib.nbm
at org.netbeans.modules.autoupdate.services.InstallSupportImpl.copy(InstallSupportImpl.java:981)
[catch] at org.netbeans.modules.autoupdate.services.InstallSupportImpl.doDownload(InstallSupportImpl.java:733)
at org.netbeans.modules.autoupdate.services.InstallSupportImpl.doDownload(InstallSupportImpl.java:661)
at org.netbeans.modules.autoupdate.services.InstallSupportImpl.access$600(InstallSupportImpl.java:92)
at org.netbeans.modules.autoupdate.services.InstallSupportImpl$1.call(InstallSupportImpl.java:172)
at org.netbeans.modules.autoupdate.services.InstallSupportImpl$1.call(InstallSupportImpl.java:144)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Because I thought that was nothing wrong with my proxy settings (no proxy is selected, and connection is tested OK), i searched and search, getting even into the NetBeans code, trying in vain to find some hidden Timeout property. Indeed there is a place in the code (AutoupdateSettings.getOpenConnectionTimeout which seems to correspond to plugin.manager.connection.timeout property) which sets a timeout - yet i couldn't make it work (mucking with .properties files in ~/AppData/Roaming/NetBeans/8.2/config/Preferences/org/netbeans/modules/autoupdate)
In the end the only workaround I found was to download the NBM file mentioned in the stack trace manually. It seems that it was either indeed my firewall (an antivirus check?), or the file was just too large in itself and would cause the timeout because of this. Or the overloaded server. Anyway.
Fortunately, it is possible to install the downloaded file through Tools -> Plugins -> Downloaded -> Add Plugins, even though that plugin already is installed. Doing this the update process continued normally (although there was another timeout later - so I repeated the above procedure) and eventually completed.
The above plugins, for which I had to do manual install, were METRO 2.0 and JAXB 2.2
I have seen this problem here often but my problem seems to be more complex. I am not able to clone and use marketplace at the same time. I have to switch between Native and Manual Settings.
Here The diffrence between my Proxy Settings:
Manual:
Cloning ist not working
Internal Internet Browser ist Working
Marketplace is working
When i add this to the eclipse.ini
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
It is this exception:
org.eclipse.jgit.api.errors.TransportException: https://XXX.XXX.XXX/scm/Test/testprof.git: cannot open git-upload-pack
at org.eclipse.jgit.api.LsRemoteCommand.execute(LsRemoteCommand.java:221)
at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:159)
at org.eclipse.egit.core.op.ListRemoteOperation.run(ListRemoteOperation.java:100)
at org.eclipse.egit.ui.internal.clone.SourceBranchPage$8.run(SourceBranchPage.java:341)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
and without it:
java.lang.Exception: org.eclipse.jgit.api.errors.TransportException: https://XXX.XX.XX/scm/XXX/XXX.git: not authorized
at org.eclipse.oomph.setup.git.impl.GitCloneTaskImpl.perform(GitCloneTaskImpl.java:882)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3305)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.access$1(SetupTaskPerformer.java:3248)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil$1.run(SetupTaskPerformer.java:4469)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
Native:
Cloning is working
Internal Brwoser is working
Marketplace is not working
When i add this to the eclipse.ini
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
this happens:
org.eclipse.core.runtime.CoreException: Cannot install remote marketplace locations: Connection failed
This is most often caused by a problem with your internet connection. Please check your internet connection and retry.
at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand.execute(MarketplaceWizardCommand.java:106)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
and without it:
Failed to stream using org.eclipse.epp.internal.mpc.core.transport.httpclient.HttpClientTransport#1e8c67f7 - falling back to org.eclipse.epp.internal.mpc.core.util.TransportFactory$1#7592008d: Connection failed
This is most often caused by a problem with your internet connection. Please check your internet connection and retry.
Some information:
Yes, my credentials are correct.
Yes, my Proxy settings are correct
ssl.verify in git configs is =false
Windows 7
Egit version 4.4.1 (I also tried 4.6)
Cloning outside of Eclipse is working too
Thanks for your help... if i miss some information please ask...
The Solution ist to Clear the HTTPS field in the Network Settings and switch back to Manual.
Marketplace works and Cloning.
I am turning to SO here as my last resort, since my situation has been so illogical that I am at my wits end, even google can't get me a relatively close response.
I'll have to be very chronological. I am maintaining an application in Eclipse. The way application changes apply to the website is when I deploy appropriate .ear and .war files in the jboss test server.
I was relatively new to this whole process, so while learning on this, I stumbled upon occurrence I simply cannot logically comprehend.
1) I made some changes to the application (let's call it changeset_1
for convenience), created appropriate .ear and .war files, deployed
them to the jboss server.
2) Website was returning error 500. No biggie, I thought, let's deploy working files back to server. It returned the same error as if I
didn't deploy originals at all.
3) Restarting jboss server did not accomplish anything.
4) Frustrated, I thought of creating alternate files from the latest deployment directory. So I stored working project directory in the folder neighboring workspace folder used by eclipse. Then I started a new instance of Eclipse, and name new folder as a main namespase (old instance still uses old namespace folder).
5) In a new instance, I did not do any changes, I was just following
the same steps as before to create appropriate .ear and .war files and
deployed them as is to the server.
Now here is an interesting part
After performing steps above, I went to the test site link, and what I saw was: All changes from changeset_1 which I made originally in the first step successfully applied! At the same time, my last deployment was completely ignored.
Can anyone please point me in the right direction on how to approach such situation? Do I miss some kind of fundamental understanding on how all this stuff operates?
I literally don't have any more place to turn to... Unless I could not comprehend such incident to the point I could not explain it properly to google and it was giving me wrong results. Any help is really appreciated!
PS: I will do my best to provide any additional details if needed.
IMPORTANT EDIT
I initially thought I might've missed or misunderstood something, so I have recreated the scenario above for the second time. And for the second time I got the same outcome. Which no longer makes it an accident, but persistent occurrence.
EDIT 2
Upon request, here is a full error log in log file
2016-10-20 08:11:34,492 WARN
[org.jboss.detailed.classloader.ClassLoaderManager] (http-0.0.0.0-8080-1)
Unexpected error during load of:gov.ca.chp.cvs.struts.forms.CVSForm
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.apache.struts.config.FormBeanConfig.formBeanClass(FormBeanConfig.java:358)
at org.apache.struts.config.FormBeanConfig.createActionForm(FormBeanConfig.java:212)
at org.apache.struts.util.RequestUtils.createActionForm(RequestUtils.java:292)
2016-10-20 08:11:34,492 WARN
[org.jboss.detailed.classloader.ClassLoaderManager]
(http-0.0.0.0-8080-1) Unexpected error during load of:gov.ca.chp.cvs.struts.forms.CVSForm
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
Rootcause: "java.lang.UnsupportedClassVersionError: Bad version number in .class file" comes when you compile a Java class in higher version of Java Compiler and run it on lower version of JRE.
Read more: http://javarevisited.blogspot.com/2011/12/bad-version-number-in-class-files-cause.html#ixzz4NjV9ORkF
I am receiving the following error in Eclipse Neon when attempting to do a SVN checkout from Github. I have searched google and stack overflow for similar issues and answers from previous posts are not fixing the issue.
svn: E175002: Processing REPORT request response failed: XML document structures must start and end within the same entity
Its difficult to identify what attempts did not work for you to suggest something.
Can you let me know if you are using SVNKit for the checkouts.
Most issues are root to either SVNKIt compatibility or JDK issues like spooling etc.,
We have a git repository managed by gitosis under Ubuntu, which has worked well all up to the disk ran full. After reading up a bit on the issue, I found that git gc and git gc --aggresive got me quite a bit of diskspace back. Very nice.
Unfortunately this appears to have broken something in egit, as I get this message when trying to clone our repository (during the checkout phase at around 10%)
Packfile corruption detected: Unknown
zlib error.
Interestingly enough the git in msysgit works just fine as before.
I tried upgrading egit to the nightly build of 0.12 as there was some mailing list messages hinting this had been fixed within the last week, but to no avail.
My question now is, what can I do to my repository to get to a state where egit works again? I have full control over the Ubuntu instance running gitosis.
EDIT: I got a stack trace from the Eclipse event log
org.eclipse.jgit.errors.TransportException: Packfile corruption detected: Unknown zlib error.
at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:287)
at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:225)
at org.eclipse.jgit.transport.FetchProcess.fetchObjects(FetchProcess.java:214)
at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:149)
at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:111)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:903)
at org.eclipse.egit.core.op.CloneOperation.doFetch(CloneOperation.java:228)
at org.eclipse.egit.core.op.CloneOperation.run(CloneOperation.java:135)
at org.eclipse.egit.ui.internal.clone.GitCloneWizard.executeCloneOperation(GitCloneWizard.java:259)
at org.eclipse.egit.ui.internal.clone.GitCloneWizard.access$3(GitCloneWizard.java:252)
at org.eclipse.egit.ui.internal.clone.GitCloneWizard$4.run(GitCloneWizard.java:233)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.eclipse.jgit.errors.CorruptObjectException: Packfile corruption detected: Unknown zlib error.
at org.eclipse.jgit.transport.PackParser$InflaterStream.read(PackParser.java:1530)
at org.eclipse.jgit.transport.PackParser$InflaterStream.skip(PackParser.java:1500)
at org.eclipse.jgit.util.IO.skipFully(IO.java:203)
at org.eclipse.jgit.transport.PackParser.inflateAndSkip(PackParser.java:1352)
at org.eclipse.jgit.transport.PackParser.indexOneObject(PackParser.java:834)
at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:448)
at org.eclipse.jgit.storage.file.ObjectDirectoryPackParser.parse(ObjectDirectoryPackParser.java:178)
at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:410)
at org.eclipse.jgit.transport.BasePackFetchConnection.receivePack(BasePackFetchConnection.java:649)
at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:280)
... 11 more
Edit: Opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=340305
One way to get a clone without EGit is to:
make a bundle on the server
copy the unique file representing that bundle on the client side
try to clone it in command-line.
Since you mention you can process the bundle with msysgit, that suggests a bug on the Egit or JGit side, as illustrated by bug 330758.
The usual course of action is to update to the nightly latest fo EGit, using this p2 update site, and see if the problem is still there.
If the issue persists, you can then file a bug report or complete the existing one (330758).
Please check the versions of Git you are running and make sure they match.
The latest egit 0.12 does not show this behaviour.
Hopefully the bug has been fixed for real, and not just an accidental side effect.