Re: any free JDKs not using jikes as compiler?
Hi Andrew,
Andrew Vaughan wrote:
Hi
The reason that I ask is that I would like to try to get Subversions java
binding (JavaHL) into the archive. (The current source package has support
for building JavaHL but it is disabled by default).
Attached two patches which fix the jikes build problem. BTW, its not
jikes fault but wrong coding sytle in the java files. jike is very
strict to the specification - which javac is not.
Could you please forward the patches to upstream ?
Put the patches in your debian/patches dir and copy the two line change
in the attached series file to your series file. I successfully built
the javaHL bindings with these patches in my chroot.
Two comments:
(1) The debian/libsvn-javahl directory gets created and populated with
the native and java libraries if ENABLE_JAVAHL=yes is set in the rules
file - however no libsvn-javahl package gets created. But I think this
is only a minor packaging problem.
(2) According to the java policy the native library parts should be
installed under /usr/lib/jni directory. I personally would also name the
package just libsvn-java. libsvn-javahl doesn't say much to a user and
confuses him in my opinion.
Regards,
Wolfgang
PS: I am eager awaiting the JavaHL bindings so I can use the eclipse svn
plugin without recompiling subversion from source.
--- subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/Notify.java.orig 2004-06-12 13:01:25.0 +
+++ subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/Notify.java 2005-04-06 07:28:09.0 +
@@ -56,7 +56,7 @@
*/
public static final String getActionName(int action)
{
- return actionNames[action];
+ return NotifyAction.actionNames[action];
}
}
@@ -73,7 +73,7 @@
*/
public static final String getStatusName(int status)
{
- return statusNames[status];
+ return NotifyStatus.statusNames[status];
}
}
--- subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/Status.java.orig 2004-09-06 05:56:11.0 +
+++ subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/Status.java 2005-04-06 07:47:48.0 +
@@ -490,31 +490,31 @@
{
switch (kind)
{
-case none:
+case StatusKind.none:
return "non-svn";
-case normal:
+case StatusKind.normal:
return "normal";
-case added:
+case StatusKind.added:
return "added";
-case missing:
+case StatusKind.missing:
return "missing";
-case deleted:
+case StatusKind.deleted:
return "deleted";
-case replaced:
+case StatusKind.replaced:
return "replaced";
-case modified:
+case StatusKind.modified:
return "modified";
-case merged:
+case StatusKind.merged:
return "merged";
-case conflicted:
+case StatusKind.conflicted:
return "conflicted";
-case ignored:
+case StatusKind.ignored:
return "ignored";
-case incomplete:
+case StatusKind.incomplete:
return "incomplete";
-case external:
+case StatusKind.external:
return "external";
-case unversioned:
+case StatusKind.unversioned:
default:
return "unversioned";
}
kaffe.patch -p0
kaffe-cast.patch -p0
jikes_compile_1.patch -p0
jikes_compile_2.patch -p0
repos-templates.patch -p0
svnshell.patch -p0
rpath.patch -p0
r11771.patch -p0
swig-version.patch -p0
swig-noruntime.patch -p0
swig-py-lock.patch
gcj 4.0: RFC on this change
I just read this: http://gcc.gnu.org/PR20750 any comment on this? now if --with-java-home is not specified it works as usual daniele. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Removal libxalan-java, lib-saxon-java
On Tue, 2005-04-05 at 15:28 +0200, Arnaud Vandyck wrote: > Mon, 28 Mar 2005 16:51:22 +0200, > Wolfgang Baer <[EMAIL PROTECTED]> wrote: > > this is another RFC for the removal of libxalan-java > > and now also lib-saxon-java > > > > Both are no longer used in build depends nor runtime > > depends. lib-saxon-java is superseded by libsaxon-java, > > but is still in the archive. Well, not having dependencies doesn't mean they aren't used! For instance, I use libxalan-java!! -- Martin Ferrari <[EMAIL PROTECTED]> DECIDIR Argentina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Removal libxalan-java, lib-saxon-java
Martin Ferrari wrote: On Tue, 2005-04-05 at 15:28 +0200, Arnaud Vandyck wrote: Mon, 28 Mar 2005 16:51:22 +0200, Wolfgang Baer <[EMAIL PROTECTED]> wrote: this is another RFC for the removal of libxalan-java and now also lib-saxon-java Both are no longer used in build depends nor runtime depends. lib-saxon-java is superseded by libsaxon-java, but is still in the archive. Well, not having dependencies doesn't mean they aren't used! For instance, I use libxalan-java!! Hi Martin, where do you need libxalan-java ? Can't you use libxalan2-java instead ? BTW, libxalan-java is not buildable from source anymore and therefore also not maintainable ! Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Removal libxalan-java, lib-saxon-java
Hi! On Wed, 2005-04-06 at 15:15 +0200, Wolfgang Baer wrote: > > Well, not having dependencies doesn't mean they aren't used! For > > instance, I use libxalan-java!! > > Hi Martin, > > where do you need libxalan-java ? Can't you use libxalan2-java instead ? > BTW, libxalan-java is not buildable from source anymore and therefore > also not maintainable ! I didn't know about build problems with libxalan-java. I am a sysadmin, so I don't directly use it, but instead the local programmers use it, and I've made a bunch of debian packages out of in-house applications. I can ask them to migrate to libxalan2-java (we have time until sarge is released), but there isn't any mechanism in place to do these (app breaking) changes smoothly? I ask because recently I've seen a lot of important (to me) packages being removed from sid/sarge mercylessly.. Thanks! -- Martin Ferrari <[EMAIL PROTECTED]> DECIDIR Argentina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The only effective method
Newest Penis enlaregment system! Fast Extender The only effective nonsurgical method to lengthen the penis is by employing devices that pull at the glans of the penis for extended periods of time. This is known as traction; where tissues under continuous tension will undergoe cellular multiplication. The result is tissue expansion, resulting in a permanent increase of the tissue... Source : Wikipedia You can get it here: http://www.oi6.net/e/viks you face me parabolic me you puppet me salvador me you exacerbate me boastful me you away me lamellar me you morale me rhetoric me you penitentiary me strata me you tonsillitis me expansion me you bart me cowherd me you appendage me controlling me you thirst me bring me http://k3y.net/e.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: Bug#303405: Acknowledgement (ITP: libxmlrpc-java -- Java implementation of XML-RPC protocol)
-- Forwarded message -- From: Debian Bug Tracking System <[EMAIL PROTECTED]> Date: Apr 6, 2005 11:48 AM Subject: Bug#303405: Acknowledgement (ITP: libxmlrpc-java -- Java implementation of XML-RPC protocol) To: Martin Ferrari <[EMAIL PROTECTED]> Thank you for the problem report you have sent regarding Debian. This is an automatically generated reply, to let you know your message has been received. It is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to debian-devel@lists.debian.org (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): <[EMAIL PROTECTED]> martin ferrari <[EMAIL PROTECTED]> If you wish to submit further information on your problem, please send it to [EMAIL PROTECTED] (and *not* to [EMAIL PROTECTED]). Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Debian bug tracking system administrator (administrator, Debian Bugs database) -- Martín Ferrari
Re: any free JDKs not using jikes as compiler?
Daniel Bonniot wrote: > > Unfortunately jikes 1.22 can't build JavaHL. It does build with Sun's > > JDK. > > Did you report this bug to jikes upstream? > I haven't. And I won't since Wolfgang said that jikes is only sticking closer to the spec than sun's javac. > > Is kcj coming back? > > I think that in any case, it would be good to have a kjc package back in > Debian (from upstream releases or CVS). > > Good luck, > > Daniel -- Thanks Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: any free JDKs not using jikes as compiler?
On Wed, 6 Apr 2005 06:26 pm, Wolfgang Baer wrote: > Hi Andrew, > > Andrew Vaughan wrote: > > Hi > > > > The reason that I ask is that I would like to try to get Subversions java > > binding (JavaHL) into the archive. (The current source package has > > support for building JavaHL but it is disabled by default). What I wrote above seems to have given you the wrong impression. I'm just a Debian user not a DD. I'm not intending to package javahl, merely to convince David Kimdon (Subversion maintainer) to build javahl as part of subversion. Since Subversion is in main, I needed to find a way to build javahl using free java tools. Note that all the credit for the existing javahl support in subversion belongs to other people. > > Attached two patches which fix the jikes build problem. BTW, its not > jikes fault but wrong coding sytle in the java files. jike is very > strict to the specification - which javac is not. > > Could you please forward the patches to upstream ? will do. But I won't have time for a couple of days. > > Put the patches in your debian/patches dir and copy the two line change > in the attached series file to your series file. I successfully built > the javaHL bindings with these patches in my chroot. > > Two comments: > > (1) The debian/libsvn-javahl directory gets created and populated with > the native and java libraries if ENABLE_JAVAHL=yes is set in the rules > file - however no libsvn-javahl package gets created. But I think this > is only a minor packaging problem. You need to regenerate debian/control otherwise dpkg-buildpackage does not build the new deb. $ rm debian/control $ debian/rules debian/control > > (2) According to the java policy the native library parts should be > installed under /usr/lib/jni directory. I personally would also name the ok. > package just libsvn-java. libsvn-javahl doesn't say much to a user and > confuses him in my opinion. ack. the name javahl comes from subversion upstream. It appears to be an abbreviation of java High Level bindings. At one stage there were also java bindings generated through swig. My feeling is that trying to would also confuse some people. > > Regards, > > Wolfgang > > PS: I am eager awaiting the JavaHL bindings so I can use the eclipse svn > plugin without recompiling subversion from source. me too :) [EMAIL PROTECTED] keeps getting hammered about how hard it is to build javahl. I doubt its worth trying to convince david to upload with javahl enabled this close to the sarge freeze. (The new deb would need to go through new). But I hope to file a wishlist for subversion 1.2rc in experimental with javahl enabled over the weekend. -- Thanks Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
