Hi Ed, all @Ed: First, don't pretend you don't know what "internal" means here, you're smarter than that. Those projects deliberately built against such risk and it's fair to have them dealing with there own issues. Platform is a welcoming project, and anyone who needs to make code API can ask and do.
> 1. I don't see that JDT ought to have exclusive special privileges to > use internal things. > > JDT doesn't have privileges and everyone is free to use internal packages. But JDT succeeds to do it well because it does understand and comply with the meaning of internal and have set some practices to not be affected in a breaking way: building against Platform master source code or latest integration/nightly build to spot defects ASAP, agreement in making the necessary changes when need be or asking immediately to Platform for some remediation in too tricky scenarios, configuration of version range to not be affected by changes in internal code... Every project that follows similar practices can safely use internals. Projects that use internals without such practices were warned in the IDE when choosing to pick and internal API, and deliberately chose to ignore the warning either by keeping the reference to internal code, or not setting up a process that allows to spot such issues extremely early. Fortunately, the milestone builds are here so that even projects that don't have such a process as JDT one can detect issue a bit later, during milestones and react accordingly. But I agree with Alex and others that any request to have internal code managed like API is something Platform cannot afford at the moment, and could afford better if users of such internal code were more involved in Platform to make those officially APIs, or at the very least asking for those to become APIs on the bug tracker. Please revert this change before M5. > Why would Platform make an effort for downstream projects not properly using code? Platform is fully working as contracted in project plan, nothing to blame on Platform here. And in the future, please consider that any internal API that is used by > any other project is going to cause problems for many projects just as it > did for JDT: > Sure, but that won't prevent internal code from changing in a non-API compatible way forever. In the future, projects that use internal code just have to be ready to change your code which has internal references, like they've been expected to be since inception of API contracts. > https://bugs.eclipse.org/bugs/show_bug.cgi?id=529118 And see how JDT dealt with it? A patch was produced then merged. JDT understands what internal means, takes responsibility and remediates gently without offending other developers. Take that as an example. Now, for the specific case of HTMLPrinter, I agree it would better become an API then. @Ed: would you mind opening the bug request?
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
