Does the current directory structure cause problems with IDEs such as Eclipse or Netbeans, don't their indexing and search mechanisms mean that a developer doesn't have to traverse trees?
Dan,
IDEs do help, but I found that they cannot always tell you what the implementation of an interface is. For example, if I point the cursor at a method, it will show the comments associated with that method. But this is usually an interface, and if I want to see the implementation, I have to do a search to find out.
For this reason, I decided to generate Javadoc documentation so that I could use Javadoc's ability to list out implementations, etc.
I wish that the interfaces and implementations were packaged close together - like org.package.module for interface, and org.package.module.impl for implementations. This would have made it easier to find the relevant implementations. The problem with current structure is that one has to navigate down two different directories.
Instead of moving code around to an alternate convention (I_/Impl class
name tags iapi/impl packages) that as you say gains no functional value,
I would prefer to see activity around reducing footprint by removing the
iapi/impl split and merging classes in *some* situations.
I would argue that we should leave things as they are for the time being, as changing things will make it harder for anyone trying to understand the code. Stability is important for anyone trying to follow the code.
Regards
Dibyendu
