Order click-through to sources not in sync with classpath

Hi all,

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.

Best regards,

Johan

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>product</groupId>
    <artifactId>mypart</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>product</groupId>
            <artifactId>full</artifactId>
            <version>${project.version}</version>
        </dependency>
    </dependencies>

</project>

5 comments
Comment actions Permalink

Johan,

If the dependency imported as a Library dependency, its attached sources will be used.
If it is a Module dependency, then local sources will be used.

Please check your Project Structure->Modules->Dependencies.

Is this stil is not clear, please add more details on how the project is layedout and how it is imported in IDEA.

Thanks,
Anton Makeev

0
Comment actions Permalink

Hello Anton,

Thanks for the information. Indeed, continuing with my pom example, the "full" dependency is imported as library (with its sources jar correctly arttached). That part works perfectly.

So my dependencies look something like this:

JDK_X_Y_Z
<Module source>
Maven:product:full:version

In my setup the product:full artifact is the superset of product:mypart so indeed the code of "mypart" is also present in "full". Problem is that for classes present in the <Module sources> (the "mypart" code) we get to see the .java sources coming from the product:full sources.jar. This happens when we click through and while debugging.

Since we can not split up our code base we need this setup were we check out a part of the code and use the full build for the remaining classes. Again, this works both to compile and run.

If I made things less clear let me know.

Regards,

Johan

0
Comment actions Permalink

I understood your issue. Please create a youtrack issue and add this as a description.
I'll investigate it a bit later.

Thanks,
Anton Makeev

0
Comment actions Permalink

Hi Anton,

Many thanks for the prompt reply. I've created IDEA-66984

Regards,

Johan

0
Comment actions Permalink

You might get what you want by listing the project your are working on as an exclusion in the overall project pom. With luck IntelliJ then won't have a decision to make over whether to use the maven sources or your local ones.

0

Please sign in to leave a comment.