nOn 12-03-23 05:41 AM, Matthias-Christian Ott wrote:
On Fri, Mar 23, 2012 at 08:06:25AM -0400, Barry Hawkins wrote:On 3/23/12 6:47 AM, Matthias-Christian Ott wrote:Hi, I have been assigned to a legacy Java project, which uses several messed up Ant buildfiles. I'm going to replace or clean up the build system as part of project maintainance. I read that Maven (similar to other language-specific package management software) has been a problem for Debian for a long time and that Debian struggles with the general Java software packaging mentality which often ignores system wide package managers. One of the goals for the project is to make software packaging and distribution easier and automatic. Gentoo and Fedora seem to support Maven and Ant, but prefer Ant. Is that also true for Debian? If so, are there any preferred build target naming conventions, like [1]? Regards, Matthias-Christian [1] https://wiki.apache.org/ant/TheElementsOfAntStyleI can tell you that of all the projects I have worked with for years and all those my friends work with, I have yet to find anyone who uses the Maven that is packaged with a distribution. The common practice is to have Ant + Ivy, Maven, or Gradle + Ivy using a repository outside the OS package management system's own packages. Coupling a Java project to using the Java libraries packaged with the current version of your operating system's offerings is generally avoided, as you invariably need a library or a version of a library that is not available.This practice seems to be widespread, but I wonder what you do about security updates then. GNU/Linux distributions seem to either have enough man power and an organizational structure to do proper security updates or do rolling releases. If you hardcode the versions you can't do the later and it seems security updates aren't offered in the common Maven repositories. Thats not true at all. New versions get into the repositories all the time and you just upgrade the version and release a new build. You control it all rather than the distro that might have no idea about your application and therefore no idea if a different version of a library actually works. If you use Debian stable you have a long enough update cycle including security updates, so that should work once you packaged all your dependencies (the project I'm working on the dependency management consists putting years-old JAR files, some with unknown licensing status and origin, in directory). In the maven world you use a repository manager for all that during build time and you then ship the libraries as part of your software.. giving you complete control. Also the update cycle of Debian (or pretty much any distro actually) is way to slow and also too much out of reach to be able to control of the application developer to be able to control it in terms of QA cycle and much more.. If you want to support multiple operating systems and distributions, the required effort will of course increase linearly. Yes.. true.. But looking at other programming languages (Python, Ruby, Perl, Lua, Haskell, _javascript_ etc.) these language-specific package managers seem to become some kind of a problem, because many people seem to care less about system wide package managers (perhaps because they don't have one, as with Windows and Mac OS X) and about the operating system and the installed software as an integrated whole. The problem is that system wide package manager are better but e.g. in the case of Maven often go against the ideas and work that upstream is doing and that can cause a big culture clash.. e.g. read for http://discursive.com/2012/03/15/the-debian-java-package-team-futility-defined/ or http://kohsuke.org/2012/03/16/debian-and-maven-a-crash-of-culture/ It applies to me too.. e.g. I use Maven commercially and train on it and I can not recommend the Debian packages because they are too divergent from upstream and actually break default Maven behaviour and make it impossible to support a Maven build across operating system because the Debian package is just too different. I understand the conundrum that applies to Debian in the sense that it needs to build from source and be offline.. but more and more that is unrealistic imho. It might be a great idea to provide a Maven package that is completely compatible as an alternative to the Debian internal one in some outside repo. Manfred http://simpligility.com |