Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
On 26 Jun 2014, at 10:49, Doug Schaefer wrote: We build directly against the Eclipse one. Does that mean we can't do that any more? you haven't been able to do that for ~2 years. Michael - do you recall why ODT keeps getting be allowed in the release train ? Thought we opened a bugzilla on this a while back since it really does not seem sane a plugin on the release train is allowed to mutate one of the plugins. /max Doug From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Mickael Istria [mist...@redhat.com] Sent: Thursday, June 26, 2014 10:45 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version On 06/26/2014 04:42 PM, Doug Schaefer wrote: 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? FYI, for JBoss Tools and JBoss Developer Studio, we do have a mirror of the Luna repository from where we explicitly exclude the OTDT patch. And since we consume this repository, we are sure we always get the JDT one. https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/jbosstools/updates/requirements/luna/build.xml#L32 HTH -- Mickael Istria Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools My bloghttp://mickaelistria.wordpress.com - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev /max http://about.me/maxandersen ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
FWIW, we build m2e against simrel repository and don't have any problems. http://ci.tesla.io:8080/view/m2e/job/m2eclipse-core/ -- Regards, Igor On 2014-06-27, 10:27, Max Rydahl Andersen wrote: On 26 Jun 2014, at 10:49, Doug Schaefer wrote: We build directly against the Eclipse one. Does that mean we can't do that any more? you haven't been able to do that for ~2 years. Michael - do you recall why ODT keeps getting be allowed in the release train ? Thought we opened a bugzilla on this a while back since it really does not seem sane a plugin on the release train is allowed to mutate one of the plugins. /max Doug From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Mickael Istria [mist...@redhat.com] Sent: Thursday, June 26, 2014 10:45 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version On 06/26/2014 04:42 PM, Doug Schaefer wrote: 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? FYI, for JBoss Tools and JBoss Developer Studio, we do have a mirror of the Luna repository from where we explicitly exclude the OTDT patch. And since we consume this repository, we are sure we always get the JDT one. https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/jbosstools/updates/requirements/luna/build.xml#L32 HTH -- Mickael Istria Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools My bloghttp://mickaelistria.wordpress.com - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev /max http://about.me/maxandersen ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
Yeah, I think we're OK since we depend on the eclipse.sdk feature which brings in the right version of JDT. I just saw OTDT fly by with another error message, but that seemed unrelated and is now gone. But I do remember a lot of concern when this came along and Max's question is a valid one to ask. We do have two JDT's in the simrel repo. That's pretty scary. Doug From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [i...@ifedorenko.com] Sent: Friday, June 27, 2014 10:35 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version FWIW, we build m2e against simrel repository and don't have any problems. http://ci.tesla.io:8080/view/m2e/job/m2eclipse-core/ -- Regards, Igor On 2014-06-27, 10:27, Max Rydahl Andersen wrote: On 26 Jun 2014, at 10:49, Doug Schaefer wrote: We build directly against the Eclipse one. Does that mean we can't do that any more? you haven't been able to do that for ~2 years. Michael - do you recall why ODT keeps getting be allowed in the release train ? Thought we opened a bugzilla on this a while back since it really does not seem sane a plugin on the release train is allowed to mutate one of the plugins. /max Doug From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Mickael Istria [mist...@redhat.com] Sent: Thursday, June 26, 2014 10:45 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version On 06/26/2014 04:42 PM, Doug Schaefer wrote: 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? FYI, for JBoss Tools and JBoss Developer Studio, we do have a mirror of the Luna repository from where we explicitly exclude the OTDT patch. And since we consume this repository, we are sure we always get the JDT one. https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/jbosstools/updates/requirements/luna/build.xml#L32 HTH -- Mickael Istria Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools My bloghttp://mickaelistria.wordpress.com - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev /max http://about.me/maxandersen ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
On 06/27/2014 05:34 PM, Doug Schaefer wrote: But I do remember a lot of concern when this came along and Max's question is a valid one to ask. We do have two JDT's in the simrel repo. That's pretty scary. Doug OK, I had to dig 3+ years into the past to find the original agreement. Here are the main references for your convenience: The general case was discussed in this bug: https://bugs.eclipse.org/330312 Conclusion: no new rules needed for such a rare situation. The special case should be handled via a request for exception. Request for exception was raised via tools PMC: http://dev.eclipse.org/mhonarc/lists/tools-pmc/msg01491.html The result was to make the decision depend on an agreement between JDT and Object Teams. This reflects the discussion in both tools PMC and Planning Council. This agreement has been achieved in a phone call between Dani and myself. After that call, I brought the request to the eclipse PMC: http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg01338.html In that thread you find Dani's confirmation, four +1 votes, and no 0 or -1 votes. Aside from formal process, need I assure anybody on this list, how much I care about the quality and reputation of JDT? best, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
No one doubts your commitment to JDT. You've been great helping them out. And we all appreciate that. I guess the real question, is that if someone ends up with the OTDT version of the JDT, do bad things happen? 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? Thanks, Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Stephan Herrmann [stephan.herrm...@berlin.de] Sent: Friday, June 27, 2014 12:16 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version On 06/27/2014 05:34 PM, Doug Schaefer wrote: But I do remember a lot of concern when this came along and Max's question is a valid one to ask. We do have two JDT's in the simrel repo. That's pretty scary. Doug OK, I had to dig 3+ years into the past to find the original agreement. Here are the main references for your convenience: The general case was discussed in this bug: https://bugs.eclipse.org/330312 Conclusion: no new rules needed for such a rare situation. The special case should be handled via a request for exception. Request for exception was raised via tools PMC: http://dev.eclipse.org/mhonarc/lists/tools-pmc/msg01491.html The result was to make the decision depend on an agreement between JDT and Object Teams. This reflects the discussion in both tools PMC and Planning Council. This agreement has been achieved in a phone call between Dani and myself. After that call, I brought the request to the eclipse PMC: http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg01338.html In that thread you find Dani's confirmation, four +1 votes, and no 0 or -1 votes. Aside from formal process, need I assure anybody on this list, how much I care about the quality and reputation of JDT? best, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
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 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
looks similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=350133 I've seen the same problem with tycho builds against Luna RC4 repo (OTDT version of org.eclipse.jdt.core bundle being selected by the p2 resolver instead of the original one) workaround for tycho builds is to filter out the OTDT bundle version from the target platform https://wiki.eclipse.org/index.php?title=Tycho/Target_Platform#Filtering (or use .target file with perfect version matches) My impression is it's up to p2 resolver implementation details which solution is chosen, so depending on the overall bundles being resolved, either the solution using OTDT or original may be chosen. Regards, Jan From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Paul Webster Sent: Mittwoch, 25. Juni 2014 01:44 To: Cross project issues Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version On Tue, Jun 24, 2014 at 6:09 PM, Thomas Hallgren tho...@tada.semailto:tho...@tada.se wrote: I just encountered a build failure when using the platform repository in conjunction with the luna staging one. The failure was caused by p2 preferring the objectteams patch for org.eclipse.jdt.core in favor of the original. Seems the patch has a higher version (3.10.0.v_OTDT_r230_201406101339) than the one found in the platform repo (3.9.2.v20140114-1555). I don't know what's causing it, but the staging repo doesn't have that version of jdt.core: pwebster@build:/home/data/httpd/download.eclipse.org/releases/staginghttp://download.eclipse.org/releases/staging ls plugins/org.eclipse.jdt.core_* plugins/org.eclipse.jdt.core_3.10.0.v20140604-1726.jar plugins/org.eclipse.jdt.core_3.10.0.v_OTDT_r230_201406101339.jar None of the eclipse/updates/4.4* repos have 3.9.2 (which is Kepler SR2 I guess) either. PW ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
On 06/25/2014 12:09 AM, Thomas Hallgren wrote: I just encountered a build failure when using the platform repository in conjunction with the luna staging one. The failure was caused by p2 preferring the objectteams patch for org.eclipse.jdt.core in favor of the original. Seems the patch has a higher version (3.10.0.v_OTDT_r230_201406101339) than the one found in the platform repo (3.9.2.v20140114-1555). I don't recall having seen this problem before so something must be different. Anyone have a clue as to what might be causing this? One thing, exactly, has changed in Object Teams in this regard: I followed Pascal's advice for avoiding unintended updates from the original to the OTDT variant. On 06/25/2014 09:13 AM, Sievers, Jan wrote: looks similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=350133 That's the exact reference to our best effort to improve this. I double checked and from all I can see the meta data looks exactly as advised: - the OTDT variant of org.eclipse.jdt.core has a non-greedy dependency on our patch feature (since Juno) - cannot be installed without explicitly selecting that patch feature. - the patch feature is marked as a patch for the *bundle* org.eclipse.jdt.core, not for the jdt feature (new in Luna). - patch feature is not regarded as an update of the jdt feature. Can you share a setup for reproduction? The reference to 3.9.2... looks fishy, indeed. regards, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
On 2014-06-25 12:57, Stephan Herrmann wrote: Can you share a setup for reproduction? The reference to 3.9.2... looks fishy, indeed. The reference to 3.9.2 was introduced when I tried to fix the problem and appointed the wrong platform site. My error. Please disregard that. The real problem occurs when I'm using releases/staging (i.e. RC4) from my Buckminster build. I'm currently circumventing it by redirecting all requests for org.eclipse.jdt.* directly to the 4.4milestones platform repository. - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
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) - thomas On 2014-06-25 12:57, Stephan Herrmann wrote: On 06/25/2014 12:09 AM, Thomas Hallgren wrote: I just encountered a build failure when using the platform repository in conjunction with the luna staging one. The failure was caused by p2 preferring the objectteams patch for org.eclipse.jdt.core in favor of the original. Seems the patch has a higher version (3.10.0.v_OTDT_r230_201406101339) than the one found in the platform repo (3.9.2.v20140114-1555). I don't recall having seen this problem before so something must be different. Anyone have a clue as to what might be causing this? One thing, exactly, has changed in Object Teams in this regard: I followed Pascal's advice for avoiding unintended updates from the original to the OTDT variant. On 06/25/2014 09:13 AM, Sievers, Jan wrote: looks similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=350133 That's the exact reference to our best effort to improve this. I double checked and from all I can see the meta data looks exactly as advised: - the OTDT variant of org.eclipse.jdt.core has a non-greedy dependency on our patch feature (since Juno) - cannot be installed without explicitly selecting that patch feature. - the patch feature is marked as a patch for the *bundle* org.eclipse.jdt.core, not for the jdt feature (new in Luna). - patch feature is not regarded as an update of the jdt feature. Can you share a setup for reproduction? The reference to 3.9.2... looks fishy, indeed. regards, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
Correction. Should say selected by Buckminster, not selected by p2 since this isn't a build-time best-effort resolution and not a full p2 resolution. I guess the same can be said about the Tycho resolution. - thomas On 2014-06-25 14:17, 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) - thomas On 2014-06-25 12:57, Stephan Herrmann wrote: On 06/25/2014 12:09 AM, Thomas Hallgren wrote: I just encountered a build failure when using the platform repository in conjunction with the luna staging one. The failure was caused by p2 preferring the objectteams patch for org.eclipse.jdt.core in favor of the original. Seems the patch has a higher version (3.10.0.v_OTDT_r230_201406101339) than the one found in the platform repo (3.9.2.v20140114-1555). I don't recall having seen this problem before so something must be different. Anyone have a clue as to what might be causing this? One thing, exactly, has changed in Object Teams in this regard: I followed Pascal's advice for avoiding unintended updates from the original to the OTDT variant. On 06/25/2014 09:13 AM, Sievers, Jan wrote: looks similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=350133 That's the exact reference to our best effort to improve this. I double checked and from all I can see the meta data looks exactly as advised: - the OTDT variant of org.eclipse.jdt.core has a non-greedy dependency on our patch feature (since Juno) - cannot be installed without explicitly selecting that patch feature. - the patch feature is marked as a patch for the *bundle* org.eclipse.jdt.core, not for the jdt feature (new in Luna). - patch feature is not regarded as an update of the jdt feature. Can you share a setup for reproduction? The reference to 3.9.2... looks fishy, indeed. regards, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
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. Is your build including the feature org.eclipse.objectteams.otdt.core.patch.feature.group? 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. regards, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
On Tue, Jun 24, 2014 at 6:09 PM, Thomas Hallgren tho...@tada.se wrote: I just encountered a build failure when using the platform repository in conjunction with the luna staging one. The failure was caused by p2 preferring the objectteams patch for org.eclipse.jdt.core in favor of the original. Seems the patch has a higher version (3.10.0.v_OTDT_r230_201406101339) than the one found in the platform repo (3.9.2.v20140114-1555). I don't know what's causing it, but the staging repo doesn't have that version of jdt.core: pwebster@build:/home/data/httpd/download.eclipse.org/releases/staging ls plugins/org.eclipse.jdt.core_* plugins/org.eclipse.jdt.core_3.10.0.v20140604-1726.jar plugins/org.eclipse.jdt.core_3.10.0.v_OTDT_r230_201406101339.jar None of the eclipse/updates/4.4* repos have 3.9.2 (which is Kepler SR2 I guess) either. PW ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
