| RE: [cdt-dev] CDT 3.0 Closing |
|
We do a cursory check on a couple of ones that we know are important to our customers (Rational ClearCase, SlickEdit), but that’s about it. It’s sort of a “it might work, but we don’t officially support it” policy. Even in the case of SlickEdit they have their plugin dependencies setup so that nothing works if you don’t have both JDT and CDT installed, and since our product doesn’t include JDT, SlickEdit lovers are sort of out of luck.
We strive towards the ideal of having an open Eclipse/CDT platform that would allow us all to just mash eachothers products together at will, but I don’t know if that will ever come to fruition. When it comes down to it, even if you don’t modify Eclipse + CDT, you’re generally not just shipping those components alone, you’re making an integrated product using them, and it’s hard to make products that can just bolt together like Voltron into one big uber-product.
___________________________________________
Chris Recoskie Software Designer IDE Frameworks Group Texas Instruments, Toronto
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lott, Jeremiah
> There will always be some bug discovered by our internal QA that some project manager says we > must fix for our product release, or some feature that our customers say they must have, etc., and > it’s very difficult to just wait for the next CDT release for what you need and pitch your own product > schedule out the window.
Just out of curiosity, do you then test for compatibility with 3rd party plugins? I've been OK with our procedure so far, but if no one else is doing things this way, then we may be running a higher risk than necessary. Plus if everyone else is modifying CDT, then our approach to compatibility produces less benefit anyway, as no one else is actually using the exact codebase we are using as our compatibility criteria.
Jeremiah |