@cuddly-garage-87447 If you are asking for opinions here, you are probably going to mostly hear, "put everything in one repo." That's what Pants was designed for.

Yep, read that already 🙂

Opinions pertaining to that particular situation would be great. I understand that pants developers would argue for a company-wide mono-repo, but perhaps would advise against team-wide mono-repo, for reasons that I cannot foresee with my limited knowledge.

My understanding from that google article is that it takes a decent amount of resources to make mono-repos work at scale. We don't have those resources, but on the other hand we're not aiming at that scale (at least not in the foreseeable future).

Maybe a more specific question: how hard is it to change CI/CD (jenkins) pipelines designed for multi-repos? I couldn't find that answer after some googling.

thanks for all the help tom + john. this might be a little out of scope of pants in particular, but assume i'm a complete rube when it comes to deploying java packages. i have a complicated service binary that depends on a bunch of 3rdparty jars. i would like to put this on a *nix server somewhere and run it. is the best practices to use

jvm_app

, bundle it all as a jar with other jars inside it, and deploy that to my servers?

in pants lingo: this is a

deployjar

, correct?

i think my brain is having a hard time understanding binaries, vs bundles, vs deployjars

@cuddly-garage-87447 the problem is that sharing binary artifacts between repos can be a nightmare. If you do this, I would recommend you find a way so that the relationship always goes in one direction, repo a always consumes artifacts from repo b and not vice versa.

Can anyone else run this command in their pants workspace (on master):

./pants idea src:: tests:: examples:: testprojects::  --exclude-target-regexp=testprojects/src/java/org/pantsbuild/testproject/targetlevels/unspecified

I'm getting:

Exception message: Already defined module IvyModuleRef(jersey:jersey:latest.integration:sources:jar), as rev 0.7-ea!

trying to debug it now.

zundel I get the same error

@fast-megabyte-33579 thanks for confirming

hmm i did a cache less build with

default_platform=java8

, it seems fine tho https://rbcommons.com/s/twitter/r/4320/file/14139/

Looks like that error is a known issue - the offending target is excluded. I've fixed up the failing test now

@thankful-library-32113 At 4sq, we have - a scala_library that holds the service code and resources as dependencies. - a jvm_binary that depends on that library, any runtime deps, and sets the main - a jvm_app that has one dependency - the above jvm_binary. We have some internal tasks that bundle loose resources, but that is not quite best practice and is something we are close to removing. By default running `bundle `on a jvm_app creates a "slim jar" instead of a deployjar. 🙂 With a slim jar, your $service jar would be empty except for a classpath, and all the dependencies (including the resources) are jars found under

libs

. If you prefer a "fatjar" you can set an 'archive' in the jvm_app BUILD file and it will create one for you (grep

Archive.TYPE_NAMES

for allowable archives)

@limited-country-20626 : xx: to get a fatjar, you'd set

jvm_app(.., deployjar=True)

the

archive

is an outer wrapper around the result

well - there is the actual API then : ) we don't have this set anywhere, although I thought I remembered archive implying deployjar from the bundle_create CRs.

it doesn't. if you don't specify archive, you just get loose directories and jars under

dist

archive

takes the result (be it a fatjar because

deployjar=True

, or a series of jars because

deployjar=False

) and wraps it up in a zip/tar/etc under

dist

got it; are

deployjars

runnable via

java -jar

, or do i also have to do special things to mess with a classpath?

ah, okay. So you could use it to turn a fatjar into a different archive type.

@thankful-library-32113 : in both cases (deployjar=True/False) the result is runnable with

java -jar

@limited-country-20626 : no: just a wrapper. inside the wrapper will still be a (fat)jar

@thankful-library-32113 : a fatjar is inherently

java -jar

runnable, because there is only one

does

java -jar

know about the lib folder, and will put it on the classpath automatically? in the case where i don't make it a deployjar

a non-fatjar uses a manifest that refers (relatively) to the libs directory

oh

got it