Question: I have a situation where I'm refactoring old code, taking apart an old monster project and splitting it (for various reasons) into smaller sub projects. One project is going to end up containing mostly interfaces while their associated implementations are in another project, and I'm not sure about the best way of setting up the package structure. 

Should I go for 

> 
> *org.company.interfaceproject.util.InterfaceClass*  and   
> 
> *org.company.implementationproject.util.ImplementationClass*
> 
> 
> 

or

> 
> *org.company.project.util.InterfaceClass*  and   
> 
> *org.company.project.util.ImplementationClass*
> 
> 
> 

where the first implementation has the advantage of pointing out to which project the files belong, while the second on doesn't mix in the fact that the files are in different projects at all. 

I guess there is no right and wrong here, but I'm curious if anybody has any opinions on the matter.

Answer: 
Both have merits. It ultimately depends on you intentions for the project. If your intent is to eventually create alternate implementations of the interfaces it may make more sense to go with option 1. If this will be the only implementation of the interfaces option 2 would be more reasonable.
If you can you should put the interface clases into a seperate plugin/package.
When you use interfaces you most of the time will have more than one implementation of this interface.

I would prefer option 1