Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Convention for "internal" packages

Correct me if I'm wrong but x-internal applies at the package level, not the class level. How does one differentiate API from internal classes if they are not separated into different packages by name? And if this is the case, what would be better as the differentiator than "internal"?

Also, x-internal has several serious problems that I can see. First, it only marks something "discouraged" rather than "restricted". In JSF, we turn off "discouraged" since otherwise our WTP dependencies light up our warnings log like a (yellow) Christmas tree. However, we do respect strictly the "forbidden" flag, which is what you get if you use x-friends. Second, x-friends is actually *overriden* when you use x-internal.


David M Williams wrote:

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.


*"Ian Trimble" <ian.trimble@xxxxxxxxxx>*
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/10/2007 12:51 PM
Please respond to
"ian.trimble@xxxxxxxxxx" <ian.trimble@xxxxxxxxxx>; Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

	"wtp-dev@xxxxxxxxxxx" <wtp-dev@xxxxxxxxxxx>
	[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: _ian.trimble@oracle.com_ <mailto:ian.trimble@xxxxxxxxxx>
Web: _ <>
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


wtp-dev mailing list

Back to the top