libxalan2-java to main - second take

Michael Koch konqueror@gmx.de
Mon Mar 21 03:47:08 2005


On Sun, Mar 20, 2005 at 01:19:17PM +0100, Wolfgang Baer wrote:
> 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.

Sounds like a bug somewhere. gjdoc had this behaviour under some
circumstances too.

> 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.

Please file a bug for this against gjdoc. This should be fixed upstream.
And this way it doesn't get forgotten.

> 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)

Afaik sabelvm supports java.endorsed.dirs already. Perhaps you can use
it to build the package.
 
> 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.

There were some talk about this lately. I dont remember where. probably
on GCJ irc channel or so. I will try to dig up a solution for us.


Michael
-- 
Java Trap: http://www.gnu.org/philosophy/java-trap.html