Modularity and anti-spaghettiness has been one of the key organizing goals of the InfoGrid code base for a long time. Its most obvious sign is that InfoGrid is currently comprised of more than 100 separately defined Modules with explicit dependencies. These have recently been further broken down into several separate InfoGrid Projects?.
Within many of those Modules, further modularity can be detected. E.g. the org.infogrid.utils Module contains a number of different object frameworks which have no dependencies on each other and could have been defined in separate Modules. This was not done in order to keep the number of separate Modules down.
Because of this principle, application developers are able to pick and choose from InfoGrid exactly those Modules that are advantageous to their project, and ignore the others. Because specific implementations of abstract concepts are often found in different Modules than the definition of those concepts, it becomes straightforward to create InfoGrid applications that replace some InfoGrid code with code that in the view of the application developer, is more appropriate for the particular project on hand, without having to "work around" InfoGrid.