|Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
Hi Doug, On 06/27/2014 06:36 PM, Doug Schaefer wrote:
I guess the real question, is that if someone ends up with the OTDT version of the JDT, do bad things happen?
JDT has occasionally received a bug report that was actually a bug in OTDT. The same happens with Groovy as well. From memory I'd say that the latter is more frequent, but definitely neither source of bugs is relevant to the overall quality of JDT (Andy's role is quite similar to mine, actually). > I agree you followed all that was asked of you, but I think we assumed and
I do hope you've accomplished what's best for the community at large. What were the plans to mitigate these issues?
For the community at large, the p2 related measures, which have been discussed here and there, should avoid the problem from the outset. Other than that our main strategy is: Every Object Teams build runs *all JDT tests* To be fully open: the Luna build triggered a few failures in JDT/UI's LeakTestSuite, which could be a hard-to-reproduce bug in the original JDT/UI or caused by OTDT (*if* caused by OTDT, its definitely not caused by the o.e.jdt.core variant, hence not relevant to this thread). Other than that every release of OTDT passes all JDT tests. I only see one potential danger: if our variant of o.e.jdt.core accidentally publishes some additional API in JDT's namespace this could theoretically cause incompatibility. Real life combination of OTDT with other plugins consuming JDT has never revealed any such problem. Still, during Mars I will give it an extra round of reviewing to check if there might be any case of not being binary compatible. I am not saying all consumers should get the OTDT variant :) but even *if* a few get it by accident, it don't see any harm. Am I missing any other issues you'd like to see addressed? best, Stephan
Back to the top