From news at panamahatsdirect.com Fri Jul 1 03:14:24 2005 From: news at panamahatsdirect.com (Panama Hats Direct) Date: Thu, 30 Jun 2005 19:14:24 -0800 Subject: [fedora-java] Your Hat Order Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.bmp Type: image/bmp Size: 23085 bytes Desc: not available URL: From 760khanh at absolutemotion.com Sat Jul 2 00:04:50 2005 From: 760khanh at absolutemotion.com (Vanessa J. Smith) Date: Sat, 02 Jul 2005 00:04:50 +0000 Subject: [fedora-java] Adobe Photoshop 8.0 - very low price Message-ID: <165801c57e99$975c7da9$7d99e9a3@absolutemotion.com> Get all the software you need for less! Our software is 2-10 times cheaper than sold by our competitors. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... To view full list of products go: http://www.soft-cds.com Sincerely, Vanessa Smith _____________________________________________________ To be taken off future campaigns, go here _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From manuel.dahmen at laposte.net Sat Jul 2 16:38:40 2005 From: manuel.dahmen at laposte.net (Manuel Dahmen) Date: Sat, 02 Jul 2005 18:38:40 +0200 Subject: [fedora-java] Installing Java3D on FC4 Message-ID: <42C6C310.3010502@laposte.net> Hello, I'm new to Fedora and I don't know where to unzip j3d-132-linux-x86.zip (archive from Sun). And: is that all I need to do to create J3D projects in Eclipse? Or is there something else to do? Thanks. Manuel Dahmen. From tromey at redhat.com Sun Jul 3 18:08:17 2005 From: tromey at redhat.com (Tom Tromey) Date: 03 Jul 2005 12:08:17 -0600 Subject: [fedora-java] rssowl: libgcj bugs that need fixing for it to run In-Reply-To: References: Message-ID: >>>>> "Robin" == Robin Green writes: Robin> 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22211 Robin> "Thread.interrupt sometimes causes abort if thread is already dead" I fixed this one in gcc cvs. The fix isn't on the 4.0 branch yet (the 4.0 branch is temporarily frozen) but I will move it over there after it reopens. (Feel free to remind me if I happen to forget.) Robin> 2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 Robin> "AttachCurrentThread() not working" This one looks hard. The GC likes to intercept some pthread calls in order to do things like add the new stacks to the root set. Maybe there is some way we can make this work for Linux though. Tom From tromey at redhat.com Sun Jul 3 18:16:26 2005 From: tromey at redhat.com (Tom Tromey) Date: 03 Jul 2005 12:16:26 -0600 Subject: [fedora-java] Weird ecj + utf8 issue In-Reply-To: <1119995925.23504.12.camel@tophat.toronto.redhat.com> References: <1119995925.23504.12.camel@tophat.toronto.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: Andrew> I came across a weird issue while trying to build rssowl. Andrew> I've attached the test file. Trying this works: Andrew> ecj RSSOwlI18nZHtw.java Andrew> while this appears to hang: Andrew> ecj -encoding utf8 RSSOwlI18nZHtw.java I can't even run ecj on my FC4 box :-( I'm using eclipse-ecj-3.1.0_fc-0.RC3.3. When I try 'ecj RSSOwlI18nZHtw.java', I see: Exception in thread "main" java.lang.NoClassDefFoundError: while resolving class: org.eclipse.jdt.internal.compiler.batch.Main at java.lang.VMClassLoader.transformException(java.lang.Class, java.lang.Throwable) (/usr/lib/libgcj.so.6.0.0) at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0) at org.eclipse.jdt.internal.compiler.batch.Main.main(java.lang.String[]) (/usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0.jar.so) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.problem.ProblemSeverities not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) ...5 more Andrew> To add to the bizarre-ness, this appears to be as small as I can make Andrew> the test file without it being unable to reproduce the problem; I can't Andrew> seem to remove any of the lines if I want to continue to reproduce. In Andrew> another interesting twist, renaming the file (and class) to "TestUTF8" Andrew> does not reproduce the problem. Andrew> Anyone know what's going on? This would be consistent with some kind of buffer boundary issue -- like if some obscure charset translation failure occurs only when the triggering data appears at the boundary of an internal buffer. With a bug like this, small changes to the text would hide the failure. That's just one possible theory though. Tom From green at redhat.com Sun Jul 3 20:35:56 2005 From: green at redhat.com (Anthony Green) Date: Sun, 03 Jul 2005 13:35:56 -0700 Subject: [fedora-java] libswt-atk-gtk? Message-ID: <1120422956.3057.9.camel@localhost.localdomain> The latest Azureus seems to want to load libswt-atk-gtk-3128.so, but I don't see that on my FC4 system. Is it hidden somewhere, or did we not package it? Thanks, AG From overholt at redhat.com Sun Jul 3 22:19:31 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 3 Jul 2005 18:19:31 -0400 Subject: [fedora-java] Re: libswt-atk-gtk? In-Reply-To: <1120422956.3057.9.camel@localhost.localdomain> References: <1120422956.3057.9.camel@localhost.localdomain> Message-ID: <20050703221930.GA20699@redhat.com> * Anthony Green [2005-07-03 16:36]: > The latest Azureus seems to want to load libswt-atk-gtk-3128.so, but I > don't see that on my FC4 system. > > Is it hidden somewhere, or did we not package it? It's not in the packages we released with FC4. Well, not explicitly, that is - it's in the SWT jar. The packages on rawhide and the forthcoming 3.1 packages (which will go out as an update for FC4) have the .sos extracted from the jars. Andrew From green at redhat.com Sun Jul 3 23:25:40 2005 From: green at redhat.com (Anthony Green) Date: Sun, 03 Jul 2005 16:25:40 -0700 Subject: [fedora-java] Re: libswt-atk-gtk? In-Reply-To: <20050703221930.GA20699@redhat.com> References: <1120422956.3057.9.camel@localhost.localdomain> <20050703221930.GA20699@redhat.com> Message-ID: <1120433140.3057.12.camel@localhost.localdomain> On Sun, 2005-07-03 at 18:19 -0400, Andrew Overholt wrote: > It's not in the packages we released with FC4. Well, not explicitly, that > is - it's in the SWT jar. The packages on rawhide and the forthcoming 3.1 > packages (which will go out as an update for FC4) have the .sos extracted > from the jars. Ok, thanks - I found it. I thought that if it was in the .jar file it would automatically get exploded into my .eclipse directory, but I see that only some of the .so files are. This will be much nicer when we get your update. AG From overholt at redhat.com Mon Jul 4 00:30:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 03 Jul 2005 20:30:14 -0400 Subject: [fedora-java] Re: libswt-atk-gtk? In-Reply-To: <1120433140.3057.12.camel@localhost.localdomain> References: <1120422956.3057.9.camel@localhost.localdomain> <20050703221930.GA20699@redhat.com> <1120433140.3057.12.camel@localhost.localdomain> Message-ID: <1120437014.20313.9.camel@localhost.localdomain> On Sun, 2005-03-07 at 16:25 -0700, Anthony Green wrote: > On Sun, 2005-07-03 at 18:19 -0400, Andrew Overholt wrote: > > It's not in the packages we released with FC4. Well, not explicitly, that > > is - it's in the SWT jar. The packages on rawhide and the forthcoming 3.1 > > packages (which will go out as an update for FC4) have the .sos extracted > > from the jars. > > Ok, thanks - I found it. I thought that if it was in the .jar file it > would automatically get exploded into my .eclipse directory, but I see > that only some of the .so files are. We are using the FileInitializer from our RC3 packages and beyond. There should be no more (active ... old ones could still be around I think) .sos in there once you update to the packages that have them extracted at build (well, %install) time. > This will be much nicer when we get your update. You know you can install the rawhide stuff, right? yum --enablerepo=development install eclipse-pde Andrew From green at redhat.com Mon Jul 4 01:49:15 2005 From: green at redhat.com (Anthony Green) Date: Sun, 03 Jul 2005 18:49:15 -0700 Subject: [fedora-java] rssowl: libgcj bugs that need fixing for it to run In-Reply-To: References: Message-ID: <1120441755.3057.29.camel@localhost.localdomain> On Sun, 2005-07-03 at 12:08 -0600, Tom Tromey wrote: > Robin> 2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 > Robin> "AttachCurrentThread() not working" > > This one looks hard. The GC likes to intercept some pthread calls in > order to do things like add the new stacks to the root set. Maybe > there is some way we can make this work for Linux though. The attached trick appears to work. Rather than wrap the pthread_create symbol, we override it with our own implementation and then use a glibc runtime linker trick to get a pointer to the real pthread_create. I can work up a submittable patch if you're in agreement with the general approach. AG -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.txt Type: text/x-patch Size: 2247 bytes Desc: not available URL: From vektor at dumbterm.net Mon Jul 4 03:14:42 2005 From: vektor at dumbterm.net (Billy Biggs) Date: Sun, 3 Jul 2005 22:14:42 -0500 Subject: [fedora-java] Re: libswt-atk-gtk? In-Reply-To: <1120433140.3057.12.camel@localhost.localdomain> References: <1120422956.3057.9.camel@localhost.localdomain> <20050703221930.GA20699@redhat.com> <1120433140.3057.12.camel@localhost.localdomain> Message-ID: <20050704031442.GA20582@dumbterm.net> Anthony Green (green at redhat.com): > Ok, thanks - I found it. I thought that if it was in the .jar file it > would automatically get exploded into my .eclipse directory, but I see > that only some of the .so files are. They are extracted on demand as the application calls loadLibrary(). -Billy From gbenson at redhat.com Tue Jul 5 14:41:12 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 5 Jul 2005 15:41:12 +0100 Subject: [fedora-java] New file layout for nativified rpms Message-ID: <20050705144111.GJ4974@redhat.com> Hi all, The way bc-compiled rpms are made is currently time-consuming and fiddly, and all too easy to make mistakes. I'm writing a script to automate this, but there's a number of changes to the filesystem layout I'd like to introduce at the same time, partly out of necessity and partly for future-proofing. Currently, bc-compiled rpms have solibs in /usr/lib, one per jarfile, and class mappings in /usr/lib/gcj-4.0.0/classmap.db.d, one per binary rpm. For instance, ant has these two jarfiles: /usr/share/java/ant-1.6.2.jar /usr/share/java/ant-launcher-1.6.2.jar so it has these native files: /usr/lib/gcj-4.0.0/classmap.db.d/ant-1.6.2.db /usr/lib/libant-1.6.2.jar.so /usr/lib/libant-launcher-1.6.2.jar.so Fully-automatic compilation will require one mapping database per jarfile, and I'd like to stick all the solibs and databases in package-specific databases under /usr/lib/gcj, so to continue the example ant would have: /usr/lib/gcj/ant/libant-1.6.2.jar.db /usr/lib/gcj/ant/libant-1.6.2.jar.so /usr/lib/gcj/ant/libant-launcher-1.6.2.jar.db /usr/lib/gcj/ant/libant-launcher-1.6.2.jar.so My reason for moving from /usr/lib/gcj-4.0.0/classmap.db.d as the mappings directory is that this name will of course change when gcj is upgraded -- I don't wish to rebuild my ninety-plus rpms every time gcj bumps unless I actually have to. We can make rebuild-gcj-db pick up files from both the old and new directories until all rpms have been rebuilt. My reason for moving the solibs into this directory is simply because then nativified rpms need only one line in their %files section to pick up the native binaries. Can anyone see any problems with this layout? Cheers, Gary From doko at cs.tu-berlin.de Tue Jul 5 14:54:04 2005 From: doko at cs.tu-berlin.de (Matthias Klose) Date: Tue, 5 Jul 2005 16:54:04 +0200 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: <20050705144111.GJ4974@redhat.com> References: <20050705144111.GJ4974@redhat.com> Message-ID: <17098.40716.634018.609660@gargle.gargle.HOWL> Gary Benson writes: > My reason for moving from /usr/lib/gcj-4.0.0/classmap.db.d as the > mappings directory is that this name will of course change when gcj > is upgraded -- I don't wish to rebuild my ninety-plus rpms every time > gcj bumps unless I actually have to. We can make rebuild-gcj-db pick > up files from both the old and new directories until all rpms have > been rebuilt. Are you able to use the bc-compiled files, built using gcj-4.0.x, with gcj-4.1.x? Matthias From aph at redhat.com Tue Jul 5 15:07:29 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jul 2005 16:07:29 +0100 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: <17098.40716.634018.609660@gargle.gargle.HOWL> References: <20050705144111.GJ4974@redhat.com> <17098.40716.634018.609660@gargle.gargle.HOWL> Message-ID: <17098.41521.634258.31700@zapata.pink> Matthias Klose writes: > Gary Benson writes: > > My reason for moving from /usr/lib/gcj-4.0.0/classmap.db.d as the > > mappings directory is that this name will of course change when gcj > > is upgraded -- I don't wish to rebuild my ninety-plus rpms every time > > gcj bumps unless I actually have to. We can make rebuild-gcj-db pick > > up files from both the old and new directories until all rpms have > > been rebuilt. > > Are you able to use the bc-compiled files, built using gcj-4.0.x, with > gcj-4.1.x? Probably, but ATM I don't think we can guarantee for sure. Andrew. From gbenson at redhat.com Tue Jul 5 15:29:32 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 5 Jul 2005 16:29:32 +0100 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: <17098.41521.634258.31700@zapata.pink> References: <20050705144111.GJ4974@redhat.com> <17098.40716.634018.609660@gargle.gargle.HOWL> <17098.41521.634258.31700@zapata.pink> Message-ID: <20050705152930.GK4974@redhat.com> Andrew Haley wrote: > Matthias Klose writes: > > Gary Benson writes: > > > My reason for moving from /usr/lib/gcj-4.0.0/classmap.db.d as > > > the mappings directory is that this name will of course change > > > when gcj is upgraded -- I don't wish to rebuild my ninety-plus > > > rpms every time gcj bumps unless I actually have to. We can > > > make rebuild-gcj-db pick up files from both the old and new > > > directories until all rpms have been rebuilt. > > > > Are you able to use the bc-compiled files, built using gcj-4.0.x, > > with gcj-4.1.x? > > Probably, but ATM I don't think we can guarantee for sure. I agree. But in the same way we probably can't guarantee compatibility between gcj-4.0.0-x and gcj-4.0.0-y. Cheers, Gary From aph at redhat.com Tue Jul 5 15:36:18 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jul 2005 16:36:18 +0100 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: <20050705152930.GK4974@redhat.com> References: <20050705144111.GJ4974@redhat.com> <17098.40716.634018.609660@gargle.gargle.HOWL> <17098.41521.634258.31700@zapata.pink> <20050705152930.GK4974@redhat.com> Message-ID: <17098.43250.755786.728733@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Matthias Klose writes: > > > Gary Benson writes: > > > > My reason for moving from /usr/lib/gcj-4.0.0/classmap.db.d as > > > > the mappings directory is that this name will of course change > > > > when gcj is upgraded -- I don't wish to rebuild my ninety-plus > > > > rpms every time gcj bumps unless I actually have to. We can > > > > make rebuild-gcj-db pick up files from both the old and new > > > > directories until all rpms have been rebuilt. > > > > > > Are you able to use the bc-compiled files, built using gcj-4.0.x, > > > with gcj-4.1.x? > > > > Probably, but ATM I don't think we can guarantee for sure. > > I agree. But in the same way we probably can't guarantee compatibility > between gcj-4.0.0-x and gcj-4.0.0-y. I think that's a very different case. We're trying very hard to do just that. Andrew. From tromey at redhat.com Tue Jul 5 15:32:49 2005 From: tromey at redhat.com (Tom Tromey) Date: 05 Jul 2005 09:32:49 -0600 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: <20050705152930.GK4974@redhat.com> References: <20050705144111.GJ4974@redhat.com> <17098.40716.634018.609660@gargle.gargle.HOWL> <17098.41521.634258.31700@zapata.pink> <20050705152930.GK4974@redhat.com> Message-ID: >>>>> "Gary" == Gary Benson writes: >> Probably, but ATM I don't think we can guarantee for sure. Gary> I agree. But in the same way we probably can't guarantee compatibility Gary> between gcj-4.0.0-x and gcj-4.0.0-y. We can always make mistakes... but we do try to guarantee that we don't break compatibility in this case, even in the 4.0.x series. So far, as far as I know, 4.1 can use any BC-compiled object generated by 4.0. However, we don't want to really promise that we won't break this in the future, as we might find some reason that we can't keep this working. Our hope is that starting with 4.1 we can guarantee compatibility. Tom From gbenson at redhat.com Tue Jul 5 15:58:49 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 5 Jul 2005 16:58:49 +0100 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: References: <20050705144111.GJ4974@redhat.com> <17098.40716.634018.609660@gargle.gargle.HOWL> <17098.41521.634258.31700@zapata.pink> <20050705152930.GK4974@redhat.com> Message-ID: <20050705155848.GL4974@redhat.com> Tom Tromey wrote: > >>>>> "Gary" == Gary Benson writes: > Gary> I agree. But in the same way we probably can't guarantee > Gary> compatibility between gcj-4.0.0-x and gcj-4.0.0-y. > > We can always make mistakes... but we do try to guarantee that we > don't break compatibility in this case, even in the 4.0.x series. Ah, ok. Is the BC-ABI immune to things like adding extra members/methods to classes then? > So far, as far as I know, 4.1 can use any BC-compiled object > generated by 4.0. However, we don't want to really promise that we > won't break this in the future, as we might find some reason that we > can't keep this working. > > Our hope is that starting with 4.1 we can guarantee compatibility. If compatibility _is_ broken, will it fail gracefully? Cheers, Gary From aph at redhat.com Tue Jul 5 16:08:04 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jul 2005 17:08:04 +0100 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: <20050705155848.GL4974@redhat.com> References: <20050705144111.GJ4974@redhat.com> <17098.40716.634018.609660@gargle.gargle.HOWL> <17098.41521.634258.31700@zapata.pink> <20050705152930.GK4974@redhat.com> <20050705155848.GL4974@redhat.com> Message-ID: <17098.45156.279418.9156@zapata.pink> Gary Benson writes: > Tom Tromey wrote: > > >>>>> "Gary" == Gary Benson writes: > > Gary> I agree. But in the same way we probably can't guarantee > > Gary> compatibility between gcj-4.0.0-x and gcj-4.0.0-y. > > > > We can always make mistakes... but we do try to guarantee that we > > don't break compatibility in this case, even in the 4.0.x series. > > Ah, ok. Is the BC-ABI immune to things like adding extra > members/methods to classes then? That's what it's for... Andrew. From gbenson at redhat.com Tue Jul 5 16:15:20 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 5 Jul 2005 17:15:20 +0100 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: <17098.45156.279418.9156@zapata.pink> References: <20050705144111.GJ4974@redhat.com> <17098.40716.634018.609660@gargle.gargle.HOWL> <17098.41521.634258.31700@zapata.pink> <20050705152930.GK4974@redhat.com> <20050705155848.GL4974@redhat.com> <17098.45156.279418.9156@zapata.pink> Message-ID: <20050705161519.GM4974@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Tom Tromey wrote: > > > >>>>> "Gary" == Gary Benson writes: > > > Gary> I agree. But in the same way we probably can't guarantee > > > Gary> compatibility between gcj-4.0.0-x and gcj-4.0.0-y. > > > > > > We can always make mistakes... but we do try to guarantee that > > > we don't break compatibility in this case, even in the 4.0.x > > > series. > > > > Ah, ok. Is the BC-ABI immune to things like adding extra > > members/methods to classes then? > > That's what it's for... Sweet :) From mckinlay at redhat.com Tue Jul 5 17:28:16 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Tue, 05 Jul 2005 13:28:16 -0400 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: <20050705155848.GL4974@redhat.com> References: <20050705144111.GJ4974@redhat.com> <17098.40716.634018.609660@gargle.gargle.HOWL> <17098.41521.634258.31700@zapata.pink> <20050705152930.GK4974@redhat.com> <20050705155848.GL4974@redhat.com> Message-ID: <42CAC330.4040805@redhat.com> Gary Benson wrote: >>Gary> I agree. But in the same way we probably can't guarantee >>Gary> compatibility between gcj-4.0.0-x and gcj-4.0.0-y. >> >>We can always make mistakes... but we do try to guarantee that we >>don't break compatibility in this case, even in the 4.0.x series. >> >> > >Ah, ok. Is the BC-ABI immune to things like adding extra >members/methods to classes then? > > Yes. In general the BC-ABI conforms to chapter 13 of the JLS. >>So far, as far as I know, 4.1 can use any BC-compiled object >>generated by 4.0. However, we don't want to really promise that we >>won't break this in the future, as we might find some reason that we >>can't keep this working. >> >>Our hope is that starting with 4.1 we can guarantee compatibility. >> >> > >If compatibility _is_ broken, will it fail gracefully? > > libgcj 4.0.0 would crash if it saw a compiled class with an incompatible version ID, but this is fixed in 4.0.1 and 4.1. Now, we will silently refuse to load the class and fall back to the bytecode interpreter when a native-compiled class could not be loaded for some reason. But, I'm not sure that this is really the most "graceful" behaviour - the user could easily be unaware that their .so did not load and wonder why performance is bad. Other alternatives we could consider include: 1. Issue a warning before falling back to the bytecode interpreter 2. Throw a ClassFormatError/ClassNotFoundException/VerifyError Note that this will most likely happen when you try to run a newwer compiled class against an old runtime. In general, we will try to preserve backwards-compatibility so that old compiled classes will continue to work with new runtimes - although, as Tom points out, we don't yet guarantee it. Bryce From jdf.lists at gmail.com Tue Jul 5 17:29:23 2005 From: jdf.lists at gmail.com (Joshua Daniel Franklin) Date: Tue, 5 Jul 2005 10:29:23 -0700 Subject: [fedora-java] Installing Java3D on FC4 In-Reply-To: <42C6C310.3010502@laposte.net> References: <42C6C310.3010502@laposte.net> Message-ID: <67437bc40507051029470808ac@mail.gmail.com> On 7/2/05, Manuel Dahmen wrote: > I'm new to Fedora and I don't know where to unzip j3d-132-linux-x86.zip > (archive from Sun). Are you using Fedora Core 4? Have you installed Sun's JVM too? If you're using JPackage, build an RPM out of the zip: http://jpackage.org/rpm.php?id=2607 and then install it. I also use the below script to link the Java3d files into the default JVM, otherwise you need to do something like this: cd /usr/share/java3d/demo/java3d/TextureTest java -cp `build-classpath-directory /usr/share/java/java3d`:./ -Djava.library.path=/usr/lib MultiTextureTest #!/bin/sh # 2005-06-15 # Joshua Daniel Franklin # # puts the native extention .so and .jar files in the # current default JRE --- run first time you install # or switch to a JRE since /usr/lib/jvm/java is a link # /usr/lib/jvm/java -> /etc/alternatives/java_sdk # /etc/alternatives/java_sdk -> /usr/lib/jvm/java-1.5.0-sun for i in $(rpm -ql java3d | grep '.so$' ); do ln -s $i /usr/lib/jvm/java/jre/lib/i386 done for i in $(rpm -ql java3d | grep '.jar$' ); do ln -s $i /usr/lib/jvm/java/jre/lib/ext done #----------------- > And: is that all I need to do to create J3D projects in Eclipse? Or is > there something else to do? I don't know, though you can certainly try. From overholt at redhat.com Tue Jul 5 19:16:18 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 05 Jul 2005 15:16:18 -0400 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: References: Message-ID: <1120590978.714.0.camel@tofu.toronto.redhat.com> On Thu, 2005-30-06 at 16:24 -0500, Ian Pilcher wrote: > From what I can tell, Fedora Core 4 provides a very good Java 1.4.2 > development environment. The one thing that I cannot find is Java API > documentation (the equivalent of JPackage's java-1.4.2-sun-manual). > > Have I just missed it, or is it not available? You haven't missed it, no. I believe Anthony Green did some packaging of the libgcj or Classpath javadocs. Anthony? This could be a good candidate for Fedora Extras (and potentially Fedora Core 5). Andrew From overholt at redhat.com Tue Jul 5 19:17:24 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 05 Jul 2005 15:17:24 -0400 Subject: [fedora-java] Installing Java3D on FC4 In-Reply-To: <42C6C310.3010502@laposte.net> References: <42C6C310.3010502@laposte.net> Message-ID: <1120591044.714.2.camel@tofu.toronto.redhat.com> On Sat, 2005-02-07 at 18:38 +0200, Manuel Dahmen wrote: > And: is that all I need to do to create J3D projects in Eclipse? Or is > there something else to do? You should probably be able to just add the Java3D jar(s) to the build path of your Eclipse project and be on your way. Andrew From i.pilcher at comcast.net Tue Jul 5 20:31:51 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 05 Jul 2005 15:31:51 -0500 Subject: [fedora-java] Re: Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120590978.714.0.camel@tofu.toronto.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> Message-ID: Andrew Overholt wrote: > You haven't missed it, no. I believe Anthony Green did some packaging > of the libgcj or Classpath javadocs. Anthony? This could be a good > candidate for Fedora Extras (and potentially Fedora Core 5). I found classpath-javadoc or JPackage.org, which looks like exactly what I'm looking for. Unfortunately, it conflicts with Fedora's version of jpackage-utils, which owns /usr/share/javadoc/java. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From i.pilcher at comcast.net Tue Jul 5 20:34:48 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 05 Jul 2005 15:34:48 -0500 Subject: [fedora-java] Should jpackage-utils own javadoc/java? Message-ID: Fedora's version of jpackage-utils owns /usr/share/javadoc/java. JPackage's version does not. This causes a conflict with JPackage's classpath-javadoc. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From green at redhat.com Tue Jul 5 20:44:29 2005 From: green at redhat.com (Anthony Green) Date: Tue, 05 Jul 2005 13:44:29 -0700 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120590978.714.0.camel@tofu.toronto.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> Message-ID: <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-07-05 at 15:16 -0400, Andrew Overholt wrote: > > Have I just missed it, or is it not available? > > You haven't missed it, no. I believe Anthony Green did some packaging > of the libgcj or Classpath javadocs. Anthony? This could be a good > candidate for Fedora Extras (and potentially Fedora Core 5). Here's the SRPM. I haven't tried building it in a while. http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm I look into submitting it to extras. This reminds me... we should import the GNU Classpath package description html files into GCC. Thanks, AG From fitzsim at redhat.com Tue Jul 5 20:51:49 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 05 Jul 2005 16:51:49 -0400 Subject: [fedora-java] Should jpackage-utils own javadoc/java? In-Reply-To: References: Message-ID: <1120596709.3379.56.camel@tortoise.toronto.redhat.com> On Tue, 2005-07-05 at 15:34 -0500, Ian Pilcher wrote: > Fedora's version of jpackage-utils owns /usr/share/javadoc/java. > JPackage's version does not. This causes a conflict with JPackage's > classpath-javadoc. Yeah, we made that change before classpath-javadoc was available. We should import classpath-javadoc into Fedora and release /usr/share/javadoc/java from jpackage-utils. Can you file a bug in bugzilla under the jpackage-utils component for this? Thanks, Tom From overholt at redhat.com Tue Jul 5 20:57:38 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 5 Jul 2005 16:57:38 -0400 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050705205738.GF5300@redhat.com> * Anthony Green [2005-07-05 16:44]: > On Tue, 2005-07-05 at 15:16 -0400, Andrew Overholt wrote: > > > Have I just missed it, or is it not available? > > > > You haven't missed it, no. I believe Anthony Green did some packaging > > of the libgcj or Classpath javadocs. Anthony? This could be a good > > candidate for Fedora Extras (and potentially Fedora Core 5). > > Here's the SRPM. I haven't tried building it in a while. > > http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm It builds great for me. I think we should change it to require libgcj-src, though, since that's what provides /usr/share/java/src-4.0.0.zip. Otherwise, it looks good to me. > I look into submitting it to extras. [...] By "I" do you mean "I'll"? I can look into it if you want. Andrew From i.pilcher at comcast.net Tue Jul 5 21:15:28 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 05 Jul 2005 16:15:28 -0500 Subject: [fedora-java] Re: Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: Anthony Green wrote: > > Here's the SRPM. I haven't tried building it in a while. > > http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm > It should BuildRequire libgcj-src. > I look into submitting it to extras. This reminds me... we should > import the GNU Classpath package description html files into GCC. I'd argue that it should be in Core (and that it should be built as part of the libgcj SRPM). I'd also suggest having a java-1.4.2-gcj-compat-doc RPM which creates appropriate symlinks in /usr/share/javadoc. (See my other note about the ownership of /usr/share/javadoc/java.) Good stuff! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From green at redhat.com Tue Jul 5 21:23:58 2005 From: green at redhat.com (Anthony Green) Date: Tue, 05 Jul 2005 14:23:58 -0700 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <20050705205738.GF5300@redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705205738.GF5300@redhat.com> Message-ID: <1120598638.2951.30.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-07-05 at 16:57 -0400, Andrew Overholt wrote: > > I look into submitting it to extras. [...] > > By "I" do you mean "I'll"? Yes. > I can look into it if you want. Even better. That would be great - thanks! AG From overholt at redhat.com Tue Jul 5 21:38:42 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 5 Jul 2005 17:38:42 -0400 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120598638.2951.30.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705205738.GF5300@redhat.com> <1120598638.2951.30.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050705213842.GG5300@redhat.com> * Anthony Green [2005-07-05 17:24]: > On Tue, 2005-07-05 at 16:57 -0400, Andrew Overholt wrote: > > > I look into submitting it to extras. [...] On second thought, should we ship this or classpath-javadoc? Andrew From overholt at redhat.com Tue Jul 5 21:39:05 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 5 Jul 2005 17:39:05 -0400 Subject: [fedora-java] Re: Java API doc (javadoc) from GCJ/classpath? In-Reply-To: References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050705213905.GH5300@redhat.com> * Ian Pilcher [2005-07-05 17:16]: > >I look into submitting it to extras. This reminds me... we should > >import the GNU Classpath package description html files into GCC. > > I'd argue that it should be in Core (and that it should be built as > part of the libgcj SRPM). I'd also suggest having a > java-1.4.2-gcj-compat-doc RPM which creates appropriate symlinks in > /usr/share/javadoc. (See my other note about the ownership of > /usr/share/javadoc/java.) I agree. Andrew From i.pilcher at comcast.net Tue Jul 5 21:44:22 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 05 Jul 2005 16:44:22 -0500 Subject: [fedora-java] Re: Should jpackage-utils own javadoc/java? In-Reply-To: <1120596709.3379.56.camel@tortoise.toronto.redhat.com> References: <1120596709.3379.56.camel@tortoise.toronto.redhat.com> Message-ID: Thomas Fitzsimmons wrote: > Yeah, we made that change before classpath-javadoc was available. We > should import classpath-javadoc into Fedora and > release /usr/share/javadoc/java from jpackage-utils. Can you file a bug > in bugzilla under the jpackage-utils component for this? Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162533 I've also created https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162534 -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From i.pilcher at comcast.net Tue Jul 5 21:53:35 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 05 Jul 2005 16:53:35 -0500 Subject: [fedora-java] Re: Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <20050705213905.GH5300@redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705213905.GH5300@redhat.com> Message-ID: Andrew Overholt wrote: > * Ian Pilcher [2005-07-05 17:16]: >> >>I'd argue that it should be in Core (and that it should be built as >>part of the libgcj SRPM). I'd also suggest having a >>java-1.4.2-gcj-compat-doc RPM which creates appropriate symlinks in >>/usr/share/javadoc. (See my other note about the ownership of >>/usr/share/javadoc/java.) > > > I agree. > FYI - I've put an RFE in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162534 It's under GCC, since that's where libgcj comes from. Interested parties on the Java side of things may want to add themselves to the cc list. On second thought, I believe that the "compatibility" package should probably be named classpath-javadoc-libgcj-compat, since it will provide compatibility with JPackage's classpath-javadoc. Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From green at redhat.com Tue Jul 5 21:58:03 2005 From: green at redhat.com (Anthony Green) Date: Tue, 05 Jul 2005 14:58:03 -0700 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <20050705213842.GG5300@redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705205738.GF5300@redhat.com> <1120598638.2951.30.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705213842.GG5300@redhat.com> Message-ID: <1120600684.2951.66.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-07-05 at 17:38 -0400, Andrew Overholt wrote: > * Anthony Green [2005-07-05 17:24]: > > On Tue, 2005-07-05 at 16:57 -0400, Andrew Overholt wrote: > > > > I look into submitting it to extras. [...] > > On second thought, should we ship this or classpath-javadoc? Why would it make sense to ship classpath javadoc? We don't ship classpath. AG From overholt at redhat.com Tue Jul 5 21:59:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 5 Jul 2005 17:59:14 -0400 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120600684.2951.66.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705205738.GF5300@redhat.com> <1120598638.2951.30.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705213842.GG5300@redhat.com> <1120600684.2951.66.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050705215914.GI5300@redhat.com> * Anthony Green [2005-07-05 17:58]: > On Tue, 2005-07-05 at 17:38 -0400, Andrew Overholt wrote: > > * Anthony Green [2005-07-05 17:24]: > > > On Tue, 2005-07-05 at 16:57 -0400, Andrew Overholt wrote: > > > > > I look into submitting it to extras. [...] > > > > On second thought, should we ship this or classpath-javadoc? > > Why would it make sense to ship classpath javadoc? We don't ship > classpath. I know. I think this should go into the gcc RPM and not as a standalone package. Andrew From green at redhat.com Tue Jul 5 22:03:00 2005 From: green at redhat.com (Anthony Green) Date: Tue, 05 Jul 2005 15:03:00 -0700 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <20050705215914.GI5300@redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705205738.GF5300@redhat.com> <1120598638.2951.30.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705213842.GG5300@redhat.com> <1120600684.2951.66.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705215914.GI5300@redhat.com> Message-ID: <1120600980.2951.69.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-07-05 at 17:59 -0400, Andrew Overholt wrote: > * Anthony Green [2005-07-05 17:58]: > > On Tue, 2005-07-05 at 17:38 -0400, Andrew Overholt wrote: > > > * Anthony Green [2005-07-05 17:24]: > > > > On Tue, 2005-07-05 at 16:57 -0400, Andrew Overholt wrote: > > > > > > I look into submitting it to extras. [...] > > > > > > On second thought, should we ship this or classpath-javadoc? > > > > Why would it make sense to ship classpath javadoc? We don't ship > > classpath. > > I know. I think this should go into the gcc RPM and not as a standalone > package. Oh, right - I agree. I wrote this package after we started hearing about the FC4 size problems. I would have submitted a GCC spec file patch to Jakub otherwise. AG From overholt at redhat.com Tue Jul 5 22:03:41 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 5 Jul 2005 18:03:41 -0400 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120600980.2951.69.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705205738.GF5300@redhat.com> <1120598638.2951.30.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705213842.GG5300@redhat.com> <1120600684.2951.66.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705215914.GI5300@redhat.com> <1120600980.2951.69.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050705220341.GJ5300@redhat.com> * Anthony Green [2005-07-05 18:03]: > > I know. I think this should go into the gcc RPM and not as a standalone > > package. > > Oh, right - I agree. > > I wrote this package after we started hearing about the FC4 size > problems. I would have submitted a GCC spec file patch to Jakub > otherwise. We don't really have to worry about size restrictions for FC5 (yet) or for FC4 updates. Andrew From mark at klomp.org Tue Jul 5 22:32:07 2005 From: mark at klomp.org (Mark Wielaard) Date: Wed, 06 Jul 2005 00:32:07 +0200 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120600684.2951.66.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705205738.GF5300@redhat.com> <1120598638.2951.30.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050705213842.GG5300@redhat.com> <1120600684.2951.66.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1120602727.11058.28.camel@localhost.localdomain> On Tue, 2005-07-05 at 14:58 -0700, Anthony Green wrote: > On Tue, 2005-07-05 at 17:38 -0400, Andrew Overholt wrote: > > * Anthony Green [2005-07-05 17:24]: > > > On Tue, 2005-07-05 at 16:57 -0400, Andrew Overholt wrote: > > > > > I look into submitting it to extras. [...] > > > > On second thought, should we ship this or classpath-javadoc? > > Why would it make sense to ship classpath javadoc? We don't ship > classpath. For the record. Whether you use libgcj, kaffe or classpath as core class libraries in principle the documentation generated by gjdoc should be the same for all three. Since they all are build from GNU Classpath sources. Modulo small bug fixes/not yet merged documentation updates of course. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tromey at redhat.com Tue Jul 5 23:14:27 2005 From: tromey at redhat.com (Tom Tromey) Date: 05 Jul 2005 17:14:27 -0600 Subject: [fedora-java] Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> This reminds me... we should import the GNU Classpath package Anthony> description html files into GCC. This won't be needed as soon as I finish the big classpath merge. This won't help 4.0.x though. Tom From gbenson at redhat.com Wed Jul 6 13:01:11 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 6 Jul 2005 14:01:11 +0100 Subject: [fedora-java] New file layout for nativified rpms In-Reply-To: <42CAC330.4040805@redhat.com> References: <20050705144111.GJ4974@redhat.com> <17098.40716.634018.609660@gargle.gargle.HOWL> <17098.41521.634258.31700@zapata.pink> <20050705152930.GK4974@redhat.com> <20050705155848.GL4974@redhat.com> <42CAC330.4040805@redhat.com> Message-ID: <20050706130109.GD4852@redhat.com> Bryce McKinlay wrote: > Gary Benson wrote: > > If compatibility _is_ broken, will it fail gracefully? > > libgcj 4.0.0 would crash if it saw a compiled class with an > incompatible version ID, but this is fixed in 4.0.1 and 4.1. Now, we > will silently refuse to load the class and fall back to the bytecode > interpreter when a native-compiled class could not be loaded for > some reason. > > But, I'm not sure that this is really the most "graceful" behaviour > - the user could easily be unaware that their .so did not load and > wonder why performance is bad. Other alternatives we could consider > include: > > 1. Issue a warning before falling back to the bytecode interpreter > 2. Throw a ClassFormatError/ClassNotFoundException/VerifyError My vote would go for #1. > Note that this will most likely happen when you try to run a newwer > compiled class against an old runtime. In general, we will try to > preserve backwards-compatibility so that old compiled classes will > continue to work with new runtimes - although, as Tom points out, we > don't yet guarantee it. Cool. From gbenson at redhat.com Wed Jul 6 15:40:56 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 6 Jul 2005 16:40:56 +0100 Subject: [fedora-java] aot-compile-rpm Message-ID: <20050706154056.GE4852@redhat.com> Over the past couple of days I've been writing a replacement for aot-compile and find-and-aot-compile. They were both good when they were first written but the demands of Eclipse and JOnAS have exposed numerous shortcomings. Attached is a copy of aot-compile-rpm which I'd like to commit into java-1.4.2-gcj-compat if everyone's agreeable. It's an order of magnitude more complex than aot-compile and find-and-aot-compile, but it's advantages over them are manifold: IT'S MUCH MORE USABLE ===================== Nativifying an rpm using aot-compile-rpm is a matter of copy-and-paste: 1. Remove "BuildArch: noarch" 2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp" and "Requires(post,postun)" on same. 3. Add "aot-compile-rpm" to the very end of %install. 4. Add "/usr/bin/rebuild-gcj-db %{_libdir}" to %post and %postun. 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files. With aot-compile or find-and-aot-compile step 4 was much more complex. I was always uneasy about nativifying things I didn't myself maintain, postgresql-jdbc for example, because I was wary of dropping a bunch of fragile code on someone else. No longer. IT FINDS JARS BY SIGNATURE RATHER THAN BY EXTENSION =================================================== find-and-aot-compile identifies jarfiles by their extension, ".jar", so it misses ".war", ".ear", ".rar", and anything else the Java world happens to invent. aot-compile-rpm identifies jarfiles by opening them, so it catches them no matter what they're called. It's already found some unexpected stuff. Tomcat, for example, has a couple of servlets that are disabled by default because they are in jarfiles called ".renametojar". aot-compile-rpm finds and compiles these, so if the user renames them to enable the servlets then they'll be running BC-compiled code. IT IGNORES SUBSETTED JARFILES ============================= Several packages contain jarfiles which are a subset of others. MX4J, for example, has the APIs in mx4j-jmx.jar, the implementation in mx4j-impl.jar, and both together in mx4j.jar. aot-compile-rpm recognises that compiling mx4j.jar will get every class in the other two jars too, so it'll only compile mx4j.jar. So, aot-compile-rpm compiles MX4J in half the time (and generates half the bytes) that find-and-aot-compile does. IT WORKS AROUND THE PPC GO2 LIMIT ================================= PPC machines are limited on the size of jarfiles that can be compiled in one go, affecting Eclipse and JacORB, as described at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308. aot-compile-rpm splits large jarfiles on ppc to avoid this. One limitation of aot-compile and find-and-aot-compile that I have not addressed (yet) is SMP support. Andrew Overholt suggested generating a Makefile and letting make handle the complex stuff, which I think is an excellent idea. Implementing something along those lines is something I'd like to do, but I need to get ppc64 and s390* bootstrapped first. Cheers, Gary -------------- next part -------------- #!/usr/bin/env python import os import sys import zipfile PATHS = {"libdir": "/usr/lib/gcj", "gcj": "/usr/bin/gcj", "dbtool": "/usr/bin/gcj-dbtool"} GCJFLAGS = os.environ.get("RPM_OPT_FLAGS", "").split() + [ "-fPIC", "-findirect-dispatch"] LDFLAGS = ["-Wl,-Bsymbolic"] class Error(Exception): pass def aot_compile_rpm(basedir, libdir): """Search basedir for jarfiles, then generate solibs and class mappings for them all in libdir.""" dstdir = os.path.join(basedir, libdir.strip(os.sep)) if not os.path.isdir(dstdir): os.makedirs(dstdir) for jar in weed_jars(find_jars(basedir)): aot_compile_jar(jar, dstdir, libdir) def find_jars(dir): """Return a list of every jarfile under a directory. Goes on magic rather than file extension so we hit wars, ears, rars and anything else they cooked up lately.""" def visit(jars, dir, items): for item in items: path = os.path.join(dir, item) if os.path.islink(path) or not os.path.isfile(path): continue # could use zipfile.is_zipfile() but this is quicker if open(path, "r").read(2) != "PK": continue zf = zipfile.ZipFile(path, "r") try: zf.getinfo("META-INF/MANIFEST.MF") except KeyError: continue assert not jars.has_key(item) jars[item] = zf jars = {} os.path.walk(dir, visit, jars) jars = [(jar.filename, jar) for jar in jars.values()] jars.sort() return [jar for path, jar in jars] def weed_jars(jars): """Remove any jarfiles that are completely contained within another. This is more common than you'd think, and we only need one nativified copy of each class after all.""" while True: for jar1 in jars: for jar2 in jars: if jar1 is jar2: continue for item2 in jar2.infolist(): try: item1 = jar1.getinfo(item2.filename) except KeyError: break if item1.CRC != item2.CRC: break else: warn("subsetted %s" % jar2.filename) jars.remove(jar2) break else: continue break else: break continue return jars def aot_compile_jar(jar, dir, libdir): """Generate the shared library and class mapping for one jarfile. If the shared library already exists then it will not be overwritten. This is to allow optimizer failures and the like to be worked around.""" basename = os.path.basename(jar.filename) soname = os.path.join(dir, basename + ".so") dbname = os.path.join(dir, basename + ".db") if os.path.exists(soname): warn("not recreating %s" % soname) else: sources = split_jarfile(jar, dir) if sources == [jar.filename]: # compile and link system([PATHS["gcj"], "-shared"] + GCJFLAGS + LDFLAGS + [jar.filename, "-o", soname]) else: # compile objects = [] for source in sources: object = os.path.join(dir, os.path.basename(source) + ".o") system([PATHS["gcj"], "-c"] + GCJFLAGS + [source, "-o", object]) objects.append(object) # link system([PATHS["gcj"], "-shared"] + GCJFLAGS + LDFLAGS + objects + ["-o", soname]) # clean up for item in sources + objects: os.unlink(item) # dbtool dbname = os.path.join(dir, basename + ".db") system([PATHS["dbtool"], "-n", dbname, "64"]) system([PATHS["dbtool"], "-f", dbname, jar.filename, os.path.join(libdir, basename + ".so")]) def split_jarfile(src, dir, split = 1500): """In order to avoid #158308 we must split large jarfiles on PPC.""" if os.environ.get("RPM_ARCH") != "ppc": return [src.filename] items = src.infolist() if len([i for i in items if i.filename.endswith(".class")]) < split: return [src.filename] warn("splitting %s" % src.filename) jarfiles, dst = [], None for item in items: if (dst is None or item.filename.endswith(".class") and size >= split): if dst is not None: dst.close() path = os.path.join(dir, "%s.%d.jar" % ( os.path.basename(src.filename), len(jarfiles) + 1)) jarfiles.append(path) dst = zipfile.ZipFile(path, "w", zipfile.ZIP_STORED) size = 0 dst.writestr(item, src.read(item.filename)) size += 1 dst.close() return jarfiles def system(command): """Execute a command.""" prefix = os.environ.get("PS4", "+ ") prefix = prefix[0] + prefix print >>sys.stderr, prefix + " ".join(command) status = os.spawnv(os.P_WAIT, command[0], command) if status > 0: raise Error, "%s exited with code %d" % status elif status < 0: raise Error, "%s killed by signal %d" % -status def warn(msg): """Print a warning message.""" print >>sys.stderr, "%s: warning: %s" % ( os.path.basename(sys.argv[0]), msg) if __name__ == "__main__": try: name = os.environ.get("RPM_PACKAGE_NAME") if name is None: raise Error, "this script is designed for use in rpm specfiles" arch = os.environ.get("RPM_ARCH") if arch == "noarch": raise Error, "cannot be used on noarch packages" buildroot = os.environ.get("RPM_BUILD_ROOT") if buildroot in (None, "/"): raise Error, "bad $RPM_BUILD_ROOT" aot_compile_rpm(buildroot, os.path.join(PATHS["libdir"], name)) except Error, e: print >>sys.stderr, "%s: error: %s" % ( os.path.basename(sys.argv[0]), e) From fitzsim at redhat.com Wed Jul 6 16:51:17 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 06 Jul 2005 12:51:17 -0400 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050706154056.GE4852@redhat.com> References: <20050706154056.GE4852@redhat.com> Message-ID: <1120668677.3379.67.camel@tortoise.toronto.redhat.com> Hi, On Wed, 2005-07-06 at 16:40 +0100, Gary Benson wrote: > Over the past couple of days I've been writing a replacement for > aot-compile and find-and-aot-compile. They were both good when they > were first written but the demands of Eclipse and JOnAS have exposed > numerous shortcomings. > > Attached is a copy of aot-compile-rpm which I'd like to commit into > java-1.4.2-gcj-compat if everyone's agreeable. It's an order of > magnitude more complex than aot-compile and find-and-aot-compile, but > it's advantages over them are manifold: > > IT'S MUCH MORE USABLE > ===================== > Nativifying an rpm using aot-compile-rpm is a matter of > copy-and-paste: > > 1. Remove "BuildArch: noarch" > 2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp" > and "Requires(post,postun)" on same. Releng told me to separate these requires: Requires(post): and Requires(postun): because certain versions of RPM fail on the (post,postun) syntax. > 3. Add "aot-compile-rpm" to the very end of %install. > 4. Add "/usr/bin/rebuild-gcj-db %{_libdir}" to %post and %postun. > 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files. > > With aot-compile or find-and-aot-compile step 4 was much more > complex. I was always uneasy about nativifying things I didn't > myself maintain, postgresql-jdbc for example, because I was wary of > dropping a bunch of fragile code on someone else. No longer. > > IT FINDS JARS BY SIGNATURE RATHER THAN BY EXTENSION > =================================================== > find-and-aot-compile identifies jarfiles by their extension, ".jar", > so it misses ".war", ".ear", ".rar", and anything else the Java > world happens to invent. aot-compile-rpm identifies jarfiles by > opening them, so it catches them no matter what they're called. > > It's already found some unexpected stuff. Tomcat, for example, has > a couple of servlets that are disabled by default because they are > in jarfiles called ".renametojar". aot-compile-rpm finds and > compiles these, so if the user renames them to enable the servlets > then they'll be running BC-compiled code. Does aot-compile-rpm provide a way to exclude certain jars from native compilation? This is sometimes necessary to work around gcj bugs. > > IT IGNORES SUBSETTED JARFILES > ============================= > Several packages contain jarfiles which are a subset of others. > MX4J, for example, has the APIs in mx4j-jmx.jar, the implementation > in mx4j-impl.jar, and both together in mx4j.jar. aot-compile-rpm > recognises that compiling mx4j.jar will get every class in the other > two jars too, so it'll only compile mx4j.jar. So, aot-compile-rpm > compiles MX4J in half the time (and generates half the bytes) that > find-and-aot-compile does. > > IT WORKS AROUND THE PPC GO2 LIMIT > ================================= > PPC machines are limited on the size of jarfiles that can be > compiled in one go, affecting Eclipse and JacORB, as described > at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308. > aot-compile-rpm splits large jarfiles on ppc to avoid this. > > One limitation of aot-compile and find-and-aot-compile that I have not > addressed (yet) is SMP support. Andrew Overholt suggested generating > a Makefile and letting make handle the complex stuff, which I think is > an excellent idea. Implementing something along those lines is > something I'd like to do, but I need to get ppc64 and s390* > bootstrapped first. Great! This will be excellent. Tom From gbenson at redhat.com Wed Jul 6 17:10:26 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 6 Jul 2005 18:10:26 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <1120668677.3379.67.camel@tortoise.toronto.redhat.com> References: <20050706154056.GE4852@redhat.com> <1120668677.3379.67.camel@tortoise.toronto.redhat.com> Message-ID: <20050706171026.GF4852@redhat.com> Thomas Fitzsimmons wrote: > On Wed, 2005-07-06 at 16:40 +0100, Gary Benson wrote: > > 2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp" > > and "Requires(post,postun)" on same. > > Releng told me to separate these requires: > > Requires(post): > > and > > Requires(postun): > > because certain versions of RPM fail on the (post,postun) syntax. I've seen bugs from it before, but I didn't know they worked separately. Cool... > > aot-compile-rpm identifies jarfiles by opening them, so it > > catches them no matter what they're called. > > Does aot-compile-rpm provide a way to exclude certain jars from > native compilation? This is sometimes necessary to work around gcj > bugs. There's no generic way, but if you have already compiled a solib yourself then it won't recreate it. This allows you to compile it with -O0 instead of -O2, for example, which has worked for every gcj bug I've seen so far. Cheers, Gary From overholt at redhat.com Wed Jul 6 17:48:23 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 06 Jul 2005 13:48:23 -0400 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050706171026.GF4852@redhat.com> References: <20050706154056.GE4852@redhat.com> <1120668677.3379.67.camel@tortoise.toronto.redhat.com> <20050706171026.GF4852@redhat.com> Message-ID: <1120672103.714.6.camel@tofu.toronto.redhat.com> On Wed, 2005-06-07 at 18:10 +0100, Gary Benson wrote: > Thomas Fitzsimmons wrote: > > Does aot-compile-rpm provide a way to exclude certain jars from > > native compilation? This is sometimes necessary to work around gcj > > bugs. > > There's no generic way, but if you have already compiled a solib > yourself then it won't recreate it. This allows you to compile it > with -O0 instead of -O2, for example, which has worked for every gcj > bug I've seen so far. The way we've been doing it with Eclipse is by moving the .jars that we don't want to be compiled to .jar.bak. This won't work with aot-compile-rpm, so we'll have to find a better way. -O2 -> -O0 doesn't work in some cases. Yes, tracking down the remaining mis-compilations is on my list of things to do :) . Andrew From greenrd at presidium.org Wed Jul 6 19:28:18 2005 From: greenrd at presidium.org (Robin Green) Date: Wed, 6 Jul 2005 15:28:18 -0400 (EDT) Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050706154056.GE4852@redhat.com> References: <20050706154056.GE4852@redhat.com> Message-ID: On Wed, 06 Jul 2005 16:40:56 +0100, Gary Benson wrote: > Over the past couple of days I've been writing a replacement for > aot-compile and find-and-aot-compile. Good stuff, looking forward to using it! I've attached a matching rebuild-gcj-db2 script and a sample Hello World .spec so that others can more easily try it out. Is it worth merging the .db files into one .db file per package, to reduce the number of files that have to be merged at RPM install time? -- Robin -------------- next part -------------- #!/bin/bash # rebuild-gcj-db2 : ${1?" $0: Re-build the gcj classmap .db Usage: $0 LIBDIR LIBDIR - the target library location "} dbLocation=`/usr/bin/gcj-dbtool -p $1` dbDir=`dirname $dbLocation` dbComponentDirs="$1/gcj $dbLocation.d" mkdir -p $dbDir $dbComponentDirs find $dbComponentDirs -type f -name '*.db' -print0 \ | /usr/bin/gcj-dbtool -0 -m $dbLocation -------------- next part -------------- %define name jhello %define version 1.0.0 %define release 3rdg Name: %name Summary: Hello World in Java Version: %version Release: %release License: Public Domain Group: Productivity Epoch: 0 Source: http://www.greenrd.org/sw/jhello/jhello.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release} Prefix: %{_prefix} Requires: java Requires: jpackage-utils Requires(post): java-1.4.2-gcj-compat Requires(postun): java-1.4.2-gcj-compat #BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp BuildRequires: java-gcj AutoReqProv: no %description jhello is the classic Hello World program in Java %prep %setup -q -n %{name}-%{version} %build gcj -g -C HelloWorld.java jar cvf %{name}.jar HelloWorld.class %install %__rm -rf $RPM_BUILD_ROOT %__mkdir_p %{buildroot}{%{_bindir},%{_javadir}} %__cp -a %{name}.jar $RPM_BUILD_ROOT/%{_javadir} # script %__cat > %{buildroot}/%{_bindir}/%{name} << EOF #!/bin/sh # # %{name} script # JPackage Project # Source functions library . %{_datadir}/java-utils/java-functions # Source system prefs if [ -f %{_sysconfdir}/%{name}.conf ] ; then . %{_sysconfdir}/%{name}.conf fi # Source user prefs if [ -f \$HOME/.%{name}rc ] ; then . \$HOME/.%{name}rc fi # Configuration MAIN_CLASS="HelloWorld" BASE_JARS="%{name}" # Set parameters set_jvm set_classpath \$BASE_JARS set_flags "" # Let's start run "\$@" EOF # Set optimization level to 0 # Not necessary - just demonstrates how it can be done RPM_OPT_FLAGS="-O0 `echo $RPM_OPT_FLAGS|sed -e 's|-O2||g'`" aot-compile-rpm %clean [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT %post rebuild-gcj-db2 %{_libdir} %postun rebuild-gcj-db2 %{_libdir} %files %defattr(0644,root,root,0755) %attr(0755,root,root) %{_bindir}/%{name} %{_javadir}/* %{_libdir}/gcj/%{name} %changelog * Wed Jul 06 2005 Robin Green - Changed to use proposed new aot-compile-rpm script * Tue Jul 05 2005 Robin Green - Changed to use proposed new find-and-aot-compile script * Sun Jun 26 2005 Robin Green - Initial release From jdesbonnet at gmail.com Thu Jul 7 00:21:46 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Thu, 7 Jul 2005 01:21:46 +0100 Subject: [fedora-java] Eclipse + Sysdeo tomcat plugin problem on FC4/i386 Message-ID: <1cef3e950507061721453fae1a@mail.gmail.com> Despite having the java and eclipse RPMs installed, I've decide to stick to the original tarball distributions of java, tomcat and eclipse for the moment (that setup works perfectly for me on FC2, FC3). Eclipse is in my home directory, Java is in /usr/local/jdk1.5.0_04 (with /usr/local/jdk1.5.0_04/bin at the top of my PATH env var). My Tomcat is in /opt/tomcat/jakarta-tomcat-5.5.9/.... I run eclipse as per normal and it works great, except when I use the Tomcat plugin from Sysdeo (tomcatPluginV31beta.zip) to start the Tomcat engine. Here is the console output from Eclipse when I attempt to start Tomcat: Jul 7, 2005 1:09:10 AM org.apache.catalina.startup.Catalina load WARNING: Can't load server.xml Jul 7, 2005 1:09:10 AM org.apache.catalina.startup.Catalina load WARNING: Can't load server.xml Jul 7, 2005 1:09:10 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 0 ms java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409) Caused by: java.lang.NullPointerException at org.apache.catalina.startup.Catalina.await(Catalina.java:600) at org.apache.catalina.startup.Catalina.start(Catalina.java:560) ... 6 more I suspect it's clashing with something already installed. I don't really want to remove java and all it's dependancies from my system unless absolutely necessary. The sysdeo plugin in configured properly (I think) -- it's configured to use the Sun JavaVM. Any ideas how I can diagnose this further? Thanks, Joe. From gbenson at redhat.com Thu Jul 7 08:35:57 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 7 Jul 2005 09:35:57 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: References: <20050706154056.GE4852@redhat.com> Message-ID: <20050707083555.GA15080@redhat.com> Robin Green wrote: > Is it worth merging the .db files into one .db file per package, to > reduce the number of files that have to be merged at RPM install > time? One big database doesn't work with packages that have more than one binary rpm containing jarfiles. The optimum would really be one database per binary rpm, but there's no way to get that information at a time you can make use of it. Cheers, Gary From gbenson at redhat.com Thu Jul 7 11:25:53 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 7 Jul 2005 12:25:53 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <1120672103.714.6.camel@tofu.toronto.redhat.com> References: <20050706154056.GE4852@redhat.com> <1120668677.3379.67.camel@tortoise.toronto.redhat.com> <20050706171026.GF4852@redhat.com> <1120672103.714.6.camel@tofu.toronto.redhat.com> Message-ID: <20050707112553.GA26149@redhat.com> Andrew Overholt wrote: > On Wed, 2005-06-07 at 18:10 +0100, Gary Benson wrote: > > Thomas Fitzsimmons wrote: > > > Does aot-compile-rpm provide a way to exclude certain jars from > > > native compilation? This is sometimes necessary to work around > > > gcj bugs. > > > > There's no generic way, but if you have already compiled a solib > > yourself then it won't recreate it. This allows you to compile it > > with -O0 instead of -O2, for example, which has worked for every > > gcj bug I've seen so far. > > The way we've been doing it with Eclipse is by moving the .jars that > we don't want to be compiled to .jar.bak. This won't work with > aot-compile-rpm, so we'll have to find a better way. -O2 -> -O0 > doesn't work in some cases. Yes, tracking down the remaining > mis-compilations is on my list of things to do :) . Ok, I added an --exclude option to handle this, and it's now built in beehive as java-1.4.2-gcj-compat-1.4.2.0-40jpp_32rh so if you could test it it would be very cool. You should be able to drop all solib compilation and database building stuff, sticking an aot-compile-rpm at the end of %install, and changing the %files sections to the new locations. Note that for --exclude the path you must is the final installed path of the jarfile, for example /usr/share/eclipse/plugins/org.eclipse.ui.workbench_3.1.0.jar (_not_ prefixed with $RPM_BUILD_ROOT). Note also that you shouldn't need to do this for the PPC limit (#158308) because aot-compile-rpm ought to be able to handle it. If you do have problems then let me know as it's a bug I should be fixing. Also note that for optimizer failures you can build the solib yourself into the location that aot-compile-rpm would have built it _before_ running aot-compile-rpm. aot-compile-rpm will generate the database for it. Finally, note that you can remove the %{_libdir} argument from all the rebuild-gcj-db commands, as it's not necessary any more. Cheers, Gary From greenrd at presidium.org Thu Jul 7 13:56:47 2005 From: greenrd at presidium.org (Robin Green) Date: Thu, 7 Jul 2005 09:56:47 -0400 (EDT) Subject: [fedora-java] Automating pre-build/checkout steps for eclipse features/plugins? Message-ID: While hacking on the eclipse-pydev rpm, and looking at packaging eclipse-emf and eclipse-ve for fedora, I've noticed that the procedure you have to follow to check out source code from CVS before you can even build a new version of a package, isn't obvious. (In fact, it doesn't seem to be really documented at all for some as-yet-unpackaged-by-fedora features, like eclipse-emf. run.sh? build.sh? start.sh? Which one should I use?) Take eclipse-pydev for example. In eclipse-pydev.spec we have just one source tarball: Source0: eclipse-pydev-fetched-HEAD-0.9.3.tar.gz However, not only is there no _formal_ description of where this came from (because there is no standard way of representing CVS branches and directories as URLs, and eclipse.org doesn't provide checked-out tarballs), this isn't even one single CVS checkout. It's actually (so far as I can make out) a combination of four CVS checkouts - org.python.pydev.releng, and then checked out within that, org.python.pydev, org.python.pydev.debug, and org.python.pydev.help. What I'd like to see eventually is a systematic way of scripting or describing the checkout of new versions, maybe in a new %fetch section in .spec files - so that no human intelligence, and definitely no mystic undocumented incantations (like on this page: http://download.eclipse.org/tools/emf/downloads/drops/2.1.0/I200506091102/buildlog.txt ) are required. It goes against the spirit of open source to have mystic undocumented incantations required to merely check out the source code in the correct structure required - or to do any "preBuild" steps: unfortunately, the eclipse.pde build system, which is used by a number of eclipse features, permits a "preBuild" step which occurs even *before* CVS checkout - which cannot in general be ran in a .spec file because checkout has already occurred by that point. (I don't think running anything before CVS checkout is a good idea, and I can't see why that would be necessary.) It may well be the case that the procedure for checking out most eclipse features from CVS in the right structure is in fact extremely simple. However, simple it may be, but it doesn't appear to be documented anywhere. Any suggestions? -- Robin From che666 at gmail.com Thu Jul 7 14:06:45 2005 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 7 Jul 2005 16:06:45 +0200 Subject: [fedora-java] open-xchange and gcj In-Reply-To: References: Message-ID: Hello to everyone. Id be curious if anyone yet successfully tried to build open-xchange with core 4 or rawhides gcj/libgcj. Id be very interested in the matter actually and it would be a first step to get nice Packages out for the exchange replacement to make it fit into a repository without nasty java dependencys. regards, Rudolf Kastl http://newrpms.sunsite.dk From greenrd at presidium.org Thu Jul 7 14:06:40 2005 From: greenrd at presidium.org (Robin Green) Date: Thu, 07 Jul 2005 15:06:40 +0100 Subject: [fedora-java] Re: aot-compile-rpm References: <20050706154056.GE4852@redhat.com> <1120668677.3379.67.camel@tortoise.toronto.redhat.com> <20050706171026.GF4852@redhat.com> Message-ID: On Wed, 06 Jul 2005 18:10:26 +0100, Gary Benson wrote: > There's no generic way, but if you have already compiled a solib > yourself then it won't recreate it. This allows you to compile it > with -O0 instead of -O2, for example, which has worked for every gcj > bug I've seen so far. By the way - if you compile with -O0, find-debuginfo.sh fails to find the source code, so you end up with missing source code in the -debuginfo package. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161722 where I've supplied a fix. This may be a moot point at the moment however, because some Java -debuginfo packages don't have any source code anyway, for another reason - see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153247 Obviously both are low-priority bugs at best, because you can just get the source code from the corresponding .src.rpm, rpmbuild -bp foo.spec to apply any patches, and then optionally shove it where the debugger can find it, which should work in 99% of cases, but I thought I'd mention them anyway. -- Robin From overholt at redhat.com Thu Jul 7 15:58:58 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 07 Jul 2005 11:58:58 -0400 Subject: [fedora-java] Automating pre-build/checkout steps for eclipse features/plugins? In-Reply-To: References: Message-ID: <1120751938.4063.19.camel@localhost.localdomain> On Thu, 2005-07-07 at 09:56 -0400, Robin Green wrote: > While hacking on the eclipse-pydev rpm, and looking at packaging > eclipse-emf and eclipse-ve for fedora, Phil Muldoon has already packaged EMF, GEF, and VE for our RHDS offerings. I've CCd him because he thinks that some work will be needed to update these to work with Eclipse 3.1 There are also issues that could bite us with our not-yet-complete swing implementation in Fedora. You two should discuss it. It would be great if you could shepherd these into Fedora Extras! > I've noticed that the procedure you have to follow to check out source > code from CVS before you can even build a new version of a package, > isn't obvious. Yeah, it sucks. Ben worked on a proposal to make this much easier: http://www.bagu.org/eclipse/plugin-source-drops.html > It may well be the case that the procedure for checking out most eclipse > features from CVS in the right structure is in fact extremely simple. > However, simple it may be, but it doesn't appear to be documented > anywhere. Ben sent a message to this mailing list a while back about how to generate the CDT tarballs: Subject: [fedora-java] generating a cdt 3.0 tarball Date: Thu, 17 Mar 2005 23:59:43 -0500 Message-Id: <1111121983.30148.6.camel at town.toronto.redhat.com> HTH, Andrew From overholt at redhat.com Thu Jul 7 16:06:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 7 Jul 2005 12:06:14 -0400 Subject: [fedora-java] IRC Channel Message-ID: <20050707160614.GA27800@redhat.com> Anyone want to set up an IRC channel for fedora-java stuff? I know we have #classpath (freenode), #eclipse{,-dev} (freenode), #java-gnome (gimpnet), #gcj (oftc), but I often feel bad spewing those channels with Fedora-specific chatter. Any suggestions? Andrew From tromey at redhat.com Thu Jul 7 16:08:53 2005 From: tromey at redhat.com (Tom Tromey) Date: 07 Jul 2005 10:08:53 -0600 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050706154056.GE4852@redhat.com> References: <20050706154056.GE4852@redhat.com> Message-ID: >>>>> "Gary" == Gary Benson writes: Gary> IT WORKS AROUND THE PPC GO2 LIMIT Gary> ================================= Gary> PPC machines are limited on the size of jarfiles that can be Gary> compiled in one go, affecting Eclipse and JacORB, as described Gary> at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308. Gary> aot-compile-rpm splits large jarfiles on ppc to avoid this. Gary> """In order to avoid #158308 we must split large jarfiles on PPC.""" Gary> if os.environ.get("RPM_ARCH") != "ppc": Gary> return [src.filename] You may want to do the splitting unconditionally. Then we won't generate machine-crushing gigabyte .s files anywhere, and we will be able to remove property files and other unused bits from the jars on all platforms. Tom From gbenson at redhat.com Thu Jul 7 16:17:15 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 7 Jul 2005 17:17:15 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: References: <20050706154056.GE4852@redhat.com> Message-ID: <20050707161714.GI26283@redhat.com> Tom Tromey wrote: > >>>>> "Gary" == Gary Benson writes: > > Gary> IT WORKS AROUND THE PPC GO2 LIMIT > Gary> ================================= > Gary> PPC machines are limited on the size of jarfiles that can be > Gary> compiled in one go, affecting Eclipse and JacORB, as described > Gary> at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308. > Gary> aot-compile-rpm splits large jarfiles on ppc to avoid this. > > Gary> """In order to avoid #158308 we must split large jarfiles on PPC.""" > Gary> if os.environ.get("RPM_ARCH") != "ppc": > Gary> return [src.filename] > > You may want to do the splitting unconditionally. Then we won't > generate machine-crushing gigabyte .s files anywhere, and we will be > able to remove property files and other unused bits from the jars on > all platforms. Since my machine has been in swapstorms over eclipse all afternoon I'm inclined to agree with you. When we compile, then nothing except classes are touched? Cheers, Gary From aph at redhat.com Thu Jul 7 16:19:59 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jul 2005 17:19:59 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050707161714.GI26283@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050707161714.GI26283@redhat.com> Message-ID: <17101.22064.487977.882580@zapata.pink> Gary Benson writes: > Tom Tromey wrote: > > >>>>> "Gary" == Gary Benson writes: > > > > Gary> IT WORKS AROUND THE PPC GO2 LIMIT > > Gary> ================================= > > Gary> PPC machines are limited on the size of jarfiles that can be > > Gary> compiled in one go, affecting Eclipse and JacORB, as described > > Gary> at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308. > > Gary> aot-compile-rpm splits large jarfiles on ppc to avoid this. > > > > Gary> """In order to avoid #158308 we must split large jarfiles on PPC.""" > > Gary> if os.environ.get("RPM_ARCH") != "ppc": > > Gary> return [src.filename] > > > > You may want to do the splitting unconditionally. Then we won't > > generate machine-crushing gigabyte .s files anywhere, and we will be > > able to remove property files and other unused bits from the jars on > > all platforms. > > Since my machine has been in swapstorms over eclipse all afternoon I'm > inclined to agree with you. > > When we compile, then nothing except classes are touched? Nothing except classes are used, no. Andrew. From gbenson at redhat.com Thu Jul 7 16:32:05 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 7 Jul 2005 17:32:05 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <17101.22064.487977.882580@zapata.pink> References: <20050706154056.GE4852@redhat.com> <20050707161714.GI26283@redhat.com> <17101.22064.487977.882580@zapata.pink> Message-ID: <20050707163204.GK26283@redhat.com> Andrew Haley wrote: > Gary Benson wrote: > > When we compile, then nothing except classes are touched? > > Nothing except classes are used, no. Cool, that's something I've been meaning to ask. I know it wasn't always like that, but I thought it might have changed with BC ABI. Cheers, Gary From gbenson at redhat.com Thu Jul 7 16:33:05 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 7 Jul 2005 17:33:05 +0100 Subject: [fedora-java] Re: aot-compile-rpm In-Reply-To: References: <20050706154056.GE4852@redhat.com> <1120668677.3379.67.camel@tortoise.toronto.redhat.com> <20050706171026.GF4852@redhat.com> Message-ID: <20050707163305.GL26283@redhat.com> Robin Green wrote: > Obviously both are low-priority bugs at best, because you can just > get the source code from the corresponding .src.rpm, rpmbuild -bp > foo.spec to apply any patches, and then optionally shove it where > the debugger can find it, which should work in 99% of cases, but I > thought I'd mention them anyway. Thanks :) From aph at redhat.com Thu Jul 7 16:35:14 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jul 2005 17:35:14 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050707163204.GK26283@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050707161714.GI26283@redhat.com> <17101.22064.487977.882580@zapata.pink> <20050707163204.GK26283@redhat.com> Message-ID: <17101.22978.973791.649109@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson wrote: > > > When we compile, then nothing except classes are touched? > > > > Nothing except classes are used, no. > > Cool, that's something I've been meaning to ask. I know it wasn't > always like that, but I thought it might have changed with BC ABI. It hansn't, not really. It's just that when we have the jar files around anyway there's no point diverting accesses to resources in the jars into the binary files. Andrew. From gbenson at redhat.com Thu Jul 7 16:36:27 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 7 Jul 2005 17:36:27 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <17101.22978.973791.649109@zapata.pink> References: <20050706154056.GE4852@redhat.com> <20050707161714.GI26283@redhat.com> <17101.22064.487977.882580@zapata.pink> <20050707163204.GK26283@redhat.com> <17101.22978.973791.649109@zapata.pink> Message-ID: <20050707163626.GM26283@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Andrew Haley wrote: > > > Gary Benson wrote: > > > > When we compile, then nothing except classes are touched? > > > > > > Nothing except classes are used, no. > > > > Cool, that's something I've been meaning to ask. I know it wasn't > > always like that, but I thought it might have changed with BC ABI. > > It hansn't, not really. It's just that when we have the jar files > around anyway there's no point diverting accesses to resources in > the jars into the binary files. Yeah. Cheers, Gary From pmuldoon at redhat.com Thu Jul 7 20:33:04 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 07 Jul 2005 15:33:04 -0500 Subject: [fedora-java] Automating pre-build/checkout steps for eclipse features/plugins? In-Reply-To: <1120751938.4063.19.camel@localhost.localdomain> References: <1120751938.4063.19.camel@localhost.localdomain> Message-ID: <1120768384.3592.16.camel@dhcp-12.hsv.redhat.com> On Thu, 2005-07-07 at 11:58 -0400, Andrew Overholt wrote: > On Thu, 2005-07-07 at 09:56 -0400, Robin Green wrote: > > While hacking on the eclipse-pydev rpm, and looking at packaging > > eclipse-emf and eclipse-ve for fedora, > > Phil Muldoon has already packaged EMF, GEF, and VE for our RHDS > offerings. I've CCd him because he thinks that some work will be needed > to update these to work with Eclipse 3.1 There are also issues that > could bite us with our not-yet-complete swing implementation in Fedora. > You two should discuss it. It would be great if you could shepherd > these into Fedora Extras! Dave Orme, the leader of the VEP project over at eclipse.org, has also expressed interest in this. So CC there. The big thing is to remove the SWING components from VEP. No free implementation support for that in Fedora (yet). That would leave SWT. The other architectural concern is how VEP draws the bean in the editor. Basically it starts a remote JVM, draws the widgets in the remote bean, then screen scrapes from that JVM and paints them in the editor. Are there implications with this relating to GCJ? Maybe with gij this might not be an issue. If I remember correctly, all three projects have associated releng plug-ins (this is how I packaged them before). Is this a viable approach for Fedora Extras? Should we define a different (jpackage-like?) approach here? Regards Phil From greenrd at presidium.org Thu Jul 7 21:34:18 2005 From: greenrd at presidium.org (Robin Green) Date: Thu, 07 Jul 2005 22:34:18 +0100 Subject: [fedora-java] Re: IRC Channel References: <20050707160614.GA27800@redhat.com> Message-ID: On Thu, 07 Jul 2005 12:06:14 -0400, Andrew Overholt wrote: > Anyone want to set up an IRC channel for fedora-java stuff? I would like to see this. I often find myself wading into stuff to find out what a problem is being caused by, so as to avoid taking up people's time with a trivial or hazy, ill-formed question on the list... with IRC there's less of a concern about asking trivial or misconceived questions. (Er, that's not to suggest that I would use the IRC channel entirely to ask stupid questions ;) > I know we have > #classpath (freenode), #eclipse{,-dev} (freenode), #java-gnome (gimpnet), > #gcj (oftc), but I often feel bad spewing those channels with > Fedora-specific chatter. Me too. > Any suggestions? Well, you've called the list fedora-java, so it's got to be #fedora-java now to be consistent, really. Or how about #ffj (Fedora Free Java)? -- Robin From i.pilcher at comcast.net Thu Jul 7 22:05:23 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 07 Jul 2005 17:05:23 -0500 Subject: [fedora-java] Re: Java API doc (javadoc) from GCJ/classpath? In-Reply-To: <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: Anthony Green wrote: > I look into submitting it to extras. This reminds me... we should > import the GNU Classpath package description html files into GCC. Anthony - I'm playing with the GCC SPEC file, working on adding a libgcj-doc subpackage. Can you provide some more detail on the statement above (i.e. where are the package descriptions found, and how would I "import" them)? Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From green at redhat.com Thu Jul 7 23:29:31 2005 From: green at redhat.com (Anthony Green) Date: Thu, 07 Jul 2005 16:29:31 -0700 Subject: [fedora-java] Re: Java API doc (javadoc) from GCJ/classpath? In-Reply-To: References: <1120590978.714.0.camel@tofu.toronto.redhat.com> <1120596269.2951.28.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1120778971.2941.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Thu, 2005-07-07 at 17:05 -0500, Ian Pilcher wrote: > I'm playing with the GCC SPEC file, working on adding a libgcj-doc > subpackage. Great! > Can you provide some more detail on the statement above > (i.e. where are the package descriptions found, and how would I "import" > them)? You'll want to look for the GNU Classpath project CVS sources. I believe each java source directory contains a package.html file which is incorporated into the HTML docs generated by gjdoc. Our libjava tree in GCC is missing these files. However... I believe tromey has a plan to merge these into the FSF GCC HEAD tree for future GCC releases (4.1, etc), but this is something we can't really apply to the FSF 4.0 branch we're using in FC4. I believe the 4.0 branch is frozen right now, so I don't know what the best thing to do is. Either we merge those files into the FSF 4.0 branch and hope that Jakub picks it up in his FC4 gcc respin, or we a patch to add the files and bundle that in the GCC RPM. Maybe somebody who knows more about the FC GCC plan can suggest an approach. AG From overholt at redhat.com Fri Jul 8 01:13:31 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 7 Jul 2005 21:13:31 -0400 Subject: [fedora-java] Re: IRC Channel In-Reply-To: References: <20050707160614.GA27800@redhat.com> Message-ID: <20050708011331.GA5228@redhat.com> * Robin Green [2005-07-07 17:36]: > Well, you've called the list fedora-java, so it's got to be #fedora-java > now to be consistent, really. Or how about #ffj (Fedora Free Java)? I like #fedora-java. Aaron said he opened the channel somewhere. Where was it, Aaron? Andrew From greenrd at presidium.org Fri Jul 8 01:23:13 2005 From: greenrd at presidium.org (Robin Green) Date: Thu, 7 Jul 2005 21:23:13 -0400 (EDT) Subject: [fedora-java] Automating pre-build/checkout steps for eclipse features/plugins? In-Reply-To: <1120768384.3592.16.camel@dhcp-12.hsv.redhat.com> References: <1120751938.4063.19.camel@localhost.localdomain> <1120768384.3592.16.camel@dhcp-12.hsv.redhat.com> Message-ID: On Thu, 7 Jul 2005, Phil Muldoon wrote: > On Thu, 2005-07-07 at 11:58 -0400, Andrew Overholt wrote: >> Phil Muldoon has already packaged EMF, GEF, and VE for our RHDS >> offerings. I've CCd him because he thinks that some work will be needed >> to update these to work with Eclipse 3.1 There are also issues that >> could bite us with our not-yet-complete swing implementation in Fedora. >> You two should discuss it. It would be great if you could shepherd >> these into Fedora Extras! > > Dave Orme, the leader of the VEP project over at eclipse.org, has also > expressed interest in this. So CC there. > > The big thing is to remove the SWING components from VEP. No free > implementation support for that in Fedora (yet). That would leave SWT. > > The other architectural concern is how VEP draws the bean in the editor. > Basically it starts a remote JVM, draws the widgets in the remote bean, > then screen scrapes from that JVM and paints them in the editor. Are > there implications with this relating to GCJ? Maybe with gij this might > not be an issue. > > If I remember correctly, all three projects have associated releng > plug-ins (this is how I packaged them before). Is this a viable approach > for Fedora Extras? Should we define a different (jpackage-like?) > approach here? Are you asking, should we use the releng "plugins" to build them? Assuming you mean that, I think we should. Otherwise we're creating a redundant second build system. JPackage generally uses whatever build system the upstream project uses - be that ant, maven or whatever. Could you post (to me, or to the list) the .spec files you have done for RHDS? -- Robin From aluchko at redhat.com Fri Jul 8 01:40:17 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Thu, 07 Jul 2005 21:40:17 -0400 Subject: [fedora-java] Re: IRC Channel In-Reply-To: <20050708011331.GA5228@redhat.com> References: <20050707160614.GA27800@redhat.com> <20050708011331.GA5228@redhat.com> Message-ID: <1120786818.3738.25.camel@jekyll> On Thu, 2005-07-07 at 21:13 -0400, Andrew Overholt wrote: > * Robin Green [2005-07-07 17:36]: > > Well, you've called the list fedora-java, so it's got to be #fedora-java > > now to be consistent, really. Or how about #ffj (Fedora Free Java)? > > I like #fedora-java. Aaron said he opened the channel somewhere. Where > was it, Aaron? Given that I'm already on a few freenode channels I went the lazy route and opened it on freenode as well :) Aaron From mark at klomp.org Fri Jul 8 13:03:45 2005 From: mark at klomp.org (Mark Wielaard) Date: Fri, 08 Jul 2005 15:03:45 +0200 Subject: [fedora-java] Re: Compiling OpenExchange with gcj and classpath In-Reply-To: <42CE7183.4010606@randomink.org> References: <42CE7183.4010606@randomink.org> Message-ID: <1120827825.5881.27.camel@localhost.localdomain> Hi, On Fri, 2005-07-08 at 17:58 +0530, Soumyadip Modak wrote: > Recently I've been looking at OpenExchange on Fedora Core 4. I was > hoping to utilise FC4's extensive free Java tools to build OX. OX > configure script didn't thorw up any problems but make failed witha lot > of errors. Can anyone please guide me how to rectify these problems to > get a completely free groupware solution ? > > Errors : I had a quick look at the errors. Below is an quick analysis, but no real solutions yet. Hopefully others can give more specific suggestions. - the servlet related warnings should be easy to solve. I am actually a Debian user. But I believe Fedora has a package called tomcat5-servlet (which you can use depending on the license of OpenExchange, unfortunately it isn't GPL compatible. There is a LGPL servlet implementation distributed with gnu paperclipse, but I don't know if Fedora ships that.). Try using "yum search servlet". - the sun.misc.BASE64 usage. That one is nasty since that isn't a publicly documented class. It shouldn't be hard to replace that code since base64 en/decoding isn't actually that difficult. (For an examples see gnu/java/net/BASE64.java or gnu/java/io/Base64InputStream.java in GNU Classpath) - ParserDelegator.parse() is missing in gcj4, but we have it in GNU Classpath. This should be backported to libgcj. Same for javax.swing.text.html.HTMLEditorKit. (Although it is mainly stubs at the moment.) - The usage of com.sun.mail ImapFolder and Rights is another non-documented, non-free issue. Hopefully that can be fixed by using an appropriate class from GNU mail or inetlib. It looks like this program was developed against a proprietary non-free java platform implementation and the use of non-standard, undocumented classes is a bit of a problem. The biggest issue is the imap and html usage for which it might be some work to create free replacements. But work is already been done on this, so it might not be that hard in the end. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pmuldoon at redhat.com Fri Jul 8 14:55:57 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Fri, 08 Jul 2005 09:55:57 -0500 Subject: [fedora-java] Automating pre-build/checkout steps for eclipse features/plugins? In-Reply-To: References: <1120751938.4063.19.camel@localhost.localdomain> <1120768384.3592.16.camel@dhcp-12.hsv.redhat.com> Message-ID: <1120834557.3771.7.camel@dhcp-12.hsv.redhat.com> > Are you asking, should we use the releng "plugins" to build them? > Assuming you mean that, I think we should. Otherwise we're creating > a redundant second build system. JPackage generally uses whatever build > system the upstream project uses - be that ant, maven or whatever. JPackage already package GEF and I don't think they use that project's releng plug-in (at least not the last time I looked). There are many problem with the releng plug-in (as discussed in Ben's proposal that Andrew posted), but point well taken on re-solving the problem. > Could you post (to me, or to the list) the .spec files you have done for > RHDS? They basically render down to calling the releng plugins and tar'ing up the output. However they are based on old versions of the VE/EMF/GEF and still expect zips to drop instead of tar.gz. Also the spec files do not use GCJ. We basically rewrote the CDT spec file for Fedora from the ground up, and it has little (if any) similarity to the spec file in RHDS. Let me ask about the spec files, but even better, I'll attempt a first GCJ spec cut for VE/GEF/EMF based off the CDT spec file, with the appropriate GCJ/dbtool bits worked in. Phil -- GPG Key ID: 1024D/239442FF From david at zarb.org Fri Jul 8 16:09:28 2005 From: david at zarb.org (David Walluck) Date: Fri, 8 Jul 2005 12:09:28 -0400 Subject: [fedora-java] Automating pre-build/checkout steps for eclipse features/plugins? In-Reply-To: <1120834557.3771.7.camel@dhcp-12.hsv.redhat.com> References: <1120751938.4063.19.camel@localhost.localdomain> <1120768384.3592.16.camel@dhcp-12.hsv.redhat.com> <1120834557.3771.7.camel@dhcp-12.hsv.redhat.com> Message-ID: <20050708120928.zan2wmop0ko4k44k@www.zarb.org> Phil Muldoon wrote: > JPackage already package GEF and I don't think they use that project's > releng plug-in (at least not the last time I looked). There are many > problem with the releng plug-in (as discussed in Ben's proposal that > Andrew posted), but point well taken on re-solving the problem. We (JPackage) build GEF manually using the provided source zips. However, we ran into a couple missing files since the source zips are not meant for building, but are instead meant for internal use by eclipse only. The plugin method has problems, but the above method is not really valid in the long run. If we tried building more than one plugin like this, I think we'd be in trouble. I haven't really looked at the spec for cdt, so I don't know how this is done, but I don't think the plugin method works either, based on Ben's proposal for fixing it. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From soumyadip at randomink.org Fri Jul 8 19:04:08 2005 From: soumyadip at randomink.org (Soumyadip Modak) Date: Sat, 09 Jul 2005 00:34:08 +0530 Subject: [fedora-java] Compiling OpenExchange with gcj and classpath Message-ID: <42CECE28.6070204@randomink.org> Resending to the Fedora-Java list, as my previous mail seems to have been rejected, and adding the OX user list: Hello, Recently I've been looking at OpenExchange on Fedora Core 4. I was hoping to utilise FC4's extensive free Java tools to build OX. OX configure script didn't thorw up any problems but make failed witha lot of errors. Can anyone please guide me how to rectify these problems to get a completely free groupware solution ? Errors : [Full list of errors at http://www.randomink.org/soumyadip/error] Making all in javabuild make[1]: Entering directory `/root/open-xchange-0.8.0-3/javabuild' /usr/bin/ant -f ../build.xml Buildfile: ../build.xml init: [javac] import com.openexchange.tools.encoding.Base64; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import com.openexchange.tools.encoding.Base64 is never used [javac] 2. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactInsEdit.java [javac] (at line 98) [javac] import sun.misc.BASE64Decoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] import sun.misc.BASE64Encoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] (at line 546) [javac] String fullcache = new BASE64Encoder().encodeBuffer(cache); [javac] ^^^^^^^^^^^^^ [javac] BASE64Encoder cannot be resolved to a type [javac] 6. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactManagement.java [javac] (at line 85) [javac] import sun.misc.BASE64Decoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] 24. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/ComposeMessage.java [javac] (at line 383) [javac] new ParserDelegator().parse(new StringReader(tmp_wms.getHTMLMailText().toString()), [javac] ^^^^^ [javac] The method parse(StringReader, html2text, boolean) is undefined for the type ParserDelegator [javac] 26. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 68) [javac] import com.sun.mail.imap.IMAPFolder; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] 28. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 180) [javac] IMAPFolder fa = (IMAPFolder)imapStore.getFolder("INBOX"); [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] 32. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 348) [javac] Rights rights = fa.myRights(); [javac] ^^^^^^ [javac] Rights cannot be resolved to a type [javac] 58. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageList.java [javac] (at line 72) [javac] import com.sun.mail.imap.Rights; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] 64. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/OXWorker.java [javac] (at line 442) [javac] String auth = "Basic " + new sun.misc.BASE64Encoder().encode((nasObjectOperations.getWUSObject(no).getUsername() + ":" + nasObjectOperations.getWUSObject(no).getPassword()).getBytes()); [javac] ^^^^^^^^ [javac] sun.misc cannot be resolved to a type [javac] 80. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 50) [javac] import javax.swing.text.html.HTMLEditorKit; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import javax.swing.text.html.HTMLEditorKit cannot be resolved [javac] 81. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 59) [javac] public class html2text extends HTMLEditorKit.ParserCallback { [javac] ^^^^^^^^^^^^^ [javac] HTMLEditorKit cannot be resolved to a type [javac] 82. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 70) [javac] if (tag.equals(HTML.Tag.BLOCKQUOTE)) { [javac] ^^^^^^^^^^^^^^^^^^^ [javac] HTML.Tag.BLOCKQUOTE cannot be resolved etc. Thanks -- Soumyadip Modak soumyadip.modak at gmail.com soumyadip at randomink.org http://www.randomink.org/soumyadip From overholt at redhat.com Fri Jul 8 19:05:30 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 8 Jul 2005 15:05:30 -0400 Subject: [fedora-java] Compiling OpenExchange with gcj and classpath In-Reply-To: <42CECE28.6070204@randomink.org> References: <42CECE28.6070204@randomink.org> Message-ID: <20050708190530.GA18474@redhat.com> Hi, * Soumyadip Modak [2005-07-08 15:03]: > Recently I've been looking at OpenExchange on Fedora Core 4. This would be something great to have. > Can anyone please guide me how to rectify these problems to get a > completely free groupware solution ? I'm assuming you saw Mark Wielaard's post? He summarizes the issues well. Andrew From soumyadip at randomink.org Fri Jul 8 19:14:57 2005 From: soumyadip at randomink.org (Soumyadip Modak) Date: Sat, 09 Jul 2005 00:44:57 +0530 Subject: [fedora-java] Compiling OpenExchange with gcj and classpath In-Reply-To: <20050708190530.GA18474@redhat.com> References: <42CECE28.6070204@randomink.org> <20050708190530.GA18474@redhat.com> Message-ID: <42CED0B1.9070602@randomink.org> Andrew Overholt wrote: >Hi, > >* Soumyadip Modak [2005-07-08 15:03]: > > >>Recently I've been looking at OpenExchange on Fedora Core 4. >> >> > >This would be something great to have. > > > >>Can anyone please guide me how to rectify these problems to get a >>completely free groupware solution ? >> >> > >I'm assuming you saw Mark Wielaard's post? He summarizes the issues well. > >Andrew > > > > > Yup.. I saw Mark's post, I'm waiting a bit for the OX people to respond before I go ahead and try hacking the source code Thanks for the encouragement. Hope to have the OX dev.s interested in this. Thanks -- Soumyadip Modak soumyadip.modak at gmail.com soumyadip at randomink.org http://www.randomink.org/soumyadip From bishoph at open-xchange.org Fri Jul 8 22:05:18 2005 From: bishoph at open-xchange.org (Martin Kauss) Date: Sat, 9 Jul 2005 00:05:18 +0200 (CEST) Subject: [fedora-java] Re: [OX Devel] Compiling OpenExchange with gcj and classpath In-Reply-To: <42CE7183.4010606@randomink.org> References: <42CE7183.4010606@randomink.org> Message-ID: <3454753.1120860319026.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> On Jul 08, 2005 02:28 PM, Soumyadip Modak wrote: > Hello, > Recently I've been looking at OpenExchange on Fedora Core 4. I was > hoping to utilise FC4's extensive free Java tools to build OX. OX > configure script didn't thorw up any problems but make failed witha lot > of errors. Can anyone please guide me how to rectify these problems to > get a completely free groupware solution ? > > Errors : > > Making all in javabuild > make[1]: Entering directory `/root/open-xchange-0.8.0-3/javabuild' > /usr/bin/ant -f ../build.xml > Buildfile: ../build.xml > > init: > > compilewebdav: > [javac] Compiling 14 source files to /root/open-xchange-0.8.0-3/build > [javac] ---------- > [javac] 1. WARNING in > /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactInsEdit.java > [javac] (at line 96) > [javac] import com.openexchange.tools.encoding.Base64; > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [javac] The import com.openexchange.tools.encoding.Base64 is never used > [javac] ---------- > [javac] ---------- [REMOVED LOTS OF ERROR MESSAGES] > [javac] (at line 53) > [javac] public class OXFolderPermissionException extends Throwable { > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [javac] The serializable class OXFolderPermissionException does not > declare a static final serialVersionUID field of type long > [javac] ---------- > [javac] 120 problems (84 errors, 36 warnings) > > Sorry for flooding. > > Thanks > > Soumyadip Modak > soumyadip at randomink.org > soumyadip.modak at gmail.com > http://www.randomink.org/soumyadip > Hi, the configure just checks the system dependencies to build the system. The needed libraries are not checked until the compile process, JFYI. The questions was asked some month ago for a Debian package as well. I tried to build Open-Xchange some time ago with GNU Classpath, but specially for mail, necessary methods and functions are just missing. We are just providing a collaboration framework and that is our focus. This means, if the functionality is covered by any other package than Sun's Javamail package one can build OX with this packages. Currently - AFAIK - this is not possible. The other question is what you mean with "extensive free Java tools" ... for some ppl. also packages offered by Sun/IBM/Bea are "free" ... By reading your website i have to mention that we have working environments (and test systems of course) with IBM JDK as well and i know admins who are using the BEA JDK to resolve errors. Greetings, Martin Kauss From soumyadip at randomink.org Sat Jul 9 03:15:30 2005 From: soumyadip at randomink.org (Soumyadip Modak) Date: Sat, 09 Jul 2005 08:45:30 +0530 Subject: [fedora-java] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: References: Message-ID: <42CF4152.3050106@randomink.org> Martin Kauss wrote > Hi, > > the configure just checks the system dependencies to build the > system. The needed libraries are not checked until the compile > process, JFYI. > > The questions was asked some month ago for a Debian package as well. > I tried to build Open-Xchange some time ago with GNU Classpath, but > specially for mail, necessary methods and functions are just missing. So what I understand is this: (Correct me if I'm wrong) 1. Problems with servlets are solvable with free Java tools, and these are not major showstoppers 2. Base64 and Parserdelegator problems need some work 3. Main problem is that the free Javamail does not implement some methods that are needed by OX. Is it possible for the OX developers to work with the Classpath developers to resolve these problems ? As far as I can understand there is no major bottleneck other than some missing functionality, and I'm sure that the Classpath people would love to have people collaborating with them. :) > We are just providing a collaboration framework and that is our > focus. This means, if the functionality is covered by any other > package than Sun's Javamail package one can build OX with this > packages. > > Currently - AFAIK - this is not possible. > > The other question is what you mean with "extensive free Java tools" > ... for some ppl. also packages offered by Sun/IBM/Bea are "free" ... I generally refer to the Debian Free Software Guidelines for my definition of Free software :) http://www.debian.org/social_contract#guidelines Thanks a lot -- Soumyadip Modak soumyadip.modak at gmail.com soumyadip at randomink.org http://www.randomink.org/soumyadip From bishoph at open-xchange.org Sat Jul 9 06:32:14 2005 From: bishoph at open-xchange.org (Martin Kauss) Date: Sat, 9 Jul 2005 08:32:14 +0200 (CEST) Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: <42CF4152.3050106@randomink.org> References: <42CF4152.3050106@randomink.org> Message-ID: <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> On Jul 09, 2005 05:15 AM, Soumyadip Modak wrote: > Martin Kauss wrote > > Hi, > > > > the configure just checks the system dependencies to build the > > system. The needed libraries are not checked until the compile > > process, JFYI. > > > > The questions was asked some month ago for a Debian package as well. > > I tried to build Open-Xchange some time ago with GNU Classpath, but > > specially for mail, necessary methods and functions are just missing. > > So what I understand is this: (Correct me if I'm wrong) > 1. Problems with servlets are solvable with free Java tools, and these > are not major showstoppers I am not aware of any servlet issues at all, tomcat for example should provide all necessary libraries. > 2. Base64 and Parserdelegator problems need some work Specially the ParserDelegator class should be part of a JDK since Java 1.2 as far as i can remember, see http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/html/parser/ParserDelegator.html and http://developer.classpath.org/doc/javax/swing/text/html/parser/ParserDelegator-source.html > 3. Main problem is that the free Javamail does not implement some > methods that are needed by OX. Correct. > Is it possible for the OX developers to work with the Classpath > developers to resolve these problems ? As far as I can understand there > is no major bottleneck other than some missing functionality, and I'm > sure that the Classpath people would love to have people collaborating > with them. :) Not sure what you mean with "to work ... to resolve these problems", but in general the answer is yes. Finally i would like to mention that Sun do a great Job for Javamail with the mail protocol support and with the supported mail servers and IMHO it will not be easy to get to the same functionality. > > We are just providing a collaboration framework and that is our > > focus. This means, if the functionality is covered by any other > > package than Sun's Javamail package one can build OX with this > > packages. > > > > Currently - AFAIK - this is not possible. > > > > The other question is what you mean with "extensive free Java tools" > > ... for some ppl. also packages offered by Sun/IBM/Bea are "free" ... > > I generally refer to the Debian Free Software Guidelines for my > definition of Free software :) > http://www.debian.org/social_contract#guidelines > > Thanks a lot > -- > Soumyadip Modak > soumyadip.modak at gmail.com > soumyadip at randomink.org > http://www.randomink.org/soumyadip > Ciao, Martin Kauss From konqueror at gmx.de Sat Jul 9 07:02:58 2005 From: konqueror at gmx.de (Michael Koch) Date: Sat, 9 Jul 2005 09:02:58 +0200 Subject: [fedora-java] Re: [OX Devel] Compiling OpenExchange with gcj and classpath In-Reply-To: <3454753.1120860319026.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> References: <42CE7183.4010606@randomink.org> <3454753.1120860319026.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> Message-ID: <20050709070258.GE7201@asterix.konqueror.de> On Sat, Jul 09, 2005 at 12:05:18AM +0200, Martin Kauss wrote: > On Jul 08, 2005 02:28 PM, Soumyadip Modak wrote: > > > Hello, > > Recently I've been looking at OpenExchange on Fedora Core 4. I was > > hoping to utilise FC4's extensive free Java tools to build OX. OX > > configure script didn't thorw up any problems but make failed witha lot > > of errors. Can anyone please guide me how to rectify these problems to > > get a completely free groupware solution ? > > > > Errors : > > > > Making all in javabuild > > make[1]: Entering directory `/root/open-xchange-0.8.0-3/javabuild' > > /usr/bin/ant -f ../build.xml > > Buildfile: ../build.xml > > > > init: > > > > compilewebdav: > > [javac] Compiling 14 source files to /root/open-xchange-0.8.0-3/build > > [javac] ---------- > > [javac] 1. WARNING in > > /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactInsEdit.java > > [javac] (at line 96) > > [javac] import com.openexchange.tools.encoding.Base64; > > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [javac] The import com.openexchange.tools.encoding.Base64 is never used > > [javac] ---------- > > [javac] ---------- > > > [REMOVED LOTS OF ERROR MESSAGES] > > > > [javac] (at line 53) > > [javac] public class OXFolderPermissionException extends Throwable { > > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [javac] The serializable class OXFolderPermissionException does not > > declare a static final serialVersionUID field of type long > > [javac] ---------- > > [javac] 120 problems (84 errors, 36 warnings) > > > > Sorry for flooding. > > > > Thanks > > > > Soumyadip Modak > > soumyadip at randomink.org > > soumyadip.modak at gmail.com > > http://www.randomink.org/soumyadip > > > > > Hi, > > the configure just checks the system dependencies to > build the system. The needed libraries are not checked > until the compile process, JFYI. > > The questions was asked some month ago for a Debian > package as well. I tried to build Open-Xchange some > time ago with GNU Classpath, but specially for mail, > necessary methods and functions are just missing. > > We are just providing a collaboration framework and > that is our focus. This means, if the functionality > is covered by any other package than Sun's Javamail > package one can build OX with this packages. > > Currently - AFAIK - this is not possible. > > The other question is what you mean with > "extensive free Java tools" ... for some > ppl. also packages offered by Sun/IBM/Bea are "free" ... You mean "free" as in "free beer" but we would like to use software that is "free" as in "freedom". Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ From dog at bluezoo.org Sat Jul 9 07:54:27 2005 From: dog at bluezoo.org (Chris Burdess) Date: Sat, 9 Jul 2005 08:54:27 +0100 Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> Message-ID: <20050709075427.GA24894@bluezoo.org> Martin Kauss wrote: > > So what I understand is this: (Correct me if I'm wrong) > > 1. Problems with servlets are solvable with free Java tools, and these > > are not major showstoppers > > I am not aware of any servlet issues at all, tomcat for example > should provide all necessary libraries. GNU provides the servlet API 2.4: cvs -d anoncvs at savannah.gnu.org:/cvsroot/classpathx co servletapi If a package is needed I can make one. > > 3. Main problem is that the free Javamail does not implement some > > methods that are needed by OX. > > Correct. I haven't heard any issues raised on classpathx-javamail at gnu.org or submitted as bugs or patches at http://savannah.gnu.org/projects/classpathx GNU JavaMail provides all the API methods provided by the JavaMail API. If OX depends on com.sun APIs or on undocumented session properties, this is an issue for OX to resolve. If there is functionality you want exposing, there should be no problem, but you have to let us know. > Finally i would like to mention that Sun do a great Job for Javamail > with the mail protocol support and with the supported mail servers > and IMHO it will not be easy to get to the same functionality. GNU JavaMail doesn't explicitly support servers, it implements the published standards. Sun's implementation supports 3 providers (IMAP4, POP3, SMTP). GNU JavaMail supports 6 providers (IMAP4rev1, POP3, SMTP, NNTP, mbox, Maildir) and we had SASL and STARTTLS support long before Sun. Arguably we provide considerably more functionality. -- Chris Burdess From greenrd at presidium.org Sat Jul 9 09:16:01 2005 From: greenrd at presidium.org (Robin Green) Date: Sat, 09 Jul 2005 10:16:01 +0100 Subject: [fedora-java] Re: aot-compile-rpm References: <20050706154056.GE4852@redhat.com> <1120668677.3379.67.camel@tortoise.toronto.redhat.com> <20050706171026.GF4852@redhat.com> <1120672103.714.6.camel@tofu.toronto.redhat.com> <20050707112553.GA26149@redhat.com> Message-ID: The new rebuild-gcj-db will fail (I think) if the full list of .db files cannot fit on one Linux command line. The following patch, which I just tested, fixes this: --- rebuild-gcj-db.orig 2005-07-09 10:07:00.000000000 +0100 +++ rebuild-gcj-db 2005-07-09 10:07:19.000000000 +0100 @@ -17,4 +17,4 @@ dirname $dbLocation | xargs mkdir -p /usr/bin/gcj-dbtool -n $dbLocation 64 find $dbLocation.d /usr/lib/gcj -name '*.db' -print0 | \ - xargs -0 /usr/bin/gcj-dbtool -m $dbLocation $dbLocation + /usr/bin/gcj-dbtool -0 -m $dbLocation $dbLocation From bishoph at open-xchange.org Sat Jul 9 11:21:08 2005 From: bishoph at open-xchange.org (Martin Kauss) Date: Sat, 9 Jul 2005 13:21:08 +0200 (CEST) Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: <20050709075427.GA24894@bluezoo.org> References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> Message-ID: <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> On Jul 09, 2005 09:54 AM, Chris Burdess wrote: > Martin Kauss wrote: > > > So what I understand is this: (Correct me if I'm wrong) > > > 1. Problems with servlets are solvable with free Java tools, and these > > > are not major showstoppers > > > > I am not aware of any servlet issues at all, tomcat for example > > should provide all necessary libraries. > > GNU provides the servlet API 2.4: > > cvs -d anoncvs at savannah.gnu.org:/cvsroot/classpathx co servletapi > > If a package is needed I can make one. > > > > 3. Main problem is that the free Javamail does not implement some > > > methods that are needed by OX. > > > > Correct. > > I haven't heard any issues raised on classpathx-javamail at gnu.org or > submitted as bugs or patches at > > http://savannah.gnu.org/projects/classpathx > > GNU JavaMail provides all the API methods provided by the JavaMail API. > If OX depends on com.sun APIs or on undocumented session properties, > this is an issue for OX to resolve. If there is functionality you want > exposing, there should be no problem, but you have to let us know. > > > Finally i would like to mention that Sun do a great Job for Javamail > > with the mail protocol support and with the supported mail servers > > and IMHO it will not be easy to get to the same functionality. > > GNU JavaMail doesn't explicitly support servers, it implements the > published standards. Sun's implementation supports 3 providers > (IMAP4, POP3, SMTP). GNU JavaMail supports 6 providers (IMAP4rev1, POP3, > SMTP, NNTP, mbox, Maildir) and we had SASL and STARTTLS support long > before Sun. Arguably we provide considerably more functionality. > -- > Chris Burdess > Hi, first of all i want to state that i do not want to start a discussion like vi/emacs, linux/windows or something similar. For us, freedom of choice is importend and if the classpath project fits the needs - it is just fine. Only one statement i want to clarify: I wrote that the Javamail API supports servers - maybe i should say that it has been tested against several servers (like mentioned in the notes, http://java.sun.com/products/javamail/NOTES13.txt). I will discuss the issue of "undocumented" calls at the beginning of the next week with our developer team and i will check again the classpath API because - like i wrote - i tested some month ago and at this time some methods were not included. I want to be up-to-date. Please be patient until we have investigated the details. Best regards, Martin Kauss From soumyadip at randomink.org Sat Jul 9 18:31:52 2005 From: soumyadip at randomink.org (Soumyadip Modak) Date: Sun, 10 Jul 2005 00:01:52 +0530 Subject: [fedora-java] Re: Compiling OpenExchange with gcj and classpath In-Reply-To: <20050709160051.7D4CC744BB@hormel.redhat.com> References: <20050709160051.7D4CC744BB@hormel.redhat.com> Message-ID: <42D01818.4040008@randomink.org> Martin Kauss wrote: >Hi, > >first of all i want to state that i do not want to start >a discussion like vi/emacs, linux/windows or something >similar. For us, freedom of choice is importend and if the >classpath project fits the needs - it is just fine. > >Only one statement i want to clarify: >I wrote that the Javamail API supports servers - maybe i should >say that it has been tested against several servers >(like mentioned in the notes, >http://java.sun.com/products/javamail/NOTES13.txt). > > >I will discuss the issue of "undocumented" calls at the beginning of >the next week with our developer team and i will check again the >classpath API because - like i wrote - i tested some month ago and >at this time some methods were not included. I want to be up-to-date. > >Please be patient until we have investigated the details. Hey that's great news. I'm certainly looking forward to getting OX to compile with GNU Classpath. Maybe, if it's impractical to get OX to support Classpath completely right now, we could have a set of patches, separate from the main OX code, which would enable us to build OX with Classpath ? It's seems to me that some code in OX might be have to be changed to do this, so this suggestion. Looking forward to all the responses Thanks a lot -- Soumyadip Modak soumyadip.modak at gmail.com soumyadip at randomink.org http://www.randomink.org/soumyadip From aph at redhat.com Mon Jul 11 10:03:26 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Jul 2005 11:03:26 +0100 Subject: [fedora-java] Re: aot-compile-rpm In-Reply-To: References: <20050706154056.GE4852@redhat.com> <1120668677.3379.67.camel@tortoise.toronto.redhat.com> <20050706171026.GF4852@redhat.com> <1120672103.714.6.camel@tofu.toronto.redhat.com> <20050707112553.GA26149@redhat.com> Message-ID: <17106.17390.323642.80551@zapata.pink> Robin Green writes: > The new rebuild-gcj-db will fail (I think) if the full list of .db > files cannot fit on one Linux command line. Are you sure that it will fail? I'm quite happy to belive you if you've really tried it, but I see nothing incorrect about the script. Your patch is nore efficient, however, so it's probably worth doing just because of that. > The following patch, which I just tested, fixes this: > > --- rebuild-gcj-db.orig 2005-07-09 10:07:00.000000000 +0100 > +++ rebuild-gcj-db 2005-07-09 10:07:19.000000000 +0100 > @@ -17,4 +17,4 @@ > dirname $dbLocation | xargs mkdir -p > /usr/bin/gcj-dbtool -n $dbLocation 64 > find $dbLocation.d /usr/lib/gcj -name '*.db' -print0 | \ > - xargs -0 /usr/bin/gcj-dbtool -m $dbLocation $dbLocation > + /usr/bin/gcj-dbtool -0 -m $dbLocation $dbLocation Should be just > + /usr/bin/gcj-dbtool -0 -m $dbLocation I think. Andrew. From overholt at redhat.com Mon Jul 11 15:25:03 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 Jul 2005 11:25:03 -0400 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050706154056.GE4852@redhat.com> References: <20050706154056.GE4852@redhat.com> Message-ID: <20050711152503.GC10052@redhat.com> Hi Gary, This is great! * Gary Benson [2005-07-06 11:41]: > > 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files. I've chopped down the Eclipse specfile and changed it to use your new aot-compile, but the files section is confusing to me. With Eclipse, we split up the package into sub-RPMs. Can we make it so that the native bits are split up like this? Should I just go through and change my current %{_libdir}/%{name}/ to %{_libdir}/gcj/%{name}/ in each of the sub-packages' %files sections? Thanks for doing this, Andrew From orion at cora.nwra.com Mon Jul 11 16:36:31 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 11 Jul 2005 10:36:31 -0600 Subject: [fedora-java] photran fortran dev module for eclipse Message-ID: <42D2A00F.9040807@cora.nwra.com> Has anyone considered building a rpm for photran: http://www.photran.org/ ? Are there other fortran modules for eclipse under development that are "better"? I was going to start trying to package it for Extras, but wanted to check with others first. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From greenrd at presidium.org Mon Jul 11 17:50:23 2005 From: greenrd at presidium.org (Robin Green) Date: Mon, 11 Jul 2005 18:50:23 +0100 Subject: [fedora-java] Re: Re: aot-compile-rpm References: <20050706154056.GE4852@redhat.com> <1120668677.3379.67.camel@tortoise.toronto.redhat.com> <20050706171026.GF4852@redhat.com> <1120672103.714.6.camel@tofu.toronto.redhat.com> <20050707112553.GA26149@redhat.com> <17106.17390.323642.80551@zapata.pink> Message-ID: On Mon, 11 Jul 2005 11:03:26 +0100, Andrew Haley wrote: > Robin Green writes: > > The new rebuild-gcj-db will fail (I think) if the full list of .db > > files cannot fit on one Linux command line. > > Are you sure that it will fail? No - actually, I was wrong. I missed the fact that the double $dbLocation would make it work. From overholt at redhat.com Mon Jul 11 17:58:52 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 Jul 2005 13:58:52 -0400 Subject: [fedora-java] photran fortran dev module for eclipse In-Reply-To: <42D2A00F.9040807@cora.nwra.com> References: <42D2A00F.9040807@cora.nwra.com> Message-ID: <1121104732.10147.3.camel@tofu.toronto.redhat.com> On Mon, 2005-11-07 at 10:36 -0600, Orion Poplawski wrote: > Has anyone considered building a rpm for photran: > http://www.photran.org/ ? Are there other fortran modules for eclipse > under development that are "better"? I was going to start trying to > package it for Extras, but wanted to check with others first. I haven't tried myself and I don't know of anyone that has. I'm also not very familiar with it, but I *think* Photran is the Fortran plug-in that I've heard of before. Having this in Extras would be great! Thanks, Andrew From overholt at redhat.com Mon Jul 11 20:25:23 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 Jul 2005 16:25:23 -0400 Subject: [fedora-java] Eclipse Automated Tests Message-ID: <20050711202523.GG10052@redhat.com> Hi, I spent a bit of time this past week getting the Eclipse automated tests set up as an RPM and making them runnable as a regular user. Thanks to Jeremy Handcock and Aaron Luchko, the former was little work. The latter, however, required me to don my hacking gloves. The tests themselves are 72 MB as distributed upstream. They're pre-built and that's how I've included them in the RPM (mostly because I haven't had time to work out how to build them or find a source zip of them); this isn't much of a concern for me ATM as we're not going to ship them in FC at least for the time being. I've put what I've got here: http://people.redhat.com/overholt/eclipse/ I've got some minor klu^H^H^H^ patches to allow for running of the tests as regular users and for writing the results to an arbitrary directory which I've put there as well so that people can see them without downloading the entire SRPM to re"build". There are things that need to be done to make the process better and I've put them in the specfile as a TODO list which I'll mirror here: # . make runtests-wrapper better (a python script?) # . verify changes made to allow running as non-root # . why does the HTML translation not really work? # . why does having eclipse-tests installed make every startup of eclipse # run in some sort of testing mode? # . why is there a "- option not found" error? # . do "/usr/share" -> "%{_datadir}" sed --in-place for the scripts and # patched xml files in the specfile # . are the dependencies all correct? I'd really love to have lots of people run these tests so that we can diagnose problems with our packaging and/or the native compilation. If anyone has time to help (a more robust runtests-wrapper is what's most needed; I've tried to prioritize the rest of the list), I'd really appreciate it. If anyone does download and re-build the SRPM [1], you can run the tests like this after installing [2]: RESULT_HOME= \ /usr/share/eclipse/plugins/org.eclipse.test/runtests-wrapper Thanks, Andrew [1] Your way or something like: mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} echo "%_topdir /home//rpmbuild" >> ~/.rpmmacros rpmbuild --rebuild eclipse-tests-3.1.0_fc-4.src.rpm [2] sudo rpm -Uvh ~/rpmbuild/RPMS//eclipse-tests-3.1.0_fc-4..rpm From orion at cora.nwra.com Mon Jul 11 20:53:00 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 11 Jul 2005 14:53:00 -0600 Subject: [fedora-java] photran fortran dev module for eclipse In-Reply-To: <20050711200330.GF10052@redhat.com> References: <42D2A00F.9040807@cora.nwra.com> <1121104732.10147.3.camel@tofu.toronto.redhat.com> <42D2C7A1.6060209@cora.nwra.com> <20050711200330.GF10052@redhat.com> Message-ID: <42D2DC2C.3090406@cora.nwra.com> Andrew Overholt wrote: > Hi, > > * Orion Poplawski [2005-07-11 15:25]: > >>The main distribution is a .zip file of the compiled plugin with a >>"features" and a "plugins" directory. I move the contents to the >>/usr/share/eclipse/features and /usr/lib/eclipse/plugins directories >>respectively, but eclipse still did not find it. Is there anything else >>I need to do? > > > Hmm. Did you try using the Eclipse update manager thingy? Does Photran > have an update site? > Not sure. If I try to "Scan for Updates" to find new features, nothing seems to show up. I eventually used this to do add the directory I made from the photran-2.1.0.zip file. > > Yes, you should compile from source. There are some issues around building > arbitrary Eclipse plug-ins from source (see [1], for example), but with a > bit of help, we should be okay on this one. We can worry about adding > native compilation later, so in the meantime, look at one of the specfiles > for the plug-ins we ship in FC (bugzilla, pydev, changelog, cdt) for some > inspiration (you can ignore most of the stuff in the gcj_support if > blocks). > Was there a url for [1]? Okay, basing off of CDT for now, with gcj_support = 0 for now. Having trouble with the build trying to fetch things: java -cp /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/startup.jar -Duser.home=/export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/home -Dosgi.install.area=/usr/share/eclipse -Dorg.eclipse.core.runtime.ignoreLockFile=true org.eclipse.core.launcher.Main -application org.eclipse.ant.core.antRunner -DjavacFailOnError=true -DdontUnzip=true -DbaseLocation=/export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK -Dpde.build.scripts=/export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts -DdontFetchAnything=true Buildfile: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/build.xml init: [touch] Creating /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/home/.cvspass unzip: zips: main: preBuild: [mkdir] Created dir: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/results preSetup: getMapFiles: [copy] Copying 1 file to /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/results/maps postSetup: fetch: preFetch: allElements: init: fetchElement: [mkdir] Created dir: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/results/features [mkdir] Created dir: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/results/plugins BUILD FAILED /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/build.xml:45: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/build.xml:21: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/build.xml:48: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/platform/customTargets.xml:13: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/genericTargets.xml:33: org.eclipse.core.runtime.CoreException: Feature org.eclipse.photran may have not been fetched correctly, check your map files. This is the line in releng/build.xml: Any ideas? > Any reason why you took this off list? Others could probably benefit from > this exercise. Nope, just did a reply rather than reply all. Back on the list... -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Mon Jul 11 21:17:15 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 11 Jul 2005 15:17:15 -0600 Subject: [fedora-java] photran fortran dev module for eclipse In-Reply-To: <42D2DC2C.3090406@cora.nwra.com> References: <42D2A00F.9040807@cora.nwra.com> <1121104732.10147.3.camel@tofu.toronto.redhat.com> <42D2C7A1.6060209@cora.nwra.com> <20050711200330.GF10052@redhat.com> <42D2DC2C.3090406@cora.nwra.com> Message-ID: <42D2E1DB.8030508@cora.nwra.com> Orion Poplawski wrote: > > BUILD FAILED > /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/build.xml:45: > The following error occurred while executing this line: > /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/build.xml:21: > The following error occurred while executing this line: > /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/build.xml:48: > The following error occurred while executing this line: > /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/platform/customTargets.xml:13: > The following error occurred while executing this line: > /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/genericTargets.xml:33: > org.eclipse.core.runtime.CoreException: Feature org.eclipse.photran may > have not been fetched correctly, check your map files. > > This is the line in releng/build.xml: > > > > value="${basedir}/platform" /> > Okay, figured out how to adapt the no-cvs2 patch to apply to photran. Now am getting: generateScript: BUILD FAILED /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/build.xml:45: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/build.xml:22: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/build.xml:61: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/platform/customTargets.xml:14: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/platform/customTargets.xml:22: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/org.eclipse.photran.releng/platform/customTargets.xml:38: The following error occurred while executing this line: /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/genericTargets.xml:63: org.eclipse.core.runtime.CoreException: Unable to find feature: org.eclipse.photran. Is there some way to turn on more verbose build debugging? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From overholt at redhat.com Mon Jul 11 21:49:18 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 Jul 2005 17:49:18 -0400 Subject: [fedora-java] photran fortran dev module for eclipse In-Reply-To: <42D2E1DB.8030508@cora.nwra.com> References: <42D2A00F.9040807@cora.nwra.com> <1121104732.10147.3.camel@tofu.toronto.redhat.com> <42D2C7A1.6060209@cora.nwra.com> <20050711200330.GF10052@redhat.com> <42D2DC2C.3090406@cora.nwra.com> <42D2E1DB.8030508@cora.nwra.com> Message-ID: <20050711214918.GA10038@redhat.com> * Orion Poplawski [2005-07-11 17:17]: > > Is there some way to turn on more verbose build debugging? ant -debug or ant -v -v -v -v -v -v Andrew From overholt at redhat.com Mon Jul 11 22:03:39 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 Jul 2005 18:03:39 -0400 Subject: [fedora-java] photran fortran dev module for eclipse In-Reply-To: <42D2DC2C.3090406@cora.nwra.com> References: <42D2A00F.9040807@cora.nwra.com> <1121104732.10147.3.camel@tofu.toronto.redhat.com> <42D2C7A1.6060209@cora.nwra.com> <20050711200330.GF10052@redhat.com> <42D2DC2C.3090406@cora.nwra.com> Message-ID: <20050711220339.GB10038@redhat.com> * Orion Poplawski [2005-07-11 16:53]: > Was there a url for [1]? Sorry: http://www.bagu.org/eclipse/plugin-source-drops.html Andrew From orion at cora.nwra.com Mon Jul 11 22:09:43 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 11 Jul 2005 16:09:43 -0600 Subject: [fedora-java] photran fortran dev module for eclipse In-Reply-To: <20050711214918.GA10038@redhat.com> References: <42D2A00F.9040807@cora.nwra.com> <1121104732.10147.3.camel@tofu.toronto.redhat.com> <42D2C7A1.6060209@cora.nwra.com> <20050711200330.GF10052@redhat.com> <42D2DC2C.3090406@cora.nwra.com> <42D2E1DB.8030508@cora.nwra.com> <20050711214918.GA10038@redhat.com> Message-ID: <42D2EE27.901@cora.nwra.com> Andrew Overholt wrote: > * Orion Poplawski [2005-07-11 17:17]: > >>Is there some way to turn on more verbose build debugging? > > > ant -debug or ant -v -v -v -v -v -v > > Andrew Okay, but I'm not calling ant directly, but through: java -cp $SDK/startup.jar \ -Duser.home=$homedir \ -Dosgi.install.area=%{eclipse_base} \ -Dorg.eclipse.core.runtime.ignoreLockFile=true \ org.eclipse.core.launcher.Main \ -application org.eclipse.ant.core.antRunner \ -DjavacFailOnError=true \ -DdontUnzip=true \ -DbaseLocation=$SDK \ -Dpde.build.scripts=$SDK/plugins/org.eclipse.pde.build_3.1.0/scripts \ -DdontFetchAnything=true Tried: export ANT_ARGS="-debug -v -v -v -v -v -v" to no avail. Any arguments to the java command to use? Anyways, it's failing in generateScript from /export/home/orion/redhat/eclipse-photran-2.1.0/eclipse-photran-2.1.0/SDK/plugins/org.eclipse.pde.build_3.1.0/scripts/genericTargets.xml And it is saying it can't find the feature org.eclipse.photran. What would it be looking for in this case? I'm not entirely sure my source archive is correct. My rpm build dir has: home org.eclipse.photran.debug.ui.tests org.eclipse.photran org.eclipse.photran-doc org.eclipse.photran-build org.eclipse.photran.doc.isv org.eclipse.photran-contrib org.eclipse.photran.doc.user org.eclipse.photran-core org.eclipse.photran-feature org.eclipse.photran.core org.eclipse.photran-launch org.eclipse.photran.core.aix org.eclipse.photran.launch org.eclipse.photran.core.linux org.eclipse.photran.make.core org.eclipse.photran.core.qnx org.eclipse.photran.make.ui org.eclipse.photran.core.solaris org.eclipse.photran.managedbuilder.core org.eclipse.photran.core.tests org.eclipse.photran.managedbuilder.core.tests org.eclipse.photran.core.win32 org.eclipse.photran.managedbuilder.ui org.eclipse.photran-cppunit org.eclipse.photran-old org.eclipse.photran.cppunit org.eclipse.photran.old org.eclipse.photran.cppunit-feature org.eclipse.photran-releng org.eclipse.photran-debug org.eclipse.photran.releng org.eclipse.photran.debug.core org.eclipse.photran.testing org.eclipse.photran.debug.core.tests org.eclipse.photran.testing-feature org.eclipse.photran.debug.mi.core org.eclipse.photran.ui org.eclipse.photran.debug.mi.ui org.eclipse.photran.ui.tests org.eclipse.photran.debug.ui SDK Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From overholt at redhat.com Tue Jul 12 20:54:57 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 12 Jul 2005 16:54:57 -0400 Subject: [fedora-java] Eclipse Automated Tests In-Reply-To: <20050711202523.GG10052@redhat.com> References: <20050711202523.GG10052@redhat.com> Message-ID: <20050712205457.GC10665@redhat.com> Hi, I took care of these two: > # . why does the HTML translation not really work? > # . do "/usr/share" -> "%{_datadir}" sed --in-place for the scripts and > # patched xml files in the specfile Still to do: > # . make runtests-wrapper better (a python script?) > # . verify changes made to allow running as non-root > # . why does having eclipse-tests installed make every startup of eclipse > # run in some sort of testing mode? > # . why is there a "- option not found" error? > # . are the dependencies all correct? New SRPM and specfile here: http://people.redhat.com/overholt/eclipse/ So other than robustness, we're pretty good to go with getting reliable results. I'm doing a full run (this takes hours) here to verify that the XML -> HTML works alright in an automated run. > RESULT_HOME= \ > /usr/share/eclipse/plugins/org.eclipse.test/runtests-wrapper Note that you should probably uninstall the tests RPM if you want to use Eclipse regularly. Andrew From soumyadip at randomink.org Fri Jul 8 12:28:51 2005 From: soumyadip at randomink.org (Soumyadip Modak) Date: Fri, 08 Jul 2005 17:58:51 +0530 Subject: [fedora-java] Compiling OpenExchange with gcj and classpath Message-ID: <42CE7183.4010606@randomink.org> Hello, Recently I've been looking at OpenExchange on Fedora Core 4. I was hoping to utilise FC4's extensive free Java tools to build OX. OX configure script didn't thorw up any problems but make failed witha lot of errors. Can anyone please guide me how to rectify these problems to get a completely free groupware solution ? Errors : Making all in javabuild make[1]: Entering directory `/root/open-xchange-0.8.0-3/javabuild' /usr/bin/ant -f ../build.xml Buildfile: ../build.xml init: compilewebdav: [javac] Compiling 14 source files to /root/open-xchange-0.8.0-3/build [javac] ---------- [javac] 1. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactInsEdit.java [javac] (at line 96) [javac] import com.openexchange.tools.encoding.Base64; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import com.openexchange.tools.encoding.Base64 is never used [javac] ---------- [javac] ---------- [javac] 2. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactInsEdit.java [javac] (at line 98) [javac] import sun.misc.BASE64Decoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] ---------- [javac] 3. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactInsEdit.java [javac] (at line 99) [javac] import sun.misc.BASE64Encoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] ---------- [javac] 4. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactInsEdit.java [javac] (at line 158) [javac] byte cached[] = new BASE64Decoder().decodeBuffer(ca); [javac] ^^^^^^^^^^^^^ [javac] BASE64Decoder cannot be resolved to a type [javac] ---------- [javac] 5. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactInsEdit.java [javac] (at line 546) [javac] String fullcache = new BASE64Encoder().encodeBuffer(cache); [javac] ^^^^^^^^^^^^^ [javac] BASE64Encoder cannot be resolved to a type [javac] ---------- [javac] ---------- [javac] 6. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactManagement.java [javac] (at line 85) [javac] import sun.misc.BASE64Decoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] ---------- [javac] 7. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactManagement.java [javac] (at line 86) [javac] import sun.misc.BASE64Encoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] ---------- [javac] 8. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ContactManagement.java [javac] (at line 168) [javac] byte cached[] = new BASE64Decoder().decodeBuffer(img); [javac] ^^^^^^^^^^^^^ [javac] BASE64Decoder cannot be resolved to a type [javac] ---------- [javac] ---------- [javac] 9. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/sessiond/SocketHandler.java [javac] (at line 52) [javac] import sun.misc.BASE64Decoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] ---------- [javac] 10. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/sessiond/SocketHandler.java [javac] (at line 53) [javac] import sun.misc.BASE64Encoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] ---------- [javac] 11. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/sessiond/SocketHandler.java [javac] (at line 282) [javac] auth_data = new String(new BASE64Decoder().decodeBuffer(st.nextToken()), "UTF-8"); [javac] ^^^^^^^^^^^^^ [javac] BASE64Decoder cannot be resolved to a type [javac] ---------- [javac] 12. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/sessiond/SocketHandler.java [javac] (at line 342) [javac] response = new BASE64Encoder().encode((h.get("uid").toString() + "\1" + h.get("passw [javac] d").toString() + "\1" + h.get("lang").toString() + "\1" + h.get("localip").toString() + "\1" + h.get("host").toString()).getBytes("UTF-8")); [javac] ^^^^^^^^^^^^^ [javac] BASE64Encoder cannot be resolved to a type [javac] ---------- [javac] 13. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/sessiond/SocketHandler.java [javac] (at line 348) [javac] auth_data = new String(new BASE64Decoder().decodeBuffer(st.nextToken()), "UTF-8"); [javac] ^^^^^^^^^^^^^ [javac] BASE64Decoder cannot be resolved to a type [javac] ---------- [javac] 14. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/sessiond/SocketHandler.java [javac] (at line 362) [javac] response = new BASE64Encoder().encode((h.get("uid").toString() + "\1" + h.get("passw [javac] d").toString() + "\1" + h.get("lang").toString() + "\1" + h.get("localip").toString() + "\1" + h.get("host").toString() + "\1" + acttime + "\1" + l_ts + "\1" + l_lt).getBytes("UTF-8")); [javac] ^^^^^^^^^^^^^ [javac] BASE64Encoder cannot be resolved to a type [javac] ---------- [javac] ---------- [javac] 15. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/tools/webdav/OXServlet.java [javac] (at line 59) [javac] import javax.servlet.SingleThreadModel; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The type SingleThreadModel is deprecated [javac] ---------- [javac] ---------- [javac] 16. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/tools/webdav/OXServlet.java [javac] (at line 88) [javac] public abstract class OXServlet extends WebDavServlet implements SingleThreadModel, Logger { [javac] ^^^^^^^^^^^^^^^^^ [javac] The type SingleThreadModel is deprecated [javac] ---------- [javac] ---------- [javac] 17. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/tools/webdav/OXServlet.java [javac] (at line 362) [javac] byte[] decoded = new sun.misc.BASE64Decoder().decodeBuffer(auth); [javac] ^^^^^^^^ [javac] sun.misc cannot be resolved to a type [javac] ---------- [javac] ---------- [javac] 18. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/umin/OXUsermin.java [javac] (at line 74) [javac] import javax.servlet.SingleThreadModel; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The type SingleThreadModel is deprecated [javac] ---------- [javac] ---------- [javac] 19. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/umin/OXUsermin.java [javac] (at line 80) [javac] import sun.misc.BASE64Encoder; [javac] ^^^^^^^^ [javac] The import sun.misc cannot be resolved [javac] ---------- [javac] 20. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/umin/OXUsermin.java [javac] (at line 82) [javac] public class OXUsermin extends HttpServlet implements SingleThreadModel{ [javac] ^^^^^^^^^ [javac] The serializable class OXUsermin does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] 21. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/umin/OXUsermin.java [javac] (at line 82) [javac] public class OXUsermin extends HttpServlet implements SingleThreadModel{ [javac] ^^^^^^^^^^^^^^^^^ [javac] The type SingleThreadModel is deprecated [javac] ---------- [javac] 22. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/umin/OXUsermin.java [javac] (at line 127) [javac] BASE64Encoder base64 = new BASE64Encoder(); [javac] ^^^^^^^^^^^^^ [javac] BASE64Encoder cannot be resolved to a type [javac] ---------- [javac] 23. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/umin/OXUsermin.java [javac] (at line 127) [javac] BASE64Encoder base64 = new BASE64Encoder(); [javac] ^^^^^^^^^^^^^ [javac] BASE64Encoder cannot be resolved to a type [javac] ---------- [javac] ---------- [javac] 24. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/ComposeMessage.java [javac] (at line 383) [javac] new ParserDelegator().parse(new StringReader(tmp_wms.getHTMLMailText().toString()), [javac] ^^^^^ [javac] The method parse(StringReader, html2text, boolean) is undefined for the type ParserDelegator [javac] ---------- [javac] 25. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/ComposeMessage.java [javac] (at line 1325) [javac] new ParserDelegator().parse(new StringReader(text), parser, true); [javac] ^^^^^ [javac] The method parse(StringReader, html2text, boolean) is undefined for the type ParserDelegator [javac] ---------- [javac] ---------- [javac] 26. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 68) [javac] import com.sun.mail.imap.IMAPFolder; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 27. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 69) [javac] import com.sun.mail.imap.Rights; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 28. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 180) [javac] IMAPFolder fa = (IMAPFolder)imapStore.getFolder("INBOX"); [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 29. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 180) [javac] IMAPFolder fa = (IMAPFolder)imapStore.getFolder("INBOX"); [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 30. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 347) [javac] IMAPFolder fa = (IMAPFolder)tmpFolder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 31. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 347) [javac] IMAPFolder fa = (IMAPFolder)tmpFolder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 32. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 348) [javac] Rights rights = fa.myRights(); [javac] ^^^^^^ [javac] Rights cannot be resolved to a type [javac] ---------- [javac] 33. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 349) [javac] if (!rights.contains(Rights.Right.READ) && !tmpFolder.isSubscribed()) { [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 34. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 352) [javac] if (!rights.contains(Rights.Right.INSERT)){ [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 35. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 507) [javac] IMAPFolder fa = (IMAPFolder)tmpFolder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 36. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 507) [javac] IMAPFolder fa = (IMAPFolder)tmpFolder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 37. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 508) [javac] Rights rights = fa.myRights(); [javac] ^^^^^^ [javac] Rights cannot be resolved to a type [javac] ---------- [javac] 38. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/FolderSettings.java [javac] (at line 509) [javac] if (!rights.contains(Rights.Right.INSERT)){ [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] ---------- [javac] 39. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 72) [javac] import com.sun.mail.imap.IMAPFolder; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 40. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 73) [javac] import com.sun.mail.imap.Rights; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 41. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 166) [javac] } else if (!WebmailFolderUtilities.hasRight(dstFolder, Rights.Right.INSERT)) { [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 42. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 178) [javac] if (mmg.length != 0 && WebmailFolderUtilities.hasRight(srcFolder, Rights.Right.DELET [javac] E)) { [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 43. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 196) [javac] if (ex instanceof com.sun.mail.iap.CommandFailedException) { [javac] ^^^^^^^^^^^^ [javac] com.sun.mail cannot be resolved to a type [javac] ---------- [javac] 44. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 275) [javac] } else if (!WebmailFolderUtilities.hasRight(dstFolder, Rights.Right.INSERT)) { [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 45. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 298) [javac] if (ex instanceof com.sun.mail.iap.CommandFailedException) { [javac] ^^^^^^^^^^^^ [javac] com.sun.mail cannot be resolved to a type [javac] ---------- [javac] 46. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 353) [javac] } else if (!WebmailFolderUtilities.hasRight(srcFolder, Rights.Right.DELETE)) { [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 47. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 401) [javac] } else if (!WebmailFolderUtilities.hasRight(dstFolder, Rights.Right.DELETE)) { [javac] [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 48. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 429) [javac] if (ex instanceof com.sun.mail.iap.CommandFailedException) { [javac] ^^^^^^^^^^^^ [javac] com.sun.mail cannot be resolved to a type [javac] ---------- [javac] 49. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 752) [javac] IMAPFolder fa = (IMAPFolder)folder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 50. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 752) [javac] IMAPFolder fa = (IMAPFolder)folder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 51. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 753) [javac] Rights rights = fa.myRights(); [javac] ^^^^^^ [javac] Rights cannot be resolved to a type [javac] ---------- [javac] 52. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageAction.java [javac] (at line 754) [javac] if (rights.contains(Rights.Right.KEEP_SEEN)) { [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] ---------- [javac] 53. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageDisplay.java [javac] (at line 60) [javac] import java.util.*; [javac] ^^^^^^^^^ [javac] The import java.util is never used [javac] ---------- [javac] ---------- [javac] 54. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageDisplay.java [javac] (at line 79) [javac] import javax.mail.internet.*; [javac] ^^^^^^^^^^^^^^^^^^^ [javac] The import javax.mail.internet is never used [javac] ---------- [javac] ---------- [javac] 55. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageDisplay.java [javac] (at line 93) [javac] import com.sun.mail.imap.Rights; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 56. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageDisplay.java [javac] (at line 95) [javac] import com.openexchange.webmail.*; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import com.openexchange.webmail is never used [javac] ---------- [javac] 57. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageDisplay.java [javac] (at line 276) [javac] if (WebmailFolderUtilities.hasRight(folder, Rights.Right.KEEP_SEEN)) { [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] ---------- [javac] 58. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageList.java [javac] (at line 72) [javac] import com.sun.mail.imap.Rights; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 59. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageList.java [javac] (at line 778) [javac] KEEP_SEEN = WebmailFolderUtilities.hasRight(folder, Rights.Right.KEEP_SEEN); [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 60. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageList.java [javac] (at line 1105) [javac] boolean delete = WebmailFolderUtilities.hasRight(folder, Rights.Right.DELETE); [javac] [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 61. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageList.java [javac] (at line 1157) [javac] boolean KEEP_SEEN = WebmailFolderUtilities.hasRight(folder, Rights.Right.KEEP_SEEN); [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 62. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageList.java [javac] (at line 1158) [javac] boolean DELETE = WebmailFolderUtilities.hasRight(folder, Rights.Right.DELETE); [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] 63. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/MessageList.java [javac] (at line 1159) [javac] boolean WRITE = WebmailFolderUtilities.hasRight(folder, Rights.Right.WRITE); [javac] [javac] ^^^^^^ [javac] Rights cannot be resolved [javac] ---------- [javac] ---------- [javac] 64. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/OXWorker.java [javac] (at line 442) [javac] String auth = "Basic " + new sun.misc.BASE64Encoder().encode((nasObjectOperations.getWUSObject(no).getUsername() + ":" + nasObjectOperations.getWUSObject(no).getPassword()).getBytes()); [javac] ^^^^^^^^ [javac] sun.misc cannot be resolved to a type [javac] ---------- [javac] ---------- [javac] 65. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/folder/WebmailFolderUtilities.java [javac] (at line 52) [javac] import com.sun.mail.imap.IMAPFolder; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 66. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/folder/WebmailFolderUtilities.java [javac] (at line 53) [javac] import com.sun.mail.imap.Rights; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 67. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/folder/WebmailFolderUtilities.java [javac] (at line 54) [javac] import javax.mail.MessagingException; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import javax.mail.MessagingException is never used [javac] ---------- [javac] 68. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/folder/WebmailFolderUtilities.java [javac] (at line 64) [javac] public static boolean hasRight(Folder folder, Rights.Right right) { [javac] ^^^^^^ [javac] Rights cannot be resolved to a type [javac] ---------- [javac] ---------- [javac] 69. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 54) [javac] import com.sun.mail.iap.ProtocolException; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 70. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 55) [javac] import com.sun.mail.iap.Response; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 71. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 56) [javac] import com.sun.mail.imap.IMAPFolder; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 72. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 57) [javac] import com.sun.mail.imap.protocol.IMAPProtocol; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 73. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 58) [javac] import com.sun.mail.imap.protocol.IMAPResponse; [javac] ^^^^^^^^^^^^ [javac] The import com.sun.mail cannot be resolved [javac] ---------- [javac] 74. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 79) [javac] IMAPFolder f = (IMAPFolder)folder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 75. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 79) [javac] IMAPFolder f = (IMAPFolder)folder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 76. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 81) [javac] Object val = f.doCommand(new IMAPFolder.ProtocolCommand() { [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 77. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 153) [javac] IMAPFolder f = (IMAPFolder)folder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 78. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 153) [javac] IMAPFolder f = (IMAPFolder)folder; [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] 79. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/imap/IMAPCommand.java [javac] (at line 155) [javac] Object val = f.doCommand(new IMAPFolder.ProtocolCommand() { [javac] ^^^^^^^^^^ [javac] IMAPFolder cannot be resolved to a type [javac] ---------- [javac] ---------- [javac] 80. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 50) [javac] import javax.swing.text.html.HTMLEditorKit; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import javax.swing.text.html.HTMLEditorKit cannot be resolved [javac] ---------- [javac] 81. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 59) [javac] public class html2text extends HTMLEditorKit.ParserCallback { [javac] ^^^^^^^^^^^^^ [javac] HTMLEditorKit cannot be resolved to a type [javac] ---------- [javac] 82. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 70) [javac] if (tag.equals(HTML.Tag.BLOCKQUOTE)) { [javac] ^^^^^^^^^^^^^^^^^^^ [javac] HTML.Tag.BLOCKQUOTE cannot be resolved [javac] ---------- [javac] 83. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 75) [javac] } else if (tag.equals(HTML.Tag.DIV)) { [javac] ^^^^^^^^^^^^ [javac] HTML.Tag.DIV cannot be resolved [javac] ---------- [javac] 84. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 84) [javac] if (tag.equals(HTML.Tag.BLOCKQUOTE)) { [javac] ^^^^^^^^^^^^^^^^^^^ [javac] HTML.Tag.BLOCKQUOTE cannot be resolved [javac] ---------- [javac] 85. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 88) [javac] } else if (tag.equals(HTML.Tag.P)) { [javac] ^^^^^^^^^^ [javac] HTML.Tag.P cannot be resolved [javac] ---------- [javac] 86. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 92) [javac] } else if (tag.equals(HTML.Tag.H1) || [javac] ^^^^^^^^^^^ [javac] HTML.Tag.H1 cannot be resolved [javac] ---------- [javac] 87. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 93) [javac] tag.equals(HTML.Tag.H2) || [javac] ^^^^^^^^^^^ [javac] HTML.Tag.H2 cannot be resolved [javac] ---------- [javac] 88. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 94) [javac] tag.equals(HTML.Tag.H3) || [javac] ^^^^^^^^^^^ [javac] HTML.Tag.H3 cannot be resolved [javac] ---------- [javac] 89. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 95) [javac] tag.equals(HTML.Tag.H4) || [javac] ^^^^^^^^^^^ [javac] HTML.Tag.H4 cannot be resolved [javac] ---------- [javac] 90. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 96) [javac] tag.equals(HTML.Tag.H5) || [javac] ^^^^^^^^^^^ [javac] HTML.Tag.H5 cannot be resolved [javac] ---------- [javac] 91. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 97) [javac] tag.equals(HTML.Tag.H6) || [javac] ^^^^^^^^^^^ [javac] HTML.Tag.H6 cannot be resolved [javac] ---------- [javac] 92. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 98) [javac] tag.equals(HTML.Tag.ADDRESS) || [javac] ^^^^^^^^^^^^^^^^ [javac] HTML.Tag.ADDRESS cannot be resolved [javac] ---------- [javac] 93. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 99) [javac] tag.equals(HTML.Tag.PRE)) { [javac] ^^^^^^^^^^^^ [javac] HTML.Tag.PRE cannot be resolved [javac] ---------- [javac] 94. ERROR in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/message/html2text.java [javac] (at line 113) [javac] if (tag.equals(HTML.Tag.BR)) { [javac] ^^^^^^^^^^^ [javac] HTML.Tag.BR cannot be resolved [javac] ---------- [javac] ---------- [javac] 95. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/Management.java [javac] (at line 69) [javac] import javax.naming.ldap.LdapContext; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import javax.naming.ldap.LdapContext is never used [javac] ---------- [javac] ---------- [javac] 96. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/Management.java [javac] (at line 74) [javac] import com.openexchange.groupware.ldap.GlobalLdapPool; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import com.openexchange.groupware.ldap.GlobalLdapPool is never used [javac] ---------- [javac] ---------- [javac] 97. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ComfireConflictException.java [javac] (at line 52) [javac] public class ComfireConflictException extends Throwable { [javac] ^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class ComfireConflictException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 98. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/ComfireMandatoryException.java [javac] (at line 53) [javac] public class ComfireMandatoryException extends Throwable { [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class ComfireMandatoryException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 99. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/InsertHandler.java [javac] (at line 49) [javac] import java.io.File; [javac] ^^^^^^^^^^^^ [javac] The import java.io.File is never used [javac] ---------- [javac] ---------- [javac] 100. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/UpdateHandler.java [javac] (at line 49) [javac] import java.io.File; [javac] ^^^^^^^^^^^^ [javac] The import java.io.File is never used [javac] ---------- [javac] ---------- [javac] 101. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/api/OXObject.java [javac] (at line 53) [javac] import java.lang.CloneNotSupportedException; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import java.lang.CloneNotSupportedException is never used [javac] ---------- [javac] ---------- [javac] 102. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/api/OXConflictException.java [javac] (at line 52) [javac] public class OXConflictException extends Exception [javac] ^^^^^^^^^^^^^^^^^^^ [javac] The serializable class OXConflictException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 103. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/api/OXMandatoryFieldException.java [javac] (at line 52) [javac] public class OXMandatoryFieldException extends Exception [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class OXMandatoryFieldException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 104. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/api/OXPermissionException.java [javac] (at line 52) [javac] public class OXPermissionException extends Exception [javac] ^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class OXPermissionException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 105. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/ssl/SSLException.java [javac] (at line 53) [javac] public class SSLException extends Exception [javac] ^^^^^^^^^^^^ [javac] The serializable class SSLException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 106. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/folder/WebmailFolderManagement.java [javac] (at line 59) [javac] public class WebmailFolderManagement extends Vector { [javac] ^^^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class WebmailFolderManagement does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 107. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/SendHandler.java [javac] (at line 42) [javac] import java.io.*; [javac] ^^^^^^^ [javac] The import java.io is never used [javac] ---------- [javac] ---------- [javac] 108. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/DefaultSendHandler.java [javac] (at line 42) [javac] import java.io.*; [javac] ^^^^^^^ [javac] The import java.io is never used [javac] ---------- [javac] ---------- [javac] 109. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/DefaultSendHandler.java [javac] (at line 44) [javac] import com.openexchange.webmail.*; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import com.openexchange.webmail is never used [javac] ---------- [javac] ---------- [javac] 110. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/ReceiveHandler.java [javac] (at line 39) [javac] import javax.mail.*; [javac] ^^^^^^^^^^ [javac] The import javax.mail is never used [javac] ---------- [javac] ---------- [javac] 111. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/ReceiveHandler.java [javac] (at line 41) [javac] import java.io.*; [javac] ^^^^^^^ [javac] The import java.io is never used [javac] ---------- [javac] ---------- [javac] 112. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/ReceiveHandler.java [javac] (at line 43) [javac] import java.security.GeneralSecurityException; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import java.security.GeneralSecurityException is never used [javac] ---------- [javac] ---------- [javac] 113. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/ReceiveHandler.java [javac] (at line 45) [javac] import java.security.*; [javac] ^^^^^^^^^^^^^ [javac] The import java.security is never used [javac] ---------- [javac] ---------- [javac] 114. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/DefaultReceiveHandler.java [javac] (at line 39) [javac] import javax.mail.*; [javac] ^^^^^^^^^^ [javac] The import javax.mail is never used [javac] ---------- [javac] ---------- [javac] 115. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/DefaultReceiveHandler.java [javac] (at line 41) [javac] import java.io.*; [javac] ^^^^^^^ [javac] The import java.io is never used [javac] ---------- [javac] ---------- [javac] 116. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/DefaultReceiveHandler.java [javac] (at line 43) [javac] import java.security.GeneralSecurityException; [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import java.security.GeneralSecurityException is never used [javac] ---------- [javac] ---------- [javac] 117. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/webmail/DefaultReceiveHandler.java [javac] (at line 45) [javac] import java.security.*; [javac] ^^^^^^^^^^^^^ [javac] The import java.security is never used [javac] ---------- [javac] ---------- [javac] 118. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/groupware/attachments/AttachmentNotFoundException.java [javac] (at line 53) [javac] public class AttachmentNotFoundException extends Exception { [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class AttachmentNotFoundException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 119. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/tools/oxfolder/OXFolderLogicException.java [javac] (at line 53) [javac] public class OXFolderLogicException extends Throwable { [javac] ^^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class OXFolderLogicException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 120. WARNING in /root/open-xchange-0.8.0-3/src/com/openexchange/tools/oxfolder/OXFolderPermissionException.java [javac] (at line 53) [javac] public class OXFolderPermissionException extends Throwable { [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class OXFolderPermissionException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] 120 problems (84 errors, 36 warnings) Sorry for flooding. Thanks Soumyadip Modak soumyadip at randomink.org soumyadip.modak at gmail.com http://www.randomink.org/soumyadip From gbenson at redhat.com Wed Jul 13 10:06:37 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 13 Jul 2005 11:06:37 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050711152503.GC10052@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050711152503.GC10052@redhat.com> Message-ID: <20050713100636.GE4681@redhat.com> Andrew Overholt wrote: > * Gary Benson [2005-07-06 11:41]: > > > > 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files. > > I've chopped down the Eclipse specfile and changed it to use your > new aot-compile, but the files section is confusing to me. With > Eclipse, we split up the package into sub-RPMs. Can we make it so > that the native bits are split up like this? Unfortunatly no, not automatically. The information is not made available by rpm. There are two options: > Should I just go through and change my current > %{_libdir}/%{name}/ to %{_libdir}/gcj/%{name}/ in each > of the sub-packages' %files sections? This is one option. The other is to rearrange the files after the aot-compile-rpm line in %install. The one you suggested is probably better. Cheers, Gary From overholt at redhat.com Wed Jul 13 12:38:45 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 13 Jul 2005 08:38:45 -0400 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050713100636.GE4681@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050711152503.GC10052@redhat.com> <20050713100636.GE4681@redhat.com> Message-ID: <20050713123844.GA18166@redhat.com> * Gary Benson [2005-07-13 06:06]: > Andrew Overholt wrote: > > * Gary Benson [2005-07-06 11:41]: > > > > > > 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files. > > > > > I've chopped down the Eclipse specfile and changed it to use your > > new aot-compile, but the files section is confusing to me. With > > Eclipse, we split up the package into sub-RPMs. Can we make it so > > that the native bits are split up like this? > > Unfortunatly no, not automatically. The information is not made > available by rpm. There are two options: > > > Should I just go through and change my current > > %{_libdir}/%{name}/ to %{_libdir}/gcj/%{name}/ in each > > of the sub-packages' %files sections? > > This is one option. The other is to rearrange the files after the > aot-compile-rpm line in %install. The one you suggested is probably > better. Okay, but what about the .db? Right now we have multiple dbs - one for each sub-package. Can we have this as well? Thanks, Andrew From gbenson at redhat.com Wed Jul 13 13:28:44 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 13 Jul 2005 14:28:44 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050713123844.GA18166@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050711152503.GC10052@redhat.com> <20050713100636.GE4681@redhat.com> <20050713123844.GA18166@redhat.com> Message-ID: <20050713132843.GG4681@redhat.com> Andrew Overholt wrote: > * Gary Benson [2005-07-13 06:06]: > > Andrew Overholt wrote: > > > * Gary Benson [2005-07-06 11:41]: > > > > 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files. > > > > > I've chopped down the Eclipse specfile and changed it to use > > > your new aot-compile, but the files section is confusing to me. > > > With Eclipse, we split up the package into sub-RPMs. Can we > > > make it so that the native bits are split up like this? > > > > Unfortunatly no, not automatically. The information is not made > > available by rpm. There are two options: > > [snip] > > Okay, but what about the .db? Right now we have multiple dbs - one > for each sub-package. Can we have this as well? aot-compile-rpm will make a separate database for each jarfile. Cheers, Gary From overholt at redhat.com Wed Jul 13 14:54:15 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 13 Jul 2005 10:54:15 -0400 Subject: [fedora-java] Eclipse Automated Tests In-Reply-To: <20050712205457.GC10665@redhat.com> References: <20050711202523.GG10052@redhat.com> <20050712205457.GC10665@redhat.com> Message-ID: <20050713145414.GA28726@redhat.com> Hi, I let the tests run after leaving yesterday. Here are results, etc. http://people.redhat.com/overholt/eclipse/eclipse-tests/results/3.1.0_fc-2.ppc.20050713 Test results: ___________________________________________________________________________ / Test | # tst | Fail | Err | % | t (s) \ |===================================|=======|======|=====|========|==========| |org.eclipse.ant.core | 84 | 3 | 0 | 96.43 | 129.894 | |org.eclipse.ant.ui | 164 | 13 | 29 | 74.39 | 262.837 | |org.eclipse.compare | 23 | 0 | 0 | 100.00 | 0.298 | |org.eclipse.core.expressions | 31 | 0 | 0 | 100.00 | 0.070 | |org.eclipse.core.filebuffer | 218 | 14 | 0 | 93.58 | 68.946 | |org.eclipse.help | 91 | 10 | 2 | 86.81 | 217.543 | |org.eclipse.jdt.core.builder | 104 | 0 | 0 | 100.00 | 260.146 | |org.eclipse.jdt.core.compiler | 5844 | 6 | 0 | 99.90 | 393.635 | |org.eclipse.jdt.core.model | 7031 | 6 | 5 | 99.84 | 1160.622 | |org.eclipse.jdt.core.performance | 1 | 0 | 0 | 100.00 | 0.041 | |org.eclipse.jdt.debug | 405 | 8 | 134 | 64.94 | 2728.929 | |org.eclipse.jdt.text | 327 | 10 | 0 | 96.94 | 226.457 | |org.eclipse.jface.text | 100 | 0 | 0 | 100.00 | 26.548 | |org.eclipse.ltk.core.refactoring | 2 | 0 | 0 | 100.00 | 1.723 | |org.eclipse.ltk.ui.refactoring | 1 | 0 | 0 | 100.00 | 0.011 | |org.eclipse.pde.ui | 0 | 0 | 0 | NaN | 0.000 | |org.eclipse.swt | 5115 | 20 | 147 | 96.74 | 98.027 | |org.eclipse.text | 366 | 0 | 0 | 100.00 | 0.516 | |org.eclipse.ui.editors | 11 | 0 | 0 | 100.00 | 7.985 | |org.eclipse.ui.rcp | 21 | 0 | 0 | 100.00 | 23.011 | |org.eclipse.ui.workbench.texteditor| 16 | 0 | 5 | 68.75 | 1.840 | \____________________________________________________________________________/ Did not complete (will investigate): org.eclipse.jdt.ui.tests.refactoring_.html org.eclipse.jdt.ui.tests_.html org.eclipse.ui.tests_.html No tests ran (will investigate): org.eclipse.pde.ui.tests_.html Dramatic size differences (from Aaron's previous run [1]): For some reason, I was getting shorter tracebacks than a previous run that Aaron did. This caused the majority of the size differences between my test run and his. org.eclipse.ant.tests.core_.html <-- smaller tracebacks (s.t) org.eclipse.ant.tests.ui_.html <-- more failures with me, (s.t) org.eclipse.core.filebuffers.tests_.html <-- took way longer, (s.t) org.eclipse.help.tests_.html <-- more tests ran w/me org.eclipse.jdt.core.tests.builder_.html <-- I ran perf. as well org.eclipse.swt.tests_.html <-- 20 vs. 0 failures org.eclipse.ui.workbench.texteditor.tests_.html <-- (s.t) My times: The tests that took forever are due to some sort of weirdness that happened after the actual tests completed because the test times themselves aren't incredibly different. I marked ones that were questionable with an asterisk. Comments are in comparison to upstream times. Not all tests listed. Jul 12 22:41 org.eclipse.jdt.core.tests.builder_.html (5 min) Jul 12 22:49 org.eclipse.jdt.core.tests.compiler_.html (8 min) Jul 12 23:09 org.eclipse.jdt.core.tests.model_.html faster! (20 min) * Jul 13 01:17 org.eclipse.ui.editors.tests_.html !!!! (2 h 8 min) * Jul 13 01:18 org.eclipse.ui.workbench.texteditor.tests_.html (1 min) Jul 13 01:19 org.eclipse.ui.tests.rcp_.html (1 min) Jul 13 02:06 org.eclipse.jdt.debug.tests_.html obviously! (47 min) * Jul 13 06:21 org.eclipse.ltk.ui.refactoring.tests_.html !!!! (4 h 15 min) * Jul 13 06:22 org.eclipse.ltk.core.refactoring.tests_.html (1 min) Jul 13 06:22 org.eclipse.text.tests_.html (< 1 min) Jul 13 06:23 org.eclipse.jface.text.tests_.html (1 min) Jul 13 06:25 org.eclipse.core.filebuffers.tests_.html (2 min) Jul 13 06:30 org.eclipse.ant.tests.ui_.html (5 min) Jul 13 06:33 org.eclipse.swt.tests_.html (3 min) Thoughts: We're doing well overall. The debug tests I would expect to fail since we don't yet have JDWP. I should have logged everything so that I could tell what was taking so long between tests; I will do that the next time I run them. Note that these were run on my G5 box with our ppc RPMs from rawhide (but not the latest gcc from rawhide). Andrew [1] http://people.redhat.com/aluchko/eclipse-3.1.0_fc-2_tests_gcj/ From mark at klomp.org Wed Jul 13 15:11:42 2005 From: mark at klomp.org (Mark Wielaard) Date: Wed, 13 Jul 2005 17:11:42 +0200 Subject: [fedora-java] Eclipse Automated Tests In-Reply-To: <20050713145414.GA28726@redhat.com> References: <20050711202523.GG10052@redhat.com> <20050712205457.GC10665@redhat.com> <20050713145414.GA28726@redhat.com> Message-ID: <1121267502.13727.87.camel@localhost.localdomain> On Wed, 2005-07-13 at 10:54 -0400, Andrew Overholt wrote: > I let the tests run after leaving yesterday. Here are results, etc. > > http://people.redhat.com/overholt/eclipse/eclipse-tests/results/3.1.0_fc-2.ppc.20050713 Wow! Just wanted to say: NICE! We really need more automated tests like this. Thanks for doing this. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From overholt at redhat.com Wed Jul 13 16:07:55 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 13 Jul 2005 12:07:55 -0400 Subject: [fedora-java] photran fortran dev module for eclipse In-Reply-To: <42D2EE27.901@cora.nwra.com> References: <42D2A00F.9040807@cora.nwra.com> <1121104732.10147.3.camel@tofu.toronto.redhat.com> <42D2C7A1.6060209@cora.nwra.com> <20050711200330.GF10052@redhat.com> <42D2DC2C.3090406@cora.nwra.com> <42D2E1DB.8030508@cora.nwra.com> <20050711214918.GA10038@redhat.com> <42D2EE27.901@cora.nwra.com> Message-ID: <20050713160755.GA29302@redhat.com> Hi, So after taking a quick look online, it looks like photran a) doesn't work Eclipse 3.1 yet and b) doesn't have public CVS. Something will need to be done about the latter if we want a buildable source zip. We should contact the authors and discuss options and then hopefully be ready to go by the time photran works with 3.1. Andrew From orion at cora.nwra.com Wed Jul 13 16:15:57 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 13 Jul 2005 10:15:57 -0600 Subject: [fedora-java] photran fortran dev module for eclipse In-Reply-To: <20050713160755.GA29302@redhat.com> References: <42D2A00F.9040807@cora.nwra.com> <1121104732.10147.3.camel@tofu.toronto.redhat.com> <42D2C7A1.6060209@cora.nwra.com> <20050711200330.GF10052@redhat.com> <42D2DC2C.3090406@cora.nwra.com> <42D2E1DB.8030508@cora.nwra.com> <20050711214918.GA10038@redhat.com> <42D2EE27.901@cora.nwra.com> <20050713160755.GA29302@redhat.com> Message-ID: <42D53E3D.4000307@cora.nwra.com> Andrew Overholt wrote: > Hi, > > So after taking a quick look online, it looks like photran a) doesn't work > Eclipse 3.1 yet and b) doesn't have public CVS. Something will need to be > done about the latter if we want a buildable source zip. We should contact > the authors and discuss options and then hopefully be ready to go by the > time photran works with 3.1. > > Andrew I've contacted the developers to try to get access to the sources. I've gotten a positive response, but no source yet. We'll see. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bishoph at open-xchange.org Wed Jul 13 17:05:32 2005 From: bishoph at open-xchange.org (Martin Kauss) Date: Wed, 13 Jul 2005 19:05:32 +0200 (CEST) Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> Message-ID: <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> On Jul 09, 2005 01:21 PM, Martin Kauss wrote: > On Jul 09, 2005 09:54 AM, Chris Burdess wrote: > > > Martin Kauss wrote: > > > > So what I understand is this: (Correct me if I'm wrong) > > > > 1. Problems with servlets are solvable with free Java tools, and these > > > > are not major showstoppers > > > > > > I am not aware of any servlet issues at all, tomcat for example > > > should provide all necessary libraries. > > > > GNU provides the servlet API 2.4: > > > > cvs -d anoncvs at savannah.gnu.org:/cvsroot/classpathx co servletapi > > > > If a package is needed I can make one. > > > > > > 3. Main problem is that the free Javamail does not implement some > > > > methods that are needed by OX. > > > > > > Correct. > > > > I haven't heard any issues raised on classpathx-javamail at gnu.org or > > submitted as bugs or patches at > > > > http://savannah.gnu.org/projects/classpathx > > > > GNU JavaMail provides all the API methods provided by the JavaMail API. > > If OX depends on com.sun APIs or on undocumented session properties, > > this is an issue for OX to resolve. If there is functionality you want > > exposing, there should be no problem, but you have to let us know. > > > > > Finally i would like to mention that Sun do a great Job for Javamail > > > with the mail protocol support and with the supported mail servers > > > and IMHO it will not be easy to get to the same functionality. > > > > GNU JavaMail doesn't explicitly support servers, it implements the > > published standards. Sun's implementation supports 3 providers > > (IMAP4, POP3, SMTP). GNU JavaMail supports 6 providers (IMAP4rev1, POP3, > > SMTP, NNTP, mbox, Maildir) and we had SASL and STARTTLS support long > > before Sun. Arguably we provide considerably more functionality. > > -- > > Chris Burdess > > > > > Hi, > > first of all i want to state that i do not want to start > a discussion like vi/emacs, linux/windows or something > similar. For us, freedom of choice is importend and if the > classpath project fits the needs - it is just fine. > > Only one statement i want to clarify: > I wrote that the Javamail API supports servers - maybe i should > say that it has been tested against several servers > (like mentioned in the notes, http://java.sun.com/products/javamail/NOTES13.txt). > > > I will discuss the issue of "undocumented" calls at the beginning of the next > week with our developer team and i will check again the classpath > API because - like i wrote - i tested some month ago and > at this time some methods were not included. I want to be up-to-date. > > Please be patient until we have investigated the details. > > > Best regards, > > Martin Kauss > Hi again, as i told you we have tested the current GNU classapth javamail version against OX. Here are the results: The complete part "Rights" is missing in the classpath implementation or i was not able to find it (http://www.gnu.org/software/classpathx/javamail/javadoc/alphaindex.html). However, there is another big issue: If you take a deeper look into the implementation, related to the errors you get from your compiler, you see that the methods just do not match: http://www.gnu.org/software/classpathx/javamail/javadoc/gnu/mail/providers/imap/IMAPFolder.html http://java.sun.com/products/javamail/1.3/docs/javadocs/com/sun/mail/imap/IMAPFolder.html There are some other minor issues, but the ones above are really big ones. I am not sure what was meant with this "undocumented" stuff, but maybe somebody can comment this and our results. Best regards, Martin Kauss From david at zarb.org Wed Jul 13 18:17:55 2005 From: david at zarb.org (David Walluck) Date: Wed, 13 Jul 2005 14:17:55 -0400 Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> Message-ID: <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> Martin Kauss wrote: > The complete part "Rights" is missing in the classpath > implementation or i was not able to find it > (http://www.gnu.org/software/classpathx/javamail/javadoc/alphaindex.html). The problem is that Rights, as well as ACL and Quota, are in a com.sun package. Quoting from the documentation: ``In general, applications should not need to use the classes in this package directly. Instead, they should use the APIs defined by javax.mail package (and subpackages). ... WARNING: The APIs unique to this package should be considered EXPERIMENTAL. They may be changed in the future in ways that are incompatible with applications using the current APIs.'' The problem is that we have public javax.mail API's that return class instances from the internal package com.sun.mail. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From overholt at redhat.com Wed Jul 13 18:48:53 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 13 Jul 2005 14:48:53 -0400 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050713132843.GG4681@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050711152503.GC10052@redhat.com> <20050713100636.GE4681@redhat.com> <20050713123844.GA18166@redhat.com> <20050713132843.GG4681@redhat.com> Message-ID: <20050713184853.GA31384@redhat.com> * Gary Benson [2005-07-13 09:28]: > > Okay, but what about the .db? Right now we have multiple dbs - one > > for each sub-package. Can we have this as well? > > aot-compile-rpm will make a separate database for each jarfile. Cool. I went through and added aot-compile-rpm to the end of %install but it fails with: + aot-compile-rpm Traceback (most recent call last): File "/usr/bin/aot-compile-rpm", line 203, in ? aot_compile_rpm( File "/usr/bin/aot-compile-rpm", line 25, in aot_compile_rpm for jar in weed_jars(strip_exclusions(find_jars(basedir), exclusions)): File "/usr/bin/aot-compile-rpm", line 48, in find_jars os.path.walk(dir, visit, jars) File "/usr/lib/python2.4/posixpath.py", line 298, in walk walk(name, func, arg) File "/usr/lib/python2.4/posixpath.py", line 298, in walk walk(name, func, arg) File "/usr/lib/python2.4/posixpath.py", line 298, in walk walk(name, func, arg) File "/usr/lib/python2.4/posixpath.py", line 298, in walk walk(name, func, arg) File "/usr/lib/python2.4/posixpath.py", line 298, in walk walk(name, func, arg) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/bin/aot-compile-rpm", line 45, in visit assert not jars.has_key(item) AssertionError error: Bad exit status from /var/tmp/rpm-tmp.84677 (%install) Any ideas? My python-fu is _very_ weak (and by that I mean it's non-existent). Andrew From crawley at dstc.edu.au Thu Jul 14 01:56:03 2005 From: crawley at dstc.edu.au (Stephen Crawley) Date: Thu, 14 Jul 2005 11:56:03 +1000 Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: Message from David Walluck of "Wed, 13 Jul 2005 14:17:55 -0400." <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> Message-ID: <200507140155.j6E1t4o2007601@piglet.dstc.edu.au> You wrote: > The problem is that we have public javax.mail API's that return class > instances from the internal package com.sun.mail. Really? My reading was that the javax.mail.Folder is clean. The problem is that some key public methods com.sun.mail.imap.IMAPFolder do not have corresponding methods in a javax.mail.* interface. The net result is that someone trying to access the "IMAP ACL extension" functionality cannot avoid using vendor specific APIs. The same applies to other IMAP functionality and to functionality in the other providers. Someone ought to report this to Sun as a defect in the JavaMail 1.3 APIs. The APIs have not been touched since JSR 919 in 2002! -- Steve From emailsretornados at yahoo.com.br Thu Jul 14 07:04:08 2005 From: emailsretornados at yahoo.com.br (Cameras Sim. CFTV com FRETE GRATIS para TODO Brasil) Date: Thu, 14 Jul 2005 07:04:08 GMT Subject: [fedora-java] Cameras Sim. CFTV - FRETE GRATIS para TODO Brasil Message-ID: <200507140704.j6E745bH030138@mx3.redhat.com> An HTML attachment was scrubbed... URL: From gbenson at redhat.com Thu Jul 14 08:54:38 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 14 Jul 2005 09:54:38 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050713184853.GA31384@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050711152503.GC10052@redhat.com> <20050713100636.GE4681@redhat.com> <20050713123844.GA18166@redhat.com> <20050713132843.GG4681@redhat.com> <20050713184853.GA31384@redhat.com> Message-ID: <20050714085437.GA4688@redhat.com> Andrew Overholt wrote: > Cool. I went through and added aot-compile-rpm to the end of > %install but it fails with: > > + aot-compile-rpm > Traceback (most recent call last): > [snip] > AssertionError > error: Bad exit status from /var/tmp/rpm-tmp.84677 (%install) > > Any ideas? My python-fu is _very_ weak (and by that I mean it's > non-existent). I committed some improvements to this bit yesterday; the very latest aot-compile-rpm (from java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_37rh) might cope, and even if it doesn't it'll give you a more meaningful error message. (And if it does give an error then let me know and I'll fix it...) Cheers, Gary From peter.backlund at home.se Thu Jul 14 09:00:28 2005 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 14 Jul 2005 11:00:28 +0200 Subject: [fedora-java] .jar and .so both loaded? Message-ID: <1121331628.12533.12.camel@localhost.localdomain> Hello. I have a couple of questions about class loading in natively compiled Java applications: should an application that has been natively compiled (i.e. all .jars compiled into .so by gcj and a .db created, according to http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ) load both the .jars and the .so into memory? lsof seems to think that is the case. Also, Eclipse in Rawhide consumes almost twice as much memory for starting up and opening HelloWorld.java as the Sun JVM 1.5.0_03/upstream Eclipse combination. Is it still possible to build a Java application into a standalone executable, that does not require gij to run? Is there any guilde on how to do that? /Peter Backlund From aph at redhat.com Thu Jul 14 09:42:29 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jul 2005 10:42:29 +0100 Subject: [fedora-java] .jar and .so both loaded? In-Reply-To: <1121331628.12533.12.camel@localhost.localdomain> References: <1121331628.12533.12.camel@localhost.localdomain> Message-ID: <17110.13189.862003.59849@zapata.pink> Peter Backlund writes: > I have a couple of questions about class loading in natively compiled > Java applications: should an application that has been natively compiled > (i.e. all .jars compiled into .so by gcj and a .db created, according to > http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ) load both > the .jars and the .so into memory? lsof seems to think that is the > case. Yes. > Also, Eclipse in Rawhide consumes almost twice as much memory for > starting up and opening HelloWorld.java as the Sun JVM 1.5.0_03/upstream > Eclipse combination. Yeah, we know. It's something we need to investigate and fix. > Is it still possible to build a Java application into a standalone > executable, that does not require gij to run? Is there any guilde on how > to do that? As far as I'm aware it's all in the manual. Andrew. From gbenson at redhat.com Thu Jul 14 09:59:33 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 14 Jul 2005 10:59:33 +0100 Subject: [fedora-java] .jar and .so both loaded? In-Reply-To: <1121331628.12533.12.camel@localhost.localdomain> References: <1121331628.12533.12.camel@localhost.localdomain> Message-ID: <20050714095932.GC4688@redhat.com> Peter Backlund wrote: > Is it still possible to build a Java application into a standalone > executable, that does not require gij to run? Is there any guilde > on how to do that? You can use something like: gcj --main=com.foo.bar.Main libbaz.jar.so -o moose (Though you don't gain much over gij) Cheers, Gary From aph at redhat.com Thu Jul 14 10:02:07 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jul 2005 11:02:07 +0100 Subject: [fedora-java] .jar and .so both loaded? In-Reply-To: <20050714095932.GC4688@redhat.com> References: <1121331628.12533.12.camel@localhost.localdomain> <20050714095932.GC4688@redhat.com> Message-ID: <17110.14367.217082.148815@zapata.pink> Gary Benson writes: > Peter Backlund wrote: > > Is it still possible to build a Java application into a standalone > > executable, that does not require gij to run? Is there any guilde > > on how to do that? > > You can use something like: > > gcj --main=com.foo.bar.Main libbaz.jar.so -o moose gcj --main=com.foo.bar.Main -lbaz.jar -o moose Andrew. From gbenson at redhat.com Thu Jul 14 10:10:51 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 14 Jul 2005 11:10:51 +0100 Subject: [fedora-java] .jar and .so both loaded? In-Reply-To: <17110.14367.217082.148815@zapata.pink> References: <1121331628.12533.12.camel@localhost.localdomain> <20050714095932.GC4688@redhat.com> <17110.14367.217082.148815@zapata.pink> Message-ID: <20050714101050.GD4688@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Peter Backlund wrote: > > > Is it still possible to build a Java application into a standalone > > > executable, that does not require gij to run? Is there any guilde > > > on how to do that? > > > > You can use something like: > > > > gcj --main=com.foo.bar.Main libbaz.jar.so -o moose > > gcj --main=com.foo.bar.Main -lbaz.jar -o moose Eclipse does what I said to make the ecj executable. What's the difference? Cheers, Gary From aph at redhat.com Thu Jul 14 10:24:59 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jul 2005 11:24:59 +0100 Subject: [fedora-java] .jar and .so both loaded? In-Reply-To: <20050714101050.GD4688@redhat.com> References: <1121331628.12533.12.camel@localhost.localdomain> <20050714095932.GC4688@redhat.com> <17110.14367.217082.148815@zapata.pink> <20050714101050.GD4688@redhat.com> Message-ID: <17110.15739.699234.825976@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > Peter Backlund wrote: > > > > Is it still possible to build a Java application into a standalone > > > > executable, that does not require gij to run? Is there any guilde > > > > on how to do that? > > > > > > You can use something like: > > > > > > gcj --main=com.foo.bar.Main libbaz.jar.so -o moose > > > > gcj --main=com.foo.bar.Main -lbaz.jar -o moose > > Eclipse does what I said to make the ecj executable. What's the > difference? The right way to link against a shared library is the -lfoo syntax. Other forms might work. Andrew. From bishoph at open-xchange.org Thu Jul 14 12:32:57 2005 From: bishoph at open-xchange.org (Martin Kauss) Date: Thu, 14 Jul 2005 14:32:57 +0200 (CEST) Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> Message-ID: <26613121.1121344377342.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> Am Jul 13, 2005 08:17 PM schrieb David Walluck : > Martin Kauss wrote: > > > The complete part "Rights" is missing in the classpath > > implementation or i was not able to find it > > (http://www.gnu.org/software/classpathx/javamail/javadoc/alphaindex.html). > > The problem is that Rights, as well as ACL and Quota, are in a com.sun > package. > > Quoting from the documentation: > > ``In general, applications should not need to use the classes in this package > directly. Instead, they should use the APIs defined by javax.mail package (and > subpackages). > > ... > > WARNING: The APIs unique to this package should be considered > EXPERIMENTAL. They > may be changed in the future in ways that are incompatible with applications > using the current APIs.'' > > The problem is that we have public javax.mail API's that return class > instances > from the internal package com.sun.mail. > > -- > Sincerely, > > David Walluck > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > Hi. OX makes use of the class IMAPFolder and there you have the method addRights(ACL acl) which lead us to setRights(Rights rights) and there we find the Rights. The GNU classpath javamail API does not have the method addRights(ACL acl) and no setRights(Rights rights) in the IMAPFolder class, see http://www.gnu.org/software/classpathx/javamail/javadoc/gnu/mail/providers/imap/IMAPFolder.html The main issue is not to use class instances (replacements), the main issue is that the classpath API does currently not implement methods needed by OX. However, you are right, the class is experimental, but for some reasons also the GNU classpath people have implement a clone of this class. In fact we/you have to investigate if OX can offer the same functionality by using other classes and what is the effort/benefit of such a change. Greetings, Martin Kauss From peter.backlund at home.se Thu Jul 14 13:58:01 2005 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 14 Jul 2005 15:58:01 +0200 Subject: [fedora-java] Re: .jar and .so both loaded? In-Reply-To: <17110.13189.862003.59849@zapata.pink> References: <1121331628.12533.12.camel@localhost.localdomain> <17110.13189.862003.59849@zapata.pink> Message-ID: <1121349481.16479.5.camel@localhost.localdomain> tor 2005-07-14 klockan 10:42 +0100 skrev Andrew Haley: > Peter Backlund writes: > > > I have a couple of questions about class loading in natively compiled > > Java applications: should an application that has been natively compiled > > (i.e. all .jars compiled into .so by gcj and a .db created, according to > > http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ) load both > > the .jars and the .so into memory? lsof seems to think that is the > > case. > > Yes. > > > Also, Eclipse in Rawhide consumes almost twice as much memory for > > starting up and opening HelloWorld.java as the Sun JVM 1.5.0_03/upstream > > Eclipse combination. > > Yeah, we know. It's something we need to investigate and fix. My point was that the excessive memory usage might be due to the fact that both .jar and .so files are loaded into memory. Why is the bytecode needed at all when there are pre-compiled shared libraries with the same code already available? > > Is it still possible to build a Java application into a standalone > > executable, that does not require gij to run? Is there any guilde on how > > to do that? > > As far as I'm aware it's all in the manual. Well, of course, but I was looking for something a little more high-level, maybe a tutorial on how to convert a semi-big Java application into a native executable + shared libs. Anyway, I'll figure it out. Do you lose the ability to load Java bytecode during runtime when compiling it as a native executable? /Peter From gbenson at redhat.com Thu Jul 14 14:06:36 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 14 Jul 2005 15:06:36 +0100 Subject: [fedora-java] Re: .jar and .so both loaded? In-Reply-To: <1121349481.16479.5.camel@localhost.localdomain> References: <1121331628.12533.12.camel@localhost.localdomain> <17110.13189.862003.59849@zapata.pink> <1121349481.16479.5.camel@localhost.localdomain> Message-ID: <20050714140634.GH4688@redhat.com> Peter Backlund wrote: > Well, of course, but I was looking for something a little more > high-level, maybe a tutorial on how to convert a semi-big Java > application into a native executable + shared libs. Anyway, I'll > figure it out. If you are packaging said application into an rpm then aot-compile-rpm is the way to go. > Do you lose the ability to load Java bytecode during runtime when > compiling it as a native executable? Nope. Cheers, Gary From aph at redhat.com Thu Jul 14 14:45:37 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jul 2005 15:45:37 +0100 Subject: [fedora-java] Re: .jar and .so both loaded? In-Reply-To: <1121349481.16479.5.camel@localhost.localdomain> References: <1121331628.12533.12.camel@localhost.localdomain> <17110.13189.862003.59849@zapata.pink> <1121349481.16479.5.camel@localhost.localdomain> Message-ID: <17110.31377.276865.951743@zapata.pink> Peter Backlund writes: > tor 2005-07-14 klockan 10:42 +0100 skrev Andrew Haley: > > Peter Backlund writes: > > > > > I have a couple of questions about class loading in natively compiled > > > Java applications: should an application that has been natively compiled > > > (i.e. all .jars compiled into .so by gcj and a .db created, according to > > > http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ) load both > > > the .jars and the .so into memory? lsof seems to think that is the > > > case. > > > > Yes. > > > > > Also, Eclipse in Rawhide consumes almost twice as much memory for > > > starting up and opening HelloWorld.java as the Sun JVM 1.5.0_03/upstream > > > Eclipse combination. > > > > Yeah, we know. It's something we need to investigate and fix. > > My point was that the excessive memory usage might be due to the fact > that both .jar and .so files are loaded into memory. That's an interesting guess, but it may not be true at all. We'll have to make some measurements to know for sure. > Why is the bytecode needed at all when there are pre-compiled > shared libraries with the same code already available? Well, that's how class loaders work. But you can avoid this overhead altogether if you link with gcj. Just compile your java library code with gcj -shared -o libfoo.so and then link with your executable using gcj -lfoo and you won't need jar files. > > > Is it still possible to build a Java application into a standalone > > > executable, that does not require gij to run? Is there any guilde on how > > > to do that? > > > > As far as I'm aware it's all in the manual. > > Well, of course, but I was looking for something a little more > high-level, maybe a tutorial on how to convert a semi-big Java > application into a native executable + shared libs. Gary Benson is working on making that as painless as possible, and the next Fedora Core will have a lot of worked examples. But yes, we could also use a tutorial. > Anyway, I'll figure it out. > > Do you lose the ability to load Java bytecode during runtime when > compiling it as a native executable? No, not all all. That still works. Andrew. From mckinlay at redhat.com Thu Jul 14 14:58:05 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Thu, 14 Jul 2005 10:58:05 -0400 Subject: [fedora-java] Jonas vs JTA Message-ID: <42D67D7D.7060103@redhat.com> java-1.4.2-gcj-compat provides a jta.jar which is linked against libgcj's libgcj.jar. It seems that libgcj is wrong to include JTA in the core class libraries. Previous J2SE versions may have included all of javax.transaction, but the current specs for 1.4.2 and 1.5 show that the J2SE now only includes a few exceptions, which are required by CORBA. Further, this creates difficulties testing FC's Jonas with other jpackaged JVMs because they require a separate jta.jar. I propose: 1. Removing JTA from libgcj/classpath (leaving just the 3 exceptions in javax.transaction which are provided by the J2SE) 2. Remove the jta.jar link from java-gcj-compat 3. Include a separate jta package in Fedora that contains jta.jar Anyone have concerns/problems with this? Bryce From david at zarb.org Thu Jul 14 15:53:19 2005 From: david at zarb.org (David Walluck) Date: Thu, 14 Jul 2005 11:53:19 -0400 Subject: [fedora-java] Jonas vs JTA In-Reply-To: <42D67D7D.7060103@redhat.com> References: <42D67D7D.7060103@redhat.com> Message-ID: <20050714115319.v5puqrfn4sckss8k@www.zarb.org> Bryce McKinlay wrote: > It seems that libgcj is wrong to include JTA in the core class > libraries. Previous J2SE versions may have included all of > javax.transaction, but the current specs for 1.4.2 and 1.5 show that the > J2SE now only includes a few exceptions, which are required by CORBA. It depends what you're going for. I would prefer it if GNU Classpath had branches such that features specific to 1.5 would be put in a separate branch. This isn't the first time a problem like this has occured. For example, if you look at the XML classes, they are compatible with 1.5 (I don't know if 1.4-compatible classes exist). This creates compatibility issues for things that are supposed to work with a 1.4 jdk. What I have ended up doing is using xerces for the XML classes instead. The current consensus with Classpath developers seems to be to include the whole kitchen sink. In my opinion, it should include all and only what a real jdk 1.4 provides and then provide a separate branch or external package for other apis. The problem we have with the XML (and maybe JTA) is that classpath is providing too much functionality or functionality of a spec whose version differs from the one that is included in the Sun jdk. To me this is worse than not including it at all because it cuases conflicts when trying to build things if we have a hybrid 1.3/1.4/1.5 jdk all rolled into one. > Further, this creates difficulties testing FC's Jonas with other > jpackaged JVMs because they require a separate jta.jar. What are the difficulties? `build-classpath jta` should return the correct jar even though the actual jar returned may differ based on jvm version. The whole way it is set up is to allow things like this to co-exist peacefully (i.e., some jvm's may have jta included and provide jta while others will require an external jta package to satisfy the dependency). Note that this is separate from the question as to whether Classpath should ship with jta or not. I just want to be sure that there isn't a packaging bug in the jvm. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From gbenson at redhat.com Thu Jul 14 16:14:09 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 14 Jul 2005 17:14:09 +0100 Subject: [fedora-java] Jonas vs JTA In-Reply-To: <42D67D7D.7060103@redhat.com> References: <42D67D7D.7060103@redhat.com> Message-ID: <20050714161408.GK4688@redhat.com> Bryce McKinlay wrote: > 1. Removing JTA from libgcj/classpath (leaving just the 3 exceptions > in javax.transaction which are provided by the J2SE) > 2. Remove the jta.jar link from java-gcj-compat > 3. Include a separate jta package in Fedora that contains jta.jar > > Anyone have concerns/problems with this? I might be able to fix this in the jonas rpm, without touching libgcj or java-gcj-compat. Watch this space... Cheers, Gary From gbenson at redhat.com Thu Jul 14 16:26:12 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 14 Jul 2005 17:26:12 +0100 Subject: [fedora-java] Jonas vs JTA In-Reply-To: <20050714115319.v5puqrfn4sckss8k@www.zarb.org> References: <42D67D7D.7060103@redhat.com> <20050714115319.v5puqrfn4sckss8k@www.zarb.org> Message-ID: <20050714162611.GL4688@redhat.com> David Walluck wrote: > Bryce McKinlay wrote: > > Further, this creates difficulties testing FC's Jonas with > > other jpackaged JVMs because they require a separate jta.jar. > > What are the difficulties? `build-classpath jta` should return the > correct jar even though the actual jar returned may differ based on > jvm version. It does, however, jonas makes a symbolic link to jta.jar using build-jar-repository at build time (well, %install time). Fedora's jonas is built with gcj, so the link points to gcj's jta.jar (in /usr/lib/jvm-exports/java/jta.jar). This link is not changed when you switch JVM. Cheers, Gary From gbenson at redhat.com Thu Jul 14 16:27:28 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 14 Jul 2005 17:27:28 +0100 Subject: [fedora-java] Jonas vs JTA In-Reply-To: <20050714161408.GK4688@redhat.com> References: <42D67D7D.7060103@redhat.com> <20050714161408.GK4688@redhat.com> Message-ID: <20050714162726.GM4688@redhat.com> Gary Benson wrote: > Bryce McKinlay wrote: > > 1. Removing JTA from libgcj/classpath (leaving just the 3 exceptions > > in javax.transaction which are provided by the J2SE) > > 2. Remove the jta.jar link from java-gcj-compat > > 3. Include a separate jta package in Fedora that contains jta.jar > > > > Anyone have concerns/problems with this? > > I might be able to fix this in the jonas rpm, without touching > libgcj or java-gcj-compat. Watch this space... I was wrong. Bryce, your suggestion seems to be the best way forward. Cheers, Gary From tromey at redhat.com Thu Jul 14 17:30:50 2005 From: tromey at redhat.com (Tom Tromey) Date: 14 Jul 2005 11:30:50 -0600 Subject: [fedora-java] .jar and .so both loaded? In-Reply-To: <1121331628.12533.12.camel@localhost.localdomain> References: <1121331628.12533.12.camel@localhost.localdomain> Message-ID: >>>>> "Peter" == Peter Backlund writes: Peter> Is it still possible to build a Java application into a standalone Peter> executable, that does not require gij to run? Is there any guilde on how Peter> to do that? Note that it can be tricky to do this for large applications, like Eclipse. You end up having to modify the application to understand how to treat gcj specially. This is what we did in the Eclipse 2.x days, but in 3.x they changed their class loaders and we didn't want to repeat the hacking... hence the current approach, which is invisible to the application. But, it certainly could be done. I think OSGi (the class loading infrastructure eclipse uses) leaves open the possibility of changes like this -- you can write your own low-level bits or something. (Obviously I'm not up on the details :-) Tom From fitzsim at redhat.com Thu Jul 14 17:43:13 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 14 Jul 2005 13:43:13 -0400 Subject: [fedora-java] Jonas vs JTA In-Reply-To: <42D67D7D.7060103@redhat.com> References: <42D67D7D.7060103@redhat.com> Message-ID: <1121362993.5852.62.camel@tortoise.toronto.redhat.com> On Thu, 2005-07-14 at 10:58 -0400, Bryce McKinlay wrote: > java-1.4.2-gcj-compat provides a jta.jar which is linked against > libgcj's libgcj.jar. > > It seems that libgcj is wrong to include JTA in the core class > libraries. Previous J2SE versions may have included all of > javax.transaction, but the current specs for 1.4.2 and 1.5 show that the > J2SE now only includes a few exceptions, which are required by CORBA. > > Further, this creates difficulties testing FC's Jonas with other > jpackaged JVMs because they require a separate jta.jar. > > I propose: > > 1. Removing JTA from libgcj/classpath (leaving just the 3 exceptions in > javax.transaction which are provided by the J2SE) > 2. Remove the jta.jar link from java-gcj-compat > 3. Include a separate jta package in Fedora that contains jta.jar > > Anyone have concerns/problems with this? Sounds good. You'll need to do 1) either upstream or in the Rawhide GCC RPMs. Gary and I can handle 2 and 3. Tom From dog at bluezoo.org Thu Jul 14 18:26:11 2005 From: dog at bluezoo.org (Chris Burdess) Date: Thu, 14 Jul 2005 19:26:11 +0100 Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: <26613121.1121344377342.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> <26613121.1121344377342.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> Message-ID: Martin Kauss wrote: >> The problem is that Rights, as well as ACL and Quota, are in a com.sun >> package. > > OX makes use of the class IMAPFolder and there you have the method > addRights(ACL acl) which lead us to setRights(Rights rights) > and there we find the Rights. > > The GNU classpath javamail API does not have the method addRights(ACL > acl) > and no setRights(Rights rights) in the IMAPFolder class, see > > http://www.gnu.org/software/classpathx/javamail/javadoc/gnu/mail/ > providers/imap/IMAPFolder.html > > The main issue is not to use class instances (replacements), > the main issue is that the classpath API does currently not > implement methods needed by OX. You haven't asked for them at any time, so it hasn't even been on our to-do list. > However, you are right, the class is experimental, It's not that it's experimental. It's that it's a private Sun implementation, it is not part of the API, and it will never be present in a free Java runtime. > but for some reasons also the GNU classpath people > have implement a clone of this class. It's not a clone. It's a completely different private implementation, that is still not part of the API. As Stephen Crawley noted, the problem is that the public API is underspecified and in order to use advanced IMAP functionality you need to use private implementations. > In fact we/you > have to investigate if OX can offer the same functionality > by using other classes and what is the effort/benefit > of such a change. The underlying library used by the GNU providers is called inetlib. It provides a much lower-level API to IMAP and other network protocols. If you want performance, and you can live without a MIME framework, it may be of interest to you. If you just want ACL support in the GNU IMAP provider, we can schedule it in for the next release. -- Chris Burdess From fernando at lozano.eti.br Thu Jul 14 20:46:21 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Thu, 14 Jul 2005 17:46:21 -0300 Subject: [fedora-java] .jar and .so both loaded? In-Reply-To: References: <1121331628.12533.12.camel@localhost.localdomain> Message-ID: <42D6CF1D.9090507@lozano.eti.br> Hi, >Peter> Is it still possible to build a Java application into a standalone >Peter> executable, that does not require gij to run? Is there any guilde on how >Peter> to do that? > >Note that it can be tricky to do this for large applications, like >Eclipse. You end up having to modify the application to understand >how to treat gcj specially. This is what we did in the Eclipse 2.x >days, but in 3.x they changed their class loaders and we didn't want >to repeat the hacking... hence the current approach, which is >invisible to the application. > > Hasn't anyone tried to use Eclipse CDT infrastructure for this? It is based on GDB and GDB supports native Java debugging. So you'd use a mix of JDT and CDT plug-ins for developing native GCJ apps. []s, Fernando Lozano From nando at antunes.eti.br Fri Jul 15 00:44:52 2005 From: nando at antunes.eti.br (C.F. Scheidecker Antunes) Date: Thu, 14 Jul 2005 18:44:52 -0600 Subject: [fedora-java] FC4 Tomcat & Jakarta Hell Message-ID: <42D70704.5060505@antunes.eti.br> Hello All, FC4 comes with Tomcat5 and Jakarta stuff such as struts, commons, etc. However FC4 does not come with a SUN JVM and I usually install my own in place of the currently one. I also install my own Tomcat and Jakarta stuff so that I can have the latest. I've also noticed that there is a service created to run Tomcat5 as well. Tomcat5 runs with a user tomcat which seems great as it not acceptable to run it as root. However it is an older version, it is organized spreaded into separate and various rpm packages which is not productive as well as not scalable. Struts is even version 1.1. Hence what I need is to install my own stuff. What do you recommend regarding this issue? Shall I remove the entire FC4 stuff or keep it and install my Tomcat/Jakarta/Struts/JVM and then change the service to reflect on my installation? In this case I assume I will have to change the privileges of the tomcat user and group and also make my root directory and its subdirectories reflect those privileges. Any suggestions or docs on Tomcat for FC4? Does anyone use Tomcat/struts/Commons with FC4? Thanks in advance, C.F. From green at redhat.com Fri Jul 15 00:49:28 2005 From: green at redhat.com (Anthony Green) Date: Thu, 14 Jul 2005 17:49:28 -0700 Subject: [fedora-java] Jonas vs JTA In-Reply-To: <42D67D7D.7060103@redhat.com> References: <42D67D7D.7060103@redhat.com> Message-ID: <1121388568.2988.8.camel@localhost.localdomain> On Thu, 2005-07-14 at 10:58 -0400, Bryce McKinlay wrote: > I propose: > > 1. Removing JTA from libgcj/classpath (leaving just the 3 exceptions in > javax.transaction which are provided by the J2SE) > 2. Remove the jta.jar link from java-gcj-compat > 3. Include a separate jta package in Fedora that contains jta.jar > > Anyone have concerns/problems with this? I proposed an RPM back in March that generated a jta.jar directly from the installed libgcj.jar, https://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00023.html Later I suggested it would be better to simply add this logic to the GCC spec file (on an internal RH mailing list I'm afraid). AG From eliteequitymktg at dfzmail.net Fri Jul 15 03:07:13 2005 From: eliteequitymktg at dfzmail.net (Elite Equity Marketing) Date: Thu, 14 Jul 2005 22:07:13 -0500 Subject: [fedora-java] YaSheng Group (YHGG) Announces 1st Quarter Results of $145 Million in Revenue Message-ID: <200507150307.j6F37HBj024561@mx1.redhat.com> An HTML attachment was scrubbed... URL: From dog at bluezoo.org Fri Jul 15 07:58:59 2005 From: dog at bluezoo.org (Chris Burdess) Date: Fri, 15 Jul 2005 08:58:59 +0100 Subject: [fedora-java] Fwd: Request to mailing list Devel rejected Message-ID: It would really be nice if the Open Exchange people sometimes engaged in a bit of open exchange. Begin forwarded message: > From: devel-bounces at open-xchange.org > Date: 15 July 2005 06:56:59 BST > To: dog at bluezoo.org > Subject: Request to mailing list Devel rejected > > Your request to the Devel mailing list > > Posting of your message titled "Re: [fedora-java] Re: [OX Devel] > Re: Devel Digest, Vol 12, Issue 6" > > has been rejected by the list moderator. The moderator gave the > following reason for rejecting your request: > > "No reason given" > > Any questions or comments should be directed to the list administrator > at: > > devel-owner at open-xchange.org > -- Chris Burdess From sebastian.kotyrba at open-xchange.org Fri Jul 15 08:09:07 2005 From: sebastian.kotyrba at open-xchange.org (Sebastian Kotyrba) Date: Fri, 15 Jul 2005 10:09:07 +0200 (CEST) Subject: [fedora-java] Re: Fwd: Request to mailing list Devel rejected In-Reply-To: References: Message-ID: <4519815.1121414947341.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> Helo, the process for rejecting emails is half automatic. They will be rejected, when: - the mail is send with an unknown emailadres - the mail is to bog (>100kb) - masked as spam (from spamassassin) Your eMail address 'dog at bluezoo.org' is not in the devel list!!! '/var/lib/mailman/bin# ./list_members devel | grep blue' return null Please send eMails to the maillinglists with your registrated eMail-address. Best regards, ?Sebastian Kotyrba Am Fr 15.07.2005 09:58 schrieb Chris Burdess : >It would really be nice if the Open Exchange people sometimes engaged >in a bit of open exchange. > >Begin forwarded message: > >>From: devel-bounces at open-xchange.org >>Date: 15 July 2005 06:56:59 BST >>To: dog at bluezoo.org >>Subject: Request to mailing list Devel rejected >> >>Your request to the Devel mailing list >> >>Posting of your message titled "Re: [fedora-java] Re: [OX Devel] >>Re: Devel Digest, Vol 12, Issue 6" >> >>has been rejected by the list moderator. The moderator gave the >>following reason for rejecting your request: >> >>"No reason given" >> >>Any questions or comments should be directed to the list administrator >>at: >> >>devel-owner at open-xchange.org >> >-- >Chris Burdess > > From bishoph at open-xchange.org Fri Jul 15 08:37:39 2005 From: bishoph at open-xchange.org (Martin Kauss) Date: Fri, 15 Jul 2005 10:37:39 +0200 (CEST) Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> <26613121.1121344377342.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> Message-ID: <22481221.1121416659482.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> Am Jul 14, 2005 08:26 PM schrieb Chris Burdess : > Martin Kauss wrote: > >> The problem is that Rights, as well as ACL and Quota, are in a com.sun > >> package. > > > > OX makes use of the class IMAPFolder and there you have the method > > addRights(ACL acl) which lead us to setRights(Rights rights) > > and there we find the Rights. > > > > The GNU classpath javamail API does not have the method addRights(ACL > > acl) > > and no setRights(Rights rights) in the IMAPFolder class, see > > > > http://www.gnu.org/software/classpathx/javamail/javadoc/gnu/mail/ > > providers/imap/IMAPFolder.html > > > > The main issue is not to use class instances (replacements), > > the main issue is that the classpath API does currently not > > implement methods needed by OX. > > You haven't asked for them at any time, so it hasn't even been on our > to-do list. > > > However, you are right, the class is experimental, > > It's not that it's experimental. It's that it's a private Sun > implementation, it is not part of the API, and it will never be present > in a free Java runtime. > > > but for some reasons also the GNU classpath people > > have implement a clone of this class. > > It's not a clone. It's a completely different private implementation, > that is still not part of the API. > > As Stephen Crawley noted, the problem is that the public API is > underspecified and in order to use advanced IMAP functionality you need > to use private implementations. > > > In fact we/you > > have to investigate if OX can offer the same functionality > > by using other classes and what is the effort/benefit > > of such a change. > > The underlying library used by the GNU providers is called inetlib. It > provides a much lower-level API to IMAP and other network protocols. If > you want performance, and you can live without a MIME framework, it may > be of interest to you. > > If you just want ACL support in the GNU IMAP provider, we can schedule > it in for the next release. > -- > Chris Burdess > Hi again. I stated this out in one of my earlier post, but i will make it even more clear: Open-Xchange provides currently a collaboration server, several extensions and frameworks. We are focused on functionality and features for the users and customers. To get this functionality we are using several libraries - you can see the list in out INSTALL file. Now the question came up if OX can build by using only "free" software tools and libraries. We can help to make such an implementation happen, but our focus is the solution and the features. Thats why we have not ask for methods. Now, if there is a strong demand and the GNU Classpath developers are scheduling the complete implementation of the required classes and methods for one of the next GNU Classpath javamail API releases, we should have some conversation how this can be implemented in a very easy way (like some kind of configure option) to support it (of course we must keep an eye on the effort ;-). And to avoid any rumor, this strategy is part of our general developing concepts. We do not reinvent wheels we are using existing infrastructure wherever it fits our needs. Greetings, Martin Kauss From NQG24419 at nifty.com Fri Jul 15 09:04:39 2005 From: NQG24419 at nifty.com (Ryan McDougall) Date: Fri, 15 Jul 2005 18:04:39 +0900 Subject: [fedora-java] Compiling a basic SWT app on FC4 Message-ID: <1121418279.17204.20.camel@SEMPUKI> I apologize if this question is too low level for this list, but I've spend the entire afternoon googling to no avail. I am trying to compile a simple SWT app using either Sun's Java or GCJ (preferably both) on my FC4 system. If I am successful at this (and the process is indeed complex), I don't mind writing up a tutorial for the Wiki or some such, in return. I have gcj and eclipse installed, as well as Sun's 1.5 JDK (java and javac are currently linked to Suns JVM, but I can change that back). short. Here are the current rpms that are relevant: libswt3-gtk2-3.1.0_fc-0.M6.22 libgcj-4.0.0-8 gcc-java-4.0.0-8 java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_31rh java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh Here is the simple app source in a file called TestGui.java: import org.eclipse.swt.*; public class TestGui { public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); Label label = new Label (shell, SWT.CENTER); label.setText ("Hello_world"); label.setBounds (shell.getClientArea ()); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } } I have tried the following commands based on guesses based on online tutorials: $ gcj --classpath=/usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.1.0.jar /usr/lib/eclipse/plugins/org.eclipse.swt.gtk_3.1.0.jar.so --main=TestGui TestGui.java -o Test Running Test gives me the following error: Exception in thread "main" java.lang.LinkageError: unexpected exception during linking: org.eclipse.swt.widgets.Display at java.lang.VMClassLoader.transformException(java.lang.Class, java.lang.Throwable) (/usr/lib/libgcj.so.6.0.0) at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0) at TestGui.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) Caused by: java.lang.NullPointerException at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.6.0.0) ...4 more I also tried: $ javac -classpath /usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.1.0.jar TestGui.java $ java -Djava.library.path=/usr/lib/eclipse/plugins/org.eclipse.swt.gtk_3.1.0.jar.so TestGui With the result being: Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/swt/widgets/Composite But I don't expect you to help me out with a propriety thing. :) Thank you for your time and effort! Cheers, Ryan From gbenson at redhat.com Fri Jul 15 09:09:18 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 15 Jul 2005 10:09:18 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050714085437.GA4688@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050711152503.GC10052@redhat.com> <20050713100636.GE4681@redhat.com> <20050713123844.GA18166@redhat.com> <20050713132843.GG4681@redhat.com> <20050713184853.GA31384@redhat.com> <20050714085437.GA4688@redhat.com> Message-ID: <20050715090916.GA5059@redhat.com> Gary Benson wrote: > Andrew Overholt wrote: > > Cool. I went through and added aot-compile-rpm to the end of > > %install but it fails with: > > > > + aot-compile-rpm > > Traceback (most recent call last): > > [snip] > > AssertionError > > error: Bad exit status from /var/tmp/rpm-tmp.84677 (%install) > > > > Any ideas? My python-fu is _very_ weak (and by that I mean it's > > non-existent). > > I committed some improvements to this bit yesterday; the very latest > aot-compile-rpm (from java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_37rh) > might cope, and even if it doesn't it'll give you a more meaningful > error message. I guess it coped then ;) Can I suggest this patch to eclipse.spec? Cheers, Gary -------------- next part -------------- Index: eclipse.spec =================================================================== RCS file: /cvs/dist/rpms/eclipse/devel/eclipse.spec,v retrieving revision 1.171 diff -u -r1.171 eclipse.spec --- eclipse.spec 14 Jul 2005 21:29:47 -0000 1.171 +++ eclipse.spec 15 Jul 2005 09:06:21 -0000 @@ -821,20 +821,16 @@ $RPM_BUILD_ROOT%{_datadir}/java/eclipse-ecj.jar %if %{gcj_support} -aot-compile-rpm --exclude /usr/share/eclipse/plugins/org.eclipse.osgi_3.1.0.jar - # FIXME: temporarily disable org.eclipse.ui.forms_3.1.0.jar.so # see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146463 -rm -f $RPM_BUILD_ROOT%{_libdir}/gcj/%{name}/org.eclipse.ui.forms_3.1.0.jar.db -rm -f $RPM_BUILD_ROOT%{_libdir}/gcj/%{name}/org.eclipse.ui.forms_3.1.0.jar.so # FIXME: temporarily disable org.eclipse.ui.workbench_3.1.0.jar.so # see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151919 -rm -f $RPM_BUILD_ROOT%{_libdir}/gcj/%{name}/org.eclipse.ui.workbench_3.1.0.jar.so -rm -f $RPM_BUILD_ROOT%{_libdir}/gcj/%{name}/org.eclipse.ui.workbench_3.1.0.jar.db # FIXME: temporarily disable org.eclipse.osgi_3.1.0.jar.so # see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158137 -rm -f $RPM_BUILD_ROOT%{_libdir}/gcj/%{name}/org.eclipse.osgi_3.1.0.jar.so -rm -f $RPM_BUILD_ROOT%{_libdir}/gcj/%{name}/org.eclipse.osgi_3.1.0.jar.db +aot-compile-rpm \ + --exclude /usr/share/eclipse/plugins/org.eclipse.ui.forms_3.1.0.jar \ + --exclude /usr/share/eclipse/plugins/org.eclipse.ui.workbench_3.1.0.jar \ + --exclude /usr/share/eclipse/plugins/org.eclipse.osgi_3.1.0.jar # Build and install ecj binary pushd $RPM_BUILD_ROOT%{_libdir}/gcj/%{name} From aph at redhat.com Fri Jul 15 09:46:16 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 Jul 2005 10:46:16 +0100 Subject: [fedora-java] Compiling a basic SWT app on FC4 In-Reply-To: <1121418279.17204.20.camel@SEMPUKI> References: <1121418279.17204.20.camel@SEMPUKI> Message-ID: <17111.34280.549028.101825@zapata.pink> Ryan McDougall writes: > I apologize if this question is too low level for this list, but I've > spend the entire afternoon googling to no avail. This is very much on-topic. > I am trying to compile a simple SWT app using either Sun's Java or GCJ > (preferably both) on my FC4 system. If I am successful at this (and the > process is indeed complex), I don't mind writing up a tutorial for the > Wiki or some such, in return. > > I have gcj and eclipse installed, as well as Sun's 1.5 JDK (java and > javac are currently linked to Suns JVM, but I can change that back). > short. > > Here are the current rpms that are relevant: > libswt3-gtk2-3.1.0_fc-0.M6.22 > libgcj-4.0.0-8 > gcc-java-4.0.0-8 > java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_31rh > java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh > > Here is the simple app source in a file called TestGui.java: > > import org.eclipse.swt.*; > > public class TestGui > { > public static void main (String [] args) { > Display display = new Display (); > Shell shell = new Shell (display); > Label label = new Label (shell, SWT.CENTER); > label.setText ("Hello_world"); > label.setBounds (shell.getClientArea ()); > shell.open (); > while (!shell.isDisposed ()) { > if (!display.readAndDispatch ()) display.sleep (); > } > display.dispose (); > } > } > > I have tried the following commands based on guesses based on online > tutorials: > > $ gcj > --classpath=/usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.1.0.jar /usr/lib/eclipse/plugins/org.eclipse.swt.gtk_3.1.0.jar.so --main=TestGui TestGui.java -o Test > > Running Test gives me the following error: > > Exception in thread "main" java.lang.LinkageError: unexpected exception > during linking: org.eclipse.swt.widgets.Display > at java.lang.VMClassLoader.transformException(java.lang.Class, > java.lang.Throwable) (/usr/lib/libgcj.so.6.0.0) > at java.lang.VMClassLoader.resolveClass(java.lang.Class) > (/usr/lib/libgcj.so.6.0.0) > at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0) > at TestGui.main(java.lang.String[]) (Unknown Source) > at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) > at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) > Caused by: java.lang.NullPointerException > at java.lang.VMClassLoader.resolveClass(java.lang.Class) > (/usr/lib/libgcj.so.6.0.0) > ...4 more OK, I had to add one line at the start of your demo: import org.eclipse.swt.widgets.*; And I tried to run it: $ gij -classpath /usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.1.0.jar TestGui Exception in thread "main" java.lang.UnsatisfiedLinkError: libswt-pi-gtk-3128: file not found at java.lang.Runtime._load(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) So, where is libswt-pi-gtk-3128 ? Bizzarrely, I found it in $HOME/.eclipse/org.eclipse.platform_3.1.0/configuration/org.eclipse.osgi/bundles/59/1/.cp/os/linux/x86/libswt-pi-gtk-3128.so (sorry, no, I have *no idea* why it's there) And then I ran the test like this: LD_LIBRARY_PATH=$HOME/.eclipse/org.eclipse.platform_3.1.0/configuration/org.eclipse.osgi/bundles/59/1/.cp/os/linux/x86 java -classpath /usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.1.0.jar TestGui which ran fine. There is probably some more official way of getting the path to libswt-pi-gtk-3128.so. Andrew. From vektor at dumbterm.net Fri Jul 15 12:19:44 2005 From: vektor at dumbterm.net (Billy Biggs) Date: Fri, 15 Jul 2005 07:19:44 -0500 Subject: [fedora-java] Compiling a basic SWT app on FC4 In-Reply-To: <17111.34280.549028.101825@zapata.pink> References: <1121418279.17204.20.camel@SEMPUKI> <17111.34280.549028.101825@zapata.pink> Message-ID: <20050715121944.GC7225@dumbterm.net> Andrew Haley (aph at redhat.com): > > Here are the current rpms that are relevant: > > libswt3-gtk2-3.1.0_fc-0.M6.22 > > $ gij -classpath /usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.1.0.jar TestGui > Exception in thread "main" java.lang.UnsatisfiedLinkError: libswt-pi-gtk-3128: file not found > at java.lang.Runtime._load(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) > > So, where is libswt-pi-gtk-3128 ? Bizzarrely, I found it in > > $HOME/.eclipse/org.eclipse.platform_3.1.0/configuration/org.eclipse.osgi/bundles/59/1/.cp/os/linux/x86/libswt-pi-gtk-3128.so The .jar file "org.eclipse.swt.gtk_3.1.0.jar" is SWT, but packaged as an Eclipse plugin. libswt-pi-gtk-3128.so is one of the JNI shared libraries required by SWT. It is located inside the SWT plugin .jar, and is extracted on-demand by Eclipse. Upstream at eclipse.org, we provide a separate SWT download, which is just swt.jar alone along with all of the shared libraries. IMHO, this package should be providing something similar. An swt.jar file, and the .so files, suitable for building standalone applications. libswt3-gtk2-3.1.0_fc-0.M6.22 I don't think it's doing that currently. -Billy From overholt at redhat.com Fri Jul 15 12:44:54 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 15 Jul 2005 08:44:54 -0400 Subject: [fedora-java] Compiling a basic SWT app on FC4 In-Reply-To: <20050715121944.GC7225@dumbterm.net> References: <1121418279.17204.20.camel@SEMPUKI> <17111.34280.549028.101825@zapata.pink> <20050715121944.GC7225@dumbterm.net> Message-ID: <20050715124454.GA3395@redhat.com> * Billy Biggs [2005-07-15 08:20]: > Upstream at eclipse.org, we provide a separate SWT download, which is > just swt.jar alone along with all of the shared libraries. > > IMHO, this package should be providing something similar. An swt.jar > file, and the .so files, suitable for building standalone applications. I thought I had mentioned this before, but here it is again: upstream, we did work to extract the .sos at install time. This work didn't make it into FC4 due to time and size constraints. As soon as we get a gcc update to FC4, 3.1 final will hit as an update which has these .sos extracted. Andrew From overholt at redhat.com Fri Jul 15 12:47:30 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 15 Jul 2005 08:47:30 -0400 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050715090916.GA5059@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050711152503.GC10052@redhat.com> <20050713100636.GE4681@redhat.com> <20050713123844.GA18166@redhat.com> <20050713132843.GG4681@redhat.com> <20050713184853.GA31384@redhat.com> <20050714085437.GA4688@redhat.com> <20050715090916.GA5059@redhat.com> Message-ID: <20050715124729.GB3395@redhat.com> * Gary Benson [2005-07-15 05:09]: > > I guess it coped then ;) Yup! > Can I suggest this patch to eclipse.spec? > [...] > +aot-compile-rpm \ > + --exclude /usr/share/eclipse/plugins/org.eclipse.ui.forms_3.1.0.jar \ > + --exclude /usr/share/eclipse/plugins/org.eclipse.ui.workbench_3.1.0.jar \ > + --exclude /usr/share/eclipse/plugins/org.eclipse.osgi_3.1.0.jar I tried the multiple --excludes and it didn't work. I assumed that syntax was just not supported. It is actually better IMO if we leave the jar.sos around (I should have made them .bak) so that it's easy to test if they're still mis-compiled. Either way, the new aot-compile-rpm is amAzing and I'm in the process or enabling it in all the other packages for which I am responsible. Thanks! Andrew From david at zarb.org Fri Jul 15 12:46:03 2005 From: david at zarb.org (David Walluck) Date: Fri, 15 Jul 2005 08:46:03 -0400 Subject: [fedora-java] FC4 Tomcat & Jakarta Hell In-Reply-To: <42D70704.5060505@antunes.eti.br> References: <42D70704.5060505@antunes.eti.br> Message-ID: <20050715084603.knglhwv64goo0008@www.zarb.org> "C.F. Scheidecker Antunes" wrote: > FC4 comes with Tomcat5 and Jakarta stuff such as struts, commons, etc. > However FC4 does not come with a SUN JVM and I usually install my own in > place of the currently one. I also install my own Tomcat and Jakarta You don't normally have to do the installs yourself. That's what the rpms are for. Also, tomcat 5.0.30 *is* the latest version of 5.0.x. Maybe you are talking about 5.5.x? > However it is an older version, it is organized spreaded into separate > and various rpm packages which is not productive as well as not > scalable. Struts is even version 1.1. I have no idea what you mean by the first part, but I don't think it is correct. As for struts, if I remember correctly, version 1.1.x is used because the newer version of struts does not work on a free stack. If you want the latest version, you'll have to use the Sun jdk right now. > Hence what I need is to install my own stuff. What do you recommend > regarding this issue? You can install the JPackage versions of tomcat5 which are compatible with FC4. JPackage also provides an rpm of the Sun jdk (but you will have to rebuild the rpm yourself, due to licensing restrictions). The JPackage version of tomcat 5.0.30 uses the struts 1.2.4. I see that struts 1.2.7 is the latest, but at least here you will get the 1.2.x series instead of 1.1.x. Finally, in the JPackage devel section on the you will find tomcat 5.5.7, but I see that tomcat 5.5.9 is the latest. You may want to subscribe to the jpackage-discuss mailing list and ask if struts 1.2.7 and tomcat 5.5.9 packages can be made. They will probably be rolled out fairly quickly, in which case you can then have the latest and greatest versions in rpm form, complete with dedicated user and startup scripts. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From gbenson at redhat.com Fri Jul 15 12:58:19 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 15 Jul 2005 13:58:19 +0100 Subject: [fedora-java] FC4 Tomcat & Jakarta Hell In-Reply-To: <20050715084603.knglhwv64goo0008@www.zarb.org> References: <42D70704.5060505@antunes.eti.br> <20050715084603.knglhwv64goo0008@www.zarb.org> Message-ID: <20050715125818.GD5059@redhat.com> David Walluck wrote: > "C.F. Scheidecker Antunes" wrote: > > Struts is even version 1.1. > > As for struts, if I remember correctly, version 1.1.x is used > because the newer version of struts does not work on a free > stack. If you want the latest version, you'll have to use the Sun > jdk right now. Nah, the reason an old struts was used is because that's what JPackage tomcat was using at the time. Newer struts works just fine with libgcj, and indeed Fedora Rawhide has 1.2.4. Cheers, Gary From gbenson at redhat.com Fri Jul 15 13:35:12 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 15 Jul 2005 14:35:12 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050715124729.GB3395@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050711152503.GC10052@redhat.com> <20050713100636.GE4681@redhat.com> <20050713123844.GA18166@redhat.com> <20050713132843.GG4681@redhat.com> <20050713184853.GA31384@redhat.com> <20050714085437.GA4688@redhat.com> <20050715090916.GA5059@redhat.com> <20050715124729.GB3395@redhat.com> Message-ID: <20050715133511.GE5059@redhat.com> Andrew Overholt wrote: > I tried the multiple --excludes and it didn't work. I assumed that > syntax was just not supported. It should be, must be a bug. If it's not bothering you I'll not fix it right away, as I'm busy bootstrapping stuff onto the missing archs (and switching all my stuff to aot-compile-rpm as I go). > Either way, the new aot-compile-rpm is amAzing and I'm in the > process or enabling it in all the other packages for which I am > responsible. Thanks! You're welcome! Oh, and I'll do jsch, because I need it like now. Cheers, Gary From overholt at redhat.com Fri Jul 15 13:51:27 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 15 Jul 2005 09:51:27 -0400 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050715133511.GE5059@redhat.com> References: <20050706154056.GE4852@redhat.com> <20050711152503.GC10052@redhat.com> <20050713100636.GE4681@redhat.com> <20050713123844.GA18166@redhat.com> <20050713132843.GG4681@redhat.com> <20050713184853.GA31384@redhat.com> <20050714085437.GA4688@redhat.com> <20050715090916.GA5059@redhat.com> <20050715124729.GB3395@redhat.com> <20050715133511.GE5059@redhat.com> Message-ID: <20050715135127.GA8879@redhat.com> * Gary Benson [2005-07-15 09:35]: > Andrew Overholt wrote: > > I tried the multiple --excludes and it didn't work. I assumed that > > syntax was just not supported. > > It should be, must be a bug. If it's not bothering you I'll not fix > it right away, as I'm busy bootstrapping stuff onto the missing archs > (and switching all my stuff to aot-compile-rpm as I go). Sure, sounds good. > Oh, and I'll do jsch, because I need it like now. Oh yeah, sorry. Andrew From djo at coconut-palm-software.com Fri Jul 15 13:48:05 2005 From: djo at coconut-palm-software.com (David J. Orme) Date: Fri, 15 Jul 2005 08:48:05 -0500 Subject: [fedora-java] Compiling a basic SWT app on FC4 In-Reply-To: <17111.34280.549028.101825@zapata.pink> References: <1121418279.17204.20.camel@SEMPUKI> <17111.34280.549028.101825@zapata.pink> Message-ID: <42D7BE95.2060600@coconut-palm-software.com> Andrew Haley wrote: >So, where is libswt-pi-gtk-3128 ? Bizzarrely, I found it in > > $HOME/.eclipse/org.eclipse.platform_3.1.0/configuration/org.eclipse.osgi/bundles/59/1/.cp/os/linux/x86/libswt-pi-gtk-3128.so > >(sorry, no, I have *no idea* why it's there) > > I can help here. In 3.1, Eclipse went to a plugin packaging format where *everything* in a plugin winds up in a single JAR file. (They did this to improve startup performance, as well as a few other things.) Which is fine if you're just running .class files out of the JAR. But obviously this won't work for anything that needs a native library (ie: SWT) in order to run. I don't know if the solution they came up with is generic or if it only applies to SWT. But what I do know is that when you run Eclipse for the first time, the launcher realizes that it needs those .sos somewhere in the file system in order for SWT to run, automatically unpacks them, and puts them into a configuration area. The location of the configuration area depends on how Eclipse was installed and who is running it. If it was installed in a system directory of a multiuser system, that directory is normally owned by root or Administrator and can only be written to by someone with UID=0 or equivalent. In this case, Eclipse has no choice but to create a copy of the SWT shared libraries in the account of the user who ran the Eclipse binary. This is the behavior you are observing. If, however, Eclipse is installed locally in a user's account, or if the user is (normally stupidly) running Eclipse as root or Administrator, then it unpacks the SWT libraries exactly once and installs them inside of its own install directory. Hope this helps. :-) Best regards, Dave Orme -- Got Java? Use db4objects! PGP Public Key (for confidential communications): http://www.coconut-palm-software.com/~djo/public_key.txt From gbenson at redhat.com Fri Jul 15 13:52:02 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 15 Jul 2005 14:52:02 +0100 Subject: [fedora-java] aot-compile-rpm In-Reply-To: <20050715135127.GA8879@redhat.com> References: <20050711152503.GC10052@redhat.com> <20050713100636.GE4681@redhat.com> <20050713123844.GA18166@redhat.com> <20050713132843.GG4681@redhat.com> <20050713184853.GA31384@redhat.com> <20050714085437.GA4688@redhat.com> <20050715090916.GA5059@redhat.com> <20050715124729.GB3395@redhat.com> <20050715133511.GE5059@redhat.com> <20050715135127.GA8879@redhat.com> Message-ID: <20050715135201.GF5059@redhat.com> Andrew Overholt wrote: > * Gary Benson [2005-07-15 09:35]: > > Oh, and I'll do jsch, because I need it like now. > > Oh yeah, sorry. Don't be, it's no biggie. Cheers, Gary From david at zarb.org Fri Jul 15 14:14:57 2005 From: david at zarb.org (David Walluck) Date: Fri, 15 Jul 2005 10:14:57 -0400 Subject: [fedora-java] FC4 Tomcat & Jakarta Hell In-Reply-To: <20050715125818.GD5059@redhat.com> References: <42D70704.5060505@antunes.eti.br> <20050715084603.knglhwv64goo0008@www.zarb.org> <20050715125818.GD5059@redhat.com> Message-ID: <20050715101457.65t73m5xc0o0ks4g@www.zarb.org> Gary Benson wrote: > Nah, the reason an old struts was used is because that's what > JPackage tomcat was using at the time. Newer struts works > just fine with libgcj, and indeed Fedora Rawhide has 1.2.4. I forgot to check, but there it is: Still, I recall Fernando saying he absoluetly needed struts11 which is why he kept both packages. I guess whatever the reason, it is not related to tomcat. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From gbenson at redhat.com Fri Jul 15 14:25:26 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 15 Jul 2005 15:25:26 +0100 Subject: [fedora-java] aot-compile-rpm HOWTO In-Reply-To: <20050706154056.GE4852@redhat.com> References: <20050706154056.GE4852@redhat.com> Message-ID: <20050715142524.GG5059@redhat.com> A quick update on the aot-compile-rpm instructions... Gary Benson wrote: > 1. Remove "BuildArch: noarch" > 2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp" > and "Requires(post,postun)" on same. The actual lines required for this step are: BuildRequires: java-gcj-compat-devel >= 1.0.31 Requires(post): java-gcj-compat >= 1.0.31 Requires(postun): java-gcj-compat >= 1.0.31 If your package is jonas or eclipse then the first line should say 1.0.33 instead of 1.0.31. > 3. Add "aot-compile-rpm" to the very end of %install. > 4. Add "/usr/bin/rebuild-gcj-db %{_libdir}" to %post and %postun. This should be: Add "%{_bindir}/rebuild-gcj-db" to %post and %postun. Note the lack of %{_libdir}! > 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files. From gbenson at redhat.com Fri Jul 15 14:29:07 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 15 Jul 2005 15:29:07 +0100 Subject: [fedora-java] FC4 Tomcat & Jakarta Hell In-Reply-To: <20050715101457.65t73m5xc0o0ks4g@www.zarb.org> References: <42D70704.5060505@antunes.eti.br> <20050715084603.knglhwv64goo0008@www.zarb.org> <20050715125818.GD5059@redhat.com> <20050715101457.65t73m5xc0o0ks4g@www.zarb.org> Message-ID: <20050715142907.GH5059@redhat.com> David Walluck wrote: > Gary Benson wrote: > > Nah, the reason an old struts was used is because that's what > > JPackage tomcat was using at the time. Newer struts works > > just fine with libgcj, and indeed Fedora Rawhide has 1.2.4. > > I forgot to check, but there it is: > > > Still, I recall Fernando saying he absoluetly needed struts11 which > is why he kept both packages. I guess whatever the reason, it is not > related to tomcat. Maybe it was some jonas version requirement. From chr_help221 at yahoo.com Fri Jul 15 15:21:23 2005 From: chr_help221 at yahoo.com (Gekiyasu No.1) Date: Sat, 16 Jul 2005 00:21:23 +0900 Subject: [fedora-java] =?iso-2022-jp?b?GyRCN2MwQiU9JVUlSCUmJSclIkhOGyhC?= =?iso-2022-jp?b?GyRCR2QbKEIgR2VraXlhc3UgTm8uMQ==?= Message-ID: <0716105002123.67453@D7KLTF1X> =============== Gekiyasu No.1 ========================= ?????5000??????????????! ???????????????????? ????????????????? ??????????????????????? ?????????????????????????? ?????????????????? =============== ????????? ==================== ?5,000???????4???10,000??????? ?5,000???????6???15,000??????? ?20,000????????????? ?10,000???????1?????????? ??????????????????? =============== ???? ============================== ?Windows??Macintosh??????????????? ????????????????????????????? =============== ?????????? ================== ????????????????????????? ???????????????????????????????? ??http://gekiyasu-no1.com ????????????????????? ????????????????????????????? ??mail_gekiichi at horse.livedoor.com =============== ????????? ==================== ??????????????????????????????????? ??mail_gekiichi at horse.livedoor.com =============== ??????? ======================== ???????????????????????????????? ??mail_gekiichi at horse.livedoor.com ???????????????????????? ?????????????? OS ???????????????? ??????????????????????? ??mail_gekiichi at horse.livedoor.com ======================================================= ???????????????????? ??? ======================================================= From gss_info236 at yahoo.co.jp Fri Jul 15 23:27:17 2005 From: gss_info236 at yahoo.co.jp (gss_info236 at yahoo.co.jp) Date: Sat, 16 Jul 2005 8:27:17 +0900 Subject: [fedora-java] =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cCIoIXkkZiRTGyhC?= =?iso-2022-jp?b?GyRCIXkkZiRTJV4lLCU4JXMkLDpfQnAlbyE8JSshPEpnPTgkNyRGGyhC?= =?iso-2022-jp?b?GyRCJF4kOSF5GyhC?= Message-ID: <200507160026.j6G0Qh5N007451@mx1.redhat.com> ????????????????????????? ------------------------------------------------------------ (?)G.S.S.inc. ???????????1-18-13 TEL?03-6425-2182 (??? MAIL gss_info17 at yahoo.co.jp ------------------------------------------------------------ ???????????????????????????? ???????????????????????????????? ????????????????URL???????????? http://www.qmsys.net/stop.php?id=2&sid=ded148b83f7895d21bcbae66077517a2 ??URL??????????????????????????? ??????????????????????????? stop2 at qmsys.net ------------------------------------------------------------ ??????????????????????? ? ? ? ?????????????????????? ? ???????????????????? ??? ????????????????????? ? ???????????? ?2005/7???? ??? ?? ?????????????????????? ???????????/???????????1,935,654??????? ??SOHO?????????SOHO????????????? ?????????????????????? ?????????????!??????????????????? ?????????? ????????2????5?? ???????????????!?????????????????? ?????????????!?????????????????? ? ???!????????????????????!???????!!? ? ???????????????????? ??????????????http://www.soho-kaientai.jp ?????????????? ?????????????!! ? ??????????????????????5?????????? ???????????????????????????????? ????????????????????? ?????????????????300?????????????? ???????????????????????? ???????????????????????????680????????? ????????????????????????????????????? ??????????????????????????? ??????????????????????(??)???????? ????????????http://www.soho-kaientai.jp/?? ??????????????????????????????? ???????????????????????????????? ????????????????????????????????? ???????????????????????????????5,000????? ??????????5??(10,000???)????????????!! ----------------------------------------------------------------- ???????? ----------------------------------------------------------------- ?? ?http://www.soho-kaientai.jp????????? ?? ?????????????? ?? ???????????????????? ?? ??????????????????????????? ????????????????????????? --------------------------------------------------------------------- ????????????SOHO????????????! ????????????????????????(?)GSS inc. ???????????????????????????????? ????????????????????? From nando at antunes.eti.br Sun Jul 17 00:46:25 2005 From: nando at antunes.eti.br (C.F. Scheidecker Antunes) Date: Sat, 16 Jul 2005 18:46:25 -0600 Subject: [fedora-java] FC4: Howto change tge JDK Message-ID: <42D9AA61.5010101@antunes.eti.br> Hello all, Before FC4 I used to install SUN's or IBM's JDK and have a syslink under /usr/bin for java and javac. Not only that but I had them installed under /opt and then have the /etc/profile changed to have all from /opt/java/bin on the PATH. Now, they have done a whole total different deal with FC4. The jdk is configured such that there are even links under /etc/ What would be advisable in order to have a different JDK under FC4? I would like to get ride of the one that came with it. Thanks in advance, C.F. From gss_info236 at yahoo.co.jp Sat Jul 16 23:29:10 2005 From: gss_info236 at yahoo.co.jp (gss_info236 at yahoo.co.jp) Date: Sun, 17 Jul 2005 8:29:10 +0900 Subject: [fedora-java] =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cCIoIXkkZiRTGyhC?= =?iso-2022-jp?b?GyRCIXkkZiRTJV4lLCU4JXMkLDpfQnAlbyE8JSshPEpnPTgkNyRGGyhC?= =?iso-2022-jp?b?GyRCJF4kOSF5GyhC?= Message-ID: <200507170712.j6H7CCZX005523@mx1.redhat.com> ????????????????????????? ------------------------------------------------------------ (?)G.S.S.inc. ???????????1-18-13 TEL?03-6425-2182 (??? MAIL gss_info17 at yahoo.co.jp ------------------------------------------------------------ ???????????????????????????? ???????????????????????????????? ????????????????URL???????????? http://www.qmsys.net/stop.php?id=2&sid=ded148b83f7895d21bcbae66077517a2 ??URL??????????????????????????? ??????????????????????????? stop2 at qmsys.net ------------------------------------------------------------ ??????????????????????? ? ? ? ?????????????????????? ? ???????????????????? ??? ????????????????????? ? ???????????? ?2005/7???? ??? ?? ?????????????????????? ???????????/???????????1,935,654??????? ??SOHO?????????SOHO????????????? ?????????????????????? ?????????????!??????????????????? ?????????? ????????2????5?? ???????????????!?????????????????? ?????????????!?????????????????? ? ???!????????????????????!???????!!? ? ???????????????????? ??????????????http://www.soho-kaientai.jp ?????????????? ?????????????!! ? ??????????????????????5?????????? ???????????????????????????????? ????????????????????? ?????????????????300?????????????? ???????????????????????? ???????????????????????????680????????? ????????????????????????????????????? ??????????????????????????? ??????????????????????(??)???????? ????????????http://www.soho-kaientai.jp/?? ??????????????????????????????? ???????????????????????????????? ????????????????????????????????? ???????????????????????????????5,000????? ??????????5??(10,000???)????????????!! ----------------------------------------------------------------- ???????? ----------------------------------------------------------------- ?? ?http://www.soho-kaientai.jp????????? ?? ?????????????? ?? ???????????????????? ?? ??????????????????????????? ????????????????????????? --------------------------------------------------------------------- ????????????SOHO????????????! ????????????????????????(?)GSS inc. ???????????????????????????????? ????????????????????? From kms at passback.co.uk Sun Jul 17 10:42:43 2005 From: kms at passback.co.uk (Keith Sharp) Date: Sun, 17 Jul 2005 11:42:43 +0100 Subject: [fedora-java] FC4: Howto change tge JDK In-Reply-To: <42D9AA61.5010101@antunes.eti.br> References: <42D9AA61.5010101@antunes.eti.br> Message-ID: <1121596963.3054.44.camel@animal.passback.co.uk> On Sat, 2005-07-16 at 18:46 -0600, C.F. Scheidecker Antunes wrote: > Hello all, > > Before FC4 I used to install SUN's or IBM's JDK and have a syslink under > /usr/bin for java and javac. Not only that but I had them installed > under /opt and then have the /etc/profile changed to have all from > /opt/java/bin on the PATH. > > Now, they have done a whole total different deal with FC4. The jdk is > configured such that there are even links under /etc/ > > What would be advisable in order to have a different JDK under FC4? I > would like to get ride of the one that came with it. Use the nosrc packages from the JPackage project to create and install an RPM of the JDK you wish to use. I have done this successfully for the Sun JDK 1.5. JPackage is at: http://www.jpackage.org and the Sun JDK 1.5 nosrc RPM is at: http://www.jpackage.org/rpm.php?id=2663 the IBM JDK 1.4 nosrc RPM is at: http://www.jpackage.org/rpm.php?id=2096 Instructions for converting a nosrc RPM into a binary RPM: http://www.jpackage.org/rebuilding.php Keith. From nicolas.mailhot at laposte.net Mon Jul 18 13:58:31 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 18 Jul 2005 15:58:31 +0200 (CEST) Subject: [fedora-java] Jonas vs JTA In-Reply-To: <20050714162611.GL4688@redhat.com> References: <42D67D7D.7060103@redhat.com> <20050714115319.v5puqrfn4sckss8k@www.zarb.org> <20050714162611.GL4688@redhat.com> Message-ID: <61430.192.54.193.37.1121695111.squirrel@rousalka.dyndns.org> On Jeu 14 juillet 2005 18:26, Gary Benson wrote: > David Walluck wrote: >> Bryce McKinlay wrote: >> > Further, this creates difficulties testing FC's Jonas with >> > other jpackaged JVMs because they require a separate jta.jar. >> >> What are the difficulties? `build-classpath jta` should return the >> correct jar even though the actual jar returned may differ based on >> jvm version. > > It does, however, jonas makes a symbolic link to jta.jar using > build-jar-repository at build time (well, %install time). Fedora's > jonas is built with gcj, so the link points to gcj's jta.jar (in > /usr/lib/jvm-exports/java/jta.jar). This link is not changed when you > switch JVM. That's why you have evil brackets in symlink names and the rebuild-jar-repository script. To have symlinks that follow JVM switches. I don't know about jonas but I'm pretty sure the jpp tomcat package gets this right Regards, -- Nicolas Mailhot From overholt at redhat.com Mon Jul 18 14:21:29 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 18 Jul 2005 10:21:29 -0400 Subject: [fedora-java] Eclipse + CVS issues Message-ID: <20050718142129.GB4286@redhat.com> Hi, We have two issues with CVS that I'd like to sort out and hopefully get fixes into our gcc RPMs before their FC4 update. 1. checkouts of large-ish projects (GNU Classpath is something I've used as a test case) get "stuck" at about 83% finished. This is about the best information I have at this point, but tests with combinations of stock FC4 gcc (4.0.0-8, I believe) and stock FC4 Eclipse (3.1.0.M6.22 or something like that) or rawhide gcc (4.0.1-x) and rawhide Eclipse (3.1.0_fc-2) would be greatly appreciated. If we can narrow down when this problem occurred, it would help in finding its cause. I don't remember this happening with what we had around FC4 release time. Also, does CVS compression level affect this? 2. switching to the team synchronization perspective throws an error [1]. There's a similar bug [2], but I'm not sure if they're the same thing. I'm not sure if these are related to problem 1. above. If we can get some back traces and maybe some gdbing going on, hopefully we can track these bugs down. This is how I usually debug this kind of thing: install eclipse-debuginfo and gcc-debuginfo. Once I've got Eclipse in the state that I want it, I attach to that process with gdb (ps aux | grep java .. get the process # ... gdb /usr/bin/java ). There are usually around 15 threads and I think the CVS one is usually # 5. You can see thread information with the gdb command 'info threads'. Switching between threads is easy ('thread x') and you can get back traces for any of them with 'bt' (note that I'm just putting the quotes around the gdb commands but they're not necessary). You can steph through things with 's' and continue with 'c'. I read this page [3] once and it helped with signal ignoring. I'm not sure if it's necessary, but I've got this in my .gdbinit to deal with it: handle SIGPWR nostop noprint handle SIGXCPU nostop noprint It'll be great when we get full JDWP support in GNU Classpath and gcc so that debugging these library issues (I've already determined that this isn't a native compilation issue) will be easier. Thanks, Andrew [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163079 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161518 [3] http://gcc.gnu.org/java/gdb.html From chris at hubick.com Mon Jul 18 18:38:10 2005 From: chris at hubick.com (Chris Hubick) Date: Mon, 18 Jul 2005 12:38:10 -0600 Subject: [fedora-java] Eclipse + CVS issues In-Reply-To: <20050718142129.GB4286@redhat.com> References: <20050718142129.GB4286@redhat.com> Message-ID: <1121711890.22305.13.camel@FC4a.CHD.hubick.com> On Mon, 2005-07-18 at 10:21 -0400, Andrew Overholt wrote: > We have two issues with CVS that I'd like to sort out and hopefully get > fixes into our gcc RPMs before their FC4 update. Has this bug been fixed? "error accessing dev.eclipse.org cvs repository using extssh" https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146782 I followed the instructions from Comment #2 there, and I haven't been able to get it to work for me: [hubick at cs14 ~]$ eclipse WARNING: Error loading security provider org.bouncycastle.jce.provider.BouncyCastleProvider: java.lang.ClassNotFoundException: org.bouncycastle.jce.provider.BouncyCastleProvider not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} [root at cs14 ~]# ls -l /usr/share/java-ext/ total 300 lrwxrwxrwx 1 root root 30 Jul 18 12:10 bcprov.jar -> bouncycastle-jdk1.4/bcprov.jar drwxr-xr-x 2 root root 4096 Jul 18 12:09 bouncycastle-jdk1.4 -rw-r--r-- 1 root root 105959 May 26 15:52 gnu-crypto-jce-jdk1.4.jar -rw-r--r-- 1 root root 17438 May 26 15:52 gnu-crypto-sasl-jdk1.4.jar -rw-r--r-- 1 root root 143880 Aug 25 2004 puretls1.4-0.9.b4.jar [root at cs14 ~]# cat /usr/lib/security/classpath.security security.provider.1=gnu.java.security.provider.Gnu security.provider.2=org.metastatic.jessie.provider.Jessie security.provider.3=gnu.crypto.jce.GnuCrypto security.provider.4=org.bouncycastle.jce.provider.BouncyCastleProvider New to the world of Free Java tools, I have no idea how Native Eclipse/GCJ/GIJ finds classes. Is there something else I can do (register/compile bcprov.jar?) to make this work? Thanks. -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From ziga.mahkovec at klika.si Mon Jul 18 19:59:47 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Mon, 18 Jul 2005 21:59:47 +0200 Subject: [fedora-java] Eclipse + CVS issues In-Reply-To: <1121711890.22305.13.camel@FC4a.CHD.hubick.com> References: <20050718142129.GB4286@redhat.com> <1121711890.22305.13.camel@FC4a.CHD.hubick.com> Message-ID: <1121716787.3844.6.camel@localhost> On Mon, 2005-07-18 at 12:38 -0600, Chris Hubick wrote: > Has this bug been fixed? > "error accessing dev.eclipse.org cvs repository using extssh" > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146782 > > I followed the instructions from Comment #2 there, and I haven't been > able to get it to work for me: > > [hubick at cs14 ~]$ eclipse > WARNING: Error loading security provider > org.bouncycastle.jce.provider.BouncyCastleProvider: > java.lang.ClassNotFoundException: > org.bouncycastle.jce.provider.BouncyCastleProvider not found in > gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} > > [...] It seems that the default extensions directory has been moved to /usr/share/java/ext (as opposed to java-ext). You could try the following: $ sudo ln -s /usr/share/java-ext/bouncycastle-jdk1.4/bcprov.jar \ /usr/share/java/ext/bcprov.jar -- Ziga From chris at hubick.com Mon Jul 18 20:29:52 2005 From: chris at hubick.com (Chris Hubick) Date: Mon, 18 Jul 2005 14:29:52 -0600 Subject: [fedora-java] Eclipse + CVS issues In-Reply-To: <1121716787.3844.6.camel@localhost> References: <20050718142129.GB4286@redhat.com> <1121711890.22305.13.camel@FC4a.CHD.hubick.com> <1121716787.3844.6.camel@localhost> Message-ID: <1121718592.22305.18.camel@FC4a.CHD.hubick.com> On Mon, 2005-07-18 at 21:59 +0200, Ziga Mahkovec wrote: > On Mon, 2005-07-18 at 12:38 -0600, Chris Hubick wrote: > > Has this bug been fixed? > > "error accessing dev.eclipse.org cvs repository using extssh" > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146782 > > > > I followed the instructions from Comment #2 there, and I haven't been > > able to get it to work for me: > > > > [hubick at cs14 ~]$ eclipse > > WARNING: Error loading security provider > > org.bouncycastle.jce.provider.BouncyCastleProvider: > > java.lang.ClassNotFoundException: > > org.bouncycastle.jce.provider.BouncyCastleProvider not found in > > gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} > > > > [...] > > It seems that the default extensions directory has been moved > to /usr/share/java/ext (as opposed to java-ext). You could try the > following: > > $ sudo ln -s /usr/share/java-ext/bouncycastle-jdk1.4/bcprov.jar \ > /usr/share/java/ext/bcprov.jar There was no /usr/share/java/ext/, so I created it as a link to /usr/share/java-ext/. Will this break anything? Anyhow, after doing that, now I get: [hubick at cs14 ~]$ eclipse Exception in thread "main" java.lang.NoSuchFieldError: field org.bouncycastle.asn1.pkcs.PKCSObjectIdentifiers.id_RSAES_OAEP was not found. at org.bouncycastle.jce.provider.BouncyCastleProvider.BouncyCastleProvider() (Unknown Source) at java.lang.Class.newInstance() (/usr/lib/libgcj.so.6.0.0) at java.security.Security.loadProviders(java.lang.String, java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.security.Security.() (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0) at java.security.Security.getProviders() (/usr/lib/libgcj.so.6.0.0) at java.security.MessageDigest.getInstance(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.VMCompiler.() (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0) at java.lang.VMCompiler.compileClass(java.lang.ClassLoader, java.lang.String, byte[], int, int, java.security.ProtectionDomain) (/usr/lib/libgcj.so.6.0.0) at java.lang.VMClassLoader.defineClass(java.lang.ClassLoader, java.lang.String, byte[], int, int, java.security.ProtectionDomain) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.defineClass(java.lang.String, byte[], int, int, java.security.ProtectionDomain) (/usr/lib/libgcj.so.6.0.0) at java.security.SecureClassLoader.defineClass(java.lang.String, byte[], int, int, java.security.CodeSource) (/usr/lib/libgcj.so.6.0.0) at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) :( -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From tromey at redhat.com Mon Jul 18 20:27:40 2005 From: tromey at redhat.com (Tom Tromey) Date: 18 Jul 2005 14:27:40 -0600 Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> <26613121.1121344377342.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> Message-ID: >>>>> "Chris" == Chris Burdess writes: Chris> If you just want ACL support in the GNU IMAP provider, we can schedule Chris> it in for the next release. Martin> We can help to make such an implementation happen, but our Martin> focus is the solution and the features. Thats why we have not Martin> ask for methods. Now, if there is a strong demand and the GNU Martin> Classpath developers are scheduling the complete Martin> implementation of the required classes and methods for one of Martin> the next GNU Classpath javamail API releases, we should have Martin> some conversation how this can be implemented in a very easy Martin> way (like some kind of configure option) to support it (of Martin> course we must keep an eye on the effort ;-). Martin> And to avoid any rumor, this strategy is part of our general Martin> developing concepts. We do not reinvent wheels we are using Martin> existing infrastructure wherever it fits our needs. Let me make a somewhat more radical suggestion: if inetlib implements the needed ACL support, how about switching to use it exclusively? I think this has advantages on both sides. On the Classpath side it means that it is simpler to run Open Exchange on the free JVMs. On the OX side, this could mean bug fixes and feature additions on your schedule, as you wouldn't be dependent on Sun for updates. Also it means that you can avoid using things that even Sun asks that you not use: http://java.sun.com/products/javamail/1.3/docs/javadocs/overview-summary.html The JavaMail reference implementation from Sun includes protocol providers in subpackages of com.sun.mail. Note that the APIs to these protocol providers are not part of the standard JavaMail API. Portable programs will not use these APIs. Tom From dog at bluezoo.org Tue Jul 19 07:57:13 2005 From: dog at bluezoo.org (Chris Burdess) Date: Tue, 19 Jul 2005 08:57:13 +0100 Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> <26613121.1121344377342.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> Message-ID: <5be0e58a144429c07c03a8ea7c6fb789@bluezoo.org> Tom Tromey wrote: > Chris> If you just want ACL support in the GNU IMAP provider, we can > schedule > Chris> it in for the next release. > > Martin> We can help to make such an implementation happen, but our > Martin> focus is the solution and the features. Thats why we have not > Martin> ask for methods. Now, if there is a strong demand and the GNU > Martin> Classpath developers are scheduling the complete > Martin> implementation of the required classes and methods for one of > Martin> the next GNU Classpath javamail API releases, we should have > Martin> some conversation how this can be implemented in a very easy > Martin> way (like some kind of configure option) to support it (of > Martin> course we must keep an eye on the effort ;-). > > Martin> And to avoid any rumor, this strategy is part of our general > Martin> developing concepts. We do not reinvent wheels we are using > Martin> existing infrastructure wherever it fits our needs. > > Let me make a somewhat more radical suggestion: if inetlib implements > the needed ACL support, how about switching to use it exclusively? It does; the relevant IMAPConnection methods are setacl, deleteacl, getacl, listrights, myrights. It wouldn't be too much trouble to implement higher-level wrappers in IMAPFolder if working with them is conceptually easier, though. Also, as I mentioned before, JavaMail and JAF provide a whole MIME implementation that may be convenient. -- Chris Burdess From bishoph at open-xchange.org Tue Jul 19 08:26:44 2005 From: bishoph at open-xchange.org (Martin Kauss) Date: Tue, 19 Jul 2005 10:26:44 +0200 (CEST) Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: <5be0e58a144429c07c03a8ea7c6fb789@bluezoo.org> References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> <26613121.1121344377342.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> <5be0e58a144429c07c03a8ea7c6fb789@bluezoo.org> Message-ID: <6659511.1121761604412.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> On Jul 19, 2005 09:57 AM, Chris Burdess wrote: > Tom Tromey wrote: > > Chris> If you just want ACL support in the GNU IMAP provider, we can > > schedule > > Chris> it in for the next release. > > > > Martin> We can help to make such an implementation happen, but our > > Martin> focus is the solution and the features. Thats why we have not > > Martin> ask for methods. Now, if there is a strong demand and the GNU > > Martin> Classpath developers are scheduling the complete > > Martin> implementation of the required classes and methods for one of > > Martin> the next GNU Classpath javamail API releases, we should have > > Martin> some conversation how this can be implemented in a very easy > > Martin> way (like some kind of configure option) to support it (of > > Martin> course we must keep an eye on the effort ;-). > > > > Martin> And to avoid any rumor, this strategy is part of our general > > Martin> developing concepts. We do not reinvent wheels we are using > > Martin> existing infrastructure wherever it fits our needs. > > > > Let me make a somewhat more radical suggestion: if inetlib implements > > the needed ACL support, how about switching to use it exclusively? > > It does; the relevant IMAPConnection methods are setacl, deleteacl, > getacl, listrights, myrights. > > It wouldn't be too much trouble to implement higher-level wrappers in > IMAPFolder if working with them is conceptually easier, though. Also, > as I mentioned before, JavaMail and JAF provide a whole MIME > implementation that may be convenient. > -- > Chris Burdess > Chris, i will talk with Stefan about this over the next week (he is not available this week) - we will come back ASAP. Greetings, Martin Kauss From marcus at open-xchange.org Tue Jul 19 09:12:11 2005 From: marcus at open-xchange.org (Marcus Klein) Date: Tue, 19 Jul 2005 11:12:11 +0200 Subject: [fedora-java] Re: [OX Devel] Re: Devel Digest, Vol 12, Issue 6 In-Reply-To: <6659511.1121761604412.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> References: <42CF4152.3050106@randomink.org> <7478663.1120890734876.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <20050709075427.GA24894@bluezoo.org> <6649615.1120908068277.OPEN-XCHANGE.WebMail.wwwrun@ox.netline-is.de> <13623369.1121274332840.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> <20050713141755.fzsm8tic2ssk8oos@www.zarb.org> <26613121.1121344377342.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> <5be0e58a144429c07c03a8ea7c6fb789@bluezoo.org> <6659511.1121761604412.OPEN-XCHANGE.WebMail.tomcat@ox.netline-is.de> Message-ID: <42DCC3EB.7040306@open-xchange.org> Hi all! Martin Kauss schrieb: > On Jul 19, 2005 09:57 AM, Chris Burdess wrote: > > >>Tom Tromey wrote: >> >>>Chris> If you just want ACL support in the GNU IMAP provider, we can >>>schedule >>>Chris> it in for the next release. >>> >>>Martin> We can help to make such an implementation happen, but our >>>Martin> focus is the solution and the features. Thats why we have not >>>Martin> ask for methods. Now, if there is a strong demand and the GNU >>>Martin> Classpath developers are scheduling the complete >>>Martin> implementation of the required classes and methods for one of >>>Martin> the next GNU Classpath javamail API releases, we should have >>>Martin> some conversation how this can be implemented in a very easy >>>Martin> way (like some kind of configure option) to support it (of >>>Martin> course we must keep an eye on the effort ;-). >>> >>>Martin> And to avoid any rumor, this strategy is part of our general >>>Martin> developing concepts. We do not reinvent wheels we are using >>>Martin> existing infrastructure wherever it fits our needs. >>> >>>Let me make a somewhat more radical suggestion: if inetlib implements >>>the needed ACL support, how about switching to use it exclusively? First of all, you shouldn't only write to one person. The mailing list should be used to allow everyone to participate this discussion. >>It does; the relevant IMAPConnection methods are setacl, deleteacl, >>getacl, listrights, myrights. >> >>It wouldn't be too much trouble to implement higher-level wrappers in >>IMAPFolder if working with them is conceptually easier, though. Also, >>as I mentioned before, JavaMail and JAF provide a whole MIME >>implementation that may be convenient. >>-- >>Chris Burdess I think there are two possible solutions for this problem: 1. Start a Java Specification Request (JSR) that integrates ACLs into the non provider specific Java Mail API. 2. The author of Webmail has to add an abstract layer that implementations uses Sun provider specific or GNU classpath specific API for ACLs. This can be done through the GOF Design Pattern "Bridge". > Chris, > > i will talk with Stefan about this over the next week > (he is not available this week) - we will come back > ASAP. > > Greetings, > > Martin Kauss This are just my two cents that lead to a functional implementation that can base on commercial and free implementations. It must simply work for the normal groupware user. Best regards, Marcus Klein -------------- next part -------------- A non-text attachment was scrubbed... Name: marcus.vcf Type: text/x-vcard Size: 160 bytes Desc: not available URL: From aph at redhat.com Tue Jul 19 09:38:34 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jul 2005 10:38:34 +0100 Subject: [fedora-java] Eclipse + CVS issues In-Reply-To: <1121716787.3844.6.camel@localhost> References: <20050718142129.GB4286@redhat.com> <1121711890.22305.13.camel@FC4a.CHD.hubick.com> <1121716787.3844.6.camel@localhost> Message-ID: <17116.51738.348844.696439@zapata.pink> Ziga Mahkovec writes: > On Mon, 2005-07-18 at 12:38 -0600, Chris Hubick wrote: > > Has this bug been fixed? > > "error accessing dev.eclipse.org cvs repository using extssh" > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146782 > > > > I followed the instructions from Comment #2 there, and I haven't been > > able to get it to work for me: > > > > [hubick at cs14 ~]$ eclipse > > WARNING: Error loading security provider > > org.bouncycastle.jce.provider.BouncyCastleProvider: > > java.lang.ClassNotFoundException: > > org.bouncycastle.jce.provider.BouncyCastleProvider not found in > > gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} > > > > [...] > > It seems that the default extensions directory has been moved > to /usr/share/java/ext (as opposed to java-ext). I saw that too. Can whoever made this change *please* speak up and explain what's going on. Thanks, Andrew. From aph at redhat.com Tue Jul 19 09:40:44 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jul 2005 10:40:44 +0100 Subject: [fedora-java] Eclipse + CVS issues In-Reply-To: <1121718592.22305.18.camel@FC4a.CHD.hubick.com> References: <20050718142129.GB4286@redhat.com> <1121711890.22305.13.camel@FC4a.CHD.hubick.com> <1121716787.3844.6.camel@localhost> <1121718592.22305.18.camel@FC4a.CHD.hubick.com> Message-ID: <17116.51868.758343.517585@zapata.pink> Chris Hubick writes: > On Mon, 2005-07-18 at 21:59 +0200, Ziga Mahkovec wrote: > > On Mon, 2005-07-18 at 12:38 -0600, Chris Hubick wrote: > > > Has this bug been fixed? > > > "error accessing dev.eclipse.org cvs repository using extssh" > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146782 > > > > > > I followed the instructions from Comment #2 there, and I haven't been > > > able to get it to work for me: > > > > > > [hubick at cs14 ~]$ eclipse > > > WARNING: Error loading security provider > > > org.bouncycastle.jce.provider.BouncyCastleProvider: > > > java.lang.ClassNotFoundException: > > > org.bouncycastle.jce.provider.BouncyCastleProvider not found in > > > gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} > > > > > > [...] > > > > It seems that the default extensions directory has been moved > > to /usr/share/java/ext (as opposed to java-ext). You could try the > > following: > > > > $ sudo ln -s /usr/share/java-ext/bouncycastle-jdk1.4/bcprov.jar \ > > /usr/share/java/ext/bcprov.jar > > There was no /usr/share/java/ext/, so I created it as a link > to /usr/share/java-ext/. Will this break anything? > > Anyhow, after doing that, now I get: > > [hubick at cs14 ~]$ eclipse > Exception in thread "main" java.lang.NoSuchFieldError: field org.bouncycastle.asn1.pkcs.PKCSObjectIdentifiers.id_RSAES_OAEP was not found. Does PKCSObjectIdentifiers contain this field or not? Does BouncyCastleProvider refer to a field that doesn't exist? Andrew. From 3liwana at abtassoc.com Tue Jul 19 17:45:38 2005 From: 3liwana at abtassoc.com (Vanessa J. Smith) Date: Tue, 19 Jul 2005 17:45:38 +0000 Subject: [fedora-java] Windows XP - wholesale price Message-ID: <57ea01c58c89$a5a8857d$0b47b1a6@abtassoc.com> Get all the software you ever imagined for less! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Enter here: http://www.oemtotal.com Best regards, Vanessa Smith _____________________________________________________ To be taken out, go here _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tromey at redhat.com Wed Jul 20 17:49:02 2005 From: tromey at redhat.com (Tom Tromey) Date: 20 Jul 2005 11:49:02 -0600 Subject: [fedora-java] .jar and .so both loaded? In-Reply-To: <42D6CF1D.9090507@lozano.eti.br> References: <1121331628.12533.12.camel@localhost.localdomain> <42D6CF1D.9090507@lozano.eti.br> Message-ID: >>>>> "Fernando" == Fernando Lozano writes: >> Note that it can be tricky to do this for large applications, like >> Eclipse. You end up having to modify the application to understand >> how to treat gcj specially. This is what we did in the Eclipse 2.x >> days, but in 3.x they changed their class loaders and we didn't want >> to repeat the hacking... hence the current approach, which is >> invisible to the application. Fernando> Hasn't anyone tried to use Eclipse CDT infrastructure for this? It is Fernando> based on GDB and GDB supports native Java debugging. So you'd use a Fernando> mix of JDT and CDT plug-ins for developing native GCJ apps. I'm not sure if anybody has really tried this. It would be interesting to hear about someone's experiences with it though. Tom From chris at hubick.com Wed Jul 20 18:26:22 2005 From: chris at hubick.com (Chris Hubick) Date: Wed, 20 Jul 2005 12:26:22 -0600 Subject: [fedora-java] Eclipse + CVS issues In-Reply-To: <17116.51868.758343.517585@zapata.pink> References: <20050718142129.GB4286@redhat.com> <1121711890.22305.13.camel@FC4a.CHD.hubick.com> <1121716787.3844.6.camel@localhost> <1121718592.22305.18.camel@FC4a.CHD.hubick.com> <17116.51868.758343.517585@zapata.pink> Message-ID: <1121883982.16452.8.camel@FC4a.CHD.hubick.com> On Tue, 2005-07-19 at 10:40 +0100, Andrew Haley wrote: > Chris Hubick writes: > > [hubick at cs14 ~]$ eclipse > > Exception in thread "main" java.lang.NoSuchFieldError: field org.bouncycastle.asn1.pkcs.PKCSObjectIdentifiers.id_RSAES_OAEP was not found. > > Does PKCSObjectIdentifiers contain this field or not? Does > BouncyCastleProvider refer to a field that doesn't exist? Courtesy of the Eclipse "Open Type" function, it appears as though it *does* exist (8th field down): public abstract interface org.bouncycastle.asn1.pkcs.PKCSObjectIdentifiers extends java.lang.Object { public static final java.lang.String pkcs_1 = "1.2.840.113549.1.1"; public static final org.bouncycastle.asn1.DERObjectIdentifier rsaEncryption; public static final org.bouncycastle.asn1.DERObjectIdentifier md2WithRSAEncryption; public static final org.bouncycastle.asn1.DERObjectIdentifier md4WithRSAEncryption; public static final org.bouncycastle.asn1.DERObjectIdentifier md5WithRSAEncryption; public static final org.bouncycastle.asn1.DERObjectIdentifier sha1WithRSAEncryption; public static final org.bouncycastle.asn1.DERObjectIdentifier srsaOAEPEncryptionSET; public static final org.bouncycastle.asn1.DERObjectIdentifier id_RSAES_OAEP; public static final org.bouncycastle.asn1.DERObjectIdentifier id_mgf1; public static final org.bouncycastle.asn1.DERObjectIdentifier id_pSpecified; public static final org.bouncycastle.asn1.DERObjectIdentifier id_RSASSA_PSS; public static final org.bouncycastle.asn1.DERObjectIdentifier sha256WithRSAEncryption; public static final org.bouncycastle.asn1.DERObjectIdentifier sha384WithRSAEncryption; public static final org.bouncycastle.asn1.DERObjectIdentifier sha512WithRSAEncryption; public static final org.bouncycastle.asn1.DERObjectIdentifier sha224WithRSAEncryption; public static final java.lang.String pkcs_3 = "1.2.840.113549.1.3"; public static final org.bouncycastle.asn1.DERObjectIdentifier dhKeyAgreement; public static final java.lang.String pkcs_5 = "1.2.840.113549.1.5"; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithMD2AndDES_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithMD2AndRC2_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithMD5AndDES_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithMD5AndRC2_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithSHA1AndDES_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithSHA1AndRC2_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier id_PBES2; public static final org.bouncycastle.asn1.DERObjectIdentifier id_PBKDF2; public static final java.lang.String encryptionAlgorithm = "1.2.840.113549.3"; public static final org.bouncycastle.asn1.DERObjectIdentifier des_EDE3_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier RC2_CBC; public static final java.lang.String digestAlgorithm = "1.2.840.113549.2"; public static final org.bouncycastle.asn1.DERObjectIdentifier md2; public static final org.bouncycastle.asn1.DERObjectIdentifier md4; public static final org.bouncycastle.asn1.DERObjectIdentifier md5; public static final org.bouncycastle.asn1.DERObjectIdentifier id_hmacWithSHA1; public static final java.lang.String pkcs_7 = "1.2.840.113549.1.7"; public static final org.bouncycastle.asn1.DERObjectIdentifier data; public static final org.bouncycastle.asn1.DERObjectIdentifier signedData; public static final org.bouncycastle.asn1.DERObjectIdentifier envelopedData; public static final org.bouncycastle.asn1.DERObjectIdentifier signedAndEnvelopedData; public static final org.bouncycastle.asn1.DERObjectIdentifier digestedData; public static final org.bouncycastle.asn1.DERObjectIdentifier encryptedData; public static final java.lang.String pkcs_9 = "1.2.840.113549.1.9"; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_emailAddress; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_unstructuredName; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_contentType; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_messageDigest; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_signingTime; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_counterSignature; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_challengePassword; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_unstructuredAddress; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_extendedCertificateAttributes; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_signingDescription; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_extensionRequest; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_smimeCapabilities; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_friendlyName; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs_9_at_localKeyId; public static final org.bouncycastle.asn1.DERObjectIdentifier x509certType; public static final org.bouncycastle.asn1.DERObjectIdentifier id_alg_PWRI_KEK; public static final org.bouncycastle.asn1.DERObjectIdentifier preferSignedData; public static final org.bouncycastle.asn1.DERObjectIdentifier canNotDecryptAny; public static final org.bouncycastle.asn1.DERObjectIdentifier sMIMECapabilitiesVersions; public static final java.lang.String id_ct = "1.2.840.113549.1.9.16.1"; public static final org.bouncycastle.asn1.DERObjectIdentifier id_ct_TSTInfo; public static final org.bouncycastle.asn1.DERObjectIdentifier id_ct_compressedData; public static final java.lang.String id_aa = "1.2.840.113549.1.9.16.2"; public static final org.bouncycastle.asn1.DERObjectIdentifier id_aa_encrypKeyPref; public static final org.bouncycastle.asn1.DERObjectIdentifier id_aa_signingCertificate; public static final java.lang.String pkcs_12 = "1.2.840.113549.1.12"; public static final java.lang.String bagtypes = "1.2.840.113549.1.12.10.1"; public static final org.bouncycastle.asn1.DERObjectIdentifier keyBag; public static final org.bouncycastle.asn1.DERObjectIdentifier pkcs8ShroudedKeyBag; public static final org.bouncycastle.asn1.DERObjectIdentifier certBag; public static final org.bouncycastle.asn1.DERObjectIdentifier crlBag; public static final org.bouncycastle.asn1.DERObjectIdentifier secretBag; public static final org.bouncycastle.asn1.DERObjectIdentifier safeContentsBag; public static final java.lang.String pkcs_12PbeIds = "1.2.840.113549.1.12.1"; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithSHAAnd128BitRC4; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithSHAAnd40BitRC4; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithSHAAnd3_KeyTripleDES_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithSHAAnd2_KeyTripleDES_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier pbeWithSHAAnd128BitRC2_CBC; public static final org.bouncycastle.asn1.DERObjectIdentifier pbewithSHAAnd40BitRC2_CBC; static {}; } -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From tromey at redhat.com Thu Jul 21 23:46:00 2005 From: tromey at redhat.com (Tom Tromey) Date: 21 Jul 2005 17:46:00 -0600 Subject: [fedora-java] Eclipse + CVS issues In-Reply-To: <20050718142129.GB4286@redhat.com> References: <20050718142129.GB4286@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: Andrew> 1. checkouts of large-ish projects (GNU Classpath is something Andrew> I've used as a test case) get "stuck" at about 83% Andrew> finished. This is about the best information I have at Andrew> this point, but tests with combinations of stock FC4 gcc Andrew> (4.0.0-8, I believe) and stock FC4 Eclipse (3.1.0.M6.22 or Andrew> something like that) or rawhide gcc (4.0.1-x) and rawhide Andrew> Eclipse (3.1.0_fc-2) would be greatly appreciated. If we Andrew> can narrow down when this problem occurred, it would help Andrew> in finding its cause. I don't remember this happening with Andrew> what we had around FC4 release time. Also, does CVS Andrew> compression level affect this? Have you tried this with a proprietary jdk? I spent a little time today debugging this. I didn't see an actual deadlock -- I just saw the code paths in Eclipse taking a long, long time. In particular I think that the TimeoutInputStream stuff we talked about on irc is a red herring... I think those just remain live until the cvs connection is shut down. I saw read() hanging and ssh still running; if the cvs server had shut down the connection I suppose I would expect to see ssh dead (or as a zombie). Instead I did 'thread apply all bt' and looked for other threads doing work for the team plugin. One thread was in org.eclipse.team.internal.ccvs.core.resources.EclipseFolder.isModified. I went to this thread and did 'fini' a lot to see what was happening (I had to ignore SIGHUP so that gdb wouldn't lose my place). Anyway, what I observed here is that some of the 'fini's took a long time, as eclipse went over every resource in a directory (and every subdirectory recursively) making sure that no resource was modified. Anyway, I say all this just in case somebody wants to try to reproduce it, or knows something more that would invalidate my theory, or whatever. If a VM other than gcj does this quickly, then the next thing to look at is where we might be inefficient here. Unfortunately I don't have an up-to-date oprofile-ready machine atm. Tom From overholt at redhat.com Fri Jul 22 15:24:33 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 22 Jul 2005 11:24:33 -0400 Subject: [fedora-java] Odd ClassNotFoundException with RSSOwl Message-ID: <20050722152433.GA7416@redhat.com> Hi, Ben Pasero was kind enough to create an RSSOwl release for me with the Eclipse dependency removed (ie. it just depends upon SWT). I built this code against our SWT RPMs but I'm getting weird errors while running. For example, if I put in Slashdot's RSS feed into the location bar, it will load the headlines fine but fail when I click on one to get the actual story. This is what I'm doing: gij -cp /usr/share/eclipse/plugins/org.eclipse.core.runtime_3.1.0.jar:/home/overholt/rssowl/BlowfishJ.jar:/home/overholt/rssowl/codec-1.3.jar:/home/overholt/rssowl/httpclient-3.0.jar:/home/overholt/rssowl/iTextAsian.jar:/home/overholt/rssowl/itext.jar:/home/overholt/rssowl/jdom.jar:/home/overholt/rssowl/jface.jar:/home/overholt/rssowl/logging-1.0.4.jar:/home/overholt/rssowl/res.jar:/home/overholt/rssowl/swt.jar:/home/overholt/rssowl/swt-nl.jar:/home/overholt/rssowl/xerces.jar -jar rssowl.jar (with Sun's JVM, I just have to add -Djava.library.path=/usr/lib). The error I get is: Caused by: java.lang.ClassNotFoundException: org.eclipse.core.runtime.Status not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:rssowl.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) ...19 more and with Sun's stuff: Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/core/runtime/IStatus at net.sourceforge.rssowl.controller.dialog.ValidateFeedDialog.createDialogArea(Unknown Source) at net.sourceforge.rssowl.controller.dialog.ValidateFeedDialog.(Unknown Source) at net.sourceforge.rssowl.controller.EventManager.actionValidateFeeds(Unknown Source) at net.sourceforge.rssowl.controller.panel.ErrorPanel$2.widgetSelected(Unknown Source) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1021) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2867) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2572) at net.sourceforge.rssowl.controller.GUI.runEventLoop(Unknown Source) at net.sourceforge.rssowl.controller.GUI.showGui(Unknown Source) at net.sourceforge.rssowl.controller.RSSOwlLoader.(Unknown Source) at net.sourceforge.rssowl.controller.RSSOwlLoader.main(Unknown Source) Both classes that are apparently not found are in the first jar on the classpath. Any ideas? I've put the jars here: http://overholt.ca/rssowl.tar.bz2 Andrew From tromey at redhat.com Fri Jul 22 18:12:54 2005 From: tromey at redhat.com (Tom Tromey) Date: 22 Jul 2005 12:12:54 -0600 Subject: [fedora-java] Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050722152433.GA7416@redhat.com> References: <20050722152433.GA7416@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: Andrew> /usr/share/eclipse/plugins/org.eclipse.core.runtime_3.1.0.jar:/home/overholt/rssowl/BlowfishJ.jar:/home/overholt/rssowl/codec-1.3.jar:/home/overholt/rssowl/httpclient-3.0.jar:/home/overholt/rssowl/iTextAsian.jar:/home/overholt/rssowl/itext.jar:/home/overholt/rssowl/jdom.jar:/home/overholt/rssowl/jface.jar:/home/overholt/rssowl/logging-1.0.4.jar:/home/overholt/rssowl/res.jar:/home/overholt/rssowl/swt.jar:/home/overholt/rssowl/swt-nl.jar:/home/overholt/rssowl/xerces.jar If you want to use xerces you will have to make it available by setting java.endorsed.dirs to point to the directory holding its jar. Otherwise I think you'll end up using the built-in xml code (due to class loader delegation). Andrew> Caused by: java.lang.ClassNotFoundException: org.eclipse.core.runtime.Status not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:rssowl.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} Hmm, I would have expected to see more things in the class path here. It sounds like we are ignoring -cp when -jar is given. I'm not sure what behavior is correct here. One way to test this theory is to add rssowl.jar to the -cp argument, and instead of '-jar rsssowl.jar', use the name of the main class. Tom From fernando at lozano.eti.br Fri Jul 22 18:36:35 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Fri, 22 Jul 2005 15:36:35 -0300 Subject: [fedora-java] Odd ClassNotFoundException with RSSOwl In-Reply-To: References: <20050722152433.GA7416@redhat.com> Message-ID: <42E13CB3.4020308@lozano.eti.br> Hi Tom, It is the standard behaviour (at least with Sun Java) to ignore -cp and the CLASSPATH env var when using -jar. And we'd better behave the same way. []s, Fernando Lozano >Andrew> Caused by: java.lang.ClassNotFoundException: org.eclipse.core.runtime.Status not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:rssowl.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} > >Hmm, I would have expected to see more things in the class path here. >It sounds like we are ignoring -cp when -jar is given. I'm not sure >what behavior is correct here. One way to test this theory is to add >rssowl.jar to the -cp argument, and instead of '-jar rsssowl.jar', use >the name of the main class. > >Tom > > From vadimn at redhat.com Fri Jul 22 22:10:45 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 22 Jul 2005 18:10:45 -0400 Subject: [fedora-java] quick and dirty Expect-fu to help manage "java" and "javac" alternatives Message-ID: <200507221810.45179.vadimn@redhat.com> There is a mildly annoying gotcha in the way FC4 manages the "java" and "javac" alternatives. (To be fair, FC4 is merely following the JPackage suit here.) The way it works is this. If you install another JDK in addition to GCJ, you have a choice of specifying your preferred alternative systemwide like so: | $ readlink -f /usr/bin/java | /usr/bin/gij | $ sudo /usr/sbin/alternatives --config java | | There are 2 programs which provide 'java'. | | Selection Command | ----------------------------------------------- | + 1 /usr/lib/jvm/jre-1.4.2-gcj/bin/java | * 2 /usr/lib/jvm/jre-1.4.2-sun/bin/java | | Enter to keep the current selection[+], or type selection number: 2 | $ readlink -f /usr/bin/java | /usr/lib/jvm/java-1.4.2-sun-1.4.2.08/jre/bin/java Here's the rub. If you do this, you must remember to also change the "javac" alternative. (In some cases, you may not care if your /usr/bin/java and /usr/bin/javac are provided by different vendors. In most cases, you probably want to be consistent.) I wrote a script to change both "java" and "javac" alternatives in one fell swoop. Here's how it works: | $ sudo ./alt-java | spawn /usr/sbin/alternatives --config java | | There are 2 programs which provide 'java'. | | Selection Command | ----------------------------------------------- | 1 /usr/lib/jvm/jre-1.4.2-gcj/bin/java | *+ 2 /usr/lib/jvm/jre-1.4.2-sun/bin/java | | Enter to keep the current selection[+], or type selection number: 1 | 1 | spawn /usr/sbin/alternatives --config javac | | There are 2 programs which provide 'javac'. | | Selection Command | ----------------------------------------------- | 1 /usr/lib/jvm/java-1.4.2-gcj/bin/javac | *+ 2 /usr/lib/jvm/java-1.4.2-sun/bin/javac | | Enter to keep the current selection[+], or type selection number: 1 I am attaching the script in hopes that someone else will find it useful. ------------------------------------------------------------------------------ -------------- next part -------------- #!/usr/bin/expect # -*- mode: tcl -*- # Author: Vadim Nasardinov (vadimn at redhat.com) # Since: 2005-07-22 spawn /usr/sbin/alternatives --config java set prompt {Enter to keep the current selection[+], or type selection number:} proc die {} { puts "timed out" exec kill [exp_pid] exit 1 } expect { -ex $prompt { expect_user -re "(.*)\n" set selection $expect_out(1,string) send "$selection\r" # If we get nonsensical input from the user, the alternatives # system will redisplay the same prompt. In this case, we # loop. exp_continue } timeout die } # If "java" is unknown to the alternatives system, the above command # exits silently and the "selection" variable remains unset. if {![info exists selection]} { puts {"java" is not managed by alternatives} exit 1 } set client_exit [wait] set os_code [lindex $client_exit 2] set client_retc [lindex $client_exit 3] if {$os_code != 0} { puts "OS error" exit 1 } if {$client_retc != 0} { puts "something went wrong" exit $client_retc } spawn /usr/sbin/alternatives --config javac expect { -ex $prompt { # FIXME: For now, we assume that "java" and "javac" are # numbered consistently. For example, if Sun's "java" appears # as 1 in the list of "java" alternatives, then Sun's "javac" # also appears under 1 in the list of "javac" alternatives. send "$selection\r" } timeout die } wait puts $selection From greenrd at presidium.org Fri Jul 22 23:02:41 2005 From: greenrd at presidium.org (Robin Green) Date: Sat, 23 Jul 2005 00:02:41 +0100 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl References: <20050722152433.GA7416@redhat.com> Message-ID: On Fri, 22 Jul 2005 12:12:54 -0600, Tom Tromey wrote: >>>>>> "Andrew" == Andrew Overholt writes: > Andrew> /usr/share/eclipse/plugins/org.eclipse.core.runtime_3.1.0.jar:/home/overholt/rssowl/BlowfishJ.jar:/home/overholt/rssowl/codec-1.3.jar:/home/overholt/rssowl/httpclient-3.0.jar:/home/overholt/rssowl/iTextAsian.jar:/home/overholt/rssowl/itext.jar:/home/overholt/rssowl/jdom.jar:/home/overholt/rssowl/jface.jar:/home/overholt/rssowl/logging-1.0.4.jar:/home/overholt/rssowl/res.jar:/home/overholt/rssowl/swt.jar:/home/overholt/rssowl/swt-nl.jar:/home/overholt/rssowl/xerces.jar > > If you want to use xerces you will have to make it available by > setting java.endorsed.dirs to point to the directory holding its jar. > Otherwise I think you'll end up using the built-in xml code (due to > class loader delegation). Unless my patch has been applied, rssowl directly refers to Xerces. > It sounds like we are ignoring -cp when -jar is given. As Fernando points out, ignoring the classpath when -jar is provided is indeed consistent with Sun VMs, strange as it may seem. I presume that the classpath is supposed to be under the exclusive control of the jar's metainfo. -- Robin From justin.conover at gmail.com Sat Jul 23 14:18:18 2005 From: justin.conover at gmail.com (Justin Conover) Date: Sat, 23 Jul 2005 09:18:18 -0500 Subject: [fedora-java] Learning java? Message-ID: Are books like: Sams Teach Yourself Java in 24 hours Head First Java Good books to start out in Java? From overholt at redhat.com Sat Jul 23 15:59:40 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sat, 23 Jul 2005 11:59:40 -0400 Subject: [fedora-java] Learning java? In-Reply-To: References: Message-ID: <20050723155939.GA3460@redhat.com> * Justin Conover [2005-07-23 10:18]: > Are books like: > > Sams Teach Yourself Java in 24 hours > Head First Java > > Good books to start out in Java? I've never read either of them, but I did like Bruce Eckel's 'Thinking In Java'. Andrew From john_sips_tea at yahoo.com Mon Jul 25 02:42:33 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Sun, 24 Jul 2005 19:42:33 -0700 (PDT) Subject: [fedora-java] jpackage.org and FC4 Message-ID: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> I just installed Fedora Core 4, and happily, it seems to have all the Java packages already installed for me and ready to go (during the install I selected the Java and Eclipse packages, and also dev tools packages). Then, later, I noticed this site: http://jpackage.org/ They seem to have many of the same packages that already come with FC4, and they're rpm's too. At first I assumed that jpackage.org must be for other rpm-based distros besides Fedora, but then I came across this article: http://fedoranews.org/mediawiki/index.php/JPackage_Java_for_FC4 by Paul Howarth. It says: | | Fedora Core 4 users should use either the RPM from jpackage.org | or manually install the Sun Java tarball into /opt. Sun Java 1.5+ | is recommended for stability purposes. | What are they talking about? FC4 already comes with Java: [john at localhost ~]$ yum list | grep gcj java-1.4.2-gcj-compat.i386 1.4.2.0-40jpp_31rh.FC4 installed java-1.4.2-gcj-compat-devel.i386 1.4.2.0-40jpp_31rh.FC4 installed java-1.4.2-gcj-compat-src.i386 1.4.2.0-40jpp_31rh.FC4 installed libgcj.i386 4.0.0-8 installed libgcj-devel.i386 4.0.0-8 installed libgcj-src.i386 4.0.0-8 installed java-1.4.2-gcj-compat-debuginfo.i386 1.4.2.0-40jpp_31rh.FC4 updates-released Why would I install Java from jpackage.org when it already comes with FC4 and works right OOTB? Should FC4 users be using *any* packages from jpackage.org? Thanks, ---John ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From nicolas.mailhot at laposte.net Mon Jul 25 09:27:00 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 25 Jul 2005 11:27:00 +0200 (CEST) Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> Message-ID: <59116.192.54.193.37.1122283620.squirrel@rousalka.dyndns.org> On Lun 25 juillet 2005 04:42, John M. Gabriele wrote: > Should FC4 users be using *any* packages from jpackage.org? jpackage.org is a kind of upstream for FC java packages. JPP was born a few years ago when there was no free Java stack and no distro was seriously packaging java apps. Several users of rpm distributions got together to package Java software in an rpm format. One of our cunning decisions was to be JVM agnostic. When gcj matured Red Hat was able to take our packages and use them with little changes in Fedora. There is a strong wish both Red Hat and Fedora side not to break this flow, so the JPP and FC java repositories should be compatible (indeed, several JPP members are active on FE or even joined Red Hat, and several Red Hat employees were accepted in the JPP team early this year). The FC java stacks follows JPP packaging conventions. JPP serves as an incubator : you can package java software that depends on non-free java bits, or java software Red Hat is not interested in, and when the conditions change (non-free bits get reimplemented in classpath or interest arises) the package finds its way in FC. That also means some software is only available in JPP today, and JPP is not pure FOSS (meaning the answer to your original question depends on what exactly you want to achieve). Also JPP is open to packagers from all the rpm world (RHEL, FC, Mdk, Novell, Solaris, OpenPKG...). We try not to depend on a particular distribution quirk so the same packages work as-is everywhere. The team has never been big and we've never rejected anyone. Regards, -- Nicolas Mailhot From greenrd at presidium.org Mon Jul 25 11:52:35 2005 From: greenrd at presidium.org (Robin Green) Date: Mon, 25 Jul 2005 12:52:35 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> Message-ID: On Sun, 24 Jul 2005 19:42:33 -0700, John M. Gabriele wrote: > Why would I install Java from jpackage.org when it already comes with > FC4 and works right OOTB? Because gcj (the GNU compiler for Java), which is the only implementation of Java that comes with FC4, is not yet fully implemented. Most importantly, it does not fully implement either AWT or Swing - the graphical user interface systems which most graphical Java applications use. However, the Java apps and libraries shipped as part of FC4 (eclipse, ant, xerces etc.) should work fine on the gcj platform. Please file bugs if they do not. This should be documented somewhere. -- Robin From aph at redhat.com Mon Jul 25 12:18:22 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Jul 2005 13:18:22 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> Message-ID: <17124.55438.860349.673608@zapata.pink> Robin Green writes: > On Sun, 24 Jul 2005 19:42:33 -0700, John M. Gabriele wrote: > > Why would I install Java from jpackage.org when it already comes with > > FC4 and works right OOTB? > > Because gcj (the GNU compiler for Java), which is the only implementation > of Java that comes with FC4, is not yet fully implemented. Most > importantly, it does not fully implement either AWT or Swing - the > graphical user interface systems which most graphical Java applications > use. It's not just that. Just as significant is that fact that a lot of applications depend on the internal details of a particular implementation. In theory applications written in the Java language are portable, but in practice it often doesn't work out that way. Oh, and gcj has a different set of bugs from other implementations. I'd better mention that too... Andrew. From gbenson at redhat.com Mon Jul 25 12:48:28 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 25 Jul 2005 13:48:28 +0100 Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> Message-ID: <20050725124826.GB7565@redhat.com> John M. Gabriele wrote: > Should FC4 users be using *any* packages from jpackage.org? Yes, if you want to use JREs and SDKs other than the one we ship. And also yes if you want to use Java applications other than the ones we ship. However, FC4 users should be careful about upgrading packages when such an upgrade would result in a Fedora package being replaced with a JPackage one. Doing this will in many cases cause you to lose performance and/or function when using our JRE. In short, update from JPackage's yum repository at your peril. Cheers, Gary From john_sips_tea at yahoo.com Mon Jul 25 14:24:29 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Mon, 25 Jul 2005 07:24:29 -0700 (PDT) Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: Message-ID: <20050725142430.32211.qmail@web80910.mail.scd.yahoo.com> --- Robin Green wrote: > On Sun, 24 Jul 2005 19:42:33 -0700, John M. Gabriele wrote: > > Why would I install Java from jpackage.org when it already comes with > > FC4 and works right OOTB? > > [snip] > > This should be documented somewhere. I've *just* begun working on it: http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora (nothing there yet though) BTW, for wiki software, I highly recommend PmWiki. Last night I tried TWiki, phpwiki, qwikiwiki, then finally settled on PmWiki. Good docs, easy to install and configure, GPL'd, generous and active user community, clean and simple look. ---John __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From overholt at redhat.com Mon Jul 25 21:38:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 25 Jul 2005 17:38:14 -0400 Subject: [fedora-java] Odd ClassNotFoundException with RSSOwl In-Reply-To: <42E13CB3.4020308@lozano.eti.br> References: <20050722152433.GA7416@redhat.com> <42E13CB3.4020308@lozano.eti.br> Message-ID: <20050725213814.GB8095@redhat.com> * Fernando Lozano [2005-07-22 14:38]: > > It is the standard behaviour (at least with Sun Java) to ignore -cp and > the CLASSPATH env var when using -jar. And we'd better behave the same way. You are indeed correct. This was my problem. Thanks, Andrew From overholt at redhat.com Mon Jul 25 21:39:27 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 25 Jul 2005 17:39:27 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <42E55224.8010209@rssowl.org> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> Message-ID: <20050725213927.GC8095@redhat.com> Oops, I meant to CC the list. Hi Ben, * Benjamin Pasero [2005-07-25 15:58]: > > the origin of this is most likely "jface.jar" requring parts of > Eclipse's platform Jars. Ah. > I will ask a SWT comitter that told me he once managed to remove the > dependency. He might be able to create a jar for me. That won't really work unless we can patch FC's JFace build stuff to allow the JFace jar in the system to have the same dependency removed. But it's a good step forward. Either way, I've made an SRPM and specfile available for the little hackjob I did on this: http://www.overholt.ca/rssowl/ Things work pretty well for me. The specfile lists things that we need to do. If anyone wants to help, it'd be greatly appreciated. Thanks, Andrew From amermedi at dfzmail.net Mon Jul 25 21:58:09 2005 From: amermedi at dfzmail.net (American Medical) Date: Mon, 25 Jul 2005 16:58:09 -0500 Subject: [fedora-java] New Health Plan - Only $85 a Month Message-ID: <200507252158.j6PLwIGk009366@mx3.redhat.com> An HTML attachment was scrubbed... URL: From john_sips_tea at yahoo.com Tue Jul 26 04:16:34 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Mon, 25 Jul 2005 21:16:34 -0700 (PDT) Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <59116.192.54.193.37.1122283620.squirrel@rousalka.dyndns.org> Message-ID: <20050726041634.39418.qmail@web80906.mail.scd.yahoo.com> --- Nicolas Mailhot wrote: > > On Lun 25 juillet 2005 04:42, John M. Gabriele wrote: > > > Should FC4 users be using *any* packages from jpackage.org? > > jpackage.org is a kind of upstream for FC java packages. JPP was born a What does the acronym "JPP" stand for? > few years ago when there was no free Java stack and no distro was > seriously packaging java apps. Several users of rpm distributions got > together to package Java software in an rpm format. > > One of our cunning decisions was to be JVM agnostic. When gcj matured Red > Hat was able to take our packages and use them with little changes in > Fedora. There is a strong wish both Red Hat and Fedora side not to break > this flow, so the JPP and FC java repositories should be compatible > (indeed, several JPP members are active on FE FE? > or even joined Red Hat, and > several Red Hat employees were accepted in the JPP team early this year). > The FC java stacks follows JPP packaging conventions. > > JPP serves as an incubator : you can package java software that depends on > non-free java bits, or java software Red Hat is not interested in, and > when the conditions change (non-free bits get reimplemented in classpath > or interest arises) the package finds its way in FC. That also means some > software is only available in JPP today, and JPP is not pure FOSS (meaning > the answer to your original question depends on what exactly you want to > achieve). > > Also JPP is open to packagers from all the rpm world (RHEL, FC, Mdk, > Novell, Solaris, OpenPKG...). We try not to depend on a particular > distribution quirk so the same packages work as-is everywhere. The team > has never been big and we've never rejected anyone. > > Regards, > > -- > Nicolas Mailhot > > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From Nicolas.Mailhot at laPoste.net Tue Jul 26 05:59:08 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 26 Jul 2005 07:59:08 +0200 Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <20050726041634.39418.qmail@web80906.mail.scd.yahoo.com> References: <20050726041634.39418.qmail@web80906.mail.scd.yahoo.com> Message-ID: <1122357549.2254.2.camel@rousalka.dyndns.org> FC = Fedora Core FE = Fedora Extras JPP = JPackage -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From david at zarb.org Tue Jul 26 11:51:51 2005 From: david at zarb.org (David Walluck) Date: Tue, 26 Jul 2005 07:51:51 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050725213927.GC8095@redhat.com> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> Message-ID: <20050726075151.7ni993rsgs0084ko@www.zarb.org> Andrew Overholt wrote: > Things work pretty well for me. The specfile lists things that we need to > do. If anyone wants to help, it'd be greatly appreciated. Both blowfish-j and itext are already in JPackage. However, they are outdated, 2.12 -> 2.14 and 1.02b -> 1.3, respectively. So, JPackage has probably done most of the work already, but it would be nice to get the packages brought up to date in the process. As for swt-nl.jar, I know green posted a message to jpackage-discuss about this jar a few months back, which he couldn't find at the time. I have found it in CVS here: http://dev.eclipse.org/viewcvs/index.cgi/platform-swt-home/ but I don't know what it is part of (if it is not part of the swt build already). -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From i.pilcher at comcast.net Tue Jul 26 12:48:52 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 26 Jul 2005 07:48:52 -0500 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <20050725124826.GB7565@redhat.com> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> Message-ID: Gary Benson wrote: > Yes, if you want to use JREs and SDKs other than the one we ship. > And also yes if you want to use Java applications other than the > ones we ship. > > However, FC4 users should be careful about upgrading packages when > such an upgrade would result in a Fedora package being replaced with > a JPackage one. Doing this will in many cases cause you to lose > performance and/or function when using our JRE. > > In short, update from JPackage's yum repository at your peril. And therein lies a problem. As you say, there are valid reasons for using JPackage RPMs on Fedora Core 4, but doing so is "perilous". It would be a very good thing, IMNSHO, if the Fedora Java folks and the JPackage folks could develop some sort of co-existance strategy. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From david at zarb.org Tue Jul 26 13:07:38 2005 From: david at zarb.org (David Walluck) Date: Tue, 26 Jul 2005 09:07:38 -0400 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> Message-ID: <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> Ian Pilcher wrote: > It would be a very good thing, IMNSHO, if the Fedora Java folks and the > JPackage folks could develop some sort of co-existance strategy. I don't think that there are any major issues with co-existence. The idea, as I gather from the list, was always to have FC4 be ``fully'' jpp-compatible. The major issue I see is that the .so files and other binaries aren't shipped separately. I never did catch the exact reason for this. This means that if you run a jpp package on gij then it may run slower because it hasn't been natively compiled. The upside of shipping the .so files separately is that you don't have to lose them if you use a jpp package, and you don't have to turn every nice noarch package into an arch package just to get the .so files. As I understand it, it takes much too long to compile the libs on the fly (ideally what I wish could be done), but that doesn't preclude the existence of separate binary packages that would depend on the noarch packages. The other major issue I see is that sometimes the free packages are missing functionality (due to either license restrictions or actual missing functionality in the free stacks), and these jars aren't split in such a way, either, that you would know what you were missing (not that this is even really feasible). -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From gbenson at redhat.com Tue Jul 26 13:24:53 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 Jul 2005 14:24:53 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> Message-ID: <20050726132450.GB6645@redhat.com> Ian Pilcher wrote: > Gary Benson wrote: > > Yes, if you want to use JREs and SDKs other than the one we ship. > > And also yes if you want to use Java applications other than the > > ones we ship. > > > > However, FC4 users should be careful about upgrading packages when > > such an upgrade would result in a Fedora package being replaced > > with a JPackage one. Doing this will in many cases cause you to > > lose performance and/or function when using our JRE. > > > > In short, update from JPackage's yum repository at your peril. > > And therein lies a problem. As you say, there are valid reasons for > using JPackage RPMs on Fedora Core 4, but doing so is "perilous". Yes, though again it's only a problem if you replace Fedora packages with JPackage ones. Installing packages from JPackage that do not exist in Fedora should pose no problems. > It would be a very good thing, IMNSHO, if the Fedora Java folks and > the JPackage folks could develop some sort of co-existance strategy. We do coexist. Unfortunatly the limitations of rpm's linear version space mean that something has to give, and that something is upgrading. Cheers, Gary From greenrd at greenrd.org Tue Jul 26 13:25:41 2005 From: greenrd at greenrd.org (Robin Green) Date: Tue, 26 Jul 2005 14:25:41 +0100 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050726075151.7ni993rsgs0084ko@www.zarb.org> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> Message-ID: <20050726132541.GA5296@pob> On Tue, Jul 26, 2005 at 07:51:51AM -0400, David Walluck wrote: > Both blowfish-j and itext are already in JPackage. However, they are > outdated, > 2.12 -> 2.14 and 1.02b -> 1.3, respectively. Attached is my spec for blowfish-j 2.14. -- Robin -------------- next part -------------- %define name blowfish-j %define version 2.14 %define release 1rdg %define section free Name: %{name} Version: %{version} Release: %{release} Epoch: 0 Summary: A Blowfish implementation in Java License: Apache License 2.0 Url: http://blowfishj.sourceforge.net/ Source: http://prdownloads.sourceforge.net/blowfishj/blowfishj-%{version}-src.tar.gz BuildRequires: ant BuildRequires: jpackage-utils >= 0:1.5 Group: Development/Java Buildarch: noarch Buildroot: %{_tmppath}/%{name}-%{version}-buildroot Vendor: JPackage Project %description The Blowfish implementation in Java, very fast ECB and CBC encryption. Comes with the BlowfishEasy class for simple string encryption, plus a solution for streaming. %package demo Summary: Examples for %{name} Group: Development/Java %description demo Examples for %{name}. %package javadoc Summary: Javadoc for %{name} Group: Development/Documentation %description javadoc Javadoc for %{name} %prep %setup -q -n blowfishj-%{version} %build [ ! -e "$JAVA_HOME" ] && export JAVA_HOME="%{_jvmdir}/java" unset CLASSPATH ant clean dist %install # jar install -d -m 755 $RPM_BUILD_ROOT%{_javadir} install -m 644 dist/blowfishj-%{version}.jar $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar cd target/test-classes jar cf ../../dist/%{name}-test.jar * cd - install -m 644 dist/%{name}-test.jar $RPM_BUILD_ROOT%{_javadir}/%{name}-test-%{version}.jar (cd $RPM_BUILD_ROOT%{_javadir} && for jar in *-%{version}*; do \ ln -sf ${jar} ${jar/-%{version}/}; done) # javadoc install -p -d -m 755 $RPM_BUILD_ROOT%{_javadocdir}/%{name}-%{version} cp -pr dist/docs/api/* $RPM_BUILD_ROOT%{_javadocdir}/%{name}-%{version} (cd $RPM_BUILD_ROOT%{_javadocdir} && ln -sf %{name}-%{version} %{name}) %clean rm -rf $RPM_BUILD_ROOT %post javadoc rm -f %{_javadocdir}/%{name} ln -s %{name}-%{version} %{_javadocdir}/%{name} %postun javadoc if [ $1 -eq 0 ]; then rm -f %{_javadocdir}/%{name} fi %files %defattr(0644,root,root,755) %doc LICENSE.txt %{_javadir}/%{name}.jar %{_javadir}/%{name}-%{version}.jar %files demo %defattr(0644,root,root,0755) %doc src/test/java/test/net/sourceforge/blowfishj/*.java %{_javadir}/%{name}-test.jar %{_javadir}/%{name}-test-%{version}.jar %files javadoc %defattr(0644,root,root,0755) %dir %{_javadocdir}/%{name}-%{version} %{_javadocdir}/%{name}-%{version}/* %ghost %dir %{_javadocdir}/%{name} %changelog * Sun Mar 20 2005 Robin Green 0:2.14-1rdg - 2.14 - Adjust for upstream package name change and license change * Sat Oct 16 2004 David Walluck 0:2.12-1jpp - 2.12 - rebuild for JPackage 1.6 * Thu Mar 27 2003 Nicolas Mailhot 0:2.01-1jpp - Initial packaging -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gbenson at redhat.com Tue Jul 26 13:38:30 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 Jul 2005 14:38:30 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> Message-ID: <20050726133828.GC6645@redhat.com> David Walluck wrote: > Ian Pilcher wrote: > > It would be a very good thing, IMNSHO, if the Fedora Java folks > > and the JPackage folks could develop some sort of co-existance > > strategy. > > I don't think that there are any major issues with co-existence. The > idea, as I gather from the list, was always to have FC4 be ``fully'' > jpp-compatible. > > The major issue I see is that the .so files and other binaries > aren't shipped separately. I never did catch the exact reason for > this. There's a multitude of reasons. The biggest showstopper of them all (from my point of view) is that there's no way to cause the native stuff to be installed automatically. Someone who did 'yum install tomcat5' would have a very slow Tomcat if they did not know to run 'yum install tomcat-gcjlibs' or whatever. > This means that if you run a jpp package on gij then it may run > slower because it hasn't been natively compiled. The upside of > shipping the .so files separately is that you don't have to lose > them if you use a jpp package, You would lose them unless the JPackage package was compiled with the same compiler as the Fedora one since Native code is located using the MD5 of the bytecode. > As I understand it, it takes much too long to compile the libs on > the fly (ideally what I wish could be done), Yes. Hours in the case of big packages like JacORB and Xalan. You also need an incredible amount of memory, although aot-compile-rpm mitigates this somewhat. > The other major issue I see is that sometimes the free packages are > missing functionality (due to either license restrictions or actual > missing functionality in the free stacks) That's not such a problem these days, except where packages use Sun- specific classes. A bigger problem is that the Fedora rpms often contain workarounds for libgcj issues. Upgrading to the JPackage loses those workarounds. Cheers, Gary From aph at redhat.com Tue Jul 26 13:42:16 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jul 2005 14:42:16 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <20050726133828.GC6645@redhat.com> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> <20050726133828.GC6645@redhat.com> Message-ID: <17126.15800.754131.668280@zapata.pink> Gary Benson writes: > David Walluck wrote: > > Ian Pilcher wrote: > > > It would be a very good thing, IMNSHO, if the Fedora Java folks > > > and the JPackage folks could develop some sort of co-existance > > > strategy. > > > > I don't think that there are any major issues with co-existence. The > > idea, as I gather from the list, was always to have FC4 be ``fully'' > > jpp-compatible. > > > > The major issue I see is that the .so files and other binaries > > aren't shipped separately. I never did catch the exact reason for > > this. > > There's a multitude of reasons. The biggest showstopper of them all > (from my point of view) is that there's no way to cause the native > stuff to be installed automatically. Someone who did 'yum install > tomcat5' would have a very slow Tomcat if they did not know to run > 'yum install tomcat-gcjlibs' or whatever. Precompiled binaries are bug, so adding the jars to the same RPM as the binaries makes not a huge difference to the total size. Andrew. From aph at redhat.com Tue Jul 26 13:46:47 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jul 2005 14:46:47 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <17126.15800.754131.668280@zapata.pink> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> <20050726133828.GC6645@redhat.com> <17126.15800.754131.668280@zapata.pink> Message-ID: <17126.16071.180698.55096@zapata.pink> Andrew Haley writes: > > Precompiled binaries are bug, so adding the jars to the same RPM as > the binaries makes not a huge difference to the total size. Argh! Precompiled binaries are *big*. :-) Andrew. From john_sips_tea at yahoo.com Tue Jul 26 14:26:37 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Tue, 26 Jul 2005 07:26:37 -0700 (PDT) Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <1122357549.2254.2.camel@rousalka.dyndns.org> Message-ID: <20050726142637.67944.qmail@web80906.mail.scd.yahoo.com> --- Nicolas Mailhot wrote: > FC = Fedora Core > FE = Fedora Extras > JPP = JPackage > > -- > Nicolas Mailhot > I was asking about that 2nd 'P': JPP == Java Package Project ? :) ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From david at zarb.org Tue Jul 26 14:33:31 2005 From: david at zarb.org (David Walluck) Date: Tue, 26 Jul 2005 10:33:31 -0400 Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <20050726142637.67944.qmail@web80906.mail.scd.yahoo.com> References: <20050726142637.67944.qmail@web80906.mail.scd.yahoo.com> Message-ID: <20050726103331.jkut82kogoosk4cc@www.zarb.org> "John M. Gabriele" wrote: > I was asking about that 2nd 'P': > JPP == Java Package Project Yes (and it was also probably preferred to have a three-letter acronym instead of two). -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From john_sips_tea at yahoo.com Tue Jul 26 14:33:36 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Tue, 26 Jul 2005 07:33:36 -0700 (PDT) Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> Message-ID: <20050726143336.83882.qmail@web80905.mail.scd.yahoo.com> --- David Walluck wrote: > Ian Pilcher wrote: > > > It would be a very good thing, IMNSHO, if the Fedora Java folks and the > > JPackage folks could develop some sort of co-existance strategy. > > I don't think that there are any major issues with co-existence. The > idea, as I > gather from the list, was always to have FC4 be ``fully'' jpp-compatible. > > The major issue I see is that the .so files and other binaries aren't shipped > separately. [snip] Could you please explain what shared libs have to do with Java packages here? What do you mean by .so files being shipped separately? Don't Java packages just come with either: 1. jar files that consist of bundled-up .class files, or 2. binaries built with GCJ that link with the libgcj already on your system? Since JPP packages are JVM-agnostic, then wouldn't that rule out #2 above for JPP packages? Thanks, ---J ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From gbenson at redhat.com Tue Jul 26 14:36:46 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 Jul 2005 15:36:46 +0100 Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <20050726103331.jkut82kogoosk4cc@www.zarb.org> References: <20050726142637.67944.qmail@web80906.mail.scd.yahoo.com> <20050726103331.jkut82kogoosk4cc@www.zarb.org> Message-ID: <20050726143645.GD6645@redhat.com> David Walluck wrote: > "John M. Gabriele" wrote: > > > I was asking about that 2nd 'P': > > JPP == Java Package Project > > Yes (and it was also probably preferred to have a three-letter > acronym instead of two). Why? From i.pilcher at comcast.net Tue Jul 26 14:35:22 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 26 Jul 2005 09:35:22 -0500 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <20050726132450.GB6645@redhat.com> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726132450.GB6645@redhat.com> Message-ID: Gary Benson wrote: > Ian Pilcher wrote: > >>Gary Benson wrote: >> >>>In short, update from JPackage's yum repository at your peril. >> >>And therein lies a problem. As you say, there are valid reasons for >>using JPackage RPMs on Fedora Core 4, but doing so is "perilous". > > > Yes, though again it's only a problem if you replace Fedora packages > with JPackage ones. Installing packages from JPackage that do not > exist in Fedora should pose no problems. > So I can install Sun's JDK via JPackage, develop a web application, and be sure that it will run on Fedora's Tomcat? > >>It would be a very good thing, IMNSHO, if the Fedora Java folks and >>the JPackage folks could develop some sort of co-existance strategy. > > > We do coexist. Unfortunatly the limitations of rpm's linear version > space mean that something has to give, and that something is > upgrading. > Yeah, God knows I'm no RPM fanboy. I can think of a few possible strategies: 1. Move all of Fedora's JPackage-compatible/alternative packages into a separate Yum repository (fedora-java{,-devel,-updates,-testing} etc.). Users could them choose between JPackage and Fedora Java packages by enabling/disabling appropriate repositories. 2. JPackage could create specially named packages for Fedora. For example, tomcat5 could become jpp-tomcat5 or somesuch. Obviously, jpp-tomcat5 would have to provide "tomcat5", and dependency resolvers such as Yum might still mess things up; installing a JPackage RPM might pull in a Fedora package, for example. 3. Yum could be enhanced to give more control to system administrators. It might be possible, for example, to configure Yum to "prefer" packages from a particular repository regardless of their EVR. Just thinking out loud... -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From aph at redhat.com Tue Jul 26 14:39:16 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jul 2005 15:39:16 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <20050726143336.83882.qmail@web80905.mail.scd.yahoo.com> References: <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> <20050726143336.83882.qmail@web80905.mail.scd.yahoo.com> Message-ID: <17126.19220.687249.717608@zapata.pink> John M. Gabriele writes: > --- David Walluck wrote: > > > Ian Pilcher wrote: > > > > > It would be a very good thing, IMNSHO, if the Fedora Java folks and the > > > JPackage folks could develop some sort of co-existance strategy. > > > > I don't think that there are any major issues with co-existence. The > > idea, as I > > gather from the list, was always to have FC4 be ``fully'' jpp-compatible. > > > > The major issue I see is that the .so files and other binaries aren't shipped > > separately. [snip] > > Could you please explain what shared libs have to do with Java packages here? > > What do you mean by .so files being shipped separately? Don't Java packages > just come with either: > > 1. jar files that consist of bundled-up .class files, or > 2. binaries built with GCJ that link with the libgcj already on your system? > > Since JPP packages are JVM-agnostic, then wouldn't that rule out #2 > above for JPP packages? For Fedora it's not either/or: it's both. Andrew. From gbenson at redhat.com Tue Jul 26 14:48:51 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 Jul 2005 15:48:51 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <17126.16071.180698.55096@zapata.pink> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> <20050726133828.GC6645@redhat.com> <17126.15800.754131.668280@zapata.pink> <17126.16071.180698.55096@zapata.pink> Message-ID: <20050726144850.GE6645@redhat.com> Andrew Haley wrote: > Andrew Haley writes: > > > > Precompiled binaries are bug, so adding the jars to the same RPM > > as the binaries makes not a huge difference to the total size. > > Argh! Precompiled binaries are *big*. Erm, that's kind of backward. The native code is roughly four times the size of the bytecode, so our rpms are five times the size of their corresponding JPackage ones. Uncompressed, at any rate. Cheers, Gary From aph at redhat.com Tue Jul 26 14:54:17 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jul 2005 15:54:17 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <20050726144850.GE6645@redhat.com> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> <20050726133828.GC6645@redhat.com> <17126.15800.754131.668280@zapata.pink> <17126.16071.180698.55096@zapata.pink> <20050726144850.GE6645@redhat.com> Message-ID: <17126.20121.840296.606963@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Andrew Haley writes: > > > > > > Precompiled binaries are bug, so adding the jars to the same RPM > > > as the binaries makes not a huge difference to the total size. > > > > Argh! Precompiled binaries are *big*. > > Erm, that's kind of backward. The native code is roughly four times > the size of the bytecode, so our rpms are five times the size of their > corresponding JPackage ones. Uncompressed, at any rate. Right, so there's no point omitting the jars from the RPMs that contain the precompiled code. Andrew. From gbenson at redhat.com Tue Jul 26 14:58:16 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 Jul 2005 15:58:16 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <20050726143336.83882.qmail@web80905.mail.scd.yahoo.com> References: <20050726090738.sd7g7di7ks0wsswo@www.zarb.org> <20050726143336.83882.qmail@web80905.mail.scd.yahoo.com> Message-ID: <20050726145814.GF6645@redhat.com> John M. Gabriele wrote: > --- David Walluck wrote: > > Ian Pilcher wrote: > > > > > It would be a very good thing, IMNSHO, if the Fedora Java folks > > > and the JPackage folks could develop some sort of co-existance > > > strategy. > > > > I don't think that there are any major issues with co-existence. > > The idea, as I gather from the list, was always to have FC4 be > > ``fully'' jpp-compatible. > > > > The major issue I see is that the .so files and other binaries > > aren't shipped separately. [snip] > > Could you please explain what shared libs have to do with Java > packages here? > > What do you mean by .so files being shipped separately? Don't Java > packages just come with either: > > 1. jar files that consist of bundled-up .class files, or > 2. binaries built with GCJ that link with the libgcj already on your > system? Java packages in Fedora (since FC4) always contain jar files. Sometimes they also contain native code shared libraries for libgcj. Cheers, Gary From john_sips_tea at yahoo.com Tue Jul 26 15:02:12 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Tue, 26 Jul 2005 08:02:12 -0700 (PDT) Subject: [fedora-java] Java on Fedora faq Message-ID: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> It's starting to come along. :) http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora Comments? ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From nicolas.mailhot at laposte.net Tue Jul 26 15:06:19 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 26 Jul 2005 17:06:19 +0200 (CEST) Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <20050726142637.67944.qmail@web80906.mail.scd.yahoo.com> References: <1122357549.2254.2.camel@rousalka.dyndns.org> <20050726142637.67944.qmail@web80906.mail.scd.yahoo.com> Message-ID: <65026.192.54.193.37.1122390379.squirrel@rousalka.dyndns.org> On Mar 26 juillet 2005 16:26, John M. Gabriele wrote: > --- Nicolas Mailhot wrote: > >> FC = Fedora Core >> FE = Fedora Extras >> JPP = JPackage >> >> -- >> Nicolas Mailhot >> > > I was asking about that 2nd 'P': > JPP == Java Package Project The "official" name is the JPackage Project -- Nicolas Mailhot From overholt at redhat.com Tue Jul 26 15:10:59 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 26 Jul 2005 11:10:59 -0400 Subject: [fedora-java] Java on Fedora faq In-Reply-To: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> Message-ID: <20050726151059.GB13036@redhat.com> Hi John, * John M. Gabriele [2005-07-26 11:02]: > It's starting to come along. :) > > http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora > > Comments? Thanks for doing this! Have you considered moving it to the official (?) Fedora wiki? I started a Java page there a couple of weeks ago but haven't had much time to flesh it out: http://fedoraproject.org/wiki/Java I can add you to the EditGroup once you've created an account. Andrew From gbenson at redhat.com Tue Jul 26 15:15:13 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 Jul 2005 16:15:13 +0100 Subject: [fedora-java] Java on Fedora faq In-Reply-To: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> Message-ID: <20050726151513.GG6645@redhat.com> John M. Gabriele wrote: > It's starting to come along. :) > > http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora > > Comments? Firstly that the company I work for is called "Red Hat" :) That's two words, both capitalized. Also that the Java runtime we ship is "libgcj" and the Java compiler we use is called "ecj". | On the other hand, note that Eclipse comes with FC4 and runs well I don't think Eclipse uses Swing, does it? | getting Sun's Java to coexist with GNU's Java on Fedora sounds like | a pretty prickly problem to me. They should coexist just fine. | yum list | grep -i classpath The packages called classpath* are not themselves classpath. Cheers, Gary From nicolas.mailhot at laposte.net Tue Jul 26 15:24:24 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 26 Jul 2005 17:24:24 +0200 (CEST) Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <65026.192.54.193.37.1122390379.squirrel@rousalka.dyndns.org> References: <1122357549.2254.2.camel@rousalka.dyndns.org> <20050726142637.67944.qmail@web80906.mail.scd.yahoo.com> <65026.192.54.193.37.1122390379.squirrel@rousalka.dyndns.org> Message-ID: <47373.192.54.193.37.1122391464.squirrel@rousalka.dyndns.org> On Mar 26 juillet 2005 17:06, Nicolas Mailhot wrote: > > On Mar 26 juillet 2005 16:26, John M. Gabriele wrote: >> --- Nicolas Mailhot wrote: >> >>> FC = Fedora Core >>> FE = Fedora Extras >>> JPP = JPackage >>> >>> -- >>> Nicolas Mailhot >>> >> >> I was asking about that 2nd 'P': >> JPP == Java Package Project > > The "official" name is the JPackage Project (using the J* word would have led to interesting legal consequences) As for why this and not something else - frankly the team is small enough we have better things to do than argue on naming. In fact team size is our biggest constraint. This is why we do not do package derivatives tailored to a particular distribution. All the attempts to do this in the past have failed because frankly it's much less ressource-intensive to just use as-is packages made under other distributions than personalise them and rebuild the whole repository. We strive for the good-enough not the perfect. If someday we have the manpower of Mandrake club, Fedora Extras (or any project where the number of active packagers at any given point of time is in the two-digit range or more) this may change. Right now we have LSBish practical rules to ensure vanilla packages build/run everywhere. -- Nicolas Mailhot From ziga.mahkovec at klika.si Tue Jul 26 15:33:00 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Tue, 26 Jul 2005 17:33:00 +0200 Subject: [fedora-java] Java on Fedora faq In-Reply-To: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> Message-ID: <1122391980.8456.27.camel@localhost> On Tue, 2005-07-26 at 08:02 -0700, John M. Gabriele wrote: > It's starting to come along. :) > http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora > > Comments? > What other Java software comes with Fedora? > There's the Java packages in the Fedora Extras project (aka "FE"). I don't think there are any Java packages in FE. > Can I do Java GUI development on Fedora with Swing or AWT? > Yes. You've even probably already got the necessary packages > installed. See Java-Gnome. Java-GNOME uses native GTK libraries, so this wouldn't fall under Swing or AWT. -- Ziga From overholt at redhat.com Tue Jul 26 15:40:44 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 26 Jul 2005 11:40:44 -0400 Subject: [fedora-java] Java on Fedora faq In-Reply-To: <1122391980.8456.27.camel@localhost> References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> <1122391980.8456.27.camel@localhost> Message-ID: <20050726154044.GA16297@redhat.com> * Ziga Mahkovec [2005-07-26 11:33]: > > What other Java software comes with Fedora? > > There's the Java packages in the Fedora Extras project (aka "FE"). > > I don't think there are any Java packages in FE. Nope, but hopefully soon we'll have RSSOwl! :) Andrew From overholt at redhat.com Tue Jul 26 15:42:46 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 26 Jul 2005 11:42:46 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <42E56F2B.4030002@rssowl.org> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <42E56F2B.4030002@rssowl.org> Message-ID: <20050726154245.GB16297@redhat.com> (I'm sorry, for some reason I didn't CC the list with this mail, either) * Benjamin Pasero [2005-07-25 18:02]: > > > >That won't really work unless we can patch FC's JFace build stuff to allow > >the JFace jar in the system to have the same dependency removed. But it's > >a good step forward. > [...] > Hm, but if I supply a jface.jar that is compiled into RSSOwl jar, that does > not have any dependency to Eclipse anymore, doesn't that help? Or is there > another JFace on the Classpath on FC, that is used first, before looking > into RSSOwl's one? We've already got JFace in FC so we should be using it where we can. We need to be able to build all the code we ship from source. What I've done in the specfile I posted is to patch the build.xml to not explode the jars that we have RPMs for already (we will have to make this all jars before we can put this into Fedora Extras) and just tack those onto the classpath for the java command. I tried in vain to get MANIFEST.MF to include the jars in the system on its "Class-Path" line, but eventually gave up and went back to the java -cp net.sourceforge... in /usr/bin/rssowl. It would be nice if we could find some way for both you (upstream) and us (downstream) to use the same build.xml but I'm content with maintaining our own rssowl script for running (since you don't have one upstream and it's so small) and patching out the unjarring of the jars from other packages. Andrew From nicolas.mailhot at laposte.net Tue Jul 26 15:47:07 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 26 Jul 2005 17:47:07 +0200 (CEST) Subject: [fedora-java] jpackage.org and FC4 In-Reply-To: <47373.192.54.193.37.1122391464.squirrel@rousalka.dyndns.org> References: <1122357549.2254.2.camel@rousalka.dyndns.org> <20050726142637.67944.qmail@web80906.mail.scd.yahoo.com> <65026.192.54.193.37.1122390379.squirrel@rousalka.dyndns.org> <47373.192.54.193.37.1122391464.squirrel@rousalka.dyndns.org> Message-ID: <65322.192.54.193.37.1122392827.squirrel@rousalka.dyndns.org> And BTW while JPackage certainly can "eat your brainz" more often than Fedora Core, it's a not an absolute evil anymore than FE or FC are. In terms of absolute package stability you certainly have RHEL > FC > FE >= JPP (reflecting the size of the packaging and QA teams) but you also need to think in terms of application span. Starting from a package other people QAd is always less dangerous than playing with zips and tar.gz all by yourself. If you really have the time and motivation to make any given package better why the project accepts contributions. I doubt you'll find the resources to repackage everything from scratch. Most of the core packages took _many_ iterations to get to the stage they are today (not that there is not a lot of work to do still) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Jul 26 15:54:24 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 26 Jul 2005 17:54:24 +0200 (CEST) Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726132450.GB6645@redhat.com> Message-ID: <45493.192.54.193.37.1122393264.squirrel@rousalka.dyndns.org> On Mar 26 juillet 2005 16:35, Ian Pilcher wrote: > Gary Benson wrote: >> Ian Pilcher wrote: >> >>>Gary Benson wrote: >>> >>>>In short, update from JPackage's yum repository at your peril. >>> >>>And therein lies a problem. As you say, there are valid reasons for >>>using JPackage RPMs on Fedora Core 4, but doing so is "perilous". >> >> >> Yes, though again it's only a problem if you replace Fedora packages >> with JPackage ones. Installing packages from JPackage that do not >> exist in Fedora should pose no problems. >> > > So I can install Sun's JDK via JPackage, develop a web application, and > be sure that it will run on Fedora's Tomcat? So you can develop and package an app, and (provided you've followed the rules) people can change the implementation of your all your app dependencies without needing to change your package. This means switching from Sun JVM to gcj, changing XML parsers, etc. Of course this is only at the package level. You still need to do some QA to check you're not hitting a bug in the new dependency implementation that wasn't there in the one you've used before. Build once, run everywhere always actually meant build once, test everywhere. -- Nicolas Mailhot From john_sips_tea at yahoo.com Tue Jul 26 16:10:27 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Tue, 26 Jul 2005 09:10:27 -0700 (PDT) Subject: [fedora-java] Java on Fedora faq In-Reply-To: <20050726151513.GG6645@redhat.com> Message-ID: <20050726161027.30651.qmail@web80907.mail.scd.yahoo.com> --- Gary Benson wrote: > John M. Gabriele wrote: > > It's starting to come along. :) > > > > http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora > > > > Comments? > > Firstly that the company I work for is called "Red Hat" :) > That's two words, both capitalized. Red Hat is mis-written on the 'Net about as often as "separate" is misspelled there. :) > Also that the Java runtime we ship is "libgcj" and the Java compiler > we use is called "ecj". Thanks. I'll look at the man page when I get home (no FC here at work). I always thought that the "gcj" program was the front-end to the "gcc" program... > | On the other hand, note that Eclipse comes with FC4 and runs well > > I don't think Eclipse uses Swing, does it? You're right -- that sentence didn't belong in there. > | getting Sun's Java to coexist with GNU's Java on Fedora sounds like > | a pretty prickly problem to me. > > They should coexist just fine. Ok. > | yum list | grep -i classpath > > The packages called classpath* are not themselves classpath. > > Cheers, > Gary Which *are* the Classpath packages? Is there a sharp distinction between the GCJ packages and the Classpath packages? Thanks, ---J __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From john_sips_tea at yahoo.com Tue Jul 26 16:14:18 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Tue, 26 Jul 2005 09:14:18 -0700 (PDT) Subject: [fedora-java] Java on Fedora faq In-Reply-To: <1122391980.8456.27.camel@localhost> Message-ID: <20050726161418.15363.qmail@web80905.mail.scd.yahoo.com> --- Ziga Mahkovec wrote: > On Tue, 2005-07-26 at 08:02 -0700, John M. Gabriele wrote: > > It's starting to come along. :) > > http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora > > > > Comments? > > > What other Java software comes with Fedora? > > There's the Java packages in the Fedora Extras project (aka "FE"). > > I don't think there are any Java packages in FE. Ah. Thanks. That makes sense in light of recent talk here about how JPP is somewhat of an incubator for FC Java packages. > > Can I do Java GUI development on Fedora with Swing or AWT? > > Yes. You've even probably already got the necessary packages > > installed. See Java-Gnome. > > Java-GNOME uses native GTK libraries, so this wouldn't fall under Swing > or AWT. > > -- > Ziga Sorry, that was a typo of mine: s/with/without/ ---J __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From gbenson at redhat.com Tue Jul 26 16:20:51 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 Jul 2005 17:20:51 +0100 Subject: [fedora-java] Java on Fedora faq In-Reply-To: <20050726161027.30651.qmail@web80907.mail.scd.yahoo.com> References: <20050726151513.GG6645@redhat.com> <20050726161027.30651.qmail@web80907.mail.scd.yahoo.com> Message-ID: <20050726162049.GI6645@redhat.com> John M. Gabriele wrote: > --- Gary Benson wrote: > > John M. Gabriele wrote: > > > It's starting to come along. :) > > > > > > http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora > > > > > > Comments? > > > > Firstly that the company I work for is called "Red Hat" :) > > That's two words, both capitalized. > > Red Hat is mis-written on the 'Net about as often as "separate" is > misspelled there. :) Heh ;) > > Also that the Java runtime we ship is "libgcj" and the Java > > compiler we use is called "ecj". > > Thanks. I'll look at the man page when I get home (no FC here at > work). I always thought that the "gcj" program was the front-end to > the "gcc" program... gcj is a gcc front-end, and while it can compile to bytecode it's not very good at it. In Fedora we use ecj, Eclipse's compiler, to compile to bytecode. We use gcj (indirectly, via aot-compile-rpm) to compile that bytecode into native code. > Which *are* the Classpath packages? There are none. Classpath's class library exists within libgcj's rpm. Cheers, Gary From tim at birdsnest.maths.tcd.ie Tue Jul 26 11:00:13 2005 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Tue, 26 Jul 2005 12:00:13 +0100 Subject: [fedora-java] Re: jpackage.org and FC4 References: <20050726041634.39418.qmail@web80906.mail.scd.yahoo.com> <1122357549.2254.2.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > FC = Fedora Core > FE = Fedora Extras > JPP = JPackage Wouldn't it be simpler eg to say JPackage rather than JPP? The latter only saves 5 key presses ... -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From john_sips_tea at yahoo.com Tue Jul 26 16:47:33 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Tue, 26 Jul 2005 09:47:33 -0700 (PDT) Subject: [fedora-java] Java on Fedora faq In-Reply-To: <20050726151059.GB13036@redhat.com> Message-ID: <20050726164733.30962.qmail@web80910.mail.scd.yahoo.com> --- Andrew Overholt wrote: > Hi John, > > * John M. Gabriele [2005-07-26 11:02]: > > It's starting to come along. :) > > > > http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora > > > > Comments? > > Thanks for doing this! You're welcome. :) > Have you considered moving it to the official (?) > Fedora wiki? I started a Java page there a couple of weeks ago but haven't > had much time to flesh it out: > > http://fedoraproject.org/wiki/Java > Thanks Andrew. For now, I just plan to keep this little seedling to myself. :) I put a link to the official wiki in the 3rd paragraph at the top though. ---J ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From chris at hubick.com Tue Jul 26 17:58:58 2005 From: chris at hubick.com (Chris Hubick) Date: Tue, 26 Jul 2005 11:58:58 -0600 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: <20050726132450.GB6645@redhat.com> References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726132450.GB6645@redhat.com> Message-ID: <1122400738.12203.45.camel@FC4a.CHD.hubick.com> On Tue, 2005-07-26 at 14:24 +0100, Gary Benson wrote: > Ian Pilcher wrote: > > Gary Benson wrote: > > > Yes, if you want to use JREs and SDKs other than the one we ship. > > > And also yes if you want to use Java applications other than the > > > ones we ship. > > > > > > However, FC4 users should be careful about upgrading packages when > > > such an upgrade would result in a Fedora package being replaced > > > with a JPackage one. Doing this will in many cases cause you to > > > lose performance and/or function when using our JRE. > > > > > > In short, update from JPackage's yum repository at your peril. > > > > And therein lies a problem. As you say, there are valid reasons for > > using JPackage RPMs on Fedora Core 4, but doing so is "perilous". > > Yes, though again it's only a problem if you replace Fedora packages > with JPackage ones. Installing packages from JPackage that do not > exist in Fedora should pose no problems. Well, great, *now* you tell me (a little late). The first thing I did after I had FC4 set up was drop in the jpackage.repo, 'update', and then install a bunch of stuff. And what exactly is 'perilous'? Is this just a native compilation/speed issue? Will everything still work, but slowly? Is this in every case, and how do we know? Would there be a way to put hooks into JPP SRPM's, or standardize on their spec file formatting, in such a way that one could construct a yum repository which *automatically* mirrors updates in the JPP yum repo, downloading an updated SRPM, and rebuilding binary RPM's including the shared lib with instructions to install it? JPackage, supplying a jpackage.repo file and all, appears to be quite conscious of being used on FC, so I certainly would not have expected using it to break things. I don't recall seeing any big red letters saying "DON'T USE THIS TO DO AN UPDATE" on their site, or in the FC4 release notes. In fact, the FC4 notes specifically mention using RPM's from JPackage. I think a warning in section 6.1.8 would be in order, or perhaps some form of grail-shaped beacon warning of this great peril ;) And how do you use JPackage through yum while avoiding updates - what happens when you install a JPP package with a dependency on another JPP package which would update an FC4 version? If I need the 2.7.0 version of Xerces from JPP to get DOM3 support, how do I not break my native Tomcat? Much Thanks. -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From nando at antunes.eti.br Tue Jul 26 18:44:00 2005 From: nando at antunes.eti.br (C.F. Scheidecker Antunes) Date: Tue, 26 Jul 2005 12:44:00 -0600 Subject: [fedora-java] Replacing FC4 Free Java for SUN's Java Message-ID: <42E68470.8090405@antunes.eti.br> Hello All, FC4 is interesting because it comes with java and all pre installed. However I need to replace all of that and have SUN's instead. Until FC3 I did everything myself manually by: 1 - Installing JDK under /opt/ and creating an /opt/java/ link 2 - creating links under /usr/bin/ for java and javac 3 - changing /etc/profile to include /opt/java/ on the path and create a classpath All Java stuff I've put under /opt/ That way I had total control. Now, FC4 has java stuff all over and config stuff all over. Rather than learning what it is (although I had not found documentation that explains all the details) I prefer to remove everything and do it the good old manual way. I've also tried jpackage but I did not like it. Again, no control and non-free is not as easy to install. Any good docs or comments on this? Anyone suffering from the same aggravations? Thanks, C.F. From jdesbonnet at gmail.com Tue Jul 26 18:57:39 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Tue, 26 Jul 2005 19:57:39 +0100 Subject: [fedora-java] Replacing FC4 Free Java for SUN's Java In-Reply-To: <42E68470.8090405@antunes.eti.br> References: <42E68470.8090405@antunes.eti.br> Message-ID: <1cef3e9505072611574deec222@mail.gmail.com> I've got the Sun JDK at /usr/local/jdk in addition to all the default RPMs from FC4. I have found that setting the environment as follows: export JAVA_HOME=/usr/local/jdk export PATH=/usr/local/jdk/bin:$PATH makes Eclipse and most other Java apps I use run ok. Joe. On 7/26/05, C.F. Scheidecker Antunes wrote: > Hello All, > > FC4 is interesting because it comes with java and all pre installed. > However I need to replace all of that and have SUN's instead. > Until FC3 I did everything myself manually by: > > 1 - Installing JDK under /opt/ and creating an /opt/java/ link > 2 - creating links under /usr/bin/ for java and javac > 3 - changing /etc/profile to include /opt/java/ on the path and create a > classpath > > All Java stuff I've put under /opt/ > > That way I had total control. > > Now, FC4 has java stuff all over and config stuff all over. > > Rather than learning what it is (although I had not found documentation > that explains all the details) I prefer to remove everything and do it > the good old manual way. > > I've also tried jpackage but I did not like it. Again, no control and > non-free is not as easy to install. > > Any good docs or comments on this? > > Anyone suffering from the same aggravations? > > Thanks, > > C.F. > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > From aph at redhat.com Tue Jul 26 19:35:56 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jul 2005 20:35:56 +0100 Subject: [fedora-java] Replacing FC4 Free Java for SUN's Java In-Reply-To: <42E68470.8090405@antunes.eti.br> References: <42E68470.8090405@antunes.eti.br> Message-ID: <17126.37020.996103.563056@zapata.pink> C.F. Scheidecker Antunes writes: > FC4 is interesting because it comes with java and all pre installed. > However I need to replace all of that and have SUN's instead. > Until FC3 I did everything myself manually by: > > 1 - Installing JDK under /opt/ and creating an /opt/java/ link > 2 - creating links under /usr/bin/ for java and javac > 3 - changing /etc/profile to include /opt/java/ on the path and create a > classpath > > All Java stuff I've put under /opt/ > > That way I had total control. > > Now, FC4 has java stuff all over and config stuff all over. > > Rather than learning what it is (although I had not found documentation > that explains all the details) I prefer to remove everything and do it > the good old manual way. > > I've also tried jpackage but I did not like it. Again, no control and > non-free is not as easy to install. > > Any good docs or comments on this? > > Anyone suffering from the same aggravations? I'm not sure I understand your problem. If you don't want to use jpackages, cvs rm the lot of them. Then you'll be back to the way you did things before. What is wrong, exactly? Andrew. From greenrd at presidium.org Tue Jul 26 19:57:59 2005 From: greenrd at presidium.org (Robin Green) Date: Tue, 26 Jul 2005 20:57:59 +0100 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java References: <42E68470.8090405@antunes.eti.br> Message-ID: On Tue, 26 Jul 2005 12:44:00 -0600, C.F. Scheidecker Antunes wrote: > Now, FC4 has java stuff all over and config stuff all over. > > Rather than learning what it is (although I had not found documentation > that explains all the details) I prefer to remove everything and do it > the good old manual way. OK. You "can" do yum remove libgcj. HOWEVER, THIS WILL REMOVE OPEN OFFICE, ECLIPSE, AND ALL JAVA PACKAGES - because yum remove is dumb and doesn't know about alternative JDK packages. Don't say I didn't warn you! Also, I don't know how to remove all the links that point into /etc/alternatives in one fell swoop. > I've also tried jpackage but I did not like it. Again, no control and > non-free is not as easy to install. No control? Does it really matter that much where in the filesystem tree things get installed? I suggest you start learning to like JPackage. As for non-free not being easy, there are now -compat packages so it's as easy as installing the Sun JDK RPM and then installing the -compat RPM from jpackage.org. No rpm building needed any more! -- Robin From greenrd at presidium.org Tue Jul 26 20:02:51 2005 From: greenrd at presidium.org (Robin Green) Date: Tue, 26 Jul 2005 21:02:51 +0100 Subject: [fedora-java] Re: Re: jpackage.org and FC4 References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726132450.GB6645@redhat.com> <45493.192.54.193.37.1122393264.squirrel@rousalka.dyndns.org> Message-ID: On Tue, 26 Jul 2005 17:54:24 +0200, Nicolas Mailhot wrote: >> So I can install Sun's JDK via JPackage, develop a web application, and >> be sure that it will run on Fedora's Tomcat? > > So you can develop and package an app, and (provided you've followed the > rules) people can change the implementation of your all your app > dependencies without needing to change your package. Actually, no. Fedora's tomcat packages contain a native and a non-native version. The native version only works with libgcj, which is not 100% compatible with Sun's Java. That's an important caveat, I think. -- Robin From nando at antunes.eti.br Tue Jul 26 21:46:50 2005 From: nando at antunes.eti.br (C.F. Scheidecker Antunes) Date: Tue, 26 Jul 2005 15:46:50 -0600 Subject: [fedora-java] Which JVM is faster Message-ID: <42E6AF4A.1050101@antunes.eti.br> Hello all, Is there any benchmark comparison between JVMs? I wonder if the one that comes with FC4 is as fast or faster and if it is 100% compatible with all java apps. Any thoughts on that? Thanks, C.F. From greenrd at presidium.org Tue Jul 26 22:10:24 2005 From: greenrd at presidium.org (Robin Green) Date: Tue, 26 Jul 2005 23:10:24 +0100 Subject: [fedora-java] Re: Java on Fedora faq References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> Message-ID: On Tue, 26 Jul 2005 08:02:12 -0700, John M. Gabriele wrote: > It's starting to come along. :) > > http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora Here are a voluminous amount of suggested changes and additions! >Sun's Java and GNU Java should be able to coexist on the same system, but >I wouldn't know how to get that configuration working. Sun's Java and GCJ are, of course, able to coexist on the same system. Follow this simple five step guide to get the recommend setup: 1. Download a Sun JDK (not a JRE!) from http://java.sun.com/j2se/1.5.0/download.jsp - and make sure you choose the "Linux RPM in self-extracting file" option. 2. Make the file you've just downloaded executable by typing chmod +x [insert filename here] 3. Execute it by typing ./[insert filename here] This will extract and then install the RPM for you. 4. Download the binary package java-1.5.0-sun-compat-1.5.0.04-1jpp from jpackage.org. (The version number may be different by the time you read this.) You will find java-1.5.0-sun-compat near the bottom of the long list of packages on the left side of the page - click on that and then click on the first icon in the B column (on jpackage.org, B is for binary package, H is for project homepage and S is for source package.) 5. Install it with rpm -ivh java-1.5.0-sun-compat-1.5.0.04-1jpp*.rpm Optionally, you can now make the Sun JDK the default, by typing alternatives --configure java This will only affect "java" and a few other commands. To make the Sun Java compiler and JDK development tools the default as well, you also need to do: alternatives --configure javac If you wish to use a different JDK to the default one, without changing your current default, you will find each JDK in its own directory under /usr/lib/jvm - along with some shortcut links like "java-gcj" to save typing. Note that JPackage (at runtime), JPackage (when package building), and many Java applications, all have their own separate systems for setting "default" virtual machines. So just because you set the system default with the alternatives command, that does not mean it will affect everything. > Can I do Java GUI development on Fedora without Swing or AWT? > > Certainly. You've even probably already got the necessary packages installed. See Java-Gnome. Certainly. You've even probably already got the necessary packages installed. The two main options are SWT (the cross-platform toolkit that uses native libraries like GTK to render stuff) and Java-Gnome. If you want to develop cross-platform applications, your best choice is probably SWT, which comes in the libswt3-gtk2 package, and is supported by Eclipse. Eclipse has a visual editor component like other IDEs, called VE (Visual Editor), but it isn't shipped in Fedora yet. You can download it from eclipse.org and unzip it (as root) into /usr/share/eclipse - the eclipse updating mechanism doesn't work, so it's best to install it manually like that. It's not necessary to install VE to develop SWT applications - VE just provides a visual, "drag-and-drop" way of developing SWT, Swing and AWT applications and components. >Where do I file bugs on Java software in Fedora? > >There isn't a Java-software-specific bug-reporting page. Please use: https://bugzilla.redhat.com/bugzilla/ . Just be sure to search >first, to see if your bug is already listed. Consider carefully the appropriate bug database to use. Firstly, can you determine or estimate[1] (for example by running the software on a Sun JDK) if it is a bug in the Java software you are using, or it is a bug in gcj/gij/libgcj? If the former, consider if it might be appropriate to report the bug to that project itself, rather than reporting it on the Fedora bug database. If the latter, it is appropriate to post the bug to the fedora bugzilla (either under the specific package, or under "gcc" if you can identify a specific compiler or interpreter bug). gcc also has its own bug database at gcc.gnu.org, but Fedora gcc is hardly modified from mainline gcc in terms of the Java stuff, and many of the same people read both databases, so it's not the end of the world if (improbably) you post a Fedora-specific bug to the gcc database by mistake. > How do I create a Java project in Eclipse on Fedora? Easy. Just start eclipse by typing "eclipse" (that was hard, wasn't it!) (You can specify a particular virtual machine to use by typing eclipse -vm /usr/lib/jvm/jre-gcj/bin/java .) Then go to the File menu and choose New -> Project. Type your project name, choose the options, and click Next (for more options) or Finish. Notice that you can import existing source code at this point. Eclipse may now ask you whether you want to switch to the Java Perspective. If so, say Yes! Then create a New Class. If you're starting from nothing, you probably want to ask eclipse to create a "public static void main (String args [])" method for you at this point (Eclipse is really good at taking of drudgery like that). Now you can go ahead are start typing! If you develop GUIs and you prefer working in a more visual style, see above for details about Eclipse's VE plugin. Some quick tips: You can configure project-specific preferences (like which JDK to use, code style conventions, warnings to supress, etc.) by right-clicking on the project in the project browser on the left and choosing Properties. You can navigate to the declarations of fields or methods in your code by highlighting them and pressing F2, or by using the code structure browser on the right. When you get a compiler error, highlight the code that Eclipse is complaining about and press CTRL+1 - eclipse will usually be able to offer you some "quick fix" suggestions as to how to fix it - and it will not only suggest them but actually implement them for you. Very handy! When you're comfortable with the basics of Eclipse, try right-clicking on code or variables and exploring the many refactoring options that are on offer. Refactoring is essentially like the Quick Fix system, but user-initiated. Caveats: Unfortunately, a couple of things do not work well when running eclipse on libgcj on Fedora Core 4. Firstly, some users have reported hangs with large CVS checkouts (although this may only apply to bleeding-edge releases from the Fedora Development package repository). Secondly, debugging doesn't work at all with a libgcj virtual machine, because it's not implemented in libgcj yet - although work on that is underway. > How do I use Tomcat? Very briefly: "service tomcat4 start" or "service tomcat5 start" will start tomcat. (Can you guess how to stop it?) Then use "rpm -ql tomcat5|less" to explore the directory structure of Tomcat on Fedora. The main thing you need to know is that you put your webapps under /var/lib/tomcat{4,5}/webapps. -- Robin [Footnote 1] - I found a bug in AspectJ yesterday which only appeared under libgcj, but *wasn't* a libgcj bug. It was a latent bug in AspectJ that was only exposed by a slightly different, but still valid, collection class implementation in libgcj. So it's not logically valid to assume that a bug that only occurs on libgcj is necessarily a bug *in* libgcj. From greenrd at presidium.org Tue Jul 26 22:15:28 2005 From: greenrd at presidium.org (Robin Green) Date: Tue, 26 Jul 2005 23:15:28 +0100 Subject: [fedora-java] Re: Which JVM is faster References: <42E6AF4A.1050101@antunes.eti.br> Message-ID: On Tue, 26 Jul 2005 15:46:50 -0600, C.F. Scheidecker Antunes wrote: > Hello all, > > Is there any benchmark comparison between JVMs? > > I wonder if the one that comes with FC4 is as fast or faster Generally slower, in my subjective experience. Although with stuff like eclipse, not that much slower, in most circumstances. There are a range of other options for "free java" virtual machines (however, they are all incomplete). Cacao looks promising but it's still a bit flaky. Not ready for production use yet. > and if it > is 100% compatible with all java apps. Absolutely not! It is not finished yet. It is compatible with less than half of Java apps and applets. However, it is progressing in leaps and bounds, and could always use more volunteers. -- Robin From vektor at dumbterm.net Tue Jul 26 22:50:08 2005 From: vektor at dumbterm.net (Billy Biggs) Date: Tue, 26 Jul 2005 17:50:08 -0500 Subject: [fedora-java] Re: Which JVM is faster In-Reply-To: References: <42E6AF4A.1050101@antunes.eti.br> Message-ID: <20050726225008.GC13267@dumbterm.net> Robin Green (greenrd at presidium.org): > On Tue, 26 Jul 2005 15:46:50 -0600, C.F. Scheidecker Antunes wrote: > > > Is there any benchmark comparison between JVMs? > > > > I wonder if the one that comes with FC4 is as fast or faster > > Generally slower, in my subjective experience. Although with stuff > like eclipse, not that much slower, in most circumstances. If you run eclipse fully-interpreted using gij, the problems are more drastic. But, I think that's understandable. -Billy From i.pilcher at comcast.net Wed Jul 27 02:22:35 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 26 Jul 2005 21:22:35 -0500 Subject: [fedora-java] Re: jpackage.org and FC4 In-Reply-To: References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726132450.GB6645@redhat.com> <45493.192.54.193.37.1122393264.squirrel@rousalka.dyndns.org> Message-ID: Robin Green wrote: > On Tue, 26 Jul 2005 17:54:24 +0200, Nicolas Mailhot wrote: > >>So you can develop and package an app, and (provided you've followed the >>rules) people can change the implementation of your all your app >>dependencies without needing to change your package. > > > Actually, no. Fedora's tomcat packages contain a native and a non-native > version. The native version only works with libgcj, which is not 100% > compatible with Sun's Java. That's an important caveat, I think. > I suspected as much. I believe that this situation should be addressed, if possible. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From i.pilcher at comcast.net Wed Jul 27 02:24:26 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 26 Jul 2005 21:24:26 -0500 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: References: <42E68470.8090405@antunes.eti.br> Message-ID: Robin Green wrote: > HOWEVER, THIS WILL REMOVE OPEN OFFICE, ECLIPSE, AND ALL JAVA PACKAGES > - because yum remove is dumb and doesn't know about alternative JDK > packages. Don't say I didn't warn you! Will Fedora's OpenOffice work with other JVM's? -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From john_sips_tea at yahoo.com Wed Jul 27 02:45:13 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Tue, 26 Jul 2005 19:45:13 -0700 (PDT) Subject: [fedora-java] Re: Java on Fedora faq In-Reply-To: Message-ID: <20050727024514.1686.qmail@web80910.mail.scd.yahoo.com> --- Robin Green wrote: > On Tue, 26 Jul 2005 08:02:12 -0700, John M. Gabriele wrote: > > > It's starting to come along. :) > > > > http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora > > Here are a voluminous amount of suggested changes and additions! Just who *are* you Mr. Green? :) Thanks for the suggestions! > >Sun's Java and GNU Java should be able to coexist on the same system, but > >I wouldn't know how to get that configuration working. > > Sun's Java and GCJ are, of course, able to coexist on the same system. Follow > this simple five step guide to get the recommend setup: > > 1. Download a Sun JDK (not a JRE!) from > http://java.sun.com/j2se/1.5.0/download.jsp - and make sure you choose the > "Linux RPM in self-extracting file" option. > > 2. Make the file you've just downloaded executable by typing > chmod +x [insert filename here] > > 3. Execute it by typing ./[insert filename here] This will extract and then > install the RPM for you. > > 4. Download the binary package java-1.5.0-sun-compat-1.5.0.04-1jpp from > jpackage.org. (The version number may be different by the time you read > this.) > You will find java-1.5.0-sun-compat near the bottom of the long > list of packages on the left side of the page - click on that and then click > on the first icon in the B column (on jpackage.org, B is for binary package, > H is for project homepage and S is for source package.) > > 5. Install it with rpm -ivh java-1.5.0-sun-compat-1.5.0.04-1jpp*.rpm > > Optionally, you can now make the Sun JDK the default, by typing > > alternatives --configure java > > This will only affect "java" and a few other commands. To make the Sun Java > compiler and JDK development tools the default as well, you also need to do: > > alternatives --configure javac > > If you wish to use a different JDK to the default one, without changing > your current default, you will find each JDK in its own directory under > /usr/lib/jvm - along with some shortcut links like "java-gcj" to save typing. > > Note that JPackage (at runtime), JPackage (when package building), and many > Java applications, all have their own separate systems for setting "default" > virtual machines. So just because you set the system default with the > alternatives command, that does not mean it will affect everything. Robin -- thank you for the excellent instructions. However, my little hole-in-the-wall faq is aimed squarely at helping new Fedora users get started using the GNU Java implementation that comes with FC. As such, I've changed the link from JavaOnFedora to GNUJavaOnFedora: http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.GNUJavaOnFedora But your instructions are too good to go to waste! You might consider sending them off in a note to the fellow who runs the fedorafaq: http://www.fedorafaq.org/#java since there's some similar (but possibly improvable) instructions there for almost the same thing. Similarly, there are instructions here also http://stanton-finley.net/fedora_core_4_installation_notes.html#Java that you may be able to help fine-tune. > > Can I do Java GUI development on Fedora without Swing or AWT? > > > > Certainly. You've even probably already got the necessary packages > installed. See Java-Gnome. > > Certainly. You've even probably already got the necessary packages installed. > The two > main options are SWT (the cross-platform toolkit that uses native libraries > like GTK to render > stuff) and Java-Gnome. > > If you want to develop cross-platform applications, your best choice > is probably SWT, which comes in the libswt3-gtk2 package, and is supported by > Eclipse. > > Eclipse has a visual editor component like other IDEs, called VE (Visual > Editor), but it isn't shipped in > Fedora yet. You can download it from eclipse.org and unzip it (as root) into > /usr/share/eclipse > - the eclipse updating mechanism doesn't work, so it's best to install it > manually like that. > It's not necessary to install VE to develop SWT applications - VE just > provides a visual, > "drag-and-drop" way of developing SWT, Swing and AWT applications and > components. By now I'm sure you're noticing my leaning toward using copylefted software when possible. As far as creating your own software, I regularly suggest to others that if your software is to depend on other pieces to run, it's preferred that those pieces be GPL'd or LGPL'd. But, again, you've given some great suggestions, so I've tried to incorporate them while still maintaining the flavor of the document. > >Where do I file bugs on Java software in Fedora? > > > >There isn't a Java-software-specific bug-reporting page. Please use: > https://bugzilla.redhat.com/bugzilla/ . Just be sure to search >first, to see > if your bug is already listed. > > Consider carefully the appropriate bug database to use. Firstly, can you > determine or estimate[1] > (for example by running the software on a Sun JDK) if it is a bug in the Java > software > you are using, or it is a bug in gcj/gij/libgcj? If the former, consider if > it might be > appropriate to report the bug to that project itself, rather than reporting > it on the Fedora bug database. > If the latter, it is appropriate to post the bug to the fedora bugzilla > (either under the specific package, > or under "gcc" if you can identify a specific compiler or interpreter bug). > gcc also has its own bug database > at gcc.gnu.org, but Fedora gcc is hardly modified from mainline gcc in terms > of the Java stuff, and > many of the same people read both databases, so it's not the end of the world > if (improbably) you post > a Fedora-specific bug to the gcc database by mistake. Thanks. :) > > How do I create a Java project in Eclipse on Fedora? > > Easy. Just start eclipse by typing "eclipse" (that was hard, wasn't it!) (You > can specify a particular virtual > machine to use by typing eclipse -vm /usr/lib/jvm/jre-gcj/bin/java .) Then go > to the File menu and choose > New -> Project. Type your project name, choose the options, and click Next > (for more options) or Finish. > Notice that you can import existing source code at this point. > > Eclipse may now ask you whether you want to switch to the Java Perspective. > If so, say Yes! > > Then create a New Class. If you're starting from nothing, you probably want > to ask eclipse to create a > "public static void main (String args [])" method for you at this point > (Eclipse is really good at > taking of drudgery like that). Now you can go ahead are start typing! > > If you develop GUIs and you prefer working in a more visual style, see above > for details about Eclipse's > VE plugin. > > Some quick tips: You can configure project-specific preferences (like which > JDK to use, code style conventions, > warnings to supress, etc.) by right-clicking on the project in the project > browser on the left and choosing > Properties. You can navigate to the declarations of fields or methods in your > code by highlighting them > and pressing F2, or by using the code structure browser on the right. > When you get a compiler error, highlight the code that Eclipse is complaining > about and press CTRL+1 - eclipse > will usually be able to offer you some "quick fix" suggestions as to how to > fix it - and it will not only > suggest them but actually implement them for you. Very handy! > > When you're comfortable with the basics of Eclipse, try right-clicking on > code or variables and exploring > the many refactoring options that are on offer. Refactoring is essentially > like the Quick Fix system, but > user-initiated. > > Caveats: Unfortunately, a couple of things do not work well when running > eclipse on libgcj on Fedora Core 4. > Firstly, some users have reported hangs with large CVS checkouts (although > this may only apply to > bleeding-edge releases from the Fedora Development package repository). > Secondly, debugging doesn't > work at all with a libgcj virtual machine, because it's not implemented in > libgcj yet - although work on > that is underway. Thank you! Had no idea about that debugging caveat! You know though, reading your short howto reminds me how many other good ones are already out there for Eclipse (not to mention the Eclipse docs, which seem fairly complete). I think I'm going to opt for brevity, and simply try and point out the Fedora-specific Eclipse tips you'll need to know to get started quickly. > > How do I use Tomcat? > > Very briefly: "service tomcat4 start" or "service tomcat5 start" will start > tomcat. > (Can you guess how to stop it?) Then use "rpm -ql tomcat5|less" to explore > the directory structure of Tomcat > on Fedora. The main thing you need to know is that you put your webapps under > /var/lib/tomcat{4,5}/webapps. I'm working through that at the moment (though rapidly running out of time tonight), and your tips should come in helpful. :) Hmm... perhaps my tomcat is configured incorrectly, because I don't have a /var/lib/tomcat5 directory... I *do* have a /usr/share/eclipse/plugins/org.eclipse.tomcat_4.1.30.1/webapps though... Thanks again, ---J ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From tromey at redhat.com Wed Jul 27 02:55:16 2005 From: tromey at redhat.com (Tom Tromey) Date: 26 Jul 2005 20:55:16 -0600 Subject: [fedora-java] Which JVM is faster In-Reply-To: <42E6AF4A.1050101@antunes.eti.br> References: <42E6AF4A.1050101@antunes.eti.br> Message-ID: >>>>> "C" == C F Scheidecker Antunes writes: C> Is there any benchmark comparison between JVMs? Here's one: http://www.shudo.net/jit/perf/ C> I wonder if the one that comes with FC4 is as fast or faster and if it C> is 100% compatible with all java apps. C> Any thoughts on that? No free VM is 100% compatible, as the class libraries are not yet finished. gcj code is sometimes faster than the proprietary JITs, though lately we have been falling behind, I think. Also we pay a price for the BC ABI. Tom From tromey at redhat.com Wed Jul 27 02:57:45 2005 From: tromey at redhat.com (Tom Tromey) Date: 26 Jul 2005 20:57:45 -0600 Subject: [fedora-java] Re: Which JVM is faster In-Reply-To: References: <42E6AF4A.1050101@antunes.eti.br> Message-ID: >>>>> "Robin" == Robin Green writes: Robin> There are a range of other options for "free java" virtual Robin> machines (however, they are all incomplete). Cacao looks Robin> promising but it's still a bit flaky. Not ready for production Robin> use yet. My personal favorite of the non-gcj VMs is JikesRVM. It is quite promising. The factors I look at when evaluating the free VMs: * Performance * Platform coverage * Debuggability gcj scores well enough on all of these; and more importantly, in my opinion, the other free VMs fall short on one of them. Tom From overholt at redhat.com Wed Jul 27 03:36:42 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 26 Jul 2005 23:36:42 -0400 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: References: <42E68470.8090405@antunes.eti.br> Message-ID: <20050727033642.GA19567@redhat.com> * Robin Green [2005-07-26 15:59]: > > As for non-free not being easy, there are now -compat packages so it's as > easy as installing the Sun JDK RPM and then installing the -compat RPM > from jpackage.org. No rpm building needed any more! Sun's RPM is explicitly NOT recommended. See the FC4 release notes and many discussions on fedora-list. Unfortunately, RPM building _is_ necessary now. There have been many sets of instructions posted that show how to do it very easily. Andrew From overholt at redhat.com Wed Jul 27 03:47:54 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 26 Jul 2005 23:47:54 -0400 Subject: [fedora-java] Re: Java on Fedora faq In-Reply-To: References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> Message-ID: <20050727034754.GB19567@redhat.com> * Robin Green [2005-07-26 18:11]: > >Sun's Java and GNU Java should be able to coexist on the same system, but > >I wouldn't know how to get that configuration working. > > Sun's Java and GCJ are, of course, able to coexist on the same system. Follow > this simple five step guide to get the recommend setup: > > 1. Download a Sun JDK (not a JRE!) from > http://java.sun.com/j2se/1.5.0/download.jsp - and make sure you choose the > "Linux RPM in self-extracting file" option. Sorry to sound like a jerk pointing this out again, but the Sun RPMs are *NOT* recommended as they can be removed with an update to our stuff (I believe it's a problem with xml Provides but I can't recall at the moment). > Eclipse has a visual editor component like other IDEs, called VE (Visual > Editor), but it isn't shipped in Fedora yet. You can download it from > eclipse.org and unzip it (as root) into /usr/share/eclipse - the eclipse > updating mechanism doesn't work, so it's best to install it manually like I installed VE yesterday using our RPMs and the update manager. I had to install some extra packages (ie. eveything up to and including eclipse-pde-devel .. yum will bring in everything if you specify that ... hmm, maybe not eclipse-rcp-devel?) but once I had them installed, I got no errors (I think it will work even if you get "missing .../feature.xml" errors). Now, as for actually *using* VE ... well, it didn't work :) There seemed to be some issue with it spawning another VM. If someone wants to take charge and become the Fedora VE person, I'll do my best to help them. > Consider carefully the appropriate bug database to use. Firstly, can you > [...] This information would be great to have here: http://fedoraproject.org/wiki/BugsReports > > How do I create a Java project in Eclipse on Fedora? > > Easy. [...] Great write-up, Robin! Can you please add some of your comments and such to the Fedora wiki Java and/or Eclipse pages (I have the URL as the topic for #fedora-java)? > > How do I use Tomcat? > > Very briefly: "service tomcat4 start" or "service tomcat5 start" will > start tomcat. (Can you guess how to stop it?) Then use "rpm -ql > tomcat5|less" to explore the directory structure of Tomcat on Fedora. The > main thing you need to know is that you put your webapps under > /var/lib/tomcat{4,5}/webapps. Take a look at the various tomcat5 sub-packages as well (tomcat5-webapps-admin, I believe, is one of them). Often times people will have Tomcat installed and working fine but not see anything on localhost:8080 (or wherever) because they don't have the admin webapp installed. Andrew From overholt at redhat.com Wed Jul 27 03:57:49 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 26 Jul 2005 23:57:49 -0400 Subject: [fedora-java] Java on Fedora faq In-Reply-To: <20050726154044.GA16297@redhat.com> References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> <1122391980.8456.27.camel@localhost> <20050726154044.GA16297@redhat.com> Message-ID: <20050727035749.GC19567@redhat.com> * Andrew Overholt [2005-07-26 11:41]: > * Ziga Mahkovec [2005-07-26 11:33]: > > > What other Java software comes with Fedora? > > > There's the Java packages in the Fedora Extras project (aka "FE"). > > > > I don't think there are any Java packages in FE. > > Nope, but hopefully soon we'll have RSSOwl! :) I may have spoken too soon! http://article.gmane.org/gmane.linux.redhat.fedora.extras.general/6743 It'd be great if people could try this out and see if they find any problems. My build is still going but it looks good so far. Please let Jochen know if you find anything so hopefully we can get this is soon! Andrew From overholt at redhat.com Wed Jul 27 04:24:55 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 27 Jul 2005 00:24:55 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <42E69718.4060209@rssowl.org> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <42E56F2B.4030002@rssowl.org> <20050726154245.GB16297@redhat.com> <42E69718.4060209@rssowl.org> Message-ID: <20050727042455.GH19567@redhat.com> * Benjamin Pasero [2005-07-26 15:04]: > > I see. Unfortunately I will not be able to remove the dependency from JFace > as well as I did with forms. It is too heavily used in all the Dialogs. That's okay. I think for now I'm okay with having the runtime requirement on eclipse-platform. The sooner we get this out, the better IMHO. Left to do: 1) get necessary packages either created with JPackage and/or imported (preferably with aot-compile-rpm) into FE, 2) get RSSOwl built into FE and test. Andrew From overholt at redhat.com Wed Jul 27 04:41:08 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 27 Jul 2005 00:41:08 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050726075151.7ni993rsgs0084ko@www.zarb.org> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> Message-ID: <20050727044108.GA24725@redhat.com> * David Walluck [2005-07-26 07:52]: > > Both blowfish-j and itext are already in JPackage. However, they are > outdated, 2.12 -> 2.14 and 1.02b -> 1.3, respectively. So, JPackage has > probably done most of the work already, but it would be nice to get the > packages brought up to date in the process. So once these are updated, we just need to get them into FE. Has anyone gone through the FE application process yet? I've been meaning to get around to it ... > As for swt-nl.jar, I know green posted a message to jpackage-discuss > [...] > but I don't know what it is part of (if it is not part of the swt build > already). I don't think it's part of the SWT build. I don't see the files in a build tree, either. Ben, is this necessary? I'm considering including it as a Source file in the SWT RPM - David, what do you think? Andrew From overholt at redhat.com Wed Jul 27 04:42:20 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 27 Jul 2005 00:42:20 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050726075151.7ni993rsgs0084ko@www.zarb.org> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> Message-ID: <20050727044220.GB24725@redhat.com> * David Walluck [2005-07-26 07:52]: > As for swt-nl.jar, I know green posted a message to jpackage-discuss I meant to post the contents and size: $ ls -lh swt-nl.jar -rw-rw-r-- 1 andrew andrew 9.7K Jul 27 00:32 swt-nl.jar $ unzip -l swt-nl.jar Archive: swt-nl.jar Length Date Time Name -------- ---- ---- ---- 1610 08-16-04 14:46 org/eclipse/swt/internal/SWTMessages_de.properties 1582 08-16-04 14:46 org/eclipse/swt/internal/SWTMessages_es.properties 1543 08-16-04 14:46 org/eclipse/swt/internal/SWTMessages_fr.properties 1556 08-16-04 14:46 org/eclipse/swt/internal/SWTMessages_it.properties 2424 08-16-04 14:46 org/eclipse/swt/internal/SWTMessages_ja.properties 2025 08-16-04 14:46 org/eclipse/swt/internal/SWTMessages_ko.properties 1580 08-16-04 14:46 org/eclipse/swt/internal/SWTMessages_pt_BR.properties 1907 08-16-04 14:46 org/eclipse/swt/internal/SWTMessages_zh_CN.properties 1953 08-16-04 14:46 org/eclipse/swt/internal/SWTMessages_zh_TW.properties 1944 08-16-04 14:46 about.html 0 11-26-04 09:14 org/eclipse/ 0 11-26-04 09:14 org/eclipse/swt/ 0 11-30-04 08:25 org/eclipse/swt/internal/ 0 11-26-04 09:14 org/ -------- ------- 18124 14 files Andrew From vektor at dumbterm.net Wed Jul 27 04:51:12 2005 From: vektor at dumbterm.net (Billy Biggs) Date: Tue, 26 Jul 2005 23:51:12 -0500 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050727044108.GA24725@redhat.com> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> <20050727044108.GA24725@redhat.com> Message-ID: <20050727045112.GE13267@dumbterm.net> Andrew Overholt (overholt at redhat.com): > > As for swt-nl.jar, I know green posted a message to jpackage-discuss > > [...] > > but I don't know what it is part of (if it is not part of the swt > > build already). > > I don't think it's part of the SWT build. I don't see the files in a > build tree, either. Ben, is this necessary? I'm considering > including it as a Source file in the SWT RPM - David, what do you > think? It's a set of translations that were contributed to eclipse from IBM. We provide them off of the SWT homepage (www.eclipse.org/swt/). Including it as a source file in the SWT RPM seems reasonable IMHO. -Billy From gbenson at redhat.com Wed Jul 27 08:48:03 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 27 Jul 2005 09:48:03 +0100 Subject: [fedora-java] Re: Re: jpackage.org and FC4 In-Reply-To: References: <20050725024234.65987.qmail@web80902.mail.scd.yahoo.com> <20050725124826.GB7565@redhat.com> <20050726132450.GB6645@redhat.com> <45493.192.54.193.37.1122393264.squirrel@rousalka.dyndns.org> Message-ID: <20050727084801.GB4887@redhat.com> Robin Green wrote: > On Tue, 26 Jul 2005 17:54:24 +0200, Nicolas Mailhot wrote: > > > So I can install Sun's JDK via JPackage, develop a web > > > application, and be sure that it will run on Fedora's Tomcat? > > > > So you can develop and package an app, and (provided you've > > followed the rules) people can change the implementation of your > > all your app dependencies without needing to change your package. > > Actually, no. Fedora's tomcat packages contain a native and a > non-native version. The native version only works with libgcj, which > is not 100% compatible with Sun's Java. That's an important caveat, > I think. That's not true at all. All Java packages in Fedora should behave the same whatever JVM you're using. If they don't then you've found a bug that needs fixing. Cheers, Gary From gbenson at redhat.com Wed Jul 27 09:11:44 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 27 Jul 2005 10:11:44 +0100 Subject: [fedora-java] Re: Java on Fedora faq In-Reply-To: References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> Message-ID: <20050727091142.GD4887@redhat.com> Robin Green wrote: > On Tue, 26 Jul 2005 08:02:12 -0700, John M. Gabriele wrote: > > How do I use Tomcat? > > Very briefly: "service tomcat4 start" or "service tomcat5 start" > will start tomcat. Not "service tomcat4 start" -- we only ship tomcat5. > [Footnote 1] - I found a bug in AspectJ yesterday which only > appeared under libgcj, but *wasn't* a libgcj bug. It was a latent > bug in AspectJ that was only exposed by a slightly different, but > still valid, collection class implementation in libgcj. So it's not > logically valid to assume that a bug that only occurs on libgcj is > necessarily a bug *in* libgcj. This kind of thing happens all the time. The Java specification can be quite loose, and often things will because applications rely on unspecified defaults or behaviours that libgcj's (correct, as per the spec) implementation does not provide. Cheers, Gary From greenrd at presidium.org Wed Jul 27 09:44:30 2005 From: greenrd at presidium.org (Robin Green) Date: Wed, 27 Jul 2005 10:44:30 +0100 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java References: <42E68470.8090405@antunes.eti.br> Message-ID: On Tue, 26 Jul 2005 21:24:26 -0500, Ian Pilcher wrote: > Robin Green wrote: >> HOWEVER, THIS WILL REMOVE OPEN OFFICE, ECLIPSE, AND ALL JAVA PACKAGES >> - because yum remove is dumb and doesn't know about alternative JDK >> packages. Don't say I didn't warn you! > > Will Fedora's OpenOffice work with other JVM's? Yes. In fact, it will work better with a Sun JVM. The Java code in OpenOffice.org was originally written with a Sun JVM in mind, and work needs to be done to bring OO.o and libgcj into full compatibility (last I heard). -- Robin From mark at klomp.org Wed Jul 27 10:48:24 2005 From: mark at klomp.org (Mark Wielaard) Date: Wed, 27 Jul 2005 12:48:24 +0200 Subject: [fedora-java] Re: Java on Fedora faq In-Reply-To: <20050727091142.GD4887@redhat.com> References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> <20050727091142.GD4887@redhat.com> Message-ID: <1122461304.9474.10.camel@localhost.localdomain> On Wed, 2005-07-27 at 10:11 +0100, Gary Benson wrote: > Robin Green wrote: > > [Footnote 1] - I found a bug in AspectJ yesterday which only > > appeared under libgcj, but *wasn't* a libgcj bug. It was a latent > > bug in AspectJ that was only exposed by a slightly different, but > > still valid, collection class implementation in libgcj. So it's not > > logically valid to assume that a bug that only occurs on libgcj is > > necessarily a bug *in* libgcj. > > This kind of thing happens all the time. The Java specification can > be quite loose, and often things will because applications rely on > unspecified defaults or behaviours that libgcj's (correct, as per the > spec) implementation does not provide. One thing that is nice is that our collection classes seem more strict on concurrent modifications. I have found a couple of programs that modified list collections while simultaneously iterating over them. The result of that isn't deterministic, but other implementations just allow it since they don't have to throw a ConcurrentModificationException, but we always detect this situation and do throw the exception. Not that we don't have our own bugs or do things wrong in some other direction. But in a couple of places our strict reading and checking for method pre-conditions does help find (latent) bugs in programs. Cheers, Mark BTW. If something doesn't seem to work/compile with the free tool set, because it depends on com.sun.* classes please take a look at the following wiki page for some pointers: http://developer.classpath.org/mediation/ClasspathMigration (Updates welcome of course!) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From i.pilcher at comcast.net Wed Jul 27 12:41:55 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 27 Jul 2005 07:41:55 -0500 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: References: <42E68470.8090405@antunes.eti.br> Message-ID: Robin Green wrote: > On Tue, 26 Jul 2005 21:24:26 -0500, Ian Pilcher wrote: > >>Will Fedora's OpenOffice work with other JVM's? > > Yes. In fact, it will work better with a Sun JVM. The Java code in > OpenOffice.org was originally written with a Sun JVM in mind, and work > needs to be done to bring OO.o and libgcj into full compatibility (last I > heard). > If that's the case, openoffice.org-core shouldn't specifically require libgcj, which it currently does. It should require something more general, such as: Requires: java >= 1.4.2 which is provided by java-1.4.2-gcj-compat. And it should conflict with non-Sun JVMs: Conflicts: java-kaffe, java-ibm, java-bea, java-blackdown (java-1.5.0-sun provides java-sun; I'm assuming that the other JVM RPMs on JPackage have similar provides.) Let me know if this is correct. If it is, I'll bugzilla it. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From gbenson at redhat.com Wed Jul 27 12:50:52 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 27 Jul 2005 13:50:52 +0100 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: References: <42E68470.8090405@antunes.eti.br> Message-ID: <20050727125051.GC20610@redhat.com> Ian Pilcher wrote: > If that's the case, openoffice.org-core shouldn't specifically > require libgcj, which it currently does. > > It should require something more general, such as: > > Requires: java >= 1.4.2 > > which is provided by java-1.4.2-gcj-compat. > > And it should conflict with non-Sun JVMs: > > Conflicts: java-kaffe, java-ibm, java-bea, java-blackdown Please don't add conflicts to packages. Cheers, Gary From david at zarb.org Wed Jul 27 12:59:46 2005 From: david at zarb.org (David Walluck) Date: Wed, 27 Jul 2005 08:59:46 -0400 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: <20050727033642.GA19567@redhat.com> References: <42E68470.8090405@antunes.eti.br> <20050727033642.GA19567@redhat.com> Message-ID: <20050727085946.ga0dl0ng0o8k4sc4@www.zarb.org> Andrew Overholt wrote: > Sun's RPM is explicitly NOT recommended. See the FC4 release notes and I went and read the release notes: `` Fedora Core 4 users are advised not to use the Java RPM provided by Sun. It contains Provides that conflict with names used in packages provided as part of Fedora Core 4. Because of this, Sun Java might disappear from an installed system during package upgrade operations.'' But this shouldn't be the case unless something is different from jpackage.org, where this package is expected to be able to be parallel installed along with other sdk's. Just because two packages provide the same thing, the other should not disappear. What exactly is the problem (is it specific to yum)? -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aph at redhat.com Wed Jul 27 13:08:18 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jul 2005 14:08:18 +0100 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: References: <42E68470.8090405@antunes.eti.br> Message-ID: <17127.34626.805362.430044@zapata.pink> Ian Pilcher writes: > Robin Green wrote: > > On Tue, 26 Jul 2005 21:24:26 -0500, Ian Pilcher wrote: > > > >>Will Fedora's OpenOffice work with other JVM's? > > > > Yes. In fact, it will work better with a Sun JVM. The Java code in > > OpenOffice.org was originally written with a Sun JVM in mind, and work > > needs to be done to bring OO.o and libgcj into full compatibility (last I > > heard). > > If that's the case, openoffice.org-core shouldn't specifically require > libgcj, which it currently does. > > It should require something more general, such as: > > Requires: java >= 1.4.2 > > which is provided by java-1.4.2-gcj-compat. > > And it should conflict with non-Sun JVMs: > > Conflicts: java-kaffe, java-ibm, java-bea, java-blackdown There's no need for conflicts because of the alternatives machanism: the JVMs quite happily co-exist. Andrew. From david at zarb.org Wed Jul 27 13:08:01 2005 From: david at zarb.org (David Walluck) Date: Wed, 27 Jul 2005 09:08:01 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050727042455.GH19567@redhat.com> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <42E56F2B.4030002@rssowl.org> <20050726154245.GB16297@redhat.com> <42E69718.4060209@rssowl.org> <20050727042455.GH19567@redhat.com> Message-ID: <20050727090801.ivlmpfbhcgg80wsk@www.zarb.org> Andrew Overholt wrote: > do: 1) get necessary packages either created with JPackage and/or imported > (preferably with aot-compile-rpm) into FE, 2) get RSSOwl built into FE and > test. Of course we would like to see the packages at jpackage.org, too, but I understand that FC wants some added value. The problem is also that jpackage.org has no strategy (and no strategy has been proposed) for binary packages. This means that while jpackage.org was once a nice place to get Java packages for any RPM distro, now the work needs to be duplicated---not only duplicated for every distro, but at jpackage.org as well. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From david at zarb.org Wed Jul 27 13:08:32 2005 From: david at zarb.org (David Walluck) Date: Wed, 27 Jul 2005 09:08:32 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050727044108.GA24725@redhat.com> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> <20050727044108.GA24725@redhat.com> Message-ID: <20050727090832.8euhw7mpfwo484ks@www.zarb.org> Andrew Overholt wrote: > I don't think it's part of the SWT build. I don't see the files in a > build tree, either. Ben, is this necessary? I'm considering including it > as a Source file in the SWT RPM - David, what do you think? My objection is philosopical: I am always wary about shipping a binary jar that was most likely built on the non-free Sun JVM. On a more practical note, we need to find the upstream sources anyway. Can the jar be reconstructed from CVS? I am definitely for shipping these sources with eclipse/swt so that we can provide swt-nl.jar. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aph at redhat.com Wed Jul 27 13:10:04 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jul 2005 14:10:04 +0100 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: <20050727085946.ga0dl0ng0o8k4sc4@www.zarb.org> References: <42E68470.8090405@antunes.eti.br> <20050727033642.GA19567@redhat.com> <20050727085946.ga0dl0ng0o8k4sc4@www.zarb.org> Message-ID: <17127.34732.769940.60616@zapata.pink> David Walluck writes: > Andrew Overholt wrote: > > > Sun's RPM is explicitly NOT recommended. See the FC4 release notes and > > I went and read the release notes: > > `` Fedora Core 4 users are advised not to use the Java RPM provided by Sun. It > contains Provides that conflict with names used in packages provided as > part of > Fedora Core 4. Because of this, Sun Java might disappear from an installed > system during package upgrade operations.'' > > But this shouldn't be the case unless something is different from > jpackage.org, > where this package is expected to be able to be parallel installed along with > other sdk's. It is different from jpackage.org. That's why we recommend the jpackage.org RPM, not the one from Sun. Andrew. From i.pilcher at comcast.net Wed Jul 27 13:09:14 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 27 Jul 2005 08:09:14 -0500 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: <20050727125051.GC20610@redhat.com> References: <42E68470.8090405@antunes.eti.br> <20050727125051.GC20610@redhat.com> Message-ID: Gary Benson wrote: > > Please don't add conflicts to packages. > Upon reflection, I can see the problem with that. Anyone have any ideas? -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From nicolas.mailhot at laposte.net Wed Jul 27 13:16:06 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 27 Jul 2005 15:16:06 +0200 (CEST) Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: <20050727085946.ga0dl0ng0o8k4sc4@www.zarb.org> References: <42E68470.8090405@antunes.eti.br> <20050727033642.GA19567@redhat.com> <20050727085946.ga0dl0ng0o8k4sc4@www.zarb.org> Message-ID: <55295.192.54.193.37.1122470166.squirrel@rousalka.dyndns.org> On Mer 27 juillet 2005 14:59, David Walluck wrote: > > Just because two packages provide the same thing, the other should not > disappear. What exactly is the problem (is it specific to yum)? > The problem is only with the compat- package The sun rpm declares it provides xml-commons but does not put a symlink to it in the right place so all the scripts that do a build-classpath xml-commons fail when yum removes the external xml-commons during the upgrade. And anyway even if Sun rpm did put a symlink in the right place it would only work with Sun JVM. Sadly rpm limitations mean we can make sure everything works when a single JVM is installed, but any parallel JVM install will need hand-holding at some time. If we had two stacks with A, B, C, D and A', B', C', D' components with one component per package and all possible combos working all would be yummy. But what we have is A, B, CD and A'B', C', D' so things are a lot more interesting. This BTW directly stems from SUN's habit of moving API's in-jvm and generally merging components at every other release. Regards, -- Nicolas Mailhot From fernando at lozano.eti.br Wed Jul 27 13:30:08 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Wed, 27 Jul 2005 10:30:08 -0300 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050727090801.ivlmpfbhcgg80wsk@www.zarb.org> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <42E56F2B.4030002@rssowl.org> <20050726154245.GB16297@redhat.com> <42E69718.4060209@rssowl.org> <20050727042455.GH19567@redhat.com> <20050727090801.ivlmpfbhcgg80wsk@www.zarb.org> Message-ID: <42E78C60.8090604@lozano.eti.br> Hi David, > Of course we would like to see the packages at jpackage.org, too, but I > understand that FC wants some added value. The problem is also that > jpackage.org has no strategy (and no strategy has been proposed) for > binary > packages. This means that while jpackage.org was once a nice place to > get Java > packages for any RPM distro, now the work needs to be duplicated---not > only > duplicated for every distro, but at jpackage.org as well. I think JPackage guys can agree on a strategy for binary packages and all distros can be compatible with jpp packages if they want to. As far as I understand gcj on FC4 uses the gij interpreter to start Java applications, and so using Kaffe, Sun Java or any other jvm should not impact the Java app, and it used *.db files to replace the bytecodes by native code at runtime. So the inly difference are the *.so files and the corresponding *.db files. I guess it was already sugested on the list putting the native files on a separate package, and this package only is deppendent on libgcj and gij. Someone expressed concerns about users installing a Java app (say Tomcat) from it's rpm package but not the native rpm and so getting poor performance, but I think that's something users can find out on the FAQ or mailing list. For big apps (and optmizations like the use of native Java libraries) I'd like to have some kind of "meta-package" just like Familiar Linux uses. They have, for example, a language-pt package that install the keyboard layout, locale files and message files for all applications, but just for installed ones. So it's easy to add support for some language without bloating the limited flash space on a PDA with thousands of language files like desktop distros do. Instead of having to remember to install tomcat-webapps and the like, or relying on yum and up2date to find dependencies (which are not allways all I'd like to have on a default install) I'd use "rpm -i tomcat-complete" and this packages directs to install everything it needs. So FC could have meta-packages requiring both native and bytecode packages, and the bytecode packages (and even the native ones) could be jpp ones. If you ever tried to install Gnome, OpenOffice or Apache with PHP and lots of modules installed by hand, you'd love to have that meta-package concept. That's something like that Anaconda does, presenting the user categories of packages instead of individual rpm files, but more granular. []s, Fernando Lozano From fernando at lozano.eti.br Wed Jul 27 13:33:07 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Wed, 27 Jul 2005 10:33:07 -0300 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050727090832.8euhw7mpfwo484ks@www.zarb.org> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> <20050727044108.GA24725@redhat.com> <20050727090832.8euhw7mpfwo484ks@www.zarb.org> Message-ID: <42E78D13.4050407@lozano.eti.br> Hi David, [about swt-nl.jar used by RSSOwl] > My objection is philosopical: I am always wary about shipping a binary > jar that > was most likely built on the non-free Sun JVM. On a more practical > note, we > need to find the upstream sources anyway. Can the jar be reconstructed > from > CVS? I am definitely for shipping these sources with eclipse/swt so > that we can > provide swt-nl.jar. This jar package should contain no compiled code, be it bytecodes or native code. It should contain only message files and other resources like icons. So it's as good as a source tarball. []s, Fernando Lozano From david at zarb.org Wed Jul 27 13:29:49 2005 From: david at zarb.org (David Walluck) Date: Wed, 27 Jul 2005 09:29:49 -0400 Subject: [fedora-java] Re: Java on Fedora faq In-Reply-To: References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> Message-ID: <20050727092949.qotf7yhk0kw04css@www.zarb.org> Robin Green wrote: > Sun's Java and GCJ are, of course, able to coexist on the same system. Follow > this simple five step guide to get the recommend setup: You can get it down to four steps. > 2. Make the file you've just downloaded executable by typing > chmod +x [insert filename here] > > 3. Execute it by typing ./[insert filename here] This will extract and then > install the RPM for you. Here, why not run sh ./[insert filename here] as one step? -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From overholt at redhat.com Wed Jul 27 13:35:12 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 27 Jul 2005 09:35:12 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <42E78C60.8090604@lozano.eti.br> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <42E56F2B.4030002@rssowl.org> <20050726154245.GB16297@redhat.com> <42E69718.4060209@rssowl.org> <20050727042455.GH19567@redhat.com> <20050727090801.ivlmpfbhcgg80wsk@www.zarb.org> <42E78C60.8090604@lozano.eti.br> Message-ID: <20050727133512.GA1019@redhat.com> Hi Fernando, * Fernando Lozano [2005-07-27 09:26]: > > If you ever tried to install Gnome, OpenOffice or Apache with PHP and > lots of modules installed by hand, you'd love to have that meta-package > concept. That's something like that Anaconda does, presenting the user > categories of packages instead of individual rpm files, but more granular. I know this isn't exactly what you're looking for, but the groups that Anaconda presents can be used with yum as well: yum groupinstall "Gnome Desktop Environment" (I think), for example Andrew From david at zarb.org Wed Jul 27 13:52:14 2005 From: david at zarb.org (David Walluck) Date: Wed, 27 Jul 2005 09:52:14 -0400 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: <17127.34732.769940.60616@zapata.pink> References: <42E68470.8090405@antunes.eti.br> <20050727033642.GA19567@redhat.com> <20050727085946.ga0dl0ng0o8k4sc4@www.zarb.org> <17127.34732.769940.60616@zapata.pink> Message-ID: <20050727095214.av5zc4oqow08kkgo@www.zarb.org> Andrew Haley wrote: > It is different from jpackage.org. That's why we recommend the > jpackage.org RPM, not the one from Sun. I am talking about using the sun-compat rpm from jpackage.org. JPackage provides two methods (for Sun only). The first is to rebuild the JPackage provided full srpm from source. The second is to install the Sun-provided rpm *along with* the JPackage-provided sun-compat rpm. This scenario should work, as the JPackage and JPackage sun-compat rpms are supposed to provide the same infrastructure. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From david at zarb.org Wed Jul 27 14:01:34 2005 From: david at zarb.org (David Walluck) Date: Wed, 27 Jul 2005 10:01:34 -0400 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: <55295.192.54.193.37.1122470166.squirrel@rousalka.dyndns.org> References: <42E68470.8090405@antunes.eti.br> <20050727033642.GA19567@redhat.com> <20050727085946.ga0dl0ng0o8k4sc4@www.zarb.org> <55295.192.54.193.37.1122470166.squirrel@rousalka.dyndns.org> Message-ID: <20050727100134.x6yqx6f1usks0kww@www.zarb.org> Nicolas Mailhot wrote: > The problem is only with the compat- package > > The sun rpm declares it provides xml-commons but does not put a symlink to > it in the right place so all the scripts that do a > build-classpath xml-commons > fail when yum removes the external xml-commons during the upgrade. Do you mean xml-commons or xml-commons-apis? Anyway, this won't affect my answer much. This sounds like a bug in the sun-compat package. If Sun claims to provide xml-commons but doesn't actually do so, then the sun-compat package should do so by requiring xml-commons-apis, or if need be, by some sort of hack, like a file based requires on %{_javadir}/xml-commons-apis.jar. I am not sure if sun-compat should provide xml-commons or not. In JPackage, this package contains no jars anyway. This should fix the problem, if I understand correctly. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From vadimn at redhat.com Wed Jul 27 14:06:05 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Wed, 27 Jul 2005 10:06:05 -0400 Subject: [fedora-java] Which JVM is faster In-Reply-To: References: <42E6AF4A.1050101@antunes.eti.br> Message-ID: <200507271006.05128.vadimn@redhat.com> On Tuesday 26 July 2005 22:55, Tom Tromey wrote: > C> I wonder if the one that comes with FC4 ... is 100% compatible > C> with all java apps. > > No free VM is 100% compatible, as the class libraries are not yet > finished. No VM -- free or otherwise -- is 100% compatible with all java apps. (A somewhat vacuous point, but one that someone had to bring up for the sake of completeness.) From overholt at redhat.com Wed Jul 27 14:12:03 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 27 Jul 2005 10:12:03 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <42E78D13.4050407@lozano.eti.br> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> <20050727044108.GA24725@redhat.com> <20050727090832.8euhw7mpfwo484ks@www.zarb.org> <42E78D13.4050407@lozano.eti.br> Message-ID: <20050727141202.GA22441@redhat.com> * Fernando Lozano [2005-07-27 09:28]: > >Can the jar be reconstructed from CVS? I am definitely for shipping > >these sources with eclipse/swt so that we can provide swt-nl.jar. > > This jar package should contain no compiled code, be it bytecodes or > native code. It should contain only message files and other resources > like icons. So it's as good as a source tarball. Yeah, I kinda feel the same way. Billy: the .properties files themselves aren't in CVS anywhere, right? Andrew From david at zarb.org Wed Jul 27 14:14:46 2005 From: david at zarb.org (David Walluck) Date: Wed, 27 Jul 2005 10:14:46 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <42E78D13.4050407@lozano.eti.br> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> <20050727044108.GA24725@redhat.com> <20050727090832.8euhw7mpfwo484ks@www.zarb.org> <42E78D13.4050407@lozano.eti.br> Message-ID: <20050727101446.ahuyv6psm8gscs4o@www.zarb.org> Fernando Lozano wrote: > This jar package should contain no compiled code, be it bytecodes or > native code. It should contain only message files and other resources > like icons. So it's as good as a source tarball. Sort of. I am gald to see that fc now uses tomcat5 with eclipse, but previously it used tomcat4. Even though tomcat4 code is free, it could not be built with a free compiler, so no one could reproduce it. Being able to rebuild and reproduce things, including jars even when they only contain like text files, is still important from my point of view. Otherwise, you must rely on upstream to provide you with a binary jar from some unknown location (which may or may not contain binary files within it). So the issue has to do with reproducability and reliance, not what the file necessarily contains. Anyway, I am fairly confident this jar can be reconstructed out of the CVS URL I gave in a previous message. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From overholt at redhat.com Wed Jul 27 14:15:31 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 27 Jul 2005 10:15:31 -0400 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: References: <42E68470.8090405@antunes.eti.br> <20050727125051.GC20610@redhat.com> Message-ID: <20050727141530.GB22441@redhat.com> * Ian Pilcher [2005-07-27 09:11]: > Gary Benson wrote: > > > >Please don't add conflicts to packages. > > > > Upon reflection, I can see the problem with that. Anyone have any > ideas? Help make OOo and libgcj get along better? Andrew From david at zarb.org Wed Jul 27 14:28:26 2005 From: david at zarb.org (David Walluck) Date: Wed, 27 Jul 2005 10:28:26 -0400 Subject: [fedora-java] Problem compiling tomcat5-5.0.30-8jpp_1fc Message-ID: <20050727102826.8b5hsw7r5wgk0ck8@www.zarb.org> I am not able to build on a Fedora distribution right now, but I am still hoping that the gcj hackers here can help me. Ultimately, I need tomcat5 built as it is required by eclipse 3.1. I am using gcc 4.0.1 (CVS 20050606) and I am wondering if the tomcat5 build fails due to a compiler bug. I am posting as much output as I could get from ant below. Let me know if any additional information is needed. build-webapps-precompile: [mkdir] Created dir: /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30-src/jakarta-tomcat-5/build/server/webapps/admin/WEB-INF/src/admin [mkdir] Created dir: /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30-src/jakarta-tomcat-5/build/webapps/ROOT/WEB-INF/src [mkdir] Created dir: /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30-src/jakarta-tomcat-5/build/webapps/ROOT/WEB-INF/classes [mkdir] Created dir: /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30-src/jakarta-tomcat-5/build/webapps/jsp-examples/WEB-INF/src dropping /usr/lib/jvm/lib/tools.jar from path as it doesn't exist [jasper2] log4j:WARN No appenders could be found for logger (org.apache.jasper.compiler.JspRuntimeContext). [jasper2] log4j:WARN Please initialize the log4j system properly. [jasper2] java.lang.NullPointerException [jasper2] at java.lang.Object.getClass() (/usr/lib/libgcj.so.6.0.0) [jasper2] at org.apache.jasper.compiler.TagFileProcessor.loadTagFile(org.apache.jasper.compiler.Compiler, java.lang.String, javax.servlet.jsp.tagext.TagInfo, org.apache.jasper.compiler.PageInfo) (Unknown Source) [jasper2] at org.apache.jasper.compiler.TagFileProcessor.access$0(org.apache.jasper.compiler.TagFileProcessor, org.apache.jasper.compiler.Compiler, java.lang.String, javax.servlet.jsp.tagext.TagInfo, org.apache.jasper.compiler.PageInfo) (Unknown Source) [jasper2] at org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(org.apache.jasper.compiler.Node$CustomTag) (Unknown Source) [jasper2] at org.apache.jasper.compiler.Node$CustomTag.accept(org.apache.jasper.compiler.Node$Visitor) (Unknown Source) [jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(org.apache.jasper.compiler.Node$Visitor) (Unknown Source) [jasper2] at org.apache.jasper.compiler.Node$Visitor.visitBody(org.apache.jasper.compiler.Node) (Unknown Source) [jasper2] at org.apache.jasper.compiler.Node$Visitor.visit(org.apache.jasper.compiler.Node$Root) (Unknown Source) [jasper2] at org.apache.jasper.compiler.Node$Root.accept(org.apache.jasper.compiler.Node$Visitor) (Unknown Source) [jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(org.apache.jasper.compiler.Node$Visitor) (Unknown Source) [jasper2] at org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(org.apache.jasper.compiler.Compiler, org.apache.jasper.compiler.Node$Nodes) (Unknown Source) [jasper2] at org.apache.jasper.compiler.Compiler.generateJava() (Unknown Source) [jasper2] at org.apache.jasper.compiler.Compiler.compile(boolean, boolean) (Unknown Source) [jasper2] at org.apache.jasper.JspC.processFile(java.lang.String) (Unknown Source) [jasper2] at java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) (/usr/lib/libgcj.so.6.0.0) [jasper2] at org.apache.jasper.JspC.execute() (Unknown Source) [jasper2] at org.apache.tools.ant.TaskAdapter.execute() (Unknown Source) [jasper2] at org.apache.tools.ant.UnknownElement.execute() (Unknown Source) [jasper2] at org.apache.tools.ant.Task.perform() (Unknown Source) [jasper2] at org.apache.tools.ant.Target.execute() (Unknown Source) [jasper2] at org.apache.tools.ant.Target.performTasks() (Unknown Source) [jasper2] at org.apache.tools.ant.Project.executeTarget(java.lang.String) (Unknown Source) [jasper2] at org.apache.tools.ant.taskdefs.Ant.execute() (Unknown Source) [jasper2] at org.apache.tools.ant.taskdefs.CallTarget.execute() (Unknown Source) [jasper2] Error in class org.apache.jasper.JspC [antcall] Exiting /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30-src/jakarta-tomcat-5/build.xml. BUILD FAILED /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30-src/jakarta-tomcat-5/build.xml:566: The following error occurred while executing this line: /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30-src/jakarta-tomcat-5/build.xml:316: org.apache.jasper.JasperException at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(org.apache.tools.ant.BuildException, org.apache.tools.ant.Location) (Unknown Source) at org.apache.tools.ant.taskdefs.Ant.execute() (Unknown Source) at org.apache.tools.ant.taskdefs.CallTarget.execute() (Unknown Source) at org.apache.tools.ant.UnknownElement.execute() (Unknown Source) at org.apache.tools.ant.Task.perform() (Unknown Source) at org.apache.tools.ant.Target.execute() (Unknown Source) at org.apache.tools.ant.Target.performTasks() (Unknown Source) at org.apache.tools.ant.Project.executeTarget(java.lang.String) (Unknown Source) at org.apache.tools.ant.Project.executeTargets(java.util.Vector) (Unknown Source) at org.apache.tools.ant.Main.runBuild(java.lang.ClassLoader) (Unknown Source) at org.apache.tools.ant.Main.startAnt(java.lang.String[], java.util.Properties, java.lang.ClassLoader) (Unknown Source) at org.apache.tools.ant.launch.Launcher.run(java.lang.String[]) (Unknown Source) at org.apache.tools.ant.launch.Launcher.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) Caused by: /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30-src/jakarta-tomcat-5/build.xml:316: org.apache.jasper.JasperException at org.apache.tools.ant.TaskAdapter.execute() (Unknown Source) at org.apache.tools.ant.UnknownElement.execute() (Unknown Source) at org.apache.tools.ant.Task.perform() (Unknown Source) at org.apache.tools.ant.Target.execute() (Unknown Source) at org.apache.tools.ant.Target.performTasks() (Unknown Source) at org.apache.tools.ant.Project.executeTarget(java.lang.String) (Unknown Source) ...14 more Caused by: org.apache.jasper.JasperException at org.apache.jasper.JspC.processFile(java.lang.String) (Unknown Source) at org.apache.jasper.JspC.execute() (Unknown Source) at java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) (/usr/lib/libgcj.so.6.0.0) at org.apache.tools.ant.TaskAdapter.execute() (Unknown Source) ...19 more --- Nested Exception --- /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30-src/jakarta-tomcat-5/build.xml:316: org.apache.jasper.JasperException at org.apache.tools.ant.TaskAdapter.execute() (Unknown Source) at org.apache.tools.ant.UnknownElement.execute() (Unknown Source) at org.apache.tools.ant.Task.perform() (Unknown Source) at org.apache.tools.ant.Target.execute() (Unknown Source) at org.apache.tools.ant.Target.performTasks() (Unknown Source) at org.apache.tools.ant.Project.executeTarget(java.lang.String) (Unknown Source) at org.apache.tools.ant.taskdefs.Ant.execute() (Unknown Source) at org.apache.tools.ant.taskdefs.CallTarget.execute() (Unknown Source) at org.apache.tools.ant.UnknownElement.execute() (Unknown Source) at org.apache.tools.ant.Task.perform() (Unknown Source) at org.apache.tools.ant.Target.execute() (Unknown Source) at org.apache.tools.ant.Target.performTasks() (Unknown Source) at org.apache.tools.ant.Project.executeTarget(java.lang.String) (Unknown Source) at org.apache.tools.ant.Project.executeTargets(java.util.Vector) (Unknown Source) at org.apache.tools.ant.Main.runBuild(java.lang.ClassLoader) (Unknown Source) at org.apache.tools.ant.Main.startAnt(java.lang.String[], java.util.Properties, java.lang.ClassLoader) (Unknown Source) at org.apache.tools.ant.launch.Launcher.run(java.lang.String[]) (Unknown Source) at org.apache.tools.ant.launch.Launcher.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) Caused by: org.apache.jasper.JasperException at org.apache.jasper.JspC.processFile(java.lang.String) (Unknown Source) at org.apache.jasper.JspC.execute() (Unknown Source) at java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) (/usr/lib/libgcj.so.6.0.0) at org.apache.tools.ant.TaskAdapter.execute() (Unknown Source) ...19 more --- Nested Exception --- org.apache.jasper.JasperException at org.apache.jasper.JspC.processFile(java.lang.String) (Unknown Source) at org.apache.jasper.JspC.execute() (Unknown Source) at java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) (/usr/lib/libgcj.so.6.0.0) at org.apache.tools.ant.TaskAdapter.execute() (Unknown Source) at org.apache.tools.ant.UnknownElement.execute() (Unknown Source) at org.apache.tools.ant.Task.perform() (Unknown Source) at org.apache.tools.ant.Target.execute() (Unknown Source) at org.apache.tools.ant.Target.performTasks() (Unknown Source) at org.apache.tools.ant.Project.executeTarget(java.lang.String) (Unknown Source) at org.apache.tools.ant.taskdefs.Ant.execute() (Unknown Source) at org.apache.tools.ant.taskdefs.CallTarget.execute() (Unknown Source) at org.apache.tools.ant.UnknownElement.execute() (Unknown Source) at org.apache.tools.ant.Task.perform() (Unknown Source) at org.apache.tools.ant.Target.execute() (Unknown Source) at org.apache.tools.ant.Target.performTasks() (Unknown Source) at org.apache.tools.ant.Project.executeTarget(java.lang.String) (Unknown Source) at org.apache.tools.ant.Project.executeTargets(java.util.Vector) (Unknown Source) at org.apache.tools.ant.Main.runBuild(java.lang.ClassLoader) (Unknown Source) at org.apache.tools.ant.Main.startAnt(java.lang.String[], java.util.Properties, java.lang.ClassLoader) (Unknown Source) at org.apache.tools.ant.launch.Launcher.run(java.lang.String[]) (Unknown Source) at org.apache.tools.ant.launch.Launcher.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From green at redhat.com Wed Jul 27 14:54:33 2005 From: green at redhat.com (Anthony Green) Date: Wed, 27 Jul 2005 07:54:33 -0700 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: References: <42E68470.8090405@antunes.eti.br> Message-ID: <1122476073.2896.35.camel@to-dhcp6.toronto.redhat.com> On Wed, 2005-07-27 at 10:44 +0100, Robin Green wrote: > Yes. In fact, it will work better with a Sun JVM. The Java code in > OpenOffice.org was originally written with a Sun JVM in mind, and work > needs to be done to bring OO.o and libgcj into full compatibility (last I > heard). My understanding (from caolanm) is that everything we've tested with OO.o appears to work fine on FC with gcj and, for all intents and purposes, OO.o and libgcj are compatible. We have a couple of local build related patches as well as a work-around to a gcj bug (19870). The build patches have been submitted upstream (OO.o) and I believe there are partial patches for 19870 somewhere. AG From phil at mkdoc.com Wed Jul 27 15:34:33 2005 From: phil at mkdoc.com (Phil Shaw) Date: Wed, 27 Jul 2005 16:34:33 +0100 Subject: [fedora-java] Problem compiling tomcat5-5.0.30-8jpp_1fc In-Reply-To: <20050727102826.8b5hsw7r5wgk0ck8@www.zarb.org> Message-ID: <42E7B799.24224.450E0AA6@localhost> On 27 Jul 2005, at 10:28, David Walluck wrote: > I am using gcc 4.0.1 (CVS 20050606) and I am wondering if the tomcat5 > build fails due to a compiler bug. I am posting as much output as I > could get from ant below. Let me know if any additional information is > needed. Looks like you're pre-compiling the example Web applications: > build-webapps-precompile: Early on, you have this about the Sun tools.jar, which may be significant: > /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30- > src/jakarta-tomcat-5/ > build/webapps/jsp-examples/WEB-INF/src dropping > /usr/lib/jvm/lib/tools.jar from > path as it doesn't exist Here it gets sticky: > [jasper2] java.lang.NullPointerException [jasper2] at > java.lang.Object.getClass() (/usr/lib/libgcj.so.6.0.0) [jasper2] > at > org.apache.jasper.compiler.TagFileProcessor.loadTagFile(org.apache.jas > per.compiler.Compiler, java.lang.String, > javax.servlet.jsp.tagext.TagInfo, org.apache.jasper.compiler.PageInfo) > (Unknown Source) For reference, I have a stand-alone Jasper2 build target that just compiles JSP pages to validate them. The dependencies in the task definition are these for a Sun runtime: The GNU implementation of the JSTL expression language is in javax.servlet.jsp.el. This may be a problem if it has priorty over the Jakarta commons version perhaps. I have yet to upgrade to FC4, I'm lurking to glean others' experience with Tomcat installation. Hope this helps. Best regards, Phil -- MKSearch (alpha) Free, open source metadata search engine with RDF storage and query. From nicolas.mailhot at laposte.net Wed Jul 27 15:32:28 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 27 Jul 2005 17:32:28 +0200 (CEST) Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: <20050727100134.x6yqx6f1usks0kww@www.zarb.org> References: <42E68470.8090405@antunes.eti.br> <20050727033642.GA19567@redhat.com> <20050727085946.ga0dl0ng0o8k4sc4@www.zarb.org> <55295.192.54.193.37.1122470166.squirrel@rousalka.dyndns.org> <20050727100134.x6yqx6f1usks0kww@www.zarb.org> Message-ID: <35865.192.54.193.37.1122478348.squirrel@rousalka.dyndns.org> On Mer 27 juillet 2005 16:01, David Walluck wrote: > Nicolas Mailhot wrote: > >> The problem is only with the compat- package >> >> The sun rpm declares it provides xml-commons but does not put a symlink >> to >> it in the right place so all the scripts that do a >> build-classpath xml-commons >> fail when yum removes the external xml-commons during the upgrade. > > Do you mean xml-commons or xml-commons-apis? xml-commons-apis > This sounds like a bug in the sun-compat package. If Sun claims to provide > xml-commons but doesn't actually do so, problem is sun jvm provides an implementation of xml-commons-apis but - it's not exposed by a symlink (could be fixed in the compat-package) - it's an internal implementation so either you require the external xml-commons-api inconditionnaly, and people using Sun JVM have a package installed on-system they don't really need, or you don't, and if you install another jvm in parallel rpm will think xml-commons-apis is already available, except only the sun jvm can use it Regards, -- Nicolas Mailhot From vektor at dumbterm.net Wed Jul 27 15:52:06 2005 From: vektor at dumbterm.net (Billy Biggs) Date: Wed, 27 Jul 2005 10:52:06 -0500 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050727101446.ahuyv6psm8gscs4o@www.zarb.org> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> <20050727044108.GA24725@redhat.com> <20050727090832.8euhw7mpfwo484ks@www.zarb.org> <42E78D13.4050407@lozano.eti.br> <20050727101446.ahuyv6psm8gscs4o@www.zarb.org> Message-ID: <20050727155206.GA18880@dumbterm.net> David Walluck (david at zarb.org): > [...] Being able to rebuild and reproduce things, including jars even > when they only contain like text files, is still important from my > point of view. Otherwise, you must rely on upstream to provide you > with a binary jar from some unknown location (which may or may not > contain binary files within it). So the issue has to do with > reproducability and reliance, not what the file necessarily contains. A .jar isn't really any different than a .tar.gz file, both are binary blobs that contain files. This .jar is the upstream archive. It's like asking how to recreate gtk+-2.6.7.tar.gz ;) It's always important to investigate the contents of archives, but I dont think this case is really anything special beyond that. Regardless, the CVS URL you posted earlier is the CVS repository for our homepage (www.eclipse.org/swt/) so I guess that's the upstream. I think I was incorrect earlier when I said these translations were contributed by IBM, seems that they were contributed by users for the most part. -Billy From david at zarb.org Wed Jul 27 16:15:30 2005 From: david at zarb.org (David Walluck) Date: Wed, 27 Jul 2005 12:15:30 -0400 Subject: [fedora-java] Problem compiling tomcat5-5.0.30-8jpp_1fc In-Reply-To: <42E7B799.24224.450E0AA6@localhost> References: <42E7B799.24224.450E0AA6@localhost> Message-ID: <20050727121530.wy3n5jgeu8gs8co4@www.zarb.org> Phil Shaw wrote: > Early on, you have this about the Sun tools.jar, which may be > significant: > >> /home/david/rpm/BUILD/tomcat5-5.0.30/jakarta-tomcat-5.0.30- > > src/jakarta-tomcat-5/ >> build/webapps/jsp-examples/WEB-INF/src dropping > > /usr/lib/jvm/lib/tools.jar from >> path as it doesn't exist It doesn't solve the problem, but yes, it looks like a bug in build.xml. The path should be ${java.home}/lib/tools.jar, not ${java.home}/../lib/tools.jar. This looks like one for the tomcat rpm maintainer. The log4j warning can also be quelled also, but this does not appear to be the problem, either. > For reference, I have a stand-alone Jasper2 build target that just > compiles JSP pages to validate them. The dependencies in the task > definition are these for a Sun runtime: This is during the tomcat5 build, so all the jars are explicitly specified through property files, so the classes it is picking up shouldn't be an issue. I'd be happy to know if anyone has successfully gotten past this point when building the rpm, and whether any recent gcj patches may solve this issue. -- Sincerely, David Walluck ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From gbenson at redhat.com Wed Jul 27 16:16:20 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 27 Jul 2005 17:16:20 +0100 Subject: [fedora-java] Re: Java on Fedora faq In-Reply-To: <1122461304.9474.10.camel@localhost.localdomain> References: <20050726150212.77495.qmail@web80908.mail.scd.yahoo.com> <20050727091142.GD4887@redhat.com> <1122461304.9474.10.camel@localhost.localdomain> Message-ID: <20050727161618.GF20610@redhat.com> Mark Wielaard wrote: > BTW. If something doesn't seem to work/compile with the free tool > set, because it depends on com.sun.* classes please take a look at > the following wiki page for some pointers: > http://developer.classpath.org/mediation/ClasspathMigration > (Updates welcome of course!) You should point people at http://java.sun.com/products/jdk/faq/faq-sun-packages.html It's not just us GNU fascists -- Sun say the same thing! ;) From green at redhat.com Wed Jul 27 17:12:32 2005 From: green at redhat.com (Anthony Green) Date: Wed, 27 Jul 2005 10:12:32 -0700 Subject: [fedora-java] gcj and java at LinuxWorld Message-ID: <1122484352.2896.89.camel@to-dhcp6.toronto.redhat.com> Just FYI, I'll be giving an extremely short talk on java, gcj, etc as they relate to the Fedora project during the San Francisco LinuxWorld show. It will be in the Fedora booth on Wednesday the 10th at 11am. I'll hang around a little before and after just in case anybody is interested in a discussion. AG From john_sips_tea at yahoo.com Wed Jul 27 17:23:56 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Wed, 27 Jul 2005 10:23:56 -0700 (PDT) Subject: [fedora-java] gcj and java at LinuxWorld In-Reply-To: <1122484352.2896.89.camel@to-dhcp6.toronto.redhat.com> Message-ID: <20050727172356.85610.qmail@web80903.mail.scd.yahoo.com> --- Anthony Green wrote: > Just FYI, I'll be giving an extremely short talk on java, gcj, etc as > they relate to the Fedora project during the San Francisco LinuxWorld > show. It will be in the Fedora booth on Wednesday the 10th at 11am. > > I'll hang around a little before and after just in case anybody is > interested in a discussion. > > AG After you give the talk, where can we find a transcript (or an .ogg, or even a video of it if nothing else is available)? ---J ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From green at redhat.com Wed Jul 27 17:58:23 2005 From: green at redhat.com (Anthony Green) Date: Wed, 27 Jul 2005 10:58:23 -0700 Subject: [fedora-java] gcj and java at LinuxWorld In-Reply-To: <20050727172356.85610.qmail@web80903.mail.scd.yahoo.com> References: <20050727172356.85610.qmail@web80903.mail.scd.yahoo.com> Message-ID: <1122487103.2896.100.camel@to-dhcp6.toronto.redhat.com> On Wed, 2005-07-27 at 10:23 -0700, John M. Gabriele wrote: > After you give the talk, where can we find a transcript (or an .ogg, > or even a video of it if nothing else is available)? I'll post to this list if/when something becomes available. Even more interesting will be Tom Tromey's talk in Portland next week: http://conferences.oreillynet.com/cs/os2005/view/e_sess/6730 AG From tromey at redhat.com Wed Jul 27 18:16:28 2005 From: tromey at redhat.com (Tom Tromey) Date: 27 Jul 2005 12:16:28 -0600 Subject: [fedora-java] rssowl: libgcj bugs that need fixing for it to run In-Reply-To: <1120441755.3057.29.camel@localhost.localdomain> References: <1120441755.3057.29.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> The attached trick appears to work. Rather than wrap the Anthony> pthread_create symbol, we override it with our own Anthony> implementation and then use a glibc runtime linker trick to Anthony> get a pointer to the real pthread_create. This seems like a reasonable approach when libgcj is linked into the resulting executable. But how can it work if we dlopen() libgcj and then attach a previously-existing thread? I was wondering if there was some /proc-reading approach (or something like that) that we could use to find information about threads. Tom From mark at klomp.org Wed Jul 27 18:22:10 2005 From: mark at klomp.org (Mark Wielaard) Date: Wed, 27 Jul 2005 20:22:10 +0200 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050727155206.GA18880@dumbterm.net> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> <20050726075151.7ni993rsgs0084ko@www.zarb.org> <20050727044108.GA24725@redhat.com> <20050727090832.8euhw7mpfwo484ks@www.zarb.org> <42E78D13.4050407@lozano.eti.br> <20050727101446.ahuyv6psm8gscs4o@www.zarb.org> <20050727155206.GA18880@dumbterm.net> Message-ID: <1122488530.21950.22.camel@localhost.localdomain> On Wed, 2005-07-27 at 10:52 -0500, Billy Biggs wrote: > A .jar isn't really any different than a .tar.gz file, both are binary > blobs that contain files. This .jar is the upstream archive. It's like > asking how to recreate gtk+-2.6.7.tar.gz ;) tar zxf gtk+-2.6.7.tar.gz; cd gtk+-2.6.7; ./configure; make; make dist -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From i.pilcher at comcast.net Wed Jul 27 18:55:21 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 27 Jul 2005 13:55:21 -0500 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java In-Reply-To: <17127.34626.805362.430044@zapata.pink> References: <42E68470.8090405@antunes.eti.br> <17127.34626.805362.430044@zapata.pink> Message-ID: Andrew Haley wrote: > There's no need for conflicts because of the alternatives machanism: > the JVMs quite happily co-exist. The problem (as I understand it) is that OpenOffice.org (as shipped with Fedora Core) requires *either* libgcj or a Sun JVM; other JVMs won't work. RPM doesn't really provide a mechanism for this. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From mark at klomp.org Wed Jul 27 19:51:33 2005 From: mark at klomp.org (Mark Wielaard) Date: Wed, 27 Jul 2005 21:51:33 +0200 Subject: [fedora-java] gcj and java at LinuxWorld In-Reply-To: <20050727172356.85610.qmail@web80903.mail.scd.yahoo.com> References: <20050727172356.85610.qmail@web80903.mail.scd.yahoo.com> Message-ID: <1122493893.21950.32.camel@localhost.localdomain> On Wed, 2005-07-27 at 10:23 -0700, John M. Gabriele wrote: > --- Anthony Green wrote: > > > Just FYI, I'll be giving an extremely short talk on java, gcj, etc as > > they relate to the Fedora project during the San Francisco LinuxWorld > > show. It will be in the Fedora booth on Wednesday the 10th at 11am. > > After you give the talk, where can we find a transcript BTW. I have been collecting presentations around GNU Classpath at: http://www.gnu.org/software/classpath/events/events.html Actually the page hasn't been automatically update yet (should be in about 2 hours). So here is the list of some recent presentations: The Eclipse IDE and you Ben Konrath and Andrew Overholt http://overholt.ca/eclipse/GUADEC2005-EclipseIDE.pdf Encontro Javali: Escape the Java Trap: GNU Classpath and Kaffe Dalibor Topic and Mark Wielaard http://www.klomp.org/mark/classpath/GNUClasspathKaffe/ GNU Classpath Robert Schuster (in German) http://www.inf.fu-berlin.de/%7Erschuste/GNUClasspath-LinuxTag2005-English.pdf GCJ and Classpath: A Free Implementation of the Java programming language Andrew Haley (in English) http://people.redhat.com/~aph/linuxtag.tar.gz Some other things that might also be of interest when preparing a talk since they contain fun pictures of the progress we are making: Respect your packager: http://gnu.wildebeest.org/diary/index.php?p=97 Robert Schuster's paper (in German): http://page.mi.fu-berlin.de/%7Erschuste/GNUClasspath-LinuxTag2005-Paper.sxw Fun stuff (including real working swing programs): http://www.complang.tuwien.ac.at/cacaojvm/screenshots.html Stats: http://object-refinery.com/classpath/statcvs/ http://object-refinery.com/classpath/mauve/statcvs/ Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From greenrd at presidium.org Thu Jul 28 01:51:51 2005 From: greenrd at presidium.org (Robin Green) Date: Thu, 28 Jul 2005 02:51:51 +0100 Subject: [fedora-java] Re: Replacing FC4 Free Java with SUN's Java References: <42E68470.8090405@antunes.eti.br> <17127.34626.805362.430044@zapata.pink> Message-ID: On Wed, 27 Jul 2005 13:55:21 -0500, Ian Pilcher wrote: > Andrew Haley wrote: >> There's no need for conflicts because of the alternatives machanism: >> the JVMs quite happily co-exist. > > The problem (as I understand it) is that OpenOffice.org (as shipped with > Fedora Core) requires *either* libgcj or a Sun JVM; other JVMs won't > work. Not so. I think you have read more into my post than was actually there. Other JVMs should work, if libgcj works. -- Robin From john_sips_tea at yahoo.com Thu Jul 28 02:06:24 2005 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Wed, 27 Jul 2005 19:06:24 -0700 (PDT) Subject: [fedora-java] gcj and java at LinuxWorld In-Reply-To: <1122493893.21950.32.camel@localhost.localdomain> Message-ID: <20050728020624.37295.qmail@web80909.mail.scd.yahoo.com> --- Mark Wielaard wrote: > On Wed, 2005-07-27 at 10:23 -0700, John M. Gabriele wrote: > > --- Anthony Green wrote: > > > > > Just FYI, I'll be giving an extremely short talk on java, gcj, etc as > > > they relate to the Fedora project during the San Francisco LinuxWorld > > > show. It will be in the Fedora booth on Wednesday the 10th at 11am. > > > > After you give the talk, where can we find a transcript > > BTW. I have been collecting presentations around GNU Classpath at: > http://www.gnu.org/software/classpath/events/events.html > > [snip] > > Cheers, > > Mark > I can't believe you forgot this one: http://madbean.com/anim/totallygridbag/ ---J ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From overholt at redhat.com Thu Jul 28 13:54:40 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 28 Jul 2005 09:54:40 -0400 Subject: [fedora-java] Re: Odd ClassNotFoundException with RSSOwl In-Reply-To: <20050725213927.GC8095@redhat.com> References: <20050722152433.GA7416@redhat.com> <42E55224.8010209@rssowl.org> <20050725213927.GC8095@redhat.com> Message-ID: <20050728135440.GB18665@redhat.com> Hi, I updated things a bit to make the internal browser work (courtesy Robin Green in /usr/bin/eclipse) and fixed a subsequent error in the launching script. I've put my latest stuff here: http://www.overholt.ca/rssowl/ Again, the specfile lists things that we need to do. If anyone wants to help, it'd be greatly appreciated. Thanks, Andrew From green at redhat.com Thu Jul 28 14:47:10 2005 From: green at redhat.com (Anthony Green) Date: Thu, 28 Jul 2005 07:47:10 -0700 Subject: [fedora-java] rssowl: libgcj bugs that need fixing for it to run In-Reply-To: References: <1120441755.3057.29.camel@localhost.localdomain> Message-ID: <1122562031.2949.30.camel@to-dhcp6.toronto.redhat.com> On Wed, 2005-07-27 at 12:16 -0600, Tom Tromey wrote: > This seems like a reasonable approach when libgcj is linked into the > resulting executable. But how can it work if we dlopen() libgcj and > then attach a previously-existing thread? It can't; this only solves the problem reported. We could force tricky programmers to do thread registrations themselves. The PyLucene people probably solved this in some way. > I was wondering if there was some /proc-reading approach (or something > like that) that we could use to find information about threads. Well, I'm guessing that the "[stack]" line /proc//task//maps describes the extent of each stack. Is this an interface we can depend on over all Linux implementations? (isn't /proc optional during kernel configuration?) AG From hans.boehm at hp.com Thu Jul 28 18:34:36 2005 From: hans.boehm at hp.com (Boehm, Hans) Date: Thu, 28 Jul 2005 11:34:36 -0700 Subject: [fedora-java] rssowl: libgcj bugs that need fixing for it torun Message-ID: <65953E8166311641A685BDF71D8658262B70CB@cacexc12.americas.cpqcorp.net> [I missed the beginning of this thread initially.] I'm actually trying to work on some of these issues. Some status: 1) I'm currently hacking on the /proc/self/maps reading code that's already in the GC. The current code actually broke with a kernel change in August 2003 which changed the file format on 64-bit architectures. Unfortunately it didn't break blatantly enough for anyone to notice until now. I have a patch that should probably be integrated into gcj, but it needs a bit more mileage on it. 2) Reading /proc/self/maps reliably in a multithreaded environment seems hard. I'm still trying to understand this better, but there seems to be a design flaw here. Reads can return short, meaning that you don't necessarily get a consistent picture. And AFAICT, both nptl and linuxthreads unmap thread stacks after the thread becomes invisible to the user, so there is no way you can deal with this by user level synchronization. The mappings can change even if all threads that haven't exited are stopped. I currently believe that /proc/self/maps can only shrink asynchronously, so it might be possible to address this by reading it twice. 3) I have code in my gc7 tree to intercept pthread_create as suggested here. My immediate goal is to make it possible to use the gc as a preloadable malloc replacement, even in the multithreaded case. (This seems to require /proc/self/maps, since the dynamic loader seems to have its own malloc, and the objects it allocates point to objects allocated with the later malloc.) I think this is getting close to working, but I'm not quite there. 4) Gc7 (even the released, but very experimental alpha3 version) has a thread registration interface. That's probably a better solution for some of the problems here. (The implementation behind this interface is currently severely lacking in places. But at least there's an interface.) 5) My general plan is to get gc7 slightly more stable, and then set up CVS access to it. Hans > -----Original Message----- > From: Anthony Green [mailto:green at redhat.com] > Sent: Thursday, July 28, 2005 7:47 AM > To: tromey at redhat.com > Cc: Boehm, Hans; Discussion list for java related Fedora development > Subject: Re: [fedora-java] rssowl: libgcj bugs that need > fixing for it torun > > > On Wed, 2005-07-27 at 12:16 -0600, Tom Tromey wrote: > > This seems like a reasonable approach when libgcj is linked > into the > > resulting executable. But how can it work if we dlopen() > libgcj and > > then attach a previously-existing thread? > > It can't; this only solves the problem reported. We could > force tricky programmers to do thread registrations > themselves. The PyLucene people probably solved this in some way. > > > I was wondering if there was some /proc-reading approach > (or something > > like that) that we could use to find information about threads. > > Well, I'm guessing that the "[stack]" line > /proc//task//maps describes the extent of each > stack. Is this an interface we can depend on over all Linux > implementations? (isn't /proc optional during kernel > configuration?) > > AG > > > From green at redhat.com Thu Jul 28 20:06:53 2005 From: green at redhat.com (Anthony Green) Date: Thu, 28 Jul 2005 13:06:53 -0700 Subject: [fedora-java] rssowl: libgcj bugs that need fixing for it torun In-Reply-To: <65953E8166311641A685BDF71D8658262B70CB@cacexc12.americas.cpqcorp.net> References: <65953E8166311641A685BDF71D8658262B70CB@cacexc12.americas.cpqcorp.net> Message-ID: <1122581214.2949.91.camel@to-dhcp6.toronto.redhat.com> On Thu, 2005-07-28 at 11:34 -0700, Boehm, Hans wrote: > [I missed the beginning of this thread initially.] > > I'm actually trying to work on some of these issues. Some status: Cool. Robin - is there a local hack/patch we can apply to swt and/or rssowl to work around this problem until a real fix from Hans migrates into GCC? AG From greenrd at greenrd.org Thu Jul 28 20:50:54 2005 From: greenrd at greenrd.org (Robin Green) Date: Thu, 28 Jul 2005 21:50:54 +0100 Subject: [fedora-java] rssowl: libgcj bugs that need fixing for it torun In-Reply-To: <1122582213.2949.98.camel@to-dhcp6.toronto.redhat.com> References: <1122582213.2949.98.camel@to-dhcp6.toronto.redhat.com> Message-ID: <20050728205054.GA5790@pob> > On Thu, 2005-07-28 at 11:34 -0700, Boehm, Hans wrote: > > [I missed the beginning of this thread initially.] > > > > I'm actually trying to work on some of these issues. Some status: > > Cool. > > Robin - is there a local hack/patch we can apply to swt and/or rssowl to > work around this problem until a real fix from Hans migrates into GCC? I'm a bit out of my depth here. Hans wrote: "Gc7 (even the released, but very experimental alpha3 version) has a thread registration interface." This implies that the version in gcc _doesn't_ have a thread registration interface, or anything that could be hacked together into one. Is that surmise correct? If so, the only other thing I can think of is to spawn a new registered thread instead of calling AttachCurrentThread, and somehow translate all C->Java invocations on the unregistered thread into inter-thread calls onto the new registered thread. In other words, keep all Java code on a separate thread. Yuck. -- Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tromey at redhat.com Thu Jul 28 22:51:59 2005 From: tromey at redhat.com (Tom Tromey) Date: 28 Jul 2005 16:51:59 -0600 Subject: [fedora-java] rssowl: libgcj bugs that need fixing for it torun In-Reply-To: <65953E8166311641A685BDF71D8658262B70CB@cacexc12.americas.cpqcorp.net> References: <65953E8166311641A685BDF71D8658262B70CB@cacexc12.americas.cpqcorp.net> Message-ID: >>>>> "Hans" == Boehm, Hans writes: Hans> 4) Gc7 (even the released, but very experimental alpha3 version) Hans> has a thread registration interface. That's probably a better Hans> solution for some of the problems here. Yes, this is exactly what we need. Any thread that calls any gcj-compiled code will register itself one way or another. We already have the libgcj entry points for this (see _Jv_AttachCurrentThread), they just need to tell the GC about the new thread's existence. There is also a "detach thread" API in JNI, see _Jv_DetachCurrentThread. Tom From orion at cora.nwra.com Thu Jul 28 22:59:42 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 Jul 2005 16:59:42 -0600 Subject: [fedora-java] Standard version of JPEGImageDecoder Message-ID: <42E9635E.4030904@cora.nwra.com> Is there a standard JPEG api that is available with gcj that provides JPEGImageDecoder and the like that are in com.sun.image.codec.jpeg.*? Or at least something comparable? Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From hans.boehm at hp.com Fri Jul 29 00:02:35 2005 From: hans.boehm at hp.com (Boehm, Hans) Date: Thu, 28 Jul 2005 17:02:35 -0700 Subject: [fedora-java] rssowl: libgcj bugs that need fixing for it torun Message-ID: <65953E8166311641A685BDF71D8658262B70CE@cacexc12.americas.cpqcorp.net> There is some code in earlier versions of the GC to do thread registration, but it's very platform specific and thus ugly. I think there wasn't a real facility for Linux. The tricky part of doing this in general is that the GC needs to know the stack bounds for the newly registered thread. It can find the hot end, but the cold end is often hard. GC7 addresses this by providing two ways to get the cold stack end: 1) A generic mechanism that just takes the address of a local. The collector knows how to implement that everywhere. We just provide a function that calls back one of your functions f with a stack address that's guaranteed to be "below" f. Since this is not the actual base of the stack, the GC ends up tracing pointers only in "new" frames. 2) A separate routine that tries to discover the stack base in a platform dependent way. It may fail. (And currently usually does.) I think that for Linux, pthread_getattr_np works for most threads, though perhaps not the main one. (The thread pointer also probably works in many cases.) I'm not sure the JNI primitives can be implemented in terms of (1). Certainly if you use CNI that has different semantics, in that the GC doesn't see pointers "below" you on the stack. We may need (2) to work for gcj. Hans > -----Original Message----- > From: Robin Green [mailto:greenrd at greenrd.org] > Sent: Thursday, July 28, 2005 1:51 PM > To: Anthony Green; Boehm, Hans > Cc: tromey at redhat.com; Discussion list for java related > Fedora development > Subject: RE: [fedora-java] rssowl: libgcj bugs that need > fixing for it torun > > > > On Thu, 2005-07-28 at 11:34 -0700, Boehm, Hans wrote: > > > [I missed the beginning of this thread initially.] > > > > > > I'm actually trying to work on some of these issues. Some status: > > > > Cool. > > > > Robin - is there a local hack/patch we can apply to swt > and/or rssowl > > to work around this problem until a real fix from Hans > migrates into > > GCC? > > I'm a bit out of my depth here. > > Hans wrote: "Gc7 (even the released, but very experimental > alpha3 version) has a thread registration interface." This > implies that the version in gcc _doesn't_ have a thread > registration interface, or anything that could be hacked > together into one. Is that surmise correct? > > If so, the only other thing I can think of is to spawn a new > registered thread instead of calling AttachCurrentThread, and > somehow translate all C->Java invocations on the unregistered > thread into inter-thread calls onto the new registered > thread. In other words, keep all Java code on a separate thread. Yuck. > > -- > Robin > From gbenson at redhat.com Fri Jul 29 08:35:03 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 29 Jul 2005 09:35:03 +0100 Subject: [fedora-java] Standard version of JPEGImageDecoder In-Reply-To: <42E9635E.4030904@cora.nwra.com> References: <42E9635E.4030904@cora.nwra.com> Message-ID: <20050729083501.GA5224@redhat.com> Orion Poplawski wrote: > Is there a standard JPEG api that is available with gcj that > provides JPEGImageDecoder and the like that are in > com.sun.image.codec.jpeg.*? Or at least something comparable? See http://developer.classpath.org/mediation/ClasspathMigration Cheers, Gary From crisppyf at gmail.com Fri Jul 29 12:34:39 2005 From: crisppyf at gmail.com (crisppy fernandes) Date: Fri, 29 Jul 2005 18:04:39 +0530 Subject: [fedora-java] Is tomcat-connectors-4.0.6 buildable on FC4 Message-ID: Hi All can anybody give me some pointer or info related to my problem.. I am facing many issues related to building tomcat-connectors-4.0.6 on FC4 . After solving few problems i have reached a point where its searching for one struct i.e. JDK1_1InitArgs. and after searching more i have come to know that definition of this struct is now removed from source i.e jni.h file So do we have fix for this. or i am missing something. some or any help welcome. Crisppy f. -- Crisppy Fernandes From green at redhat.com Fri Jul 29 13:38:18 2005 From: green at redhat.com (Anthony Green) Date: Fri, 29 Jul 2005 06:38:18 -0700 Subject: [fedora-java] Is tomcat-connectors-4.0.6 buildable on FC4 In-Reply-To: References: Message-ID: <1122644298.2972.3.camel@to-dhcp6.toronto.redhat.com> On Fri, 2005-07-29 at 18:04 +0530, crisppy fernandes wrote: > I am facing many issues related to building tomcat-connectors-4.0.6 on FC4 . > After solving few problems i have reached a point where its searching > for one struct i.e. > JDK1_1InitArgs. and after searching more i have come to know that > definition of this struct is now removed from source i.e jni.h file > So do we have fix for this. or i am missing something. I don't think gcj ever supported JDK1_1InitArgs. If this... http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5031222 ...is to be believed, Sun's 1.5 JDK ignores it and it will likely disappear from future JDK releases. Can you modify your code to not use it? AG From crisppyf at gmail.com Fri Jul 29 14:31:07 2005 From: crisppyf at gmail.com (crisppy fernandes) Date: Fri, 29 Jul 2005 20:01:07 +0530 Subject: [fedora-java] Is tomcat-connectors-4.0.6 buildable on FC4 In-Reply-To: <1122644298.2972.3.camel@to-dhcp6.toronto.redhat.com> References: <1122644298.2972.3.camel@to-dhcp6.toronto.redhat.com> Message-ID: > I don't think gcj ever supported JDK1_1InitArgs. > But on FC2 we have compiled the same source and it worked. > If this... > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5031222 > ...is to be believed, Sun's 1.5 JDK ignores it and it will likely > disappear from future JDK releases we get this required struct definition for "JDK1_1InitArgs" in jni.h file through some os rpm, but on FC4 in the same file that structure definition is missing. > Can you modify your code to not use it? > > AG I can modify my tomcat-connector source but how i can modify jni.h file on system. which is system defined. There must be some work around this... Thanxs for reply Crisppy f.