To save me the trouble of actually trying to build a skinny JAR with pack and opening it up to look inside, does it add a manifest and, if so, what attributes are in it?

The mvn deploy:deploy-file can take a pom.xml externally to use. I guess it uploads separately. You could put it inside the jar by adding a mkdir extra && cp pom.xml extra/ then passing -e extra to pack when building.

I don't think things generally depend on the pom.xml being inside the jar though.

So... no manifest added nor needed?

And what is the difference between a "regular" skinny jar from pack and one that also has --no-libs?

@U04V70XH6 not inside the jar, nope. You do need a pom.xml, but it's generated out of band. I didn't actually check if it's in my jar, one sec, I will

No pom.xml in my jar. It runs fine.

I'm thinking back to the discussion/complaints about depstar not adding even a basic manifest into the uberjar (so you couldn't just java -jar it).

@U04V70XH6 That's a MANIFEST.MF, you can use the -e flag in pack to add it to your classpath at build time 🙂

It wasn't a big deal to add a minimal manifest with Main-Class but of course you don't actually need to -- you can just do java -cp ... clojure.main ... and run the JAR anyway.

@U04V70XH6 regarding --no-libs, the general idea of skinny jar mode is to produce something that's really cheap to rsync or something onto s3. So you generally output:

app.jar
lib/clojure-1.8.0.jar
lib/github-0.1.0.jar

Yeah, my point/question was "Does pack add a manifest by default?" and the answer seems to be "no" and, implied, does a library published to Clojars need a manifest and I think the answer is also "no".

Capsule/Onejar do add a manifest, because it's required for them to function. I'm not entirely happy with the process though. I think more could be done here, but there's nothing to drive change currently.

Ah, so "skinny" means no libs in the JAR but instead copy them to a lib/ folder?

@U04V70XH6 Yep!

In the future I might add a dedicated maven namespace to pack. I want to end up where you go via use-case rather than "underlying details". UberJAR complicates this a little, as there's choice.

Part of me is just contemplating what I might do with my fork of depstar -- to keep it as minimal as possible but open up the possibility of producing a thin JAR and being part of a workflow that could produce a pom.xml and mvn it up to Clojars... or another repo...