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