@chilly-librarian-83669 we are doing a similar migration on a similar number of sbt project. For a bit of context we were in a multi-repo setup. It was a publish-local nightmare. Then we tried a mix of nix and sbt that brought us in a mono-repo. It was a slowness nightmare. Now we are migrating to pants. I've worked almost alone on this the 6 past weeks. The sbt plugins, some code gen of our own and some legacy aspectj is the part that takes time to migrate. Some gotcha along the way (like the sources root directories, how come a build file is not the marker for this ??) Other than that, using pants is a pure bliss ! very happy with it so far !

@brief-engineer-67497 It sounds like we are following along the same road. At first it was bliss moving from multi-repo to mono-repo. We were actually able to refactor framework code. But then we hit a tipping point on the size and sbt and especially IJ synch from IJ speed made any build changes very time consuming and costly.

not right now, as long as we have not migrated everything we still have the two build systems that are running. but once we'll be using only pants, there will definitely be some (minor) changes

Thanks, that was the only way I could imagine a migration running in parallel with the old tooling.

you're welcome ^_^

our resources are all under ‘src/main/resources’ or ‘src/test/resources’

exactly, you'll probably need this bit of conf

how did you make ‘it’ (integration tests) work with IntelliJ - AFAICT, it only supports two class paths - main and test

and the empty string to be concatenated with conf

sbt is happy to add an integration test scope and run integration tests as a target. But IntelliJ can’t run them from the IDE.

hmmm I'm not sure I ever runned them from the IDE …

because IJ doesn’t really support maven-style scopes. My developers didn’t want to give up one-click debugging of integration tests from IJ.

on the other hand I have a colleague who launches everything from intellij and I'm pretty sure it worked for him out of the box with this setup

we have a lot of hand-crafted dependency exclusions and overrides in our sbt build in order to manage conflicts. Have you the same, and if so, how are you managing in pants? One more tour through classpath hell and I may just go the twitter-style unmanaged dependency route.

we some dependency exclusion but not that much, most of the time I just oxclude the transitive dependency in the pants declaration and once I used this :

jar_library(
    name='core',
    jars=[
        jar(
            org='org.hibernate',
            name='hibernate-core',
            rev='5.2.6.Final',
            excludes = [
                exclude('dom4j','dom4j')
            ]), # see <http://stackoverflow.com/a/36226800/1992669>
        jar(
            org='dom4j',
            name='dom4j',
            rev='1.6',
        )
    ],
)

perfect - that mirrors most of my exclusion patterns

intellij requires source root patterns to be respected in order to work, much more so than pants itself, which for source files allows you to stick things pretty much wherever you want, which is half of why i like pants (except apparently with respect to resources, someone here was running into that last week) -- we have some documentation on how intellij wants code to be laid out + some other intellij gotchas internally that might be useful to open source if it's not already, i would need to look at it again