Community
Participate
Working Groups
This is a follow up of bug 325176. Unfortunately, the proposed solution as described in that bug, does not work for non-Oracle JVMs (or jaxb implementations). It would be nice if there was a way to accomodate both. A solution which works on Java 5 and does not lock into one specific implementation. Thanks!
Can you provide more background why the implemented solution of hard wiring the JAXB dependency fails on non Oracle VMs? We include javax.xml.bind and com.sun.xml.bind in the SDK feature and I was assuming these are compatible with all Java VMs.
(In reply to comment #1) > Can you provide more background why the implemented solution of hard wiring the > JAXB dependency fails on non Oracle VMs? We include javax.xml.bind and > com.sun.xml.bind in the SDK feature and I was assuming these are compatible > with all Java VMs. The problem is that bundle com.sun.xml.bind cannot be resolved on my system: $ rpm -q java-1.6.0-openjdk java-1.6.0-openjdk-1.6.0.0-57.1.10.1.fc15.x86_64 In particular, the problem boils down to using a non-API class (an internal class of the com.sun.xml.bind package). Class com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.JAXBContextBuilder is used in RestFulHudsonClient.java. Also, adding "Import-Package: com.sun.xml.internal.bind.v2.runtime" in o.e.m.hudson.core's MANIFEST.MF results in No available bundle exports package 'com.sun.xml.internal.bind.v2.runtime' It works fine if only API classes are used as it was the case before the fix for bug 325176 was applied.
The com.sun.xml.bind library is available from Orbit. Can you try getting it from there?
(In reply to comment #3) > The com.sun.xml.bind library is available from Orbit. Can you try getting it > from there? I could, but I think that's beyond the point. The reason as to why I reported this issue was that the fix of bug 325176 introduced this issue. Hence, making you aware that the fix isn't really a good one, unfortunately. It's not a big deal, but I think it's worth noting. Conclusion: I think there are the following options now: 1.) Stick with com.sun.xml.bind in order to have mylyn builds working for people using Java 5. That comes with the drawback of some people having the problem I'm describing. It can be solved by using Java 6 and reverting the fix of bug 325176 (that is what we are doing). Without the fix com.sun.xml.bind is not necessary and any reasonable implementation of JAXB would do. 2.) Investigate a different fix of the original problem of bug 325176. Could it be that the original problem stems from a bug in Oracle's implementation of JAXB in Java 5? Thanks
We could in theory try the factory first and and then fall back to the Sun implementation. What I still don't quite understand is why there is a problem with having a dependency on the Sun library?
(In reply to comment #5) > We could in theory try the factory first and and then fall back to the Sun > implementation. What I still don't quite understand is why there is a problem > with having a dependency on the Sun library? Because this adds an additional dependency if someone does not use Oracle's implementation of JAXB. Only one dependency on javax.xml.bind should be sufficient. In our case we use http://ws.apache.org/jaxme/ for javax.xml.bind, but that's not enough, since there's also the hard dep on com.sun.xml.bind. That makes 2 dependencies for the same thing. It works OK if using sun's package for javax.xml.bind, but not so well if not. Trying one and then the other doesn't really change our situation. We are building from source and hence the dependencies would still be the same.
> Trying one and then the other doesn't really change our situation. We are > building from source and hence the dependencies would still be the same. We can make com.sun.xml.bind an optional depdency so you wouldn't need to include it if the JAXB factory was guaranteed to work (i.e. Java 6 was always available).
(In reply to comment #7) > > Trying one and then the other doesn't really change our situation. We are > > building from source and hence the dependencies would still be the same. > > We can make com.sun.xml.bind an optional depdency so you wouldn't need to > include it if the JAXB factory was guaranteed to work (i.e. Java 6 was always > available). I don't think that would make the code compile without patching if com.sun.xml.bind is not available. That would help for runtime purposes, but doesn't help at build time.
> I don't think that would make the code compile without patching if > com.sun.xml.bind is not available. That would help for runtime purposes, but > doesn't help at build time. I haven't looked into it in detail but we should be able to use reflection to work around the compile time dependency.
Severin, any thoughts on that? We could consider it for 3.6 if it helps with the packaging.
(In reply to comment #10) > Severin, any thoughts on that? We could consider it for 3.6 if it helps with > the packaging. It might work. Do you have a patch I could try? I can't really tell for sure until I've tested it in my workspace. Thanks!
Created attachment 195803 [details] make com.sun.xml.bind optional Let me know if that works for you.
Created attachment 195804 [details] mylyn/context/zip
That seems to do it. Thanks, Steffen!
I have pushed the change and will trigger a new build shortly. We may need to revert in case unexpected problems arise.
