Community
Participate
Working Groups
Build Identifier: After unpacking http://download.eclipse.org/tools/orbit/downloads/drops/S20110304120314/repository/plugins/com.jcraft.jsch_0.1.44.v201101211721.jar and comparing the contents to http://cdnetworks-us-1.dl.sourceforge.net/project/jsch/jsch.jar/0.1.44/jsch-0.1.44.jar I was surprised to find that all the class files are different. Obviously the manifest, plugin.properties, etc. can be expected to be new/different in the bundle. But I would have expected the original class files to be kept intact. They are not. For example, MAC.class in the original starts as feca beba 0000 2e00 1500 0007 0712 1300 whereas in the bundle it starts as feca beba 0000 2e00 1500 0001 2803 4929 despite having the same length. Were classes recompiled from sources, perhaps using ecj? This seems to contradict the intent of Orbit, though I cannot find a specific policy guideline on the subject. Reproducible: Always
They were taken directly from upstream's binary jar.
I just double-checked on fresh downloads on Logger.class; again, same length of file, but contents in a different order. It looks like Logger.class in CVS is identical to that in the origin JAR, but Logger.class in the bundle obtained from the download site differs from those two. Perhaps caused by Pack200 conditioning?
(In reply to comment #2) > ... Perhaps caused by Pack200 conditioning? Perhaps, that would explain it. But seeing this issue discussed made me "relook" at some things, and I see some oddities in build that might call for a change in build scripts (and/or imply some other bug in build scripts). First, I was thinking that com.jcraft.jsch* was one of our "pre-built" ones, that is excluding from packing. Looking at the map files, it appears that used to be true, but no longer is. And, the older ones, that were pre-built have been removed from map map files and current, active builds. Second, if I'm looking and remembering correctly, our "exclude from conditioning" part of the build script is fairly primitive, and simply excludes all com.jcraft.jsch* bundles from conditioning ... presumably, which would contradict what you are seeing, or, at least one presumed reason for what you are seeing. So, 1) I'll continue to investigate and 2) fix our "dumb" exclude statements, if they are still really being used and 3) see if "exclude" is really working at all! So, while I don't know any answers ... thought I'd document what I know.
> > So, 1) I'll continue to investigate and 2) fix our "dumb" exclude statements, > if they are still really being used and 3) see if "exclude" is really working > at all! > Ok, false alarm. Our exclude is working as intended. Sort of by accident. Even though we do specify "com.jcraft.jsch*" in one part of it, we also use ant's "fileset" which returns only _files_ and only the pre-built bundles exist there, in ${builddirectory}/plugins as (jar) files ... the rest are directories of class files, etc. So, only the prebuilt jars are picked up to add to exclude list. I will update bug 191870 with this observation, and will only change build scripts if/when we make an overall improvement in our "detection" of pre-built jars. So, back to your bug :) ... I think this can be closed as "working as designed" unless the change in byte codes you are seeing is causing some problem?
(In reply to comment #4) > I think this can be closed as "working as designed" As you see fit. > unless the change in byte codes you are seeing is causing some problem? No, it just struck me as suspicious that the bundle-ized JAR contains slightly different bytecode from the officially published library. If the classes were not in fact recompiled but merely preconditioned for Pack200 then it is much less likely that the differences would have any observable effect. Another difference is that the bundle contains com/jcraft/jsch/jgss/GSSContextKrb5.class whereas the original does not contain this package (though the matching *.java is present in its source distribution).
> > Another difference is that the bundle contains > com/jcraft/jsch/jgss/GSSContextKrb5.class whereas the original does not contain > this package (though the matching *.java is present in its source > distribution). That does sound suspicious. Pretty sure it would have had to have happened before putting into cvs. I check the latest build (directly on build machine), and compile logs are only generated for org.json (as expected) ... so ... I'll leave between you and Chris to sort out?
Regarding GSSContextKrb5.class , there was a discussion on the jsch-users mailing list (archives on sourceforge). It was an oversight upstream that some versions of JSch distributed from jcraft do not contain that class file, although the source is always included - that's what the maintainer said. Lucky us that we have the file :) since it's required for the gssapi-with-mic authentication method, which in turn is required for Kerberos, which in turn some users want or need (though it seems to be a headache to set up). Also note that there's 2 different binary variants of JSch-0.1.44 available from upstream: (a) the original version built with Jdk-1.4.0 according to MANIFEST http://sourceforge.net/projects/jsch/files/jsch.jar/0.1.44/jsch-0.1.44.jar/download and the mavenized version, built with Jdk-1.6.0_16 according to MANIFEST http://jsch.sourceforge.net/maven2/com/jcraft/jsch/0.1.44/ None of the two contain GSSContextKrb5, and none of the two are signed with Jarsigner. Though the Mavenized version is signed with gpg. Looks to me like pack200 conditioning + signing at Eclipse is a good thing to do, better than taken the unmodified binary, since some installers REQUIRE signed Jars. I'm still wondering though where Eclipse's GSSContextKrb5.class originally came from. I've added the original maintainer on CC who's also an Eclipse committer.
Another potential problem I spotted with the JSch bundle: it declares no dependency on JZlib. (Nor does JZlib appear to be in Orbit.) This renders the Eclipse-packaged bundle useless for any app which attempts to use compression: the Class.forName (in com.jcraft.jsch.Session) will try to load com/jcraft/jsch/jcraft/Compression.class but get a linkage error. Probably (1) JZlib needs to be packaged as an Orbit bundle, (2) the JSch bundle needs to declare an optional dependency on it.
Just guessing here ... but it sounds like there are some "heavy" users of this bundle that have good insight to its inner workings, and might have a (more) vested interest in making sure its exactly right ... so I bet Chris could be convinced to give up "ownership" if someone else wanted to take over and contribute a better, cleaned up version? It appears Martin's name is associated with version 0.1.41 and Chris's with 0.1.44 (the topic of this bug). Especially comment #8 might change this from a "minor" bug to a "major" bug? Suitable to fix in RC1 or RC2? Any volunteers? (Or, apologies Chris, if you are indeed interested in continuing to maintain this bundle, and respond to these issues).
(In reply to comment #9) > Any volunteers? (Or, apologies Chris, if you are indeed interested in > continuing to maintain this bundle, and respond to these issues). I am all for giving up rights on jsch if someone else wants to do it.
Changing priority and adjusting summary according to comment #9, since it seems the other discrepancies are intentional.
Chris, assigning to you since you are listed as contact. If you want to find a new "owner" that'd be fine, but otherwise think some of these issues are best answered/decided by "the contact".
FYI, JSch 0.1.45 is coming (bug 360663) so we should take care then to have jzlib included.
JSch-0.1.46 (with the desired jzlib dependency) is now attached to bug 360663 . For JZlib, I have created https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6218 to request approval for redistributing from Eclipse as an OSGi bundle (and adding it to Orbit).
I'm a little confused about this bug. I guess first thing to say is "1.44" is old enough that I think it's fair to say "won't fix" for that. Let me know if I am reading something wrong. 1.44 has not been in "active builds" for awhile, only 1.46 and 1.50 are in active builds, and about to add 1.51 (bug 447800). But, the last comment says "JSch-0.1.46 (with the desired jzlib dependency) is now attached ... ) and while I did not actually look at "attached" bundle, I looked at the one on Orbit and it has Import Package: com.jcraft.jzlib;resolution:=optional Not sure why it's "optional", but assumed this bug can be closed. I'm going to close it as "won't fix", since original request was to fix 1.44 (and, honestly, I did not go back that far in history to see if it was fixed. I hope consumers have "moved up" by now, and, I hope soon move up to 1.51. Thanks,
I am no longer working on the project consuming this bundle so I am not inclined to dig deeper either, provided that you say newer versions of the bundle do in fact declare the jzlib dep as requested in comment #8.
