Hi Java Team: The following is my recollection and impressions (before they fade away completely) from both the Java Team BoF that took place on at DC14 on August 25th and subsequent informal discussions. It is not meant to be a comprehensive set of notes (and thus may biased towards what I recall from the session). I am posting them here to initiate conversation and welcome comments and corrections of any omissions of topic, attribution or other misrepresentations. First off, thank you to Matthew Vernon for scheduling and conducting the BoF. We started with this list of topics:
* Maven / dependency hell / build system * Java 8 transition * Tomcat * Getting more contributors * Old/crufty packages Library/application packaging: Matthew Vernon gave an overview of the Java library dependency hell and the problems it creates for Debian, and there was discussion about the mismatch between upstream (build each application against a specific version and bundle the JARs with the app) and Debian's view of the world (system-level libraries shared). The general consensus seems to be that (a) we're not going to be able affect immediate change in the upstream culture with respect to ABI versioning and library bundling; but (b) current policy acts as a disincentive to application developers who have to package N (for large values of N) build-deps to provide their software to Debian. Keith Packard proposed that we allow applications depending on unpackaged leaf libraries to bundle the library source and build those JARs during the package build process. Packages still require full source and to be built from that source; that is, no JARs may included in the source package, but the package build system may create runtime dependency JARs. Those leaf library JAR(s) would then be be installed beneath /usr/share/$application/; by policy, they must not appear in /usr/share/java/. This approach carries the risk of duplicate copies of libraries and the accompanying security concerns. The preferred mechanism is still to distribute system-level libraries in their own package. This "bundle of leaves" approach should be used sparingly to facilitate introducing Java applications to Debian. This would require a policy change. Reproducible builds: There is interest in having reproducible builds of JARs (timestamps are a problem - perhaps other attributes as well?). There will be some hacking in this area; the team will then assess integrating this into our packaging toolchain. Java 8 Transition: *Speaking only for myself only*, I don't anticipate that the Java8 transition will be completed before the jessie freeze and believe that the right course of action for our users to plan for openjdk-7 in jessie and then target openjdk-8 to migrate to testing as soon as possible after the freeze. (We could provide openjdk-8 to users via backports.) I understand this may be contentious; let's discuss. Sustainability/Maintainability: I made a strawman statement about whether we might consider paring down Java within Debian to just a JDK and a few core packages (e.g. tomcat and related). This was intended to encourage discussion and to consider what that would mean. There is no serious proposal to change the current course of action, and despite phrases like "dependency hell," the Java Team is a fun and rewarding place to contribute. We could use more resources, and we welcome new members! Tomcat version for jessie: In a subsequent conversation, Miguel and I discussed targeting tomcat8 for jessie and removing tomcat6 and tomcat7 binary packages from the archive. If there are objections to this plan, please speak up. tomcat8 will probably end up with a couple extra binary/transitional packages, and thus will have go through NEW again. Old/crufty packages: Based on an email exchange with Emmanuel, I shared with the group that despite me putting it on the agenda, the Java Team does not propose to pro-actively remove packages currently in the archive unless they are unpopular leaf packages that become problematic (e.g. RC-buggy). Everything else: There are certainly topics discussed and good points made that I haven't captured here (only because I can't remember them). Please fill in the gaps and continue the discussion. Thank you, tony Additional session during DC14: For those present at DC14, I am going to look for another slot that won't conflict with any of the scheduled sessions. Detail will be sent to the debconf-discuss list once I have a time and a synopsis will be sent to debian-java.
signature.asc
Description: OpenPGP digital signature