I work on large monolithic app which builds with maven.
Individual contributors only check out a fraction of the code to work locally.
Our maven pom.xml typically looks like below. One works on "mypart" which is just a local artifact. To get all the other necessary classes we define a dependency on the entire build (called "full" artifact below). This works great compiles and runs like a charm. IJ9+10 UE all works.
We have a problem when it comes to the way IJ resolves the code for the classes (ctrl+click and click in stacktrace). Indeed, we use the sources.jar produced by maven and IJ correctly links the full-sources.jar with the full.jar When we click to see the code of a class we don't have locally we end up with the content of the sources.jar; perfect. But at some point (not understood by me) IJ will point to the content of sources.jar rather than the locally available source code for "mypart" classes. Why?
Colleague tell me IJ9 had a similar behaviour, it favours resolving to code in sources jars over the code in local modules when there are indeed duplicates. Strange. The classpath order is ok, checked and double checked. It is the way IJ navigates the sources that is unexpected and in fact useless. I can understand how mapping a class to more than one .java file can be annoying from an implementation point of view. But adding logic to favour locally available code should not that hard. Why is all that indexing good for otherwise ;)
I hope someone can shed some light on this matter and perhaps offer a solution/workaround.
<?xml version="1.0" encoding="UTF-8"?>