Caveat: I’m a boot newbie. I’m trying to create a build.boot file so I can build a number of jar files (~5), with identical dependencies, but different :main classes. I started with the basic pattern of (sift) (aot) (uber), but I can’t naively follow this with multiple (jar :file X :main Y) statements (well I can, but the non-first jars are bloated) . Can someone point me to an example of generating multiple jar files in a case like this?

@dan551 can all the classes be in all the jars and they just differ by entrypoint? or do you actually need to sift things out before jar-ing

@alandipert Yes, all the classes can be in all the jars and they just differ by entrypoint. (Although the 5 top-level entry point classes/files are orthogonal to each other, i.e., they don’t need to be in the other jar files).

@dan551 are the class names provided by the user at build time? or can you code them into your build.boot

@alandipert: yes, I could put them in my build.boot. So, my naive option is to include 5 build-jar-N deftasks, each generating fileN.jar files (but I’d have to copy each of the jar files out of the target directory prior to invoking the next build-jar-N)

@dan551 here's how i would do it: https://gist.github.com/alandipert/3d53a625d95eb8edd30f31603008d851

actually, 1 second, needs elaboration 😄

@dan551 ok, here's a recipe - that got involved quickly https://gist.github.com/alandipert/3d53a625d95eb8edd30f31603008d851

the problem with stacking jar tasks is we don't want previous jars created in the pipeline to end up in subsequent jars

so the "solution" there is to maintain a history stack of filesets. it's a means to forking the pipeline

wow, nevermind x2, that's crazy overkill. you can just sift out main1.jar instead of saving the fileset

@alandipert: Thanks, I’ll try the sift approach