Each package offers something, be it a service or a data structure on which these services operate. Also, each of these concepts is to be applied in some way to other classes, not included in this package, by means of interfaces. This ensures that these other classes can responsibly handle the situation. Therefore, an object wanting to be agreeable to for example a service has to implement that corresponding interface. (Note, that there might lie an advantage of the java interfaces in comparison to multiple c++ like inheritance: the one who subclasses/implements an interface is forced to check the adequateness of the corresponding subclass code)
Unfortunately, the packag structure is monohierarchical, and so, for example, a TransferContainer is located in the transfer package; it fits as well into the container package. Too, I felt that the structure should not be too deep, and therefore it is now flat. This all in other words: The package structure is a compromise.
Sometimes it is hard to demand that for each little service the programmer has implement another interface and so to write some code. To make this easier, she, he or it, can copy code from existing classes and change it more or less. Better though it is to use one of the off-the-shelf-Adapters. Probably one of these already fits the specialities of the particular class, and the programmer's responsibility lies now in choosing an appropriate adapter, or, if no one suffices, to make a new one.