OST issue for built in classes and SObjects in multiple module project

Issue #1308 resolved
Jonny Power created an issue

We have a multiple module project where within each mode we have different source folders for apex/other metadata/apex tests.

Previously we were having a issue with the OST not recognizing classes belonging to other modules - which we fixed by correctly defining dependencies between modules in IntelliJ via our build.gradle files.

The same issue exists though, for built in classes, like System and for our SObjects defined in our metadata source folder.

In a test class under our test source: (No builtin System class)


In our apex source: (No OST for the SObject)


Is there another setup step, similar to marking dependencies between modules in IntelliJ, to assist the OST in finding things like this?

Comments (15)

  1. Scott Wells repo owner

    Jonny, can you provide a very simple example project that evidences this issue? I use multi-module projects with cross-project dependencies all the time and haven't seen this, so there must be something in this particular project that is causing it. A standalone reproduction would be invaluable.

  2. Jonny Power reporter

    Scott, sure, let me get back to you with that. Hopefully it's easily reproduce-able in a minimal example.

  3. Jonny Power reporter

    Sorry Scott, I tired replicating this in a minimal project, had it all set up and replicated - then regenerated the OST and it worked fine.

    So, I went back and tried regenerating in my primary project again a couple of times and still no luck. I wonder what the breaking point is in my setup.

  4. Jonny Power reporter

    I wonder if it would be worthwhile to spend 15 minutes doing a screenshare with you to validate the issue - you'd probably be able to tell pretty quickly if it's a legitimate bug

  5. Scott Wells repo owner

    Jonny, I'm happy to do so, but I just started summer holiday with my family and am out of pocket for the next week for the most part. I can reply to emails somewhat out-of-band. If this can wait until 6/17 or later I can definitely do a quick screenshare with you to get to the bottom of it, though.

  6. Jonny Power reporter

    More than happy to wait for you to get back - enjoy your time off! Sorry to ping your inbox when you are on vacation.

  7. Scott Wells repo owner

    Not an issue at all. I can't ever go fully dark even on vacation! I don't mind responding to emails, albeit with a potential delay. Let's touch base week-after-next and we'll take a look at what's going on.

  8. Scott Wells repo owner

    Jonny, I'm back and relatively settled after getting a Summer '19 update out. Let me know a few times that might work for you to have a quick screenshare and hopefully we can get to the bottom of this quickly.

  9. Jonny Power reporter

    Thanks you @Scott Wells, I really appreciate this :)

    I'm in PST, free from 3.30pm today, or any time that suits you tomorrow, 10.30am - 1pm Thursday, 11am to 2pm Friday

  10. Scott Wells repo owner

    Jonny, after 3:30PM today won't work for me. Let's shoot for tomorrow. I have a meeting 1-2PM CDT, but outside of that I'm quite open tomorrow. Let me know what time would work best for you and please shoot me an email at scott@illuminatedcloud.com to which I should send the meeting invite. Thanks!

  11. Jonny Power reporter

    Thanks again for your time Scott.

    For future readers;

    Ensure your module has the correct connection SDK set;


    Will attempt to find out where that information is persisted

  12. Scott Wells repo owner

    Glad we got it (semi-)sorted out, Jonny. Also note that in general IC will set your SDK for you automatically if unspecified. You'll know about this via the "Invalid configuration for module..." notification:


    In Jonny's case the module files are being managed by Gradle based on an external definition. I'm still trying to figure out if there's some way to handle that more gracefully given the ambiguous "ownership" of module config, but it did seem that once the SDK was set once, it was retained across Gradle builds.

  13. Scott Wells repo owner

    I'm going to go ahead and resolve this for now. We can continue to discuss findings about where the SDK setting is being stored in your config here or in email. If the setting does revert automatically, feel free to reopen and we can dive back in.

  14. Log in to comment