Subject: lasix - msg#00184

Previous Message by Date: click to view message preview

Re: Jetty config depends on missing ant.jar

On Thu, Jan 20, 2005 at 12:44:25PM +0000, John Patterson wrote: > I have hit another problem with the Jetty package. It depends on > /usr/share/java/ant.jar which does not exist on my installation (unstable). > There is only an ant-1.6.jar. Creating a symlink to this fixed the problem. You need to decide which Ant version you want to use and use the versioned JAR from libant*-java. Which package should crate the ant.jar symlink? If both libant1.5-java and libant1.6-java created it they would have to conflict. So only a "main" ant package which also includes the wrapper script /usr/bin/ant can create it. > Also, shouldn't there be a /usr/share/java/servlet.jar symlink? That's the same story: Which version should servlet.jar be? 2.2, 2.3 or (in the future) 2.4? That's why the JARs in the packages contain the API version. Stefan

Next Message by Date: click to view message preview

GCJ 4.0 and native Java packages

Hello! Some of you may have noticed the gcj-4.0 packages in experimental! I have altered my Eclipse packages which I've been working on to build with gcj and run with gij by default. In the course of doing this, I have noticed that it would be very helpful to get .so files provided alongside .jar files By Default in our Java packages. Has any policy been discused involving this? Where should we located the .so's? Should the -java package be split? Does it matter? What about gcj-dbtool generation. These any many more questions await answer! Here's what I'm thinking about currently: 1. Jar files in /usr/share/java (same). 2. Native files matching Jar files in /usr/lib/java. File names the exact same as the .jar, with a .so appended. 3. Provide a new 'update-gcj-database' or some such to generate a /usr/lib/java/gcj.db file in the postinst of all of these packages. Gcj is very interesting! It has a number of ways of resolving a request for a class name to a .so file. 1. Try the packagename.so: org.apache.blah.so, org.apache.so, in decreasing order until a match is found. 2. Loaded with LD_PRELOAD. 3. Resolution of class hash->.so using a gcj db file. The third option looks like the most expandable. gcj operates directly on the .jar file, creating a .so file. This means the build for most packages doesn't have to be altered, a simple recurse of all .jars in /usr/share/java should cover it during the build process. Questions, comments. We need to get on the ball on this, before I have to do it all myself. =)

Previous Message by Thread: click to view message preview

真剣なお願い

真剣なお願いがあります。貴方の精子をください！子供が出来なくて困ってます。 絶対迷惑はかけませんので中出ししてください。一回10万円で、 妊娠できたら50万円お礼として払います。詳しくはすぐに連絡先を教えます。 出来れば本日中に返事をください。 いちよプロフィールも載せておきますね。 29歳、157cm-45kg、スリーサイズ《88・60・87》写メ有ります。 引き受けて頂けるならここに登録してもらえますか？ 掲示板で待ってます。名前はめぐみです。 http://www.aaa-www.net/~bobobo/secret.php?pr=123456 お互いの事は知らない方が後々いいと思うし、 妊娠した後は連絡を取り合いたくないので ここを利用する事にしました。

Next Message by Thread: click to view message preview

GCJ 4.0 and native Java packages

Hello! Some of you may have noticed the gcj-4.0 packages in experimental! I have altered my Eclipse packages which I've been working on to build with gcj and run with gij by default. In the course of doing this, I have noticed that it would be very helpful to get .so files provided alongside .jar files By Default in our Java packages. Has any policy been discused involving this? Where should we located the .so's? Should the -java package be split? Does it matter? What about gcj-dbtool generation. These any many more questions await answer! Here's what I'm thinking about currently: 1. Jar files in /usr/share/java (same). 2. Native files matching Jar files in /usr/lib/java. File names the exact same as the .jar, with a .so appended. 3. Provide a new 'update-gcj-database' or some such to generate a /usr/lib/java/gcj.db file in the postinst of all of these packages. Gcj is very interesting! It has a number of ways of resolving a request for a class name to a .so file. 1. Try the packagename.so: org.apache.blah.so, org.apache.so, in decreasing order until a match is found. 2. Loaded with LD_PRELOAD. 3. Resolution of class hash->.so using a gcj db file. The third option looks like the most expandable. gcj operates directly on the .jar file, creating a .so file. This means the build for most packages doesn't have to be altered, a simple recurse of all .jars in /usr/share/java should cover it during the build process. Questions, comments. We need to get on the ball on this, before I have to do it all myself. =)