About IBM supporting Java8 for Power. They just released jdk8 for IBM-i IIRC.
Cheers Wim
On Feb 21, 2015, at 10:00, Dario Foresti < Dario.Foresti@xxxxxxxxx> wrote:
Hi Scott,
thank you for your usefull reply to my question.
I'm not running one of examples within ECF, i'm running a product specific for my application.
My product config is based on features, in one of these features there is the dependency from org.eclipse.ecfremoteservice.asyncproxy bundle. If i run the product from PDE i have a version error because eclipse always load the highest version of asyncproxy
bundle, not the right one for j7 environment. And your detailed answer confirms to me that in eclipse PDE there is a bug .
Before to post my question on ecf mailing list, i tried to resolve the problem fixing the exact version of asyncprovy bundle (with the correct version and qualifier) into the feature config (as suggested also in your answer). But for me this solution seems
to be wrong, because when i run the application Eclipse continue to load the highest version of the bundle. It seems like Eclipse consider the version as a "minimum version", not a "fixed version". But, if i export the product and run the application outside
the PDE, the right plugin version is loaded and wired.
For now, the right solution for me seems to be the second one: create a product, launch the application with wrong version and then modify the created launch config forcing the 1.0.0 version of asyncproxy bundle. I try this solution and works perfectly.
At last, another little question: what about the J7 support in next ECF releases? I'm not sure that IBM will develop a JDK8 for Power8 and linux in short times and it is possible that i will have to use J7 also when the new release of ECF will be released.
Thank you for all.
Dario
On 2/20/2015 7:41 AM, Dario Foresti wrote:
In April 2014, Scott Lewis wrote:
"We arrange some set of features (maybe exactly what we have now, maybe not...I'm not sure) so that *both* versions of asyncproxy are installed into consumer's runtimes (Eclipse, other p2 users, or others...e.g. Karaf). Why do this? My thinking is this:
This way, at framework startup time if both 1.0 and 2.0 versions of async proxy are present, and the java version being used is < J8, then the asyncproxy 1.0 version will resolve and be wired to, while if the java version is >= j8 then the 2.0 version will
be used/wired. If my thinking is right on this, then this would mean that J8 users of ECF would have to do absolutely nothing to use this new CompletableFutures with async proxies....if they ran using j8 then the async proxy use of CF would/will 'just work'."
Now I'm using remote OSGI on a framework running on a java 7 environment. I can't use java 8 because the destination system of the product will be an IBM Power8 with Linux and for now a java 8 JVM is not available for this system. When the OSGI framework
starts ( on a test system with Windows 7, Eclipse Luna and Java-SE1.7 execution environment ), in console I have this error message:
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.ecf.remoteservice.asyncproxy [1248]
Unresolved requirement: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=1.8))"
It seems like the system always loads the 2.0 version of asyncproxy bundle (that require a J8 environment) instead of the right 1.0 version for J7.
So, only for my tests it seems that the Scott Lewis solution based on Require-Capability
filters and multiple version bundles does not work properly. But it is possible that i'm doing something wrong.
Anyone can help me?
And, if the solution really does not work, what can i do for load and wire the correct version of asyncproxy bundle?
Any help will be very appreciate.
Sure. First question: how are you starting/running/debugging things? If you are running one of the example product configs (e.g. TimeService.*.product from within Eclipse, there's a known problem with PDE that I'm trying to find a reliable work-around
for:
The behavior seems to be that when the Eclipse generates a launch config from running/debugging the .product config it *always* uses the highest version (i.e. 2.0.0 of asyncproxy) when there are multiple versions of a bundle present in the target (as is the
case with the ECF remoteservice SDK installed into Eclipse). In this case, it should rather select the 1.0.0 version of asyncproxy, because of the Require-Capability constraint you quote above (2.0.0 requires java8, 1.0.0 =< j7). I suspect the reason
for this is that PDE doesn't yet look at Require-Capability constraints (probably because I don't think p2 does yet either [1]) and so doesn't pay attention to the 1.8 constraint when selecting bundles for the launch config. Anyway, I'm trying to think of
ways to word around this in the next ECF release, but haven't got a solution yet.
If this is what's happening (.product config -> .launch config selecting wrong version), then one work around that you can do yourself is to generate the launch config, get the error above on start, and then go to the Run.../Debug... entry for that generated
launch config, go to the plugins tab, and unselect the 2.0.0 version and select the 1.0.0 version from the list on the plugins tab. This is inconvenient, I know, especially since if you have to change the product config, then you will need to re-generate
the .launch (as I do for the examples), change the selected version again...etc. But it does work.
If you are *not* using the example product configs, however (you have your own product config and/or features), this does point to a different/better solution for you. In that case, in your product config and/or feature that includes the asyncproxy bundle,
you can specify the *exact version* of the async proxy to use (i.e. 1.0.0.v20140410-1838). Then, when PDE generated the launch config, it will use the correct one. I understand this is somewhat brittle, because if we update the qualifier in a new version
you will have to update your product and/or feature to reference a new version, but I can say that this version has been in place for nine months without change, and I don't know of/expect any bugs, so I expect it to be relatively stable.
If I'm misunderstanding/misinterpreting what you are doing to launch please let me know. If you are doing something else/different from what I described above, then there may be other ways to prevent this from happening.
I've opened an ECF bug [2] to track pursuing a work-around for this.
Thanks for speaking up.
Scott
[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=313553
[2]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=460466
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|
