> > org.apache.harmony > > root of all package names > > > > org.apache.harmony.<modulename> > > separates module namespaces > > > > org.apache.harmony.<modulename>.<something> > > types whose API will be carefully managed. Other modules > > can use these types in their impl. > > > > org.apache.harmony.<modulename>.internal > > types reserved for use only within the module impl. Other > > modules should not use these types as they may change. > > > > org.apache.harmony.<modulename>.tests > > module's tests > > Ugh :) > > > > > org.apache.harmony.<modulename>.examples > > module's examples (if we have any!) > >
Yes! That it very similar (at least conceptually) to what I meant. The idea is to distinguish what others (I mean not only harmony developers of course, but our users who will write their java applications basing on harmony classes) can and what shouldn't use. Besides, such approach ties them to Harmony if they found such extensions (funtionality, included into packages of 'public access') useful :-) Talking about naming convension eclipse approach sounds very atrractive since lots of people are familiar with and get used it... -- Anton Avtamonov, Intel Middleware Products Division
