so that is exactly what we use internally at twitter in the monorepo (we support the pants intellij plugin as well), so it's actually a little frustrating to me that we don't have an example of a nontrivial jvm project externally that you can base off of. there may be more nontrivial open source codebases using pants in the next several months -- twitter open source is working very hard on alignment for documentation and build tooling for our open source projects, but this process is taking some time as it is mostly me and a few others on the implementation side. i've been working with someone else on a monorepo of twitter open source projects using pants, which i think would be fantastic for this exact use case, and your case might be a way i can convince others that this is significant. but right now it looks like the lack of any nontrivial examples is a pretty glaring difficulty for people who want to try using pants, along with, on the pants side, the lack of an open source implementation of the pants remote buildcache (this is another hidden difficulty we really need to rectify). the monorepo idea would likely use the BUILD files that are already in our big jvm open source projects like finatra and finagle to build them with pants (very unfortunately these BUILD files need some editing to work outside of our internal monorepo) -- but i also have experimented personally with a very simple wrapper for exposing sbt projects to pants, which could allow for incremental migration as in your case (i'm not sure if that would be useful or desired, but 70 projects sounds big enough). i can't give you a timeline for any of that right now. i can tell you that we do support pretty large builds using the intellij plugin with pants internally (and people are able to do e.g.

./pants idea-plugin some-big-project::

, which imports everything in that subdirectory, without too much difficulty, although the import itself still takes some time -- a BSP implementation may help to address this). so i'm not concerned that we really need to build a ton of extra infra to support your use case, just putting together what we do have already. i can also tell you that the pants we use internally is the same pants we release externally, with lots of

pants-plugins/

in the monorepo for our internal use cases. as i'm typing this out i'm realizing all of this actually fits together pretty effectively and i'm going to make an issue and/or a project on the pantsbuild/pants repo to track the blockers to pants adoption for largish jvm projects, especially existing sbt projects. i'm very sorry for the longish message, i wanted to say it out loud -- will be dumping this into an issue.