[
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.
--Cam
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.
Thanks,
*"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>
To
"wtp-dev@xxxxxxxxxxx" <wtp-dev@xxxxxxxxxxx>
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: _ian.trimble@oracle.com_ <mailto:ian.trimble@xxxxxxxxxx>
Web: _http://www.oracle.com_ <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
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
------------------------------------------------------------------------
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev