I just noticed this in our product builds now too. What was the solution? I imagine this is going to affect everyone that includes JDT in their product, no?
Doug. ________________________________________ From: [email protected] [[email protected]] on behalf of Thomas Hallgren [[email protected]] Sent: Wednesday, June 25, 2014 8:45 AM To: [email protected] Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version On 2014-06-25 14:27, Stephan Herrmann wrote: > On 06/25/2014 02:17 PM, Thomas Hallgren wrote: >> My guess is that the reason it gets selected by p2 is that the version >> >> 3.10.0.v_OTDT_r230_201406101339 >> >> is lexically greater than >> >> 3.10.0.v20140604-1726 >> >> since '_' (0x5f) is greater than '2' (0x32) > > This is intended and required to make the patch feature work. > Please note that this has not changed since Juno. My prior builds referenced the platform first and the release train second. This build didn't do that. Reinstating that order makes the problem go away. > > Is your build including the feature > org.eclipse.objectteams.otdt.core.patch.feature.group? No. > If that's not explicitly included and the OTDT variant is still selected, > then someone is preferring a solution with unmet dependencies over another > solution that is good indeed. Could be a bug in p2. I don't know. Don't think it's p2's nor OTDT's fault and it will work OK when installing. It fails when using tools like Buckminster or Tycho to populate the target platform since they don't use the SAT resolver and are unaware of true capability resolution. Highest version wins and that's it. - thomas _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
