[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ant dependency on jython and antlr



Hallo Daniel,

* Daniel Bonniot wrote:
>>AFAIK the junit task is in the optional.jar.
>Agreed with that. The change concerned jython and antlr.

Ok, after some more thought I've finaly understood, why there were
'dangling symlinks'. The jython.jar had to be symlinked into
/usr/share/ant/libs too.

This will not happen anymore, if we could agree on the proposed
policy: You would just add a DEPENDS="..." line, which would give you
the jars via 'java-config --all ant' (omitting any package, which it
can't find). No symlinks nessesary. Tasks could actually be added via
a $HOME/.antrc file, giving the user the possibilty to choose from
different implementations.

>Regarding the symlinks, I think they rather belong to jyton and antlr, 
>as this makes sure they are not dangling. However I'm fine with the 
>original solution too (have them in ant). Dangling symlinks are not a 
>policy violation or

As said above: if we agree on java-config to sort out the CLASSPATH,
we don't need any symlinks anymore.

>>Anyway, the more I have to do with java packaging, the more braindead
>>it seems to me...
>Now, don't be pessimistic! There _has_ to be a way to do things right ;-)

Of course. But mostly it is something which the upstream author hasn't
even thought about. Just think about the whole 'not sun-derived' JVM
mess... For example the javadoc task, which is IMO a very essetial
task, will not work with pure 'main' packages). 

jan@snoopy:~/psgr$ /usr/lib/kaffe/bin/javadoc
java.lang.ClassNotFoundException: sun.tools.javadoc.Main
   at kaffe.lang.AppClassLoader.findClass (AppClassLoader.java:296)
   at java.lang.ClassLoader.loadClass (ClassLoader.java:142)

Or packaging all dependencies in one package, like most java apps do...

Jan
-- 
Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."



Reply to: