commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject Re: [all] External and Internal API's
Date Tue, 15 Feb 2005 19:24:36 GMT
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 <mdiggory@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message