libxalan2-java to main - second take
Wolfgang Baer
WBaer@gmx.de
Sun Mar 20 05:21:04 2005
Hi all,
I spent friday night to bring libxalan2-java to main. I also updated
the MovingJavaToMain wiki page. If libxalan2-java is moved to main there
are only some uploads left to move tomcat4 to main.
I added the needed upload sequence of packages to main to the wiki.
Ok, now to libxalan2-java:
I achieved to build it with a combination of gij-3.4 for the compilation
(is old enougth to provide "only" DOM Level 2) and kaffe for the
documentation with a minor modification to the gjdoc startup script.
The problems left and to be discussed are:
The documentation is build with xalan (I do not mean the javadocs here)
and therefore fails in a chroot environment as I get GTK-Warning
errors, -Djava.awt.headless=true seems to have no effect.
I didn't find something in the policy which states that a package must
be buildable in a chroot environment. I do not know if therefore a
FTBS in a chroot is RC if it is buildable outside a chroot.
If it must be buildable in chroot environment, there would be the
(less preferable) possiblity to omit the documentation from the
libxalan2-java-doc packages except the javadocs. And later add them
back if the free vms are capable of using the -Djava.headless=true
property.
gjdoc needs some change in the startup script to pass needed java
vm options to the used vm. In this case I need to pass -xm256m to the
kaffe vm to not run out of memory. I think this could be solved easily
through allowing to pass vm arguments like:
exec ${JAVA} ${VM_ARGS or something} -classpath ${gjdocpath}
gnu.classpath.tools.gjdoc.Main ${1+"$@"}
What do you think, Michael ? Is this achievable - or any other ideas.
Currently gjdoc runs everytime with the default memory scheme of the
executing vm - this way we could influence the vm arguments parameters.
The other topic to discuss is - what about if gij-3.4 is removed from
debian after sarge. I don't think this will happen as gcc-2.95 is still
available in unstable. But if this will happen we need another way
to build libxalan2-java with free tools as otherwise we will have
to move a bunch of packages back to contrib.
I think we can believe that either of the following is true after sarge:
- gcj-3.4 will stay in debian
- one of the free vms implements -Djava.endorsed.dirs (gcj is working
on that already for the in this case needed w3c packages)
A new upstream release of xalan in the future will probably use the
DOM Level 3 interfaces already and therefore could be build with free
tools.
Comments or Suggestions ?
Regards,
Wolfgang