Community
Participate
Working Groups
The 2020-09 M2 of Orbit has a newer JNA (v 5.6.0 - https://www.eclipse.org/lists/orbit-dev/msg05331.html). AFAICT the Platform 4.17 M2 still uses the older JNA (4.5). This bug is to track updating Platform JNA to 5.6.0.
CDT wants to require 5.6.0 (see https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/166621) - but I was trying to hold off until platform had it too so that we wouldn't have 2 versions of JNA in (for example) the C/C++ EPP. I sort of expected that the builds of Platform against the new orbit would automatically pick up the newer versions - but they didn't. I cannot find where in the code the version number of JNA is specified in the target platform. JNA is not listed in eclipse.platform.releng.aggregator/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target - but is listed in features/org.eclipse.e4.rcp/feature.xml (added in Bug 558807). The version constraint in Plaform already allows 5.x (see bundles/org.eclipse.urischeme/META-INF/MANIFEST.MF - thanks to Bug 558807). Any guidance welcome.
ECF is bringing in com.sun.jna for platform. We need to get ECF to use latest JNA. From platform side we can add newer version but that will again cause same problem as multiple versions in the repo. So better to push ecf to use latest version of com.sun.jna.
Hello ECF folk - as mentioned in Comment 2 you are the source of JNA being pulled into the platform/Eclipse release. To avoid multiple versions of JNA in 2020-09 I am hoping you can do the upgrade based on a gerrit I am about to submit. JNA 5.6.0 is in Orbit.
New Gerrit change created: https://git.eclipse.org/r/c/ecf/org.eclipse.ecf/+/167234
Howdy. Yes the dependency was added by the recently-added httpclient45 provider, contributed via bug 544447. I'm not the author of the code that uses the com.sun.jna version from Orbit, so I'm not qualified to approve the gerrit change from Jonah. Further, I can't actually test things in my environment because it requires a particular windows proxy environment. I'm cc'ing Carston Reckford (author of ECF code that uses com.sun.jna) to this issue. I would ask him to verify and test in the appropriate network environment...which hopefully he still has access to...and approve the com.sun.jpa version range change. Further, I'm adding Mat Booth as he's ECF's build master, and I would ask that he validate the target platform change in the gerrit changes, approve and prepare us for a maintenance release.
Gerrit change https://git.eclipse.org/r/c/ecf/org.eclipse.ecf/+/167234 was merged to [master]. Commit: http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=2ebb49ef328bdf43f02d900610a32bb4ab20874c
ECF 3.14.13 (with fix for this) has been made available to platform via bug 566066 resolving this.
We are getting an error in resolving com.sun.jna for org.apache.httpcomponents.httpclient.win The required version range defined as com.sun.jna;version="[4.4,5)" but the version available is 5.6.0. Can you please check? Reopening this
On a build, or running it? Presumably on windows only?
(In reply to Jonah Graham from comment #9) > On a build, or running it? Presumably on windows only? We had build failure. see https://ci.eclipse.org/platform/job/eclipse.platform.releng.aggregator-Gerrit/1726/console
I hadn't understood the circular dependency between ECF and Platform projects - as ECF's target platform has Eclipse Platform in it, the ECF builds fine because both versions of JNA are in there, so the transitive dependency to older JNA didn't get flagged or identified. Unfortunately, the transitive dependency is in org.apache.httpcomponents.httpclient.win and, unlike ECF which just used a simple constant in JNA, httpclient uses much more. This means that a new (or modified dependency version) of httpclient would be needed before JNA could be picked up. Unfortunately I recommend (for now) reverting the patch and not upgrading to 5.6.0 for 2020-09. I don't know how to get past this point - I don't have the knowledge or time to fix httpcomponents and surely can't recommend doing this now. On a quick examination, it may be possible to just increase the version range.
New Gerrit change created: https://git.eclipse.org/r/c/ecf/org.eclipse.ecf/+/167746
(In reply to Jonah Graham from comment #11) > Unfortunately I recommend (for now) reverting the patch and not upgrading to > 5.6.0 for 2020-09. Revert gerrit: https://git.eclipse.org/r/c/ecf/org.eclipse.ecf/+/167746 > I don't know how to get past this point - I don't have the knowledge or time > to fix httpcomponents and surely can't recommend doing this now. On a quick > examination, it may be possible to just increase the version range. Bug 566100 is for the dependent change in Orbit.
There is also at least one other dep on [4,5) version of JNA in Simrel: See Bug 566101
Gerrit change https://git.eclipse.org/r/c/ecf/org.eclipse.ecf/+/167746 was merged to [master]. Commit: http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=e45544704095ee3293e6c45308ae179081a84ab4
I've reverted to old version range of jna.win32 for now (thanks Jonah) and will provide new release to platform (v3.14.14 for ECF)...for incorporation into 2020-09. If at all possible, before this is attempted again, I suggest that there be some communication with Carsten, so that the desired version of jna is settled upon, that it can be tested against httpclient45.win32. Or, if necessary I suppose that httpclient45.win32 could be updated...but that will probably require Carsten to identify required version of httpclient45 (and then maybe get it added to Orbit?) and then testing...which is only possible with those that have NTLM2 proxy
Thanks Scott. Carsten, can you help? Although the real/next issues is Bug 566100 and then if/when that is resolved the original patch (or similar) can be reapplied here. (Added Carsten Reckord to cc-list on suggestion from Carsten Hammer[1] - thanks Carsten!) [1]https://git.eclipse.org/r/c/ecf/org.eclipse.ecf/+/167234/2#message-8e7eaa6533fa4f6e0624cc844ede9532d88ac3b1
Platform includes latest jna now.
Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=566100#c26 The whole reason for using the older JNA was for the org.eclipse.ecf.provider.filetransfer.httpclient45.win32 bundle (which is dependent upon org.apache.httpcomponents.httpclient.win 4.5 which is dependent upon JNA 4.5 as I understand). As per discussion on 566100, we *still do not have an httpclient5 (and JNA 5)* version of this windows-specific bundle and at this point I don't expect that I can move ECF to httpclient5 for 2021-06 without it, as it would be removing functionality that some consumers (win32 some proxies) depend upon. Without someone doing the steps described here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=566100#c22 (i.e. getting org.apache.httpcomponents.httpclient.win bundle into orbit, creating and testing org.eclipse.ecf.provider.filetransfer.httpclient5.win32) ECF cannot move to httpclient5 (or JNA 5) for 2021-6. Not to mention that there is also the coordination (via cross-projects I expect) for moving the simrel projects to httpclient5...so that we can avoid situation of having more than one httpclient version in simrel.
Scott, can you do the move for 2021-12 M1? I don't think this one should be prolonged more.
(In reply to Alexander Kurtakov from comment #20) > Scott, can you do the move for 2021-12 M1? I don't think this one should be > prolonged more. https://bugs.eclipse.org/bugs/show_bug.cgi?id=566100#c22 I describe here what's needed for adding the httpclient5 win32 support (under What remains to happen). For 1: I'm not an Orbit committer, so can't do this myself. For the associated ECF .win bundle dev for httpclient5: I don't know this code at all, and further I can't test it once developed (as I don't have an ntlm proxy...or any proxy...to test against) Finally, my availability is limited.
