Hi, While testing ant and jdk plugins, I noticed a couple of things; this bug to discuss the best resolution. First, I was surprized by a "jdk" plugin; I actually thought the plugin would be "jre" because I thought it was just embedding a java runtime. But then I noticed that "ant" wasn't working on my system, compilation would fail with missing javac classes. This is because the ant Ubuntu package doesn't pull a JDK but only a JRE. Yet, ant was run successfully during a snapcraft build. This is because ant was being run with the java runtime pulled by the jdk plugin (from the snap). I found this surprizing, I was actually expecting the ant package would be used on my system against the java runtime on my system, but I can see how there are pros and cons to using system java vs. snap's java. Pros of using system jdk to run ant and embedding a jre package in the snap: - smaller runtime -- the current approach still ends up embedding a bunch of lib_.a files, lib_.so (including X.org libs) - feels more natural (to me) Cons: - ant doesn't pull a jdk by default - more complex to digest (more plugins) Pros of using snap's jdk to run ant: - less copies of java around -- no discrepancies, perhaps less waster space (not sure) - less plugins To make the matter more complex, I believe we should have multiple architecture in mind. This problem will get worse when we're considering building packages across architectures and/or for multiple architectures. This is actually quite common in the "develop on x86-64 Ubuntu desktop, deploy on ARM board" scenario. This last topic is actually what convinces me we should go for using the system JDK to run ant rather than the snap's JDK. This makes the snap less easily bloated with JDK bits (we could offer regular vs. -headless jre as an option to make this even smaller), and means we dont need to worry about cross-architecture. It's even relatively easy to support multiple architectures if we stop relying on default-java and rather use java-7-openjdk-amd64 and such. (BTW, we seem to pull Recommends; it's not clear whether it's a good default given these are usually not pulled when building .deb packages) Hence, I propose we: - change the ant plugin to pull the default-jdk package (on top of the ant package) -- this kind of feels like a workaround for the package not pulling the jdk by default which is either a bug or just a packaging opinion that "ant can be used for anything, not necessarily building java sources" - rename the jdk plugin to jre -- possibly ubuntu-jre or openjdk-jre, allowing for oracle-jre and similar, but I find the long names look ugly (- add an option to select the headless JRE) - differentiate between build and runtime envs But happy to read other opinions! Cheers, Launchpad Details: [#LP1477745](https://bugs.launchpad.net/bugs/1477745) Loïc Minier - 2015-07-23 16:49:43 -0300