> > But there are a lot of questions. For example what structure and > > content should such library have. What classes used in Harmony modules we > > should include and what classes we should not include. It's obvious that > > library which simply consists of classes used by different developers in > > different places will look like trash can but not like useful library. > Agreed. I think the package naming convention goes a long way to > structuring the code properly to make the usability interesting. Yep. But I'm trying to say that creating tolls library is probably different project with different goals.
> 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. We also should remember that using classes from different modules create additional dependencies between modules and this will decrease modularity. And developers should document such dependencies anyway. So probably we need do create "utilities" or "harmonyutilities" module and put all useful for other modules classes into this package. -- Alexey A. Petrenko Intel Middleware Products Division
