Re: AW: [geclipse-dev] GSISSH

[Thomas Köckerbauer <tkoeck@xxxxxxxxxx>]

Hi

Unfortunately it is not that easy. "com.jcraft.jsch" is nowhere used directly, 
it is used by org.eclipse.jsch.core (and .ui), which then are used by the 
(g-)Eclipse plugins. Those plugins for example provide the possibility to 
change the ssh settings in the preferences.
To make them use a "eu.geclipse.jsch" plugin those also would have to be 
changed. If we use our modified plugin directly without those plugins we loose 
the possibility to for example change the private keys in the preferences.

Besides that if we could replace/extend the com.jcraft.jsch plugin all plugins 
that use ssh (not only the ones from g-Eclipse) could use the additional 
authentication mechanism.

If we introduce a "eu.geclipse.jsch" we also would have to change every 
reference in our existing plugins that use ssh to the new plugin(s). I'm not 
sure if this will not cause IP process problems (all our ssh plugins are in 
SVN, so we also would have to get our modified jsch plugin into SVN for being 
able to reference to it). I'm not that sure how easy that is, especially since 
it is a fork of something thats there already anyway.


Cheers,
Thomas

On Wednesday 13 May 2009 16:33:51 Stuempert, Mathias IWR wrote:
> Hi Thomas,
>
> I think the easiest way would be to forget about the binary jar and to
> provide a modified source code version of jsch as an own plug-in
> (eu.geclipse.jsch?). According to their licence this should be no problem
> at all (well, I'm not the expert on licensing but this one seems to be
> rather clear ;-) :
>
> <snip>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are met:
>
>   1. Redistributions of source code must retain the above copyright notice,
>      this list of conditions and the following disclaimer.
>
>   2. Redistributions in binary form must reproduce the above copyright
>      notice, this list of conditions and the following disclaimer in
>      the documentation and/or other materials provided with the
> distribution.
>
>   3. The names of the authors may not be used to endorse or promote
> products derived from this software without specific prior written
> permission. </snip>
>
> Of course you could not easily migrate to new versions but as long as you
> can live with the current version ...
>
> Cheers, Mathias
>
>
> -----Ursprüngliche Nachricht-----
> Von: geclipse-dev-bounces@xxxxxxxxxxx im Auftrag von Thomas Köckerbauer
> Gesendet: Mi 13.05.2009 16:09
> An: Developer mailing list
> Betreff: [geclipse-dev] GSISSH
>
> Hi
>
> I've been working on the support of GSISSH in g-Eclipse the last few days
> since this was one of the requests the LRZ people had. The good news is,
> its basically implemented and works. The bad news is, I have no idea how to
> package it.
>
> The implementation replaces a few classes of the com.jcraft.jsch plugin
> (and adds one new one), due to the structure of the jsch plugin there is no
> other way then to replace some classes (there are no extension points,
> since it is basically only a plugin providing the jsch library).
>
> I first thought it would be possible by providing a fragment for the jsch
> plugin which provides the replacement classes and allows the use the use of
> the new classes and the unchanged ones from the same class loader.
> I found out that replacing already existing classes using fragments is not
> as easy as i thought:
> http://wiki.eclipse.org/FAQ_Can_fragments_be_used_to_patch_a_plug-in%3F
> http://wiki.eclipse.org/Steps_to_use_Fragments_to_patch_a_plug-in
> As you can see in the 2nd link this would also require changes in the host
> plugin (jsch) for adding a dummy jar file.
>
> Since I found out that this will not really work I currently have a jsch
> plugin project in my workspace which in addition to the jsch jar file has
> my classes as source too, which are listed before the jar file in the
> bundle class path, so that they replace the original code.
>
> The question for me now is how can we provide the gsissh functionality in
> g- Eclipse? What will happen if we provide a com.jcraft.jsch plugin that
> provides the functionality (and maybe has a higher version number) - will
> Equinox use this one instead or will this just cause problems?
>
> If somebody has an idea what to do here please comment.
>
> Another thing that I do not know is how to commit the code into the CVS (as
> com.jcraft.jsch plugin?), somehow standalone (I guess a fragment is no
> option since this will not work)? (I guess not know in which form to commit
> it we have to solve the other problem first)
>
>
> Cheers,
> Thomas
>
> _______________________________________________
> geclipse-dev mailing list
> geclipse-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/geclipse-dev
>
> _______________________________________________
> geclipse-dev mailing list
> geclipse-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/geclipse-dev