My thoughts on this are that "internal" in package names is old-school and no longer needed since OSGI and the eclipse extensions makes it not necessary. It would still be ok to do, for redundancy, but, not really required since we can use x-internal. When starting with a new package at the beginning of a develop cycle, it is fine to use 'internal' in the name, but I do not sure it is worth any risk at all this late, since the same information can be conveyed and documented using x-internal.
I do think it's important to avoid 'provisional', if it is not too disruptive to your clients/adopters at this point in the 2.0 cycle. In theory, we (WTP) should have no more 'provisional'. That was a temporary thing, and in hindsight, not that useful (and, more disruptive than expected). From here on out, new functionality that is exposed for clients should be API, or not. We still need to 'evolve' the existing provisional, but that'll be a long term process, going through proper review, etc. I'd suggest opening a bugzilla to document details of your proposed changes, and ideally provide changes to clients for review in a temporary branch, and get some voice from the community of adopters. After all, in the "cost/benefit" trade-offs, it is them that would have to pay a cost now, for a potential benefit later. That is, at this late in the cycle, we should not be making any changes _simply_ for naming convention purity. But, in the case of 'provisional', it is likely a less expensive change to make now, than later. Thanks, "Ian Trimble" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/10/2007 12:51 PM Please respond to "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; Please respond to "General discussion of project-wide or architectural issues." <[email protected]> To "[email protected]" <[email protected]> cc Subject [wtp-dev] Convention for "internal" packages We're cleaning up our package names and declaring API in the JSF Tools Project. We will be refactoring to remove "internal.provisional" from our package names. Also, we have inherited some code that currently does not include "internal" in the package name but we do not consider it API. Is it enough to manipulate the bundle manifest to mark as "x-internal" for these non-API packages, or should we also be injecting "internal" into non-API package names? What is the convention? Thanks, - Ian (JSF Tools Project) ------------------------------------------------------------ Ian Trimble JDeveloper Group Oracle Corporation Canada Inc. Office: (250) 954-0837 Email: [EMAIL PROTECTED] Web: http://www.oracle.com ------------------------------------------------------------ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
