https://pantsbuild.org/ logo
Powered by
#general
  • e

    enough-analyst-54434

    03/16/2017, 8:48 PM
    Not a great mantra if your small and moving fast I'm sure
  • s

    salmon-fish-51828

    03/16/2017, 8:49 PM
    Basically the freeze policy is such that only bug fixes would be allowed and people wouldn't be able to develop on a branch.
  • e

    enough-sundown-78166

    03/16/2017, 8:51 PM
    I'm wondering if someone could weigh in on best practices for organizing java projects. Do you have separate top-level directories for each project and then 
    src/main/...
    and 
    src/test/...
    underneath those? Or does it tend to work better to have just one 
    src/
    directory and branch out based on package beneath that?
  • e

    enough-sundown-78166

    03/16/2017, 8:52 PM
    We're mostly working with separate top-level project directories now and it feels a bit clunky
  • e

    enough-analyst-54434

    03/16/2017, 8:52 PM
    One fact to mix in is using a single dir tree physically prevents dup class names
  • e

    enough-analyst-54434

    03/16/2017, 8:52 PM
    I've seen several dups in maven multi-project style layouts
  • e

    enough-sundown-78166

    03/16/2017, 8:52 PM
    yeah, easy to do
  • e

    enough-sundown-78166

    03/16/2017, 8:54 PM
    if you have one src directory, then main and test directories under that, then it seems like it would further separate the main and test code. Is that actually a problem is your experience?
  • e

    enough-analyst-54434

    03/16/2017, 8:56 PM
    No, that works well in my experience. The only odd corner is what to do with shared test support code.
  • e

    enough-analyst-54434

    03/16/2017, 8:57 PM
    One standard is to append testing to the package and put it up in src/main
  • e

    enough-analyst-54434

    03/16/2017, 8:58 PM
    Idea being, test target should never depend on other test targets - just the unit they test up in the production code.
  • e

    enough-sundown-78166

    03/16/2017, 9:00 PM
    hmm, so for a given package 
    com.foo.bar
    , you'd also have a corresponding test package at 
    com.foo.bar.test
    ?
  • e

    enough-sundown-78166

    03/16/2017, 9:01 PM
    and just have a single src/java directory?
  • e

    enough-analyst-54434

    03/16/2017, 9:01 PM
    No, this is only for test support code, say com.foo.db.testing.DbTestHelper
  • e

    enough-sundown-78166

    03/16/2017, 9:01 PM
    ahhhh, i get it
  • e

    enough-sundown-78166

    03/16/2017, 9:01 PM
    ok, makes sense
  • e

    enough-analyst-54434

    03/16/2017, 9:02 PM
    And code used by many test packages in addition - ie: shared
  • e

    enough-analyst-54434

    03/16/2017, 9:02 PM
    Arbitrary convention, plenty would work
  • e

    enough-sundown-78166

    03/16/2017, 9:03 PM
    that's actually where I'm feeling it's awkward right now, is test support code. Currently, I'm creating another top-level project with test utils in it, and it just feels wrong
    p
    • 2
    • 1
  • e

    enough-analyst-54434

    03/16/2017, 9:05 PM
    Yeah, so maybe you like src/main/com/foo/db/testing/BUILD - maybe not, its one way to go that's fairly lightweight
  • s

    salmon-fish-51828

    03/16/2017, 9:06 PM
    You guys were very helpful. Thanks for taking time out to talk. I know this is not a mono-repo room but 'pants build tool' room so I'm wondering if there is any other place where one can talk about monorepos? If I have any questions in future, maybe it would be a more appropriate set of people to chew ears off of. Thanks nhoward_tw, toddgardner and john.sirois.
  • s

    salmon-fish-51828

    03/16/2017, 9:19 PM
    Actually one more question if you guys would care to comment- i'm assuming you guys use sbt. How do you keep a single scala version across all your projects (if you do)? I'm not a fan of repeating scalaVersion := "x" in all the 
    build.sbt
    files. And of course I'd ideally like a single version for packages too (which I can do in global.sbt to an extent. Is that wrong to do?
  • s

    salmon-fish-51828

    03/16/2017, 9:20 PM
    I have to say, we don't have any experience with mono-repos. We're only sold on the philosophy and the technical skills are not there yet.
  • w

    witty-crayon-22786

    03/16/2017, 9:21 PM
    we stopped using sbt ~5 years ago
  • w

    witty-crayon-22786

    03/16/2017, 9:22 PM
    but when we did use it, we had a common Project superclass that most projects inherited from
  • w

    witty-crayon-22786

    03/16/2017, 9:22 PM
    same strategy for maven
  • w

    witty-crayon-22786

    03/16/2017, 9:22 PM
    in a pants repo, it's all just configured once in 
    pants.ini
    .
  • s

    salmon-fish-51828

    03/16/2017, 9:23 PM
    @witty-crayon-22786 I'm not flaming here but sbt is so so so much more than dependency management that I don't see how it can be replaced
  • s

    salmon-fish-51828

    03/16/2017, 9:24 PM
    Never mind, that didn't add to the discussion
  • s

    salmon-fish-51828

    03/16/2017, 9:24 PM
    so you guys do just pants right now?
1...166716681669...2420Latest