AW: [geclipse-dev] GSISSH

["Stuempert, Mathias IWR" <mathias.stuempert@xxxxxxxxxx>]

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