You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the build.sc imported $ivy dependency, which is also dependency of modules, there would be no generated xml file for that dependency in .idea/libraries directory, and so intellij would not work with the dependency properly.
The text was updated successfully, but these errors were encountered:
I think #533 is more or less a duplicate of this, sorry. Let me copy/paste my report here and then I'll close #533:
This was discussed briefly in the Gitter channel on 23-25 Jan 2019.
One of the “selling” points of Mill is useful “Jump to Definition”. In fact, though, the generated IntelliJ project does not reference, download, or have local access to Mill's source jars.
It's tricky to test this because when you build and publish Mill locally, it publishes its source jars and then IntelliJ can find them. (Thus, building from source is a workaround for the problem.) The best I could come up with in my attempts to fix/troubleshoot this was to delete those source jars manually after publishing but before running for the first time. Also, a Mill custom-built from a local commit is going to have a version number different from anything on Maven, so pulling source jars will definitely fail anyway. I tried to get around that by setting the JVM prop MILL_VERSION to the latest version on Maven, but I don't know if that has other consequences for Mill's correct functioning.
When the build.sc imported $ivy dependency, which is also dependency of modules, there would be no generated xml file for that dependency in .idea/libraries directory, and so intellij would not work with the dependency properly.
The text was updated successfully, but these errors were encountered: