I've put a first cut of the proposed package naming convention on the website:
http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html Regards, Tim Leo Simons wrote: > On Fri, Feb 10, 2006 at 12:52:09PM +0300, Anton Avtamonov wrote: >>> As I wrote elsewhere, I propose that packages whose naming convention is: >>> org.apache.harmony.<modulename>.<something> >>> >>> represent internal APIs. All visible (public/protected) types in those >>> packages can be used by class library developers from any module, and >>> such developers can expect the API to be evolved in a compatible way. >>> >>> Module developers should not rely on the stability of anything starting: >>> org.apache.harmony.<modulename>.internal >>> >>> and are strongly discouraged from referencing visible types in such >>> packages since these are type internal module implementation code (and >>> when we turn on OSGi runtime checks the imports from other modules will >>> fail). >>> >>>> From other hand if we are talking about using these useful classes only >>>> inside Harmony then it's probably a good idea. But we need some procedure >>>> for moving a class to utilities package and we need to notify developers >>>> about class capabilities. >>> Moving it to a 'utilities' package should be as simple as making it a >>> non-internal package name; and the notification is javadoc of those >>> non-internal types. >>> >>> If people agree I'll write something for the website along these lines, >>> if not we can continue to debate it on the list. > > +1 (to the website thing, though debate obviously is fine too :-D). > > I personally think that it is a good idea to seperate out non-J2SE-specific > non-Harmony-specific stuff as much as possible. I also think it is a good idea > to evaluate very carefully on a case-by-case basis whether it makes sense to > have that kind of code live under the "harmony" banner -- experience has shown > that breaking out "true" utility stuff can help result in wider usage of that > stuff which tends to result in more bugfixes, better code, etc. > > For example (and I'm being really naive here) I can imagine that java.util > could be built on top of jakarta-commons-collections, or that > java.util.logging > could be built on top of log4j (now that'd be cool). > > But this is just me imagining stuff that might be possible in the future. For > now it doesn't make sense to worry or think about this too much - we'll see > what kind of ties between harmony and something like jakarta-commons (or > whatever other part of the open source java space we're on about here) is > possible as the issue comes up. > > cheers! > > Leo > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
