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