Daigo Moriwaki wrote:
eclipse 2.1-2 fails to install in my environment.
When I did apt-get upgrade some of the latest Eclipse pacakges installed,
but eclipse-platform fails like following:
...
dpkg: error processing /var/cache/apt/archives/eclipse-platform_2.1-2_i386.deb
(--unpack):
trying to ov
ome time...
Afterwards you can dpkg -i the debs
It takes time, it takes disk space and it does not work...
$ fakeroot dpkg-buildpackage
...
dh_installdirs
# Add here commands to install the package into debian/eclipse.
cp -ar /home/ahmed/data/eclipse-2.1/build-tree/*
/home/ahmed/data/eclipse-2.1/
Hello.
eclipse, eclipse-javac, eclipse-jdt, eclipse-platform and libswt-java
available packages are all 2.1-1 version.
Some of them depend on 2.1-3 versions of eclipse-javac, eclipse-jdt and
eclipse-platform.
Where are these 2.1-3 packages to be found?
Grzegorz B. Prokopski wrote:
Please use jikes from testing distro (1.15). You shouldn't have any
other problems because of that. Bytecode outputed by newer
jikes makes use of some functions that SableVM doesn't have yet.
Jikes seems to have changed a lot since 1.15
(http://www-124.ibm.com/devel
Grzegorz B. Prokopski wrote:
Please use jikes from testing distro (1.15). You shouldn't have any
other problems because of that. Bytecode outputed by newer
jikes makes use of some functions that SableVM doesn't have yet.
Jikes seems to have changed a lot since 1.15
(http://www-124.ibm.com/dev
Hi,
$ cat Hello.java
class Hello {
public static void main(String[] args) {
System.out.println("Hello.");
}
}
$ jikes-sable Hello.java
$ sablevm --no-copyright Hello
java.lang.UnsupportedClassVersionError
at java.lang.VMClassLoader.nativeDefineClass(VMClassLoader.java)
at
Hi,
$ cat Hello.java
class Hello {
public static void main(String[] args) {
System.out.println("Hello.");
}
}
$ jikes-sable Hello.java
$ sablevm --no-copyright Hello
java.lang.UnsupportedClassVersionError
at java.lang.VMClassLoader.nativeDefineClass(VMClassLoader.java)
a
Hi,
Ant package (http://packages.debian.org/unstable/devel/ant.html) do not
depend on any Java Compiler.
This way, ant task is unusable without some help (JAVA_HOME
environment variable, build.compiler property). It is a core Ant task
(http://jakarta.apache.org/ant/manual/index.html).
On the
Hi,
Ant package (http://packages.debian.org/unstable/devel/ant.html) do not
depend on any Java Compiler.
This way, ant task is unusable without some help (JAVA_HOME
environment variable, build.compiler property). It is a core Ant task
(http://jakarta.apache.org/ant/manual/index.html).
On the
Andrew Pimlott wrote:
But of course people are using it (tools.jar).
That is real life.
But it doesn't solve the problem of whether to use tools.jar
in the first place.
The right question.
Should tools.jar be promoted to a kind of a standard?
Answer: No.
Andrew Pimlott wrote:
But of course people are using it (tools.jar).
That is real life.
But it doesn't solve the problem of whether to use tools.jar
in the first place.
The right question.
Should tools.jar be promoted to a kind of a standard?
Answer: No.
--
To UNSUBSCRIBE, email to [E
Joe Phillips wrote:
I haven't delved too deeply into the bowels of JBOSS/Tomcat *yet* but as
I understand it, it contains the java compiler.
Ant is a simpler example.
ant (/usr/share/ant/bin/ant) command is a short shell script worth reading.
The Sun java compiler is written in java. javac is mere
Joe Phillips wrote:
I haven't delved too deeply into the bowels of JBOSS/Tomcat *yet* but as
I understand it, it contains the java compiler.
Ant is a simpler example.
ant (/usr/share/ant/bin/ant) command is a short shell script worth reading.
The Sun java compiler is written in java. javac is
java-common is documentation.
Java Policy is ... policy.
Java FAQ is something interesting. It should be updated.
How about using XML Docbook, like Java Policy, instead of SGML debiandoc?
Something like:
http://www.baizid.org/cgi-bin/viewcvs.cgi/home/ahmed/work/debian/java-common/debian-java-faq
java-common is documentation.
Java Policy is ... policy.
Java FAQ is something interesting. It should be updated.
How about using XML Docbook, like Java Policy, instead of SGML debiandoc?
Something like:
http://www.baizid.org/cgi-bin/viewcvs.cgi/home/ahmed/work/debian/java-common/debian-java
It seems that Sun is willing to modify its licencing scheme.
http://java.sun.com/features/2002/10/new_jcp.html
I did not understand it in full. I have to read it multiple times.
It is like a lawyer wrote it.
I would like to package Apache Jakarta/XML software.
Of course, I have got to do it from sources, either releases or CVS.
Surprise... They are putting jars in CVS!
These jars are not only needed to build but also to run.
If you install some of the software, you'll find your self installing
mult
It seems that Sun is willing to modify its licencing scheme.
http://java.sun.com/features/2002/10/new_jcp.html
I did not understand it in full. I have to read it multiple times.
It is like a lawyer wrote it.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Tr
I would like to package Apache Jakarta/XML software.
Of course, I have got to do it from sources, either releases or CVS.
Surprise... They are putting jars in CVS!
These jars are not only needed to build but also to run.
If you install some of the software, you'll find your self installing
mult
I am running an unstable Debian.
I have "apt-get"ed source java-common.
It was version 0.16.
A typo make it invalid XML.
References to the Debian policy do not seem correct.
I propose the attached patch.
--- policy.xml 2002-12-12 02:42:18.0 +0100
+++ policy.xml 2002-12-12 03:32:28.00
I am running an unstable Debian.
I have "apt-get"ed source java-common.
It was version 0.16.
A typo make it invalid XML.
References to the Debian policy do not seem correct.
I propose the attached patch.
--- policy.xml 2002-12-12 02:42:18.0 +0100
+++ policy.xml 2002-12-12 03:32:28.0
21 matches
Mail list logo
