@witty-crayon-22786 no, the special flags don’t work with scala_library

@happy-kitchen-89482 is there some special reason not copying the jar to dist (say if user instructs to do so) ? Just want to get some context on the original design decision

It falls out of an unfortunate design decision in which jars of libraries are considered intermediate products, not final outputs (a "bundle", which may itself be a .jar file, is a final product, but requires a jvm_binary/jvm_app iirc)

oh I see

I agree with the first half, but I consider getting a jar into dist is a “publishing” process 😕

@happy-kitchen-89482 : i would be fine with allowing the binary goal to build an output binary for a scala_library. but i think part of the issue (even now) with doing that is that it breaks target globs in some cases. probably worth it, but

example:

say you have a project directory with a bunch of

jvm_binary

and

java_library

in it

I don't know that "output binary" is the right idiom, just a jar with no manifest would be something

./pants binary ${project}::

works to build all binaries that can be built

The context is my Jar is a lib that used by another system, which it is really a JAR without entry in the manifest However I bet I can build another binary goal to work around the current limitation

and I get a Jar

there is a difference between a jar distributed via ivy/maven with a version, and a monolithic deploy jar

@happy-kitchen-89482 : what do you mean by "with no manifest"? that would be monolithic then?

@witty-crayon-22786 agree, but I may alternatively consider publish to dist is a special case (or a sort of destination only support snapshot). Well maybe I am over simplified the situation 🙂

yep. and currently that requires defining a

jvm_binary

target. i agree with benjy that we could support building a deploy bundle for any target.

but there would be the slight tradeoff of losing the ability to use globs for things like that.

I think

./pants jar <library target>

should do something sensible, and I think most new users would expect that to be something like "create a jar of <library target> and all its deps, with no manifest"

It's a bit weird that right now it doesn't do anything useful to the end user

Agreed, it should not be exposed as a documented goal at this point.

You can

clean-all

then

./pants jar ...

and find:

$ tree .pants.d/jar/create/
.pants.d/jar/create/
└── 252d64521cf9
    ├── src.java.com.sun.tools.javac.api.api
    │   ├── 5c78e180e544
    │   │   └── api.jar
    │   └── current -> 5c78e180e544
    ├── src.java.org.pantsbuild.args4j.args4j
    │   ├── 3649d44e1ce2
    │   │   └── args4j.jar
    │   └── current -> 3649d44e1ce2
    ├── src.java.org.pantsbuild.junit.annotations.annotations
    │   ├── 94c1daade151
    │   │   └── annotations.jar
    │   └── current -> 94c1daade151
    ├── src.java.org.pantsbuild.testing.testing
    │   ├── 8bc92a4eec7c
    │   │   └── testing.jar
    │   └── current -> 8bc92a4eec7c
    ├── src.java.org.pantsbuild.tools.jar.jar
    │   ├── 012ebfce1e03
    │   │   └── jar.jar
    │   └── current -> 012ebfce1e03
    ├── src.java.org.pantsbuild.tools.junit.junit
    │   ├── 47e84656060d
    │   │   └── junit.jar
    │   └── current -> 47e84656060d
    ├── src.java.org.pantsbuild.tools.junit.withretry.withretry
    │   ├── 3ab833ffe2c1
    │   │   └── withretry.jar
    │   └── current -> 3ab833ffe2c1
    └── src.java.org.pantsbuild.tools.runner.runner-library
        ├── 84cd17ae0f83
        │   └── runner-library.jar
        └── current -> 84cd17ae0f83

25 directories, 8 files

But that's obviously way too low-level and is just a workaround.

The traditional logic here was that if you need to produce a jar, it can only be for a binary or for publish and re-use. If the latter, add a provides... to the target and do a local publish, where you can set the output path, then grab the jar and sneakernet.

@happy-kitchen-89482

binary

does what you suggest today

which I think makes more sense for '... and all its deps'

Fair

jar

could be ambiguous over whether all deps are included or if it's just the classes for the target you invoked on.

Agreed

But there should still be a way to do both without jumping through too many hoops

E.g., going through a publish

I guess, although I'd love to know the use case