Re: [PROPOSAL] dh_ant
Jan Schulz wrote:
I don't agree, at least until this can also be done with packages,
where I have to call differnt targets, install difeferently and so on.
You can do this, just add the additional required commands to the
corresponding targets in debian/rules, like I did in doc++:
--- cut here ---
build/doc++::
cd doc/manual && $(MAKE) html ps
clean::
rm -f po/*.gmo
--- cut here ---
This is nice, if you have a build.xml, which fits into debian
environments. Unfortunatelly this is hardly the case (think: ant isn't
tailored to linux as configure and make are).
You just have to write a little bit more into debian/rules, the core Ant
class just calls one Ant target for the build and install step.
You don't have to use CBDS if you don't want to (like you don't have to
use debhelper) - it's just there to simplify the standard cases. You can
even use the proposed dh_ant with CDBS if you want to. I will not make a
Java Policy proposal for CDBS, I'll just use it in my packages. :-)
Please start something mroe lowlevel, which will save work in *most*
packages. I really like the idea of dh_ant, which handles Classpath,
buildfiles, properties and output.
It is low level, basically everything can be extended. Please take a
look at the examples at
http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/cdbs/examples/?cvsroot=build-common
Please give me an example of what dh_ant should do (e.g. how will it
handle the class path?) and how debian/rules would look like if it uses
dh_ant.
I wouldn't mind if that would be done in a
(package|jar-SONAME).javalibs file and deployed with the jar, so that
we could build a common starter file, which could manage the CLASSPATH
automagically.
Currently most Java packages are libraries, we only have a couple of
application that need to set the class path in a starter script. I see
no big difference between *.javalibs and symlinks in
/usr/share/.../lib/, e.g. like it's done in Ant or Tomcat.
Stefan
Reply to: