Hi,
On Fri, 2003-09-05 at 20:21, Jan Schulz wrote:
> Ok, I don't actually mind. The only real argument I have is that it
> looks better, if you have all requirements defined with comandline
> arguments, not environment variables. But ok... neither gij-3.0 nor
> gij-wrapper-3.0 have a -classpath option... What a --ing mess.
gij does come with a normal long-option --classpath. But as the gij help
output says: "Options can be specified with `-' or `--'."
> ant is IMO one of the important packages,
> which should be made working out of the box.
Have you looked at how the Red Hat people have done it in Rhug or Naoke?
http://sources.redhat.com/rhug/
http://people.redhat.com/gbenson/naoko/
> BTW: I think that ant in main will not work, when there is a javadoc
> task specified in the build.xml. Don't know if that counts as a RC
> bug...
>
> * Javac isn't a problem, as it uses Class.forName() for almost
> everything or simple assumes, that the binary is in the path. Can be
> made working with alternatives, by specifying a classpath wihich
> include the build.compiler.
Would it be a good idea to write a wrapper class that can be called by
the traditional Class.forName() contruct but that just invokes the
wanted compiler?
> * Almost all other tasks (cvs, zipper, etc) rely on the fact that the
> binary is in the path.
Which binary?
> * Javah relies on a special sun.com...javah.Main class. Doesn't matter..
gcj comes with gcjh which should be able to do everything javah does
(given the -jni flag).
> * some tasks rely on 'bin/java' or 'bin/jarsigner' in java.home
> or java.home/../ -> big problem, if that binary doesn't exist
I don't know of a free jarsigner compatible program. But as far as I
know most (all?) free core library implementations don't implement jar
verification at all.
> * javadoc relys on the fact that there is a 'bin/javadoc' in java.home
> or in java.home/../. -> big problem, if that binary doesn't exist.
gjdoc (which is packaged for Debian both as a traditional byte code
distribution as a normal application gjdoc-native) should be command
line compatible with javadoc.
> For the last two problems see the JavaEnvUtils class.
A quick look at that class suggests that it makes all kinds of
assumptions about what class availability says about versions and the
availability of other classes. It should probably be patched to test for
more features and make less assumptions of what is/isn't available.
> The problem is, that we can't really patch ant to use /usr/bin/ as a
> it also uses some specific tests (mainly, whether some classes are
> available in the Classpath) to determine, which version javadoc is and
> set special options wich only works with that version.
Why can't we patch ant to learn it about other javadoc like programs and
which options can be used with it?
> I have no idea, how we will work around this. There are several
> options, which come to mind:
>
> * Patch all VMs, so that java.home points to the right dir, which
> includes this commands in the right version (symlinks, Depends:).
Why should a VM provide all the applications? I know kaffe tries to do
this and to a lesser extend gcj comes with a couple of "standard" java
development tools. But most VMs can probably rely other free
implementations of these tools.
> * add a facade around every javadoc and java and submit a *big* patch
> to ant. Same idea as javac task. Cleanes sollution, but probably not
> manageable by debian-java.
Still this seems to be the solution to make Ant really work with other
free software solutions. It will be much work though and needs
cooperation with upstream to really work.
> * patch ant, to include /usr/bin in the search path for any command.
> Would also mean, that we have to patch ant so that it always results
> in a special interface (-> java Version) and make wrappers for the
> commands, so that they don't fail if that interface is used.
This might also work. But seeeing that the /usr/bin/java/javac wrappers
aren't that helpfull in practice I don't know if it will be more helpful
for the other applications.
> * patch ant, so that the algo for choosing a javadoc (and bin/java) is:
> return, as a last option, the debian javadoc in /usr/bin. Example:
> if (version == 1.4){
> return "/usr/bin/javadoc-1.4";
> else if (...) {...}
This again confuses the version number with the features a VM,
Classlibrary and the different tools offer.
> Oups, also not possible (all of this properties are used by ant...)
>
> --8<---------:- snip -:---------8<---------:- snip -:---------8<--
> [...]
> --8<---------:- snip -:---------8<---------:- snip -:---------8<--
>
> Can anyone test, what kaffe 1.1.1 sets as java.home?
For gcj. All system properties, their defaults and what they are used
for are described in the manual:
http://gcc.gnu.org/onlinedocs/gcj/System-properties.html
Cheers,
Mark
Attachment:
signature.asc
Description: This is a digitally signed message part