Eclipse also has a special way of sharing classes with other plugins. You
can prevent outside plugins from using internal packages by tweaking the
export definition in plugin.xml:
<runtime>
<library name="something.jar">
<export name="*"/>
</library>
</runtime>
That seems to be the primary benefit to adding an "internal" package
prefix. Without the extra functionality provided by Eclipse it's only use
is for documentation. In that case, you may as well just add a note to
the javadoc like, "This class is not part of the public API" instead of
mangling the package names.
David
--- Mark Diggory <[EMAIL PROTECTED]> wrote:
> I've been working with the Eclipse SDK quite a bit lately, Eclipse has a
> coding standard where they divide the API up into "external" and
> "internal" API's. Internal API's are subject to change, while External
> API's are more stable and regulated. The division of these API's is
> usually:
>
> External API:
> org.foo.bar
>
> Internal API:
> org.foo.bar.internal
>
> Theses are similar to "Interface and Implementation" but without the
> association to OO Class/Interface terms already having "specific
> definitions".
>
> I think this is very "savvy" concept for managing the codebase. I wonder
> if this is an idea that would be of benefit if implemented in the
> commons? Is this approach already used in some commons components?
>
> -Mark
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
