Any ideas on building a JVM JAR file with only the...
# general
w
Any ideas on building a JVM JAR file with only the compiled classes code but without the 3rd party dependencies? The situation I’m trying to deal here is some dependencies on Akka, since each Akka JAR file has a
reference.conf
file at the top-level, when trying to pack the code that needs Akka using
deploy_jar
we get file colissions (as it finds the same file name more than once). So this either requires having a target that allows to package a thin jar, or use something similar to what SBT does (in
sbt-assembly
) by having Merge strategies, not sure if anyone here has thought on other ways of solving this.
f
also WAR file support was merged earlier in the week (
jvm_war
target type). dependencies in the WAR are not unpacked so no collisions would occur from an unpacking.
(will be available in 2.11)
w
both options sound like a possible way forward. I guess the one from John is from v1
the WAR gets close, but it's a runnable JAR what I’m thinking of. More like just contents of the WEB-INF/classes folder from the WAR
but I guess that we could use auxiliary scripts to unpack the WAR and grab what we need from it.
f
we already produce a thin jar for first-party classfiles that is included in the WAR
not much work from there to have that available as a target type
mainly just a user-visible way to access what the Pants Java backend is already doing
the WAR gets close, but it’s a runnable JAR what I’m thinking of. More like just contents of the WEB-INF/classes folder from the WAR
do you still want third-party jars unpacked in this runnable jar?
or just the thin jar with first-party classfiles?
w
so, it’s either a fat jar with some options for rules to merge files when collisions show ups (due to the Akka jars all having a
reference.conf
file. Or a thin runnable jar with only 1st class compiled classes.
in the case of the latter we still will need to collect the thin jars transitive deps, but that is sort of easy to get
and well, a WAR is somehow both things
we just would need to mangle it into our own layou
f
so, it’s either a fat jar with some options for rules to merge files when collisions show ups (due to the Akka jars all having a 
reference.conf
 file. Or a thin runnable jar with only 1st class compiled classes.
we would need to port the merging code from Pants v1 into v2
not sure how much work that would be, but worth an issue to evaluate
also as an FYI on the WAR emitted by Pants,
WEB-INF/classes
will be empty as first-party classfiles are emitted as their thin jars in
WEB-INF/lib
alongside third-party jars
w
ah ok, guess that particularity with the WAR files is not a big deal, as that still gives a valid classpath
f
yup that was my thought when I implemented it that way. saved me from having to write code to figure out which
ClasspathEntry
instances where first-party or third-party.