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:
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 ?
I 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
want to support multiple operating systems and distributions, the
required effort will of course increase linearly.
But looking at other programming languages (Python, Ruby, Perl, Lua,
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..
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.