Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version

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?


From: cross-project-issues-dev-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of Thomas Hallgren [thomas@xxxxxxx]
Sent: Wednesday, June 25, 2014 8:45 AM
To: cross-project-issues-dev@xxxxxxxxxxx
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

> 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

Back to the top