Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Dalibor,
* Dalibor Topic wrote:
>> :) This discussion is nothing against being 'Proponent' of a new
>> german newsgroup...
>ouch, i sense frustration ;)
It started by a 'Request for Discussion (RfD)' to split the
de.*.StarOffice group and ended in a 905 messages (groups.google) long
discussion. The first message was in the beginning of april 2002 and
the grops were created in the end of september 2002. Very fortunatelly
I wasn't able to be the 'official' proponent (I can find 180 Postings
just under one email address from her...).
And that apaart from the fact that she tried to keep the discussion
'technical' as well... I think she will never again touch
de.admin.news.groups...
That's where I learned never to start or reply to a flame war... ;)
>> [free, but not full featured]
[adding API classes to Classpath]
Sounds easy. Lets see... Its exams and other problems until
November...
>> * makes all our packages working with every JVM, which will run it:
>> . free ones
>> . unfree ones by a well defined API and a installer script
>that's a great goal. it needs people who test & build java programs on debian
>on every java implementation in debian. I believe some of that could be
>actually done automatically, like the buildd setup for normal packages.
[nice idea about a buildd like infrastruckture to test, whether it
works on free VMs as well]
Everything IMO and AFAIK: This can't be done, as the debian all
Dependencies Information is calculated by the maintainer in
debian/control or at buildtime by certain skripts in the
<package>/debian/rules makefile (currently not possible for java).
The ready build package go then into the archive. You would have to
setup a server 'inbetween' and thats just one of the steps.
You would have to parse all this scripts (nearly impossible) or make
the package maintainer to setup his package in a way, so that it can
be done (for example set certain variables/ant properties in a way,
that it is easily changeable from outside). The CDBS (Common Debian
Build System, someting new to use in debian package building) java
classes may help with that.
This classes start at ant level, so you would have to integrate all
free VMs to work with ant -> again, we need a interface like we are
currently discussing.
Or you will have the DD make all the changes and testing with each VM,
whether it builds. This will also make a lot easier, when we have a
interface to the unfree VMs, 'which works', so that he can concentrate
on the free ones, which will possible need work to make working.
All in all, I think we first need a better working policy, before we
could start thinking about such a project.
I also think that this can only added 'next to' the packaging system,
maybe sending the apropiated BTS mails ('Wishlist: Your package is compiling
with XYZ now' 'Grave: Kaffe will not build 'XYZ' anymore'). Again,
this needs well defiend interfaces so that this here is not anymore
nessesary:
in debian/rules
|JAVA_HOME_DIRS="..."
CDBS, ant classes:
JAVA_HOME = $(shell for jh in $(JAVA_HOME_DIRS); do if [ -d "$$jh" ]; \
then echo $${jh}; exit 0; fi; done)
This is basicly the workaround in every java package I've seen so far.
In eclipse debian/rules, I've a similar line in (but I Build-Depend on
BD Java) and its repeated in /usr/bin/eclipse [1]. It only works
with BD packages, as we know the place, where they are added. Free VMs
would need to be complient to JAVA_HOME use (gcj isn't...), work with
ant (Kaffe? Sable VM?).
[1] with the fallback on /usr/bin/java, which may or may not work with
eclipse, due to the fact, that /usr/bin/java has no way to check,
whether this a eclipse 'complient' (API and Comandline) java virtual
maschine.
=> Great mess.
I've leftout packaging requirements in my Proposal as I haven't
thought about that at all...
>that would be a *great* way for debian to help free java efforts by providing
>efficient regression testing on what will be tons of java apps in debian.
Maybe it is possible to do such a thing apart from the package
management. The CDBS ant classes may be a big step in this direction.
>noble goal, but as I explained in the other mail, there are
>differences in the behaviour that some java/javac implements. Some of
>it is intentional.
BTW, does kaffe support '-cp'? I just had a bugreport about this
(actually that eclipse "does not work" because it fell back to
/usr/bin/java, which was kaffe)
It seems that the kaffe 1.0.7 does not understand '-cp', which would
mean, that I would have to patch eclipse to use '-classpath' instead
of '-cp' (not a big deal, as I don't use the binary starter
anymore... <g>)
BTW, javac 1.4.2 added that option as well...
>You could agree on a common basic synopsis for
>javac, like -d , -classspath and providing all the required sources on
>the command line. Same for the java executable.
This could be a way. It would blow up policy even more... Java Policy
requires already, that /usr/bin/java has the rt.jar on its
bootclasspath, so IMO kaffe was not policy conform until 1.1.1.
BTW, how does this work with all the different editors? Or is less
just so inteligent to know how it has to start jed/vi/pico, so that
$EDITOR is in the right line?
>I think we have some linguistic confusion here ;) What I mean is, that
>you take a program that walks over rt.jar and lists all the available
>classes, field, methods, etc. into a plain text file A. That's what I
>call the API information of a particular VM. Then you take another
>program that walks over an application's jars and classes and lists
>all reqired system (i.e. java.* , javax.*, org.w3c.*, etc.)
>classes,methods and fields, into another text file B. Then apt needs
>to determine whether textfile B is contained in textfile A.
APT only knows about the information in debian/control (or
DEBIAN/control IIRC). And Apt would let 'VM A provides API_A, VM B
provides API_B, APP C Depends API_A, API_B' pass, until VM A conflicts
VM B (which is something no java app developer will like).
>Though, now I think the java build demon aproach is better, as it
>actively figures out what works and what doesn't instead of relying on
>API descriptions.
The Mainatainer of the package will be the "Java Build Demon". :/
Hopefully helped by as much policy and helper scripts as possible...
>> First of all, it will work with packages like xerces, which already
>> now can be updated 'endorsed dir' or so, or simple adding a newer
>> version to bootclasspath.
>fine, but for example you can't put xerces into kaffe's bootclasspath as its
>licensed under GPL-incompatible ASF license.
Not even with a java -bootclasspath `getclasspath --boot` -cp ... at
packaging level (by Depending on the debian xerces package)?
If thats not possible, I simple give up... :(
>while they are boostrapping the build, they generate some code using java, xml
>and a lot of magic. ^^^^^^^^^^^^^^^^^
C(++) code? Oh my god...
>the second use for java is that you can apparently embed
>applets into html pages created by open office.
Both, applets in webpage and SO/OOo generated HTML, is bad, so I don't
care if that wouldn't work...
>and finally, uno, their component architecture, uses java.
hack/kick it out of the build...
>Eclipse uses it's own builtin java compiler, and needs to tell ant
>about it. It is supposed to integrate ant ;) kaffe doesn't integrate
>ant, ant runs on java, so there should be no need to add cruft to
>kaffe to fix ant ;)
No, it doesn't 'integrate' it. They are simple calling it withing
their code, no changes in the ant code, no magic (AFAIK). Ant isn't
used for the regular build (which happen on save and only compile,
what is needed), only for the 'call ant' action. I'm failry sure, that
they wouldn't add such a thing, if it wouldn't be used.
>they set it because they want their internal compiler instead of sun's. if
>build.compiler is not set, it default to sun's compiler.
Eclipse compiler is 'free', so we have already a Java1.4a/1.3 compiler,
which passes all of suns 'testing Kits'... Maybe I should split this
package out so that it can go into main.
>> Im of the 'whatever works best' group :) At least when I can't help
>> myself to somthing better.
>then you shouldn't use linux, since windows is a much better
>enviroment for Sun's java;)
I didn't switch to linux for its java :) More that I was held back until
everything I wanted worked. Just for the C&P bahaviour I don't want
to switch back ;)
>it's actively being supported by sun,
>whereas their linux support is non-existant on non-i386 linux
>platforms, i.e. where debian really shines ;)
Yes, I've seen that :(
>> >Then those people should write a jitter for the VM of their choice.
>> Aehm, yes, I will try that in my next break :)
>Other people have done it before, it can't be that hard ;)
:) I'm economics, not 'info' (whatever that is in english. Computer
science?) and have never touched c...
>thanks for keeping the discussion technical, I'd like to hear what you think
>about my java build demon proposal.
Sorry, to make my answere to that so short. Form my point of view, it
sounds almost impossible to do, as it would a lot of work on the
packages side, not only on the infrastructure on a nice big server.
Anyway, I think that java package maintainer will have to do such a
thing for each of their packages anyway, so sometime it might be
possible...
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: