<@UD0KF4HAB> we are doing a similar migration on a...
# general
@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 !
🔥 4
@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.
@brief-engineer-67497 - did you change directory structure from standard sbt/maven structure to default pants structure along the way?
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 ^_^
be carefull, if you are using resources, there might be a gotcha: https://github.com/pantsbuild/pants/blob/master/src/python/pants/source/source_root.py#L173
in my pants.ini I added
Copy code
#unmatched: fail
lang_canonicalizations: {
    'jvm': ('java', 'scala', ''),
    'protobuf': ('proto', ),
    'py': ('python',),
    'golang': ('go',),
    'resources': ('resources', '',),
source_root_patterns: +[
test_root_patterns: +[
our resources are all under ‘src/main/resources’ or ‘src/test/resources’
exactly, you'll probably need this bit of conf
is a default source_root_patterns and pants build its root by appending source_root to language, hence the "resources" languages to let him find the
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
I think it's because scala is pretty liberal with regards to where the sources belong
but I hit a wall when resources were not found
ha you mean with sbt ?
you add
to your project definition
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
yes he confirmed
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.
re: integration tests in IJ - Thanks, I’ll have to revisit that at some point.
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 :
Copy code
            excludes = [
            ]), # see <http://stackoverflow.com/a/36226800/1992669>
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
(this is just me being defensive though, not contradicting any of the above)