Community
Participate
Working Groups
JSch would be beneficial for reuse by other groups building on top of the base Eclipse platform. Would you approve exporting the JSch interfaces for reuse in the Eclipse 3.1 timeframe?
If it is exported we (e.g. the Team/CVS component) can't guarantee support of it. Our only interest is that it works with CVS, and as a result won't consider any bugs that don't affect CVS as blocking our release schedule. Another option would be to create a separete plug-in: org.eclipse.ssh2.
If splitting jsch.jar out into its own plugin will help with the support issue then I agree with this approach. If splitting out is to difficult in the 3.1 timeframe...I suggest we export for 3.1 and then split out in the next release.
Hi, I agree with following comments from Jean-Michel Lemieux and I think they are reasonable from Team/CVS component point of view. >If it is exported we (e.g. the Team/CVS component) can't guarantee support of >it. Our only interest is that it works with CVS, and as a result won't consider >any bugs that don't affect CVS as blocking our release schedule. I had planed to write a plug-in based on jsch for other plug-ins to allow them to enjoy ssh2 functionality; remote exec, login session, scp, sftp, port forwardings, etc. Of course, I had not expected that it will be included in Eclipse 3. It is just for fun. As a first step, I have been keeping in my mind that org.eclipse.team.internal.ccvs.ssh2.CVSSSH2Preference.java does not depend on CVS/Team plug-in.
Not for 3.1
Hi...is there a reason why this was removed for 3.1? Our product was depending on this being in 3.1.
It's not that important and the workaround is trivial - just include the jar in your product.
The problem here is not so much technical (although duplicating code is not a good thing for product footprint) rather legal. For every product that needs to include this they have to go through a lengthy legal and open source review. This would have saved countless hours of this effort.
Your point is well taken. However, exporting the jar from the CVS SSH2 plugin is something we cannot do because we cannot gaurantee 100% backwards compatibility in future releases. The proper solution is to create a separate plugin for the SSH2 support. The decision to do this needs to come from YMNK since he supports the jar. I would suggest you discuss this with him. Perhaps if you were willing to commit resources to help him maintain such a plugin, he would be willing to be involved.
The re-iterate, the Platform PMC was consulted regarding this request and they didn't support that the platform would be exposing SSH APIs (which is essentialy what exporting jsch.jar means). We don't want to be in this business now. The enhancement request will remain open - because I think it's still a valid request that may see the light at some point in the future - just not for 3.1.
We are going to investigate the possibility of doing this in 3.2.
There are a couple of ways we can make the SSH2 support a separate plugin: 1) Create a new dev.eclipse.org project that contains the Jsch.jar. This would be similar to how Ant and other libraries are included in Eclipse. 2) Have the library owner (JCraft) pre-build a JARed plugin and make it available on their site at a publiched location. A JARed plugin would be almost the same as a regular JAR but must contain an OSGI bundle manifest (and possibly a legal-related file). We would provide JCraft with the initial manifest file for them to insert in their jar. The Eclipse plaform build would obtain the JAR from JCraft when Eclipse was built (although it should be possible to configure the build process to cache the locally sothat it doesn't need to be re-obtained each build). We would prefer option 2 if possible since it is a cleaner story from our standpoint (and uses new technology;-). We are still in the process of modifying our build process to accomodate this but it should be possible soon. I wanted to send this out to see if JCraft was interested in this approach.
Option 2 is strongly urged. Creating a bundle is as simple as including some informationin the JAR manifest. We would indeed cache the provided bundle and ther ewould be no other adverse impact on JCraft. The added benefit is that this bundle would then be directly useful in other OSGi implementations etc.
By the way, I've seen number of complains about jsch library. Several projects (including JavaSVN) switched from it to Ganymed library which is also released under BSD license. According to various sources it has cleaner design and it is more stable then jsch. http://www.ganymed.ethz.ch/ssh2/
There are a couple of issues with switching to another SSH2 client: 1) We would need to rewrite the SSH2 plugin which is quite a bit or work to get right. 2) The client you mention does not use the JCE which means it contains cryto code. I suspect it would be problematic for Eclipse to ship with this plugin. Having said that, there is nothing to stop the providers of the client from also packaging their JAR as an OSGI bundle and making it available for people.
(In reply to comment #14) > There are a couple of issues with switching to another SSH2 client: > > 1) We would need to rewrite the SSH2 plugin which is quite a bit or work to get > right. Isn't it another sign of the design issues in jsch? Anyway it will also require PMC approval for using another library for ssh. > 2) The client you mention does not use the JCE which means it contains cryto > code. I suspect it would be problematic for Eclipse to ship with this plugin. It may be possible to convince Ganymed guys to use JCE. Ganymed project seems more alive then jsch in its current stage. > Having said that, there is nothing to stop the providers of the client from > also packaging their JAR as an OSGI bundle and making it available for people. By the way, I just faced the issue that OSGi does not allow to have multiple versions of the same bundle in the runtime. Which will cause whole bunch of incompatibilities and migration issues, especially if you'll stick to particular version of jsch and other plugins will use it.
(In reply to comment #15) > By the way, I just faced the issue that OSGi does not allow to have multiple > versions of the same bundle in the runtime. Which will cause whole bunch of > incompatibilities and migration issues, especially if you'll stick to > particular version of jsch and other plugins will use it. Off topic but since you mention it... The runtime definitely supports multiple versions of the same plugin active at the same time. There must be something else at play. If you have a usecase that cuases a problem, please enter a bug in Equinox/Framework.
(In reply to comment #16) > > By the way, I just faced the issue that OSGi does not allow to have multiple > > versions of the same bundle in the runtime. Which will cause whole bunch of > > incompatibilities and migration issues, especially if you'll stick to > > particular version of jsch and other plugins will use it. > > Off topic but since you mention it... The runtime definitely supports multiple > versions of the same plugin active at the same time. There must be something > else at play. If you have a usecase that cuases a problem, please enter a bug > in Equinox/Framework. That is really good to hear. Perhaps it was an issue with the update manager, which is disabling older version for the platform...
Hi, (In reply to comment #11) > 2) Have the library owner (JCraft) pre-build a JARed plugin and make it > available on their site at a publiched location. A JARed plugin would be almost > the same as a regular JAR but must contain an OSGI bundle manifest (and > possibly a legal-related file). We would provide JCraft with the initial > manifest file for them to insert in their jar. The Eclipse plaform build would > obtain the JAR from JCraft when Eclipse was built (although it should be > possible to configure the build process to cache the locally sothat it doesn't > need to be re-obtained each build). > We would prefer option 2 if possible since it is a cleaner story from our > standpoint (and uses new technology;-). We are still in the process of > modifying our build process to accomodate this but it should be possible soon. > I wanted to send this out to see if JCraft was interested in this approach. Yes, I'm interested in that approach. May I ask you to send me a manifest file and also suggest me what kind of configuration will be need in my side?
Here is a first kick at a manifest... This text should go in the META-INF/MANIFEST.MF file of the jar and the jar should be called com.jcraft.jsch_0.1.18.jar. Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Jsch Plug-in Bundle-SymbolicName: com.jcraft.jsch Bundle-Version: 0.1.18 Bundle-ClassPath: . Bundle-Vendor: JCraft Bundle-Localization: plugin Export-Package: com.jcraft.jsch;x-internal:=true, com.jcraft.jsch.jce;x-internal:=true, com.jcraft.jsch.jcraft;x-internal:=true Issues to think about: - in the Export-Package statement remove the ;x-internal:=true for each package that you want to have be externally visible. - If we currently ship source for this plugin then it would be great if you could also supply a separate source zip that contains the source packages at the root of the archive. Perhaps Michael you could try this out and give some further guidance?
We only use the com.jcraft.jsch package so the following is the manifest that works for the SSH2 plugin: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Jsch Plug-in Bundle-SymbolicName: com.jcraft.jsch Bundle-Version: 0.1.18 Bundle-ClassPath: . Bundle-Vendor: JCraft Bundle-Localization: plugin Export-Package: com.jcraft.jsch, com.jcraft.jsch.jce;x-internal:=true, com.jcraft.jsch.jcraft;x-internal:=true Of course, it is up to JCraft to decide if other clients may need access to the other packages. I have tried this manifest with a jar named com.jcraft.jsch_0.1.18.jar and a reconfigured SSH2 plugin and it worked with no problems. There are still a couple of questions we need to resolve: 1) Should we switch to using the latest Jsch version? I'm OK with the current jar but other clients may want the latest version. If we switch, we would need to do some testing on the Eclipse end to make sure there are no problems. 2) How should JCraft make it available. Jeff, is a URL from JCraft all we need? Perhaps JCraft can make both version 0.1.18 and the latest version available so we can get it working with the current version and then switch to the latest version (which would be a good test for our upgrade process).
Please reconsile if there are classes needed for proxy support. I've put a patch to another bug report some time ago. So, there could be some other classes that should be exported.
Re supplying the JAR. We are looking at how to set this up for real. Ultimately we will have to version manage such JARs so that we have reproducable builds. We also don't want to burden our suppliers with serving up the bytes everytime we care to do a build. So the best best is to get the JAR by whatever means and then give it to the Releng team as part of the base. They will put it somewhere safe and ensure it is part of the build. Adding Sonia to the list since I just volunteered her (or Kim) for something...
Hi, (In reply to comment #20) > We only use the com.jcraft.jsch package so the following is the manifest that > works for the SSH2 plugin: ... > Of course, it is up to JCraft to decide if other clients may need access to the > other packages. I agree that com.jcraft.jsch package must be enough. > 1) Should we switch to using the latest Jsch version? I'm OK with the current > jar but other clients may want the latest version. If we switch, we would need > to do some testing on the Eclipse end to make sure there are no problems. IMHO, it is preferable to use the latest version, but some testing must be done on Eclipse before switching. Is it allowed such a change before 3.2 release? If it is, I'll try some testing. > 2) How should JCraft make it available. Jeff, is a URL from JCraft all we need? > Perhaps JCraft can make both version 0.1.18 and the latest version available so > we can get it working with the current version and then switch to the latest > version (which would be a good test for our upgrade process). Of course, we can host them on our web site.
The Jsch JAR is now in the build as a separate plugin named com.jcraft.jsch. We are still hosting the JAR in the SSH2 plugin and the build fetches it from there because we don't have the build infrastructure to obtain it from another site yet.
What is the exact url for this new plugin? Also is there are any plans to move to 0.1.24 ?
The url is: http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/org.eclipse.team.cvs.ssh2/com.jcraft.jsch_0.1.18.jar?rev=HEAD&only_with_tag=v20060209&content-type=text/plain As for moving to 0.1.24, I'm not against it but its up to Yamanaka to decide if and when this would happen. Yamanaka, if you want me to try out the new version for a while, you can upload it to the repository (in the SSH2 plugin). I'll modify to be a stand alone plugin and run with it for a while to see if there are any problems. Based on how that goes, we can then decide what the best coarse of action is.
(In reply to comment #26) > Yamanaka, if you want me to try out the new version > for a while, you can upload it to the repository (in the SSH2 plugin). > I'll modify to be a stand alone plugin and run with it for a while to see if > there are any problems. Based on how that goes, we can then decide what the > best coarse of action is. Thank you for suggestion. I have been trying to use new jsch version in SSH2 plug-in and I have not encountered the problem yet in my usage. If jsch-0.1.25-rc5 is accepted on Bug 102654, I'll upload it.
(In reply to comment #26) >Yamanaka, if you want me to try out the new version > for a while, you can upload it to the repository (in the SSH2 plugin). > I'll modify to be a stand alone plugin and run with it for a while to see if > there are any problems. Based on how that goes, we can then decide what the > best coarse of action is. I have uploaded it as com.jcraft.jsch_0.1.25.jar to the repository. Are there any problems?
Thanks. I will do some initial testing today and, if all goes well, I will put it in tomorrows integration build. I have logged bug 128668 to track the conversion to the new JAR.
