From overholt at redhat.com Tue Mar 1 00:23:11 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 28 Feb 2005 19:23:11 -0500 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1109631005.3809.43.camel@nexus.verbum.private> References: <20050225164858.GH19850@redhat.com> <1109631005.3809.43.camel@nexus.verbum.private> Message-ID: <20050301002311.GA32669@redhat.com> * Colin Walters [2005-02-28 17:54]: > On Fri, 2005-02-25 at 11:48 -0500, Andrew Overholt wrote: > >Hi, > > > >I'm having some platform and other issues building these in the build > >system, so in the meantime if anyone wants to try what will become the new > >3.1-series RPMs: > > > >http://people.redhat.com/overholt/eclipse/rpms/ > > It'd be nice if you could run createrepo in there. I would, but the platform issues and build system issues are almost resolved so they'll be in rawhide later this week. > Anyways, I tried the RPMs and they seem to work pretty well (at least > "Team Synchronizing" doesn't crash which helps a lot :)). Cool. Andrew From maillist at friendVU.com Tue Mar 1 04:52:59 2005 From: maillist at friendVU.com (NetSQL) Date: Mon, 28 Feb 2005 22:52:59 -0600 Subject: [fedora-java] Sun to host Online Live Q/A Conference on Java Application Deployment (WebStart) tmrw March 1st(Boycoting?) Message-ID: Some of you are familiar with limits of applets. Web start (JNLP) allows for a more of a rich user interface then what we can do w/ Applets and DHTML. But deploying Java, applets and applications over the internet can be a challenge, including security warnings for registered applications and installation of current version of java by non-computer savvy users of our applications (can your father in law install and launch a WebStart application?) The lead of Sun?s Java deployment team and usability experts (Mike Albers -J2SE UI expert will be there hopefully) will answer your questions at 11 AM California time and guide you. Here are the details of how to participate for FREE: http://java.sun.com/developer/community/chat Above link should be enough. More? Some people are *boycotting* the chat conference because of issues since about 2001(it appears that a individuals at Sun believe that they should PERVENT deployment ? that they are doing us a favor, listed here: http://lopica.sourceforge.net/faq.html One important issue was picked up here (Scary screen for registered applications) http://forums.java.net/jive/thread.jspa?threadID=315&tstart=0 Sun?s stance is that it?s RFE and will not address it with wide deployment of Java 6 (aka Mustang) in 2007, and not on JRE 1.4.x updates, and will not do word smiting to clarify the application is registered. Another issue is deploying/update Java by corporate end users at organizations that have a LAN admin. Sample ?applets? sites: http://www.sandrasf.com/sites One example of RiA is (click to run it) http://www.blogbridge.com/install/weekly/blogbridge.jnlp MacroMedia and MS Longhorn also have RiA kits, you can read this as intro to RiA: http://www.theserverside.com/articles/article.tss?l=RiA RiA will be major part of SoA ? Services. Server side Java will be limited w/o Client Side Java. You want to hear deployment answers from Sun people in charge? OK, tmrw. 11AM CA time (2PM? NY time) .V From peter.backlund at home.se Tue Mar 1 15:08:00 2005 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 01 Mar 2005 16:08:00 +0100 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <20050225164858.GH19850@redhat.com> References: <20050225164858.GH19850@redhat.com> Message-ID: <1109689681.19651.11.camel@localhost.localdomain> fre 2005-02-25 klockan 11:48 -0500 skrev Andrew Overholt: >Hi, > >I'm having some platform and other issues building these in the build >system, so in the meantime if anyone wants to try what will become the new >3.1-series RPMs: > >http://people.redhat.com/overholt/eclipse/rpms/ First of all, I just want to say that I've run those rpms too, and they work well. Team Synchronization Perspective now works, which is a big improvment over 3.0.1. I'd like to know why gij is needed at all, when Eclipse is (supposedly) compiled into a native binary? I noticed that both .jar and .so are shipped with the eclipse-* rpms. Is there a document explaining this strategy anywhere, or could you elaborate a little on this here on the list? I'm guessing it has to do with run-time loading of bytecode plugins? /Peter Backlund From green at redhat.com Wed Mar 2 17:26:11 2005 From: green at redhat.com (Anthony Green) Date: Wed, 02 Mar 2005 09:26:11 -0800 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1109689681.19651.11.camel@localhost.localdomain> References: <20050225164858.GH19850@redhat.com> <1109689681.19651.11.camel@localhost.localdomain> Message-ID: <1109784371.5467.15.camel@localhost.localdomain> On Tue, 2005-03-01 at 16:08 +0100, Peter Backlund wrote: > I'd like to know why gij is needed at all, when Eclipse is (supposedly) > compiled into a native binary? gij is just a tiny program that loads the requested class and invokes its main() method. It doesn't have any additional interpreter code above and beyond what's already in libgcj.so. There are a couple of approaches you can take to building a native executable with gcj. [1] Link your program together using "gcj --main=foo.bar.MainClass". This pretty much mirrors the C or C++ way of thinking. You end up with an executable whose "main()" is foo.bar.MainClass.main(). [2] Build your classes into .so files and load them on demand. This is what we're doing for Eclipse and (hopefully) all of the java programs in Eclipse. We use the tiny "gij" program to kick things off. It turns out that it's much simpler to get existing java programs to run using this second approach. For one thing, you can use all of the existing wrapper shell scripts and programs (/usr/bin/eclipse, /usr/bin/ant, etc) instead of having to create/link a new main executable. There are no real downsides to this approach either. AG From green at redhat.com Wed Mar 2 17:38:04 2005 From: green at redhat.com (Anthony Green) Date: Wed, 02 Mar 2005 09:38:04 -0800 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1109784371.5467.15.camel@localhost.localdomain> References: <20050225164858.GH19850@redhat.com> <1109689681.19651.11.camel@localhost.localdomain> <1109784371.5467.15.camel@localhost.localdomain> Message-ID: <1109785084.5467.18.camel@localhost.localdomain> On Wed, 2005-03-02 at 09:26 -0800, Anthony Green wrote: > [2] Build your classes into .so files and load them on demand. This > is > what we're doing for Eclipse and (hopefully) all of the java > programs in Eclipse. Bah. Of course I meant "all of the java programs in Fedora Core". AG From overholt at redhat.com Wed Mar 2 21:12:47 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 2 Mar 2005 16:12:47 -0500 Subject: [fedora-java] Eclipse on s390{,x} Message-ID: <20050302211247.GD29000@redhat.com> Hi, Anyone interested in working on $subj? Since we're using the Eclipse compiler as our bytecode compiler, the java stack is incomplete on platforms on which we don't build Eclipse. I don't know how easy this will be, but I'm hoping it's just a matter of adding the required files (ie. duplicating the work of, say, ia64 for s390 and ppc64 for s390x) and adding sections where appropriate. Ideally we'd contribute this work back upstream to the Eclipse Foundation, but I think Ben Konrath mentioned something about doing that requiring machines or builds or something? Ben, any comments on that? I don't have any machines on which to test this work, and I'll do it myself if no one is interested, but I thought I'd open the door if anyone wants to give it a shot. We should probably have it ASAP so that our platform coverage is complete. Andrew From tromey at redhat.com Wed Mar 2 21:55:39 2005 From: tromey at redhat.com (Tom Tromey) Date: 02 Mar 2005 14:55:39 -0700 Subject: [fedora-java] Eclipse on s390{,x} In-Reply-To: <20050302211247.GD29000@redhat.com> References: <20050302211247.GD29000@redhat.com> Message-ID: Andrew> I don't know how easy this will be, but I'm hoping it's just a Andrew> matter of adding the required files (ie. duplicating the work Andrew> of, say, ia64 for s390 and ppc64 for s390x) and adding Andrew> sections where appropriate. Yeah, probably. In one version of the spec file I just ran sed over the source tree like s/ia64/... that worked pretty well. Andrew> Ideally we'd contribute this work back upstream to the Eclipse Andrew> Foundation, but I think Ben Konrath mentioned something about Andrew> doing that requiring machines or builds or something? Ben, Andrew> any comments on that? Since eclipse.org checks in the JNI libraries, they require a build machine for every platform they release on. Tom From bkonrath at redhat.com Wed Mar 2 23:15:46 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Wed, 02 Mar 2005 18:15:46 -0500 Subject: [fedora-java] Re: Eclipse on s390{,x} In-Reply-To: <20050302211247.GD29000@redhat.com> References: <20050302211247.GD29000@redhat.com> Message-ID: <1109805346.5081.6.camel@localhost.localdomain> Hi Andrew, On Wed, 2005-02-03 at 16:12 -0500, Andrew Overholt wrote: > Ideally we'd contribute this work back upstream to the Eclipse Foundation, > but I think Ben Konrath mentioned something about doing that requiring > machines or builds or something? Ben, any comments on that? Here are the upstream instructions: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-releng-home/contributingEclipsePorts.html?rev=HEAD&content-type=text/html I'm not sure if anybody is doing this right now, but I have seen references indicating that contributed builds will be available in the near future. Cheers, Ben From lien at absolutemotion.com Thu Mar 3 06:49:26 2005 From: lien at absolutemotion.com (Jennifer A. Clark) Date: Thu, 03 Mar 2005 06:49:26 +0000 Subject: [fedora-java] Adobe Acrobat 6.0 - very low price Message-ID: <3d8301c51fbd$7b694ea1$4680b726@absolutemotion.com> Get all the software you ever imagined for wholesale prices! 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 $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 Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... To view full list of products go: http://www.softuniverse.biz Best regards, Jennifer Clark _____________________________________________________ To change your mail preferences, go: http://www.softuniverse.biz/uns.htm _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From overholt at redhat.com Fri Mar 4 16:11:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 4 Mar 2005 11:11:14 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide Message-ID: <20050304161114.GA17011@redhat.com> Hi, Some exciting new stuff has landed in rawhide over the past few days: eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! If you don't have it already, try something like this: yum --enablerepo=development install \ eclipse-{bugzilla,jdt,changelog,pydev} java-1.4.2-gcj-compat{,-devel,-src} eclipse-changelog is a plugin written by Phil Muldoon to write ChangeLog entries from within Eclipse. This started off as one of those "scratching an itch" projects that has grown into something incredibly useful. Phil's doing all his development out of CVS at sources.redhat.com. Jeff Pound was kind enough to grace the world with his HTML wizardry (it's better than I could have done :) and has put some instructions and information here: http://sources.redhat.com/eclipse eclipse-bugzilla is a plugin to interact with Bugzilla systems (duh). It was started by IBM and is now being developed by Jeff Pound here at Red Hat. It's a really great plugin and everyone has lots of cool plans for it. There's still lots of cool additions and integration with other plugins (like the ChangeLog plugin, for example) that could be done, so check it out from CVS (see URL above for instructions) and send Jeff patches and/or ideas. I've put some screenshots of the ChangeLog and Bugzilla plugins (and this message) here: http://overholt.ca/wp eclipse-pydev is the PyDev plugin (http://pydev.sourceforge.net/) packaged up. I haven't had much time to play with it myself, but it looks great and I know some python developers out there are excited to get started with it. As usual, if you find bugs, please file them in RH bugzilla under Product: Fedora Core, Version: devel, Component: eclipse. In other news, Michael Koch has started an effort to close the gap between Eclipse and projects that use the autotools. He's calling it antiauto and you can check it out here: http://www.kaffe.org/~mkoch/antiauto/ We've talked about doing an autotools plugin for a long time, but this fills the gap nicely in the meantime. Enjoy! Andrew From green at redhat.com Fri Mar 4 17:50:16 2005 From: green at redhat.com (Anthony Green) Date: Fri, 04 Mar 2005 09:50:16 -0800 Subject: [fedora-java] subversion java bindings Message-ID: <1109958617.7344.30.camel@localhost.localdomain> With a little subversion.spec tweaking, I have the rawhide subversion java bindings (svn-javahl.jar) and JNI library (libsvnjavahl-1.so) building out of the box right now. Nothing currently in FC depends on this library since the current spec file disables it, but I think it makes sense to turn it on since the Eclipse svn plugin uses it, as well various servlets people have developed and are using. It wants to install the jar file in /usr/lib/svn-javahl. Should we move this to /usr/share/java? That seems like the right thing to do. I suppose I can figure out the native build bits once I see how other packages are managing it. I've attached the changes for review... AG -------------- next part -------------- A non-text attachment was scrubbed... Name: subversion-java-spec.patch Type: text/x-patch Size: 3323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: subversion-java-ok.patch Type: text/x-patch Size: 527 bytes Desc: not available URL: From jorton at redhat.com Fri Mar 4 18:14:54 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 4 Mar 2005 18:14:54 +0000 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <1109958617.7344.30.camel@localhost.localdomain> References: <1109958617.7344.30.camel@localhost.localdomain> Message-ID: <20050304181454.GA999@redhat.com> On Fri, Mar 04, 2005 at 09:50:16AM -0800, Anthony Green wrote: > With a little subversion.spec tweaking, I have the rawhide subversion > java bindings (svn-javahl.jar) and JNI library (libsvnjavahl-1.so) > building out of the box right now. Great! This needs new BuildRequires too, presumably; gcc-java >= 4.0.0, or something? > Nothing currently in FC depends on this library since the current spec > file disables it, but I think it makes sense to turn it on since the > Eclipse svn plugin uses it, as well various servlets people have > developed and are using. Yup, we've had few requests for this. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135049 joe From green at redhat.com Fri Mar 4 18:29:42 2005 From: green at redhat.com (Anthony Green) Date: Fri, 04 Mar 2005 10:29:42 -0800 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <20050304181454.GA999@redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> Message-ID: <1109960982.7344.38.camel@localhost.localdomain> On Fri, 2005-03-04 at 18:14 +0000, Joe Orton wrote: > On Fri, Mar 04, 2005 at 09:50:16AM -0800, Anthony Green wrote: > > With a little subversion.spec tweaking, I have the rawhide subversion > > java bindings (svn-javahl.jar) and JNI library (libsvnjavahl-1.so) > > building out of the box right now. > > Great! This needs new BuildRequires too, presumably; gcc-java >= 4.0.0, > or something? There's a BuildPreReq for java-1.4.2-gcj-compat-devel which pulls in the right gcj bits. AG From ziga.mahkovec at klika.si Fri Mar 4 20:07:03 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 04 Mar 2005 21:07:03 +0100 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <20050304161114.GA17011@redhat.com> References: <20050304161114.GA17011@redhat.com> Message-ID: <1109966823.8252.9.camel@localhost> On Fri, 2005-03-04 at 11:11 -0500, Andrew Overholt wrote: > Some exciting new stuff has landed in rawhide over the past few days: > eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! If you don't have > it already, try something like this: > > yum --enablerepo=development install \ > eclipse-{bugzilla,jdt,changelog,pydev} java-1.4.2-gcj-compat{,-devel,-src} On a FC3 system with the latest gcc from rawhide (4.0.0-0.30), I get: $ yum --enablerepo=development install java-1.4.2-gcj-compat{,-devel} [...] Error: Missing Dependency: libgcj.so.5 is needed by package ecj ecj-3.1-0.M4.5 wasn't rebuilt so it probably uses the old %{gccsuffix}? -- Ziga From overholt at redhat.com Fri Mar 4 20:15:16 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 4 Mar 2005 15:15:16 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1109966823.8252.9.camel@localhost> References: <20050304161114.GA17011@redhat.com> <1109966823.8252.9.camel@localhost> Message-ID: <20050304201516.GI16343@redhat.com> * Ziga Mahkovec [2005-03-04 15:11]: > On Fri, 2005-03-04 at 11:11 -0500, Andrew Overholt wrote: > > Some exciting new stuff has landed in rawhide over the past few days: > > eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! If you don't have > > it already, try something like this: > > > > yum --enablerepo=development install \ > > eclipse-{bugzilla,jdt,changelog,pydev} java-1.4.2-gcj-compat{,-devel,-src} > > On a FC3 system with the latest gcc from rawhide (4.0.0-0.30), I get: > > $ yum --enablerepo=development install java-1.4.2-gcj-compat{,-devel} > [...] > Error: Missing Dependency: libgcj.so.5 is needed by package ecj > > > ecj-3.1-0.M4.5 wasn't rebuilt so it probably uses the old > %{gccsuffix}? ecj needs to go away, but we can't get rid of it until eclipse builds on all the platforms like it does. Try something this: rpm -e gcc-g77 libgcj4{,-devel} gcc4{,-java} java-1.4.2-gcj4-compat{,-devel} yum --enablerepo=development install eclipse-ecj yum --enablerepo=development install java-1.4.2-gcj-compat{,-devel} yum --enablerepo=development install eclipse-{jdt,bugzilla,changelog} Let me know how that goes. Andrew From green at redhat.com Sat Mar 5 02:11:06 2005 From: green at redhat.com (Anthony Green) Date: Fri, 04 Mar 2005 18:11:06 -0800 Subject: [fedora-java] libgcj javadoc rpm Message-ID: <1109988666.7344.67.camel@localhost.localdomain> I just experimented with creating a noarch RPM for libgcj HTML javadoc. It uses gjdoc to generate HTML from the src.zip rawhide libgcj installs. I don't know if this is the best way to go about it, but it was convenient. I've placed the SRPM here for comment: http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm [3k] The RPM itself is 16MB, and it seems I'm out of space on people.redhat.com. Comments and suggestions welcome.... Thanks, AG From pmuldoon at redhat.com Sat Mar 5 16:54:31 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sat, 05 Mar 2005 10:54:31 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <20050304161114.GA17011@redhat.com> References: <20050304161114.GA17011@redhat.com> Message-ID: <1110041671.7422.31.camel@localhost.localdomain> > Some exciting new stuff has landed in rawhide over the past few days: > eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! Also, as of last night, eclipse-cdt (C/C++ Development Environment for Eclipse) has been built and added. In addition, again as of last night, all of the plug-ins above have been built for the x86_64 architecture. > If you don't have it already, try something like this: > > yum --enablerepo=development install \ > eclipse-{bugzilla,jdt,changelog,pydev} java-1.4.2-gcj-compat{,-devel,-src} eclipse-{bugzilla,jdt,changelog,pydev,cdt} Regards Phil Muldoon From mlists at juma.me.uk Sat Mar 5 17:21:05 2005 From: mlists at juma.me.uk (Ismael Juma) Date: Sat, 05 Mar 2005 17:21:05 +0000 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110041671.7422.31.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> Message-ID: <4229EA81.5010904@juma.me.uk> Phil Muldoon wrote: > [snip] > Also, as of last night, eclipse-cdt (C/C++ Development Environment for > Eclipse) has been built and added. > [snip] Nice. :) According to the CDT Plan, CDT 3.0 Milestone 5 will be out on the 14th of March. As you are probably aware, this is the first Milestone for the 3.0 series but they named it M5 because it runs on Eclipse 3.1 M5. Are there plans to have this version on rawhide once it's out, or is the plan to have CDT 2.0.2 in FC4? Keep up the good work and thanks in advance. Regards, Ismael From pmuldoon at redhat.com Sat Mar 5 18:24:17 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sat, 05 Mar 2005 12:24:17 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <4229EA81.5010904@juma.me.uk> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <4229EA81.5010904@juma.me.uk> Message-ID: <1110047058.7422.45.camel@localhost.localdomain> On Sat, 2005-03-05 at 17:21 +0000, Ismael Juma wrote: > Phil Muldoon wrote: > > [snip] > > Also, as of last night, eclipse-cdt (C/C++ Development Environment for > > Eclipse) has been built and added. > > [snip] > > Nice. :) > > According to the CDT Plan, CDT 3.0 Milestone 5 will be out on the 14th > of March. As you are probably aware, this is the first Milestone for the > 3.0 series but they named it M5 because it runs on Eclipse 3.1 M5. Are > there plans to have this version on rawhide once it's out, or is the > plan to have CDT 2.0.2 in FC4? We put in 2.0.2 because that was the best option for the Fedora Core 4 - Test 1 deadline (we already had it packaged for RHEL, we just had to apply the native build smarts for FC4). We did try to get CDT 2.1 in for Test 1, but build bugs prevented us. However those are (mostly) solved now, and we have every intention of upgrading the CDT, if not to CDT 3.0, at least to 2.1 soon. Though as you mention that the CDT 3.0 M5 build is partnered to the Eclipse 3.1 M5 build, there is no barrier to us putting it in FC4 as long as it is fairly sensible/stable. I'll go look at the CDT 3.0 on Monday, and see how it does when we natively build it. I'll also go look at how the CDT 3.0 and Eclipse 3.1 schedules compare at the CDT site. Regards Phil > Keep up the good work and thanks in advance. > > Regards, > Ismael > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From ziga.mahkovec at klika.si Sat Mar 5 20:44:11 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Sat, 05 Mar 2005 21:44:11 +0100 Subject: [fedora-java] Automated Eclipse tests Message-ID: <1110055451.15721.13.camel@localhost> I've been playing with this but wanted to check here first: has anyone tried running the automated Eclipse tests against the native builds? I'm referring to the these tests: http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/automatedtesting.html http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/testResults.php -- Ziga From green at redhat.com Sun Mar 6 02:37:05 2005 From: green at redhat.com (Anthony Green) Date: Sat, 05 Mar 2005 18:37:05 -0800 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110041671.7422.31.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> Message-ID: <1110076625.15251.2.camel@localhost.localdomain> On Sat, 2005-03-05 at 10:54 -0600, Phil Muldoon wrote: > > Some exciting new stuff has landed in rawhide over the past few days: > > eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! > > Also, as of last night, eclipse-cdt (C/C++ Development Environment for > Eclipse) has been built and added. Hey Phil - are there any plans to package the GEF plugin? I'd like to use this Eclipse for my project, but it requires GEF. I looked at how you packaged the CDT plugin but I don't understand how you put the source tree together. AG From pmuldoon at redhat.com Sun Mar 6 04:04:02 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sat, 05 Mar 2005 22:04:02 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110076625.15251.2.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> Message-ID: <1110081842.5776.37.camel@localhost.localdomain> > Hey Phil - are there any plans to package the GEF plugin? I'd like to > use this Eclipse for my project, but it requires GEF. Not planned for Core, but I think it would be a great candidate for Extras. The GEF plug-in is already packaged for RHEL, so it would only be a matter of adding the native smarts to the GEF rpm. We were really limited by space in what we could put in Core :{ > I looked at how you packaged the CDT plugin but I don't understand how > you put the source tree together. The source tree is basically the releng plugin that all eclipse.org projects provide, with pre-fetched source. So the CDT group provide their own releng plugin, and we use it. All Eclipse hosted projects use this approach. You can find details on releng plug-ins here: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.releng.basebuilder/readme.html?rev=HEAD&content-type=text/html We have to make some alterations to the assumptions that those releng plug-ins make (they make the assumption that it is okay to cvs co -r {tag} the code right at build time - we disagree, due to various security/code quality/infrastructure issues); they also attempt to download an upstream Eclipse SDK to build against - again we disagreed and disabled. These changes are applied as a patch against the sdk/customTargets.xml, and the platform/customTargets.xml So basically we pre-fetch the CDT code (in results/) and disable cvs access in the releng plugin. Then we invoke a headless Eclipse via the PDE build scripts (See link above) which will compile the code and deliver a zip or tarball depending on platform. Next we take that tar ball, extract any jars and build them to .so. We build a database of each jar (actually classes in each jar) to -> .so and register them in a database with gcj-dbtool. Then at post, as each plugin is installed, we merge that plugin database with the main eclipse.db so the corresponding .so can be loaded for whatever .class is being executed. Links to the webcvs version of the CDT releng plugin are here: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-releng/? cvsroot=Tools_Project We've been debating this build approach (the pde builds) for awhile. Is it is good approach? That's up for debate; we've talked about changing it. Ben Konrath has been experimenting with a different build approach. Once the dust settles on test 1, this would be a good place to debate alternate build methods that a) don't stray too far away from the upstream build process and make it painful to integrate; b) allow friendlier third party building outside of rpm that does not require a week's learning about the pde build method. Regards Phil From bkonrath at redhat.com Sun Mar 6 06:36:36 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Sun, 6 Mar 2005 01:36:36 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110081842.5776.37.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> Message-ID: <20050306063636.GA26804@town.toronto.redhat.com> Hi Phil/Anthony, On Sat, 2005-05-03 at 22:04 -0600, Phil Muldoon wrote: > We have to make some alterations to the assumptions that those releng > plug-ins make (they make the assumption that it is okay to cvs co -r > {tag} the code right at build time - we disagree, due to various > security/code quality/infrastructure issues); they also attempt to > download an upstream Eclipse SDK to build against - again we disagreed > and disabled. These changes are applied as a patch against the > sdk/customTargets.xml, and the platform/customTargets.xml Just one small correction, an Eclipse releng plugin will not try to download the SDK. You are expected to have an SDK downloaded and unpacked before you start a build. So the only thing that needs to be disabled is the fetch target of the releng build.xml. > We've been debating this build approach (the pde builds) for awhile. Is > it is good approach? That's up for debate; we've talked about changing > it. Ben Konrath has been experimenting with a different build approach. > Once the dust settles on test 1, this would be a good place to debate > alternate build methods that a) don't stray too far away from the > upstream build process and make it painful to integrate; b) allow > friendlier third party building outside of rpm that does not require a > week's learning about the pde build method. I have a solution already in mind but it will take some upstream changes. I've done a bit of work towards this but I haven't had time to finish it off. If it's important, I can try bugging the Eclipse people again and see if I can get some traction. In case your interested, here's how I generated the cdt 2.1 tarball (unfortunately it doesn't build against eclipse 3.1M5a): % mkdir temp && cd temp % /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse % mkdir home % cvs -d :pserver:anonymous at dev.eclipse.org:/home/tools co -r CDT_2_1 \ org.eclipse.cdt-releng/org.eclipse.cdt.releng % cd org.eclipse.cdt-releng/org.eclipse.cdt.releng % sed --in-place 's/HEAD/CDT_2_1/' maps/cdt.map % java -cp ../../SDK/startup.jar org.eclipse.core.launcher.Main \ -application org.eclipse.ant.core.antRunner \ -buildfile build.xml \ -Dpde.build.scripts=../../SDK/plugins/org.eclipse.pde.build_3.1.0/scripts \ -Duser.home=../../home \ -DjavacFailOnError=true \ -DdontUnzip=true \ -DmapVersionTag=CDT_2_1 \ -v fetch % cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz org.eclipse.cdt.releng This method should work with other plugins on eclipse.org. If you have any question, feel free to ping me. Cheers, Ben From green at redhat.com Sun Mar 6 06:53:05 2005 From: green at redhat.com (Anthony Green) Date: Sat, 05 Mar 2005 22:53:05 -0800 Subject: [fedora-java] A free jta package Message-ID: <1110091985.15251.31.camel@localhost.localdomain> Here's another SRPM for FC consideration.... http://people.redhat.com/green/libgcj-jta-4.0.0-1.src.rpm This package Provides "jta", which is one of the nosrc RPMS in jpackage that many other things depend on. libgcj (and GNU Classpath) already include all of the classes and interfaces found in jta, but not as a separate .jar file. The separate jar file is important because packages depending on jta usually run "build-classpath jta" to find the jta jar file. The SRPM actually contains no source code. It simply extracts the javax.transaction classes from libgcj-4.0.0.jar and zips them up into libgcj-jta-4.0.0.jar (with a symlink to jta.jar). We create a simple noarch RPM since gij will use the native versions in libgcj anyway. This package should satisfy the needs of all jta users (even for non-gcj alternatives). Could somebody please review the spec file and slip it into FC? tomcat5 depends on it, among other things. AG From green at redhat.com Sun Mar 6 08:50:19 2005 From: green at redhat.com (Anthony Green) Date: Sun, 06 Mar 2005 00:50:19 -0800 Subject: [fedora-java] java-gcj-compat patch for extdirs support Message-ID: <1110099019.15251.37.camel@localhost.localdomain> Hey Tom, java-gcj-compat's javac currently ignores the extensions directory (as we've both discovered). The Eclipse compiler doesn't have an extensions directory option either, so we have to expand it manually. This is similar to what Eclipse's JDTCompilerAdapter class does for ant. AG -------------- next part -------------- A non-text attachment was scrubbed... Name: extdirs.patch Type: text/x-patch Size: 4235 bytes Desc: not available URL: From green at redhat.com Sun Mar 6 10:42:59 2005 From: green at redhat.com (Anthony Green) Date: Sun, 06 Mar 2005 02:42:59 -0800 Subject: [fedora-java] Using the natively-built Eclipse compiler Message-ID: <1110105522.15251.49.camel@localhost.localdomain> ant and javac aren't currently using the natively-built Eclipse compiler. We need to add something like the following to /usr/bin/ant in order to pick up the .so files: # diff -c /usr/bin/ant~ /usr/bin/ant *** /usr/bin/ant~ 2005-03-05 13:13:05.000000000 -0800 --- /usr/bin/ant 2005-03-06 02:19:55.000000000 -0800 *************** *** 230,235 **** --- 230,236 ---- if $JAVACMD -version 2>&1 | grep -q "gcj"; then if [ -f /usr/share/java/jdtcore.jar ]; then LOCALCLASSPATH="$LOCALCLASSPATH:/usr/share/java/jdtcore.jar" + ANT_OPTS="$ANT_OPTS -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db" fi fi (and something similar to java-gcj-compat's javac.in, see attached patch) This will shave minutes off of the build times for some packages. I forget what the plan is wrt the db. Maybe we'll have a global one. In any case, this will do in the meanwhile. (gbenson: could you please stick the above in apache-ant-javac-ecj.patch? This is where we really need it - thanks!) AG -------------- next part -------------- A non-text attachment was scrubbed... Name: use-native-ecj.patch Type: text/x-patch Size: 716 bytes Desc: not available URL: From joe at galway.net Sun Mar 6 16:18:29 2005 From: joe at galway.net (Joe Desbonnet) Date: Sun, 06 Mar 2005 16:18:29 +0000 Subject: [fedora-java] Java library to query/create RPM packages Message-ID: <422B2D55.4020202@galway.net> Is there any Java library that enables querying and creation of RPMs? Thanks, Joe. From pmuldoon at redhat.com Sun Mar 6 17:08:46 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sun, 06 Mar 2005 11:08:46 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <20050306063636.GA26804@town.toronto.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> Message-ID: <1110128926.5913.6.camel@localhost.localdomain> On Sun, 2005-03-06 at 01:36 -0500, Ben Konrath wrote: > Hi Phil/Anthony, > > On Sat, 2005-05-03 at 22:04 -0600, Phil Muldoon wrote: > > We have to make some alterations to the assumptions that those releng > > plug-ins make (they make the assumption that it is okay to cvs co -r > > {tag} the code right at build time - we disagree, due to various > > security/code quality/infrastructure issues); they also attempt to > > download an upstream Eclipse SDK to build against - again we disagreed > > and disabled. These changes are applied as a patch against the > > sdk/customTargets.xml, and the platform/customTargets.xml > > Just one small correction, an Eclipse releng plugin will not try to > download the SDK. You are expected to have an SDK downloaded and > unpacked before you start a build. So the only thing that needs to be > disabled is the fetch target of the releng build.xml. Some do, the CDT won't. Here is an example of a target in the GEF customTargets.xml: > It's was just an example of an assumption these scripts can make, though reading back in the mail I do see to making the case that all of them make them, so point taken ;) > > We've been debating this build approach (the pde builds) for awhile. Is > > it is good approach? That's up for debate; we've talked about changing > > it. Ben Konrath has been experimenting with a different build approach. > > Once the dust settles on test 1, this would be a good place to debate > > alternate build methods that a) don't stray too far away from the > > upstream build process and make it painful to integrate; b) allow > > friendlier third party building outside of rpm that does not require a > > week's learning about the pde build method. > > I have a solution already in mind but it will take some upstream > changes. I've done a bit of work towards this but I haven't had time to > finish it off. If it's important, I can try bugging the Eclipse people > again and see if I can get some traction. I'd like to try and see if there are other solutions from the list out there, before we move on to the Eclipse fellas. Who knows, someone might already have the perfect nirvana of build systems for releng plugins just waiting out there ;) Regards Phil From Nicolas.Mailhot at laPoste.net Sun Mar 6 17:44:41 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 06 Mar 2005 18:44:41 +0100 Subject: [fedora-java] Java library to query/create RPM packages In-Reply-To: <422B2D55.4020202@galway.net> References: <422B2D55.4020202@galway.net> Message-ID: <1110131087.26618.18.camel@rousalka.dyndns.org> Le dimanche 06 mars 2005 ? 16:18 +0000, Joe Desbonnet a ?crit : > Is there any Java library that enables querying and creation of RPMs? You can call rpm & build-classpath from ant. One of the (many) reasons build-classpath returns a well-formed java path is to allow result injection in ant (via path elements) Once you've got system-wide jar resolution you can generate specs dynamically via xslt. I wouldn't advise it though - it's a great way to shoot yourself in the foot. The easiest way is always to have a working ant build and pack the result in an rpm via an external spec file Regards, -- Nicolas Mailhot -------------- 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 talios at gmail.com Sun Mar 6 21:45:30 2005 From: talios at gmail.com (Mark Derricutt) Date: Mon, 7 Mar 2005 10:45:30 +1300 Subject: [fedora-java] Java library to query/create RPM packages In-Reply-To: <422B2D55.4020202@galway.net> References: <422B2D55.4020202@galway.net> Message-ID: <5184347f050306134547ece9f6@mail.gmail.com> Take alook at jRPM - http://jrpm.sourceforge.net Mark On Sun, 06 Mar 2005 16:18:29 +0000, Joe Desbonnet wrote: > Is there any Java library that enables querying and creation of RPMs? > Thanks, > Joe. > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > From tromey at redhat.com Sun Mar 6 23:50:02 2005 From: tromey at redhat.com (Tom Tromey) Date: 06 Mar 2005 16:50:02 -0700 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110105522.15251.49.camel@localhost.localdomain> References: <1110105522.15251.49.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> I forget what the plan is wrt the db. Maybe we'll have a global one. Yeah, the current consensus is a global one. The precise details of how it will be managed haven't been worked out. I suppose I ought to add this to libgcj configury soon. Tom From zbalevsky at limepeer.com Mon Mar 7 00:15:34 2005 From: zbalevsky at limepeer.com (zbalevsky) Date: Sun, 06 Mar 2005 19:15:34 -0500 Subject: [fedora-java] Self Introduction - Zlatin Balevsky Message-ID: <422B9D26.5020206@limepeer.com> Greetings, I'm a developer at Lime Wire LLC (the gnutella p2p client) and an avid Fedora fan. Although our product uses Swing heavily and hence won't be able to run on a free jvm anytime soon, I'm greatly interrested in helping liberate as much of java as possible. I'm specifically interrested in the gcj port of Eclipse and will most likely be contribute to that by testing and whatnot. Best Regards, Zlatin Balevsky From fitzsim at redhat.com Mon Mar 7 02:25:58 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 06 Mar 2005 21:25:58 -0500 Subject: [fedora-java] Re: java-gcj-compat patch for extdirs support In-Reply-To: <1110099019.15251.37.camel@localhost.localdomain> References: <1110099019.15251.37.camel@localhost.localdomain> Message-ID: <1110162358.3227.5.camel@rh-ibm-t41> On Sun, 2005-03-06 at 00:50 -0800, Anthony Green wrote: > Hey Tom, > > java-gcj-compat's javac currently ignores the extensions directory (as > we've both discovered). The Eclipse compiler doesn't have an > extensions directory option either, so we have to expand it manually. > This is similar to what Eclipse's JDTCompilerAdapter class does for ant. > Great, thanks! I just hit this problem myself tonight. I'll incorporate this into java-gcj-compat tomorrow. Tom From fitzsim at redhat.com Mon Mar 7 02:30:28 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 06 Mar 2005 21:30:28 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110105522.15251.49.camel@localhost.localdomain> References: <1110105522.15251.49.camel@localhost.localdomain> Message-ID: <1110162628.3227.11.camel@rh-ibm-t41> On Sun, 2005-03-06 at 02:42 -0800, Anthony Green wrote: > ant and javac aren't currently using the natively-built Eclipse > compiler. > javac in the latest java-gcj-compat does use the natively-built compiler actually, but it uses the old ABI and the gcjlib:// class loading mechanism. This patch is a better idea so I'll use it instead. Note that these changes wouldn't be required if we had a system-wide dbtool database. We really need to get support for this into libgcj's configury. Tom > We need to add something like the following to /usr/bin/ant in order to > pick up the .so files: > > # diff -c /usr/bin/ant~ /usr/bin/ant > *** /usr/bin/ant~ 2005-03-05 13:13:05.000000000 -0800 > --- /usr/bin/ant 2005-03-06 02:19:55.000000000 -0800 > *************** > *** 230,235 **** > --- 230,236 ---- > if $JAVACMD -version 2>&1 | grep -q "gcj"; then > if [ -f /usr/share/java/jdtcore.jar ]; then > LOCALCLASSPATH="$LOCALCLASSPATH:/usr/share/java/jdtcore.jar" > + ANT_OPTS="$ANT_OPTS -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db" > fi > fi > > (and something similar to java-gcj-compat's javac.in, see attached patch) > > This will shave minutes off of the build times for some packages. > > I forget what the plan is wrt the db. Maybe we'll have a global one. > In any case, this will do in the meanwhile. > > (gbenson: could you please stick the above in apache-ant-javac-ecj.patch? This is > where we really need it - thanks!) > > AG > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From tromey at redhat.com Sun Mar 6 23:50:02 2005 From: tromey at redhat.com (Tom Tromey) Date: 06 Mar 2005 16:50:02 -0700 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110105522.15251.49.camel@localhost.localdomain> References: <1110105522.15251.49.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> I forget what the plan is wrt the db. Maybe we'll have a global one. Yeah, the current consensus is a global one. The precise details of how it will be managed haven't been worked out. I suppose I ought to add this to libgcj configury soon. Tom From bkonrath at redhat.com Mon Mar 7 05:40:21 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Mon, 07 Mar 2005 00:40:21 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110128926.5913.6.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> Message-ID: <1110174021.7119.49.camel@town.toronto.redhat.com> On Sun, 2005-03-06 at 11:08 -0600, Phil Muldoon wrote: > Some do, the CDT won't. Here is an example of a target in the GEF > customTargets.xml: > > > > > > > > Oh sorry, my mistake, I haven't encountered this yet. This is good to know though. > I'd like to try and see if there are other solutions from the list out > there, before we move on to the Eclipse fellas. Who knows, someone might > already have the perfect nirvana of build systems for releng plugins > just waiting out there ;) Ok, but I'm not sure who else would have the same build requirements (besides other GNU/Linux distributors). Of course, anyone who has ideas is welcome to speak up :) Here is a list of the build methods that I've come up with, as well as my proposed solution (which I just updated about five minutes ago): http://people.redhat.com/bkonrath/eclipse/buildable-source-zips.html There is also a thread that I started on eclipse.org about this but you'll need to register if you want to read it: http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg02967.html Cheers, Ben From aluchko at redhat.com Mon Mar 7 07:40:36 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Mon, 07 Mar 2005 00:40:36 -0700 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <1110055451.15721.13.camel@localhost> References: <1110055451.15721.13.camel@localhost> Message-ID: <1110181236.28220.4.camel@localhost.localdomain> On Sat, 2005-03-05 at 21:44 +0100, Ziga Mahkovec wrote: > I've been playing with this but wanted to check here first: has anyone > tried running the automated Eclipse tests against the native builds? > > I'm referring to the these tests: > > http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/automatedtesting.html > http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/testResults.php > I'm in the process of finalizing a system to run the automated eclipse tests on our native builds. Right now it's down to a couple kinks in the test system and getting some kind of public server set up to show the results. The system should be ready in the next few days though I haven't looked into the public server yet (will start looking around Monday). Aaron From nicolas.mailhot at laposte.net Mon Mar 7 08:25:07 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Mar 2005 09:25:07 +0100 (CET) Subject: [fedora-java] Self Introduction - Zlatin Balevsky In-Reply-To: <422B9D26.5020206@limepeer.com> References: <422B9D26.5020206@limepeer.com> Message-ID: <14753.192.54.193.137.1110183907.squirrel@rousalka.dyndns.org> On Lun 7 mars 2005 1:15, zbalevsky a ?crit : > Greetings, > > I'm a developer at Lime Wire LLC (the gnutella p2p client) and an avid > Fedora fan. Although our product uses Swing heavily and hence won't be > able to run on a free jvm anytime soon, I'm greatly interrested in > helping liberate as much of java as possible. I think there are some Limewire bits in JPackage (probably outdated). Cleaning up the packages would help future Fedora inclusion (as long as it's closed JVM only it's JPackage stuff) Regards, -- Nicolas Mailhot From ziga.mahkovec at klika.si Mon Mar 7 15:17:48 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Mon, 07 Mar 2005 16:17:48 +0100 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <1110181236.28220.4.camel@localhost.localdomain> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> Message-ID: <1110208669.10581.11.camel@localhost> On Mon, 2005-03-07 at 00:40 -0700, Aaron Luchko wrote: > I'm in the process of finalizing a system to run the automated eclipse > tests on our native builds. Right now it's down to a couple kinks in > the test system and getting some kind of public server set up to show > the results. The system should be ready in the next few days though I > haven't looked into the public server yet (will start looking around > Monday). Great, thanks. I ran a subset of these tests and gcj did pretty well. Might be interesting to run the tests against a non-free JRE as well, for performance comparison. -- Ziga From pmuldoon at redhat.com Mon Mar 7 19:06:08 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 07 Mar 2005 13:06:08 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110174021.7119.49.camel@town.toronto.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> Message-ID: <1110222368.6220.39.camel@localhost.localdomain> > > Here is a list of the build methods that I've come up with, as well as > my proposed solution (which I just updated about five minutes ago): > > http://people.redhat.com/bkonrath/eclipse/buildable-source-zips.html I liked your proposed solution. I don't think adding the native step to the build.xml is a large burden, especially if there are already patches generated and pushed upstream. We can add those to the Fedora Eclipse while we wait. The releng plug-in being necessary is not a huge deal either. They are pretty standard now, and don't require much knowledge investment to get going. Also eclipse.org has standardized on the releng build method, so it should be in our best interest that all plug-ins that ship in Fedora Extras/Core should have one. If there are third party authors out there that don't have them, we can always assist as necessary. Anybody else in the community have any comments on this, or other proposals? I'd like to get the ball rolling on this, and we can maybe get the implementation working before May and the final Fedora 4 release. Regards Phil Muldoon From aluchko at redhat.com Mon Mar 7 22:20:38 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Mon, 07 Mar 2005 15:20:38 -0700 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <1110208669.10581.11.camel@localhost> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> Message-ID: <1110234039.5456.7.camel@localhost.localdomain> On Mon, 2005-03-07 at 16:17 +0100, Ziga Mahkovec wrote: > On Mon, 2005-03-07 at 00:40 -0700, Aaron Luchko wrote: > > I'm in the process of finalizing a system to run the automated eclipse > > tests on our native builds. Right now it's down to a couple kinks in > > the test system and getting some kind of public server set up to show > > the results. The system should be ready in the next few days though I > > haven't looked into the public server yet (will start looking around > > Monday). > > Great, thanks. I ran a subset of these tests and gcj did pretty well. > Might be interesting to run the tests against a non-free JRE as well, > for performance comparison. I've been pitting them up against the IBM and BEA jvms we have for the stuff we ship with RHEL-3, the last time I successfully ran them was with the last 3.0 we had, it didn't fare too badly other than debugging (no JDWP) though our stuff has changed quite a bit since then. Aaron From dpaun at rogers.com Tue Mar 8 03:15:04 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Mon, 7 Mar 2005 22:15:04 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <1110234039.5456.7.camel@localhost.localdomain> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> Message-ID: <20050308031504.GJ29253@rogers.com> On Mon, Mar 07, 2005 at 03:20:38PM -0700, Aaron Luchko wrote: > I've been pitting them up against the IBM and BEA jvms we have for the > stuff we ship with RHEL-3, the last time I successfully ran them was > with the last 3.0 we had, it didn't fare too badly other than debugging > (no JDWP) though our stuff has changed quite a bit since then. "didn't fare too badly" = faster, slower, about the same? Any hard numbers? -- Dimi. From jorton at redhat.com Tue Mar 8 11:00:12 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 8 Mar 2005 11:00:12 +0000 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <1109960982.7344.38.camel@localhost.localdomain> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> Message-ID: <20050308110012.GC2587@redhat.com> On Fri, Mar 04, 2005 at 10:29:42AM -0800, Anthony Green wrote: > On Fri, 2005-03-04 at 18:14 +0000, Joe Orton wrote: > > On Fri, Mar 04, 2005 at 09:50:16AM -0800, Anthony Green wrote: > > > With a little subversion.spec tweaking, I have the rawhide subversion > > > java bindings (svn-javahl.jar) and JNI library (libsvnjavahl-1.so) > > > building out of the box right now. > > > > Great! This needs new BuildRequires too, presumably; gcc-java >= 4.0.0, > > or something? > > There's a BuildPreReq for java-1.4.2-gcj-compat-devel which pulls in the > right gcj bits. Ah, sorry, I missed that. I committed this with a change to use the jdk_path macro which was unused otherwise. It built on i386 but didn't on at least ia64: + make javahl /usr/lib/jvm/java-1.4.2-gcj/bin/javac -d subversion/bindings/java/javahl/classes -classpath ... Missing resource : org/eclipse/jdt/internal/compiler/batch/messages.properties for locale en_US Exception in thread "main" java.lang.ExceptionInInitializerError <> Caused by: java.util.MissingResourceException: Bundle org.eclipse.jdt.internal.compiler.batch.messages not found <> make: *** [javahl-java] Error 1 error: Bad exit status from /usr/src/build/536680-ia64/install-tmp/rpm-tmp.80923 (%build) is that a compiler bug? joe From green at redhat.com Tue Mar 8 12:27:46 2005 From: green at redhat.com (Anthony Green) Date: Tue, 08 Mar 2005 04:27:46 -0800 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <20050308110012.GC2587@redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> Message-ID: <1110284867.5352.4.camel@localhost.localdomain> On Tue, 2005-03-08 at 11:00 +0000, Joe Orton wrote: > It built on i386 but didn't on at least ia64: > > + make javahl > /usr/lib/jvm/java-1.4.2-gcj/bin/javac -d > subversion/bindings/java/javahl/classes -classpath ... > Missing resource : > org/eclipse/jdt/internal/compiler/batch/messages.properties for locale > en_US > Exception in thread "main" java.lang.ExceptionInInitializerError > <> > Caused by: java.util.MissingResourceException: Bundle > org.eclipse.jdt.internal.compiler.batch.messages not found > <> > make: *** [javahl-java] Error 1 > error: Bad exit status from > /usr/src/build/536680-ia64/install-tmp/rpm-tmp.80923 (%build) > This is troubling. This looks like the Eclipse compiler is broken on ia64. But surely we're using that compiler to build other things right now. Does anybody here know? AG From green at redhat.com Tue Mar 8 14:37:09 2005 From: green at redhat.com (Anthony Green) Date: Tue, 08 Mar 2005 06:37:09 -0800 Subject: [fedora-java] tomcat5 Message-ID: <1110292630.5352.8.camel@localhost.localdomain> I see that tomcat5 is in rawhide now - thanks Gary! I started it up, and saw the process running until I tried to view a page, then the process died. Here are the contents of /var/log/tomcat5/catalina.out. Any ideas? Thanks, AG -------------- next part -------------- Bootstrap: Class loader creation threw exception java.lang.IllegalArgumentException: addRepositoryInternal: repository='file:/usr/share/tomcat5/common/lib/[jdbc-stdext].jar' at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(java.lang.String) (Unknown Source) at org.apache.catalina.loader.StandardClassLoader.StandardClassLoader(java.lang.String[]) (Unknown Source) at org.apache.catalina.startup.ClassLoaderFactory.createClassLoader(java.io.File[], java.io.File[], java.net.URL[], java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) at org.apache.catalina.startup.Bootstrap.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.io.FileNotFoundException: /usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or directory) at gnu.java.nio.channels.FileChannelImpl.open(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) at gnu.java.nio.channels.FileChannelImpl.FileChannelImpl(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) at java.io.RandomAccessFile.RandomAccessFile(java.lang.String, java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.util.zip.ZipFile.ZipFile(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.util.jar.JarFile.JarFile(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.util.jar.JarFile.JarFile(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(java.lang.String) (Unknown Source) ...8 more Bootstrap: Class loader creation threw exception java.lang.IllegalArgumentException: addRepositoryInternal: repository='file:/usr/share/tomcat5/common/lib/[jdbc-stdext].jar' at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(java.lang.String) (Unknown Source) at org.apache.catalina.loader.StandardClassLoader.StandardClassLoader(java.lang.String[]) (Unknown Source) at org.apache.catalina.startup.ClassLoaderFactory.createClassLoader(java.io.File[], java.io.File[], java.net.URL[], java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) at org.apache.catalina.startup.Bootstrap.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.io.FileNotFoundException: /usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or directory) at gnu.java.nio.channels.FileChannelImpl.open(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) at gnu.java.nio.channels.FileChannelImpl.FileChannelImpl(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) at java.io.RandomAccessFile.RandomAccessFile(java.lang.String, java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.util.zip.ZipFile.ZipFile(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.util.jar.JarFile.JarFile(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.util.jar.JarFile.JarFile(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(java.lang.String) (Unknown Source) ...8 more From vadimn at redhat.com Tue Mar 8 14:48:11 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Tue, 8 Mar 2005 09:48:11 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110292630.5352.8.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> Message-ID: <200503080948.11924@vadim.nasardinov> On Tuesday 08 March 2005 09:37, Anthony Green wrote: > I started it up, and saw the process running until I tried to view a > page, then the process died. Here are the contents > of /var/log/tomcat5/catalina.out. Any ideas? > > Caused by: java.io.FileNotFoundException: > /usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or > directory) > at gnu.java.nio.channels.FileChannelImpl.open(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your machine? From green at redhat.com Tue Mar 8 15:15:32 2005 From: green at redhat.com (Anthony Green) Date: Tue, 08 Mar 2005 07:15:32 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <200503080948.11924@vadim.nasardinov> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> Message-ID: <1110294932.10073.2.camel@localhost.localdomain> On Tue, 2005-03-08 at 09:48 -0500, Vadim Nasardinov wrote: > Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your > machine? lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm Bah. Ok, the java-1.4.2-gcj-compat spec file says: Provides: jndi, jdbc-stdext So, do we need to play tricks for these, like I suggested for jta? AG From overholt at redhat.com Tue Mar 8 15:40:55 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 8 Mar 2005 10:40:55 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <20050308031504.GJ29253@rogers.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> Message-ID: <20050308154055.GB30854@redhat.com> CCing Bryce McKinlay * Dimitrie O. Paun [2005-03-07 22:16]: > On Mon, Mar 07, 2005 at 03:20:38PM -0700, Aaron Luchko wrote: > > I've been pitting them up against the IBM and BEA jvms we have for the > > stuff we ship with RHEL-3, the last time I successfully ran them was > > with the last 3.0 we had, it didn't fare too badly other than debugging > > (no JDWP) though our stuff has changed quite a bit since then. > > "didn't fare too badly" = faster, slower, about the same? Any hard numbers? I don't have any hard numbers, but things feel about the same or faster than with a proprietary JVM. The thing to remember is that we have no gcj optimizations turned on at this point. I know Bryce was working on it ... Bryce, do you have a status of that? Andrew From overholt at redhat.com Tue Mar 8 15:44:06 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 8 Mar 2005 10:44:06 -0500 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <1110284867.5352.4.camel@localhost.localdomain> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> Message-ID: <20050308154406.GC30854@redhat.com> * Anthony Green [2005-03-08 07:34]: > On Tue, 2005-03-08 at 11:00 +0000, Joe Orton wrote: > > It built on i386 but didn't on at least ia64: > > > > + make javahl > > /usr/lib/jvm/java-1.4.2-gcj/bin/javac -d > > subversion/bindings/java/javahl/classes -classpath ... > > Missing resource : > > org/eclipse/jdt/internal/compiler/batch/messages.properties for locale > > en_US > > Exception in thread "main" java.lang.ExceptionInInitializerError > > <> > > Caused by: java.util.MissingResourceException: Bundle > > org.eclipse.jdt.internal.compiler.batch.messages not found > > <> > > make: *** [javahl-java] Error 1 > > error: Bad exit status from > > /usr/src/build/536680-ia64/install-tmp/rpm-tmp.80923 (%build) > > > > This is troubling. This looks like the Eclipse compiler is broken on > ia64. But surely we're using that compiler to build other things right > now. Does anybody here know? There's a gcc backend bug (most likely) on ia64 right now so I can't build Eclipse on it. We still have an older ecj build on ia64, though, so j-g-c can build on it. We will have eclipse-ecj when I can build it on ia64. gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 Andrew From mckinlay at redhat.com Tue Mar 8 15:50:41 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Tue, 08 Mar 2005 10:50:41 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <20050308154055.GB30854@redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> Message-ID: <422DC9D1.5090702@redhat.com> Andrew Overholt wrote: >CCing Bryce McKinlay > >* Dimitrie O. Paun [2005-03-07 22:16]: > > >>On Mon, Mar 07, 2005 at 03:20:38PM -0700, Aaron Luchko wrote: >> >> >>>I've been pitting them up against the IBM and BEA jvms we have for the >>>stuff we ship with RHEL-3, the last time I successfully ran them was >>>with the last 3.0 we had, it didn't fare too badly other than debugging >>>(no JDWP) though our stuff has changed quite a bit since then. >>> >>> >>"didn't fare too badly" = faster, slower, about the same? Any hard numbers? >> >> > >I don't have any hard numbers, but things feel about the same or faster >than with a proprietary JVM. The thing to remember is that we have no gcj >optimizations turned on at this point. I know Bryce was working on it ... >Bryce, do you have a status of that? > My last eclipse -O2 attempt was a few weeks ago, and some fixes have gone in to GCJ since then. At this point it should be possible to compile most of the .jar's with -O2, but there are likely to still be optimization bugs that cause eclipse to misbehave or crash when it is built with -O2. Is resources.jar still used entirely uncompiled? We should perhaps concentrate on that bug first. Startup time is also an issue - we should be able to beat the JVM easily here but currently we arn't. It would be worth profiling the startup sequence to see if any obvious bottlenecks can be identified. Bryce From gbenson at redhat.com Tue Mar 8 16:16:46 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 8 Mar 2005 16:16:46 +0000 Subject: [fedora-java] Re: tomcat5 In-Reply-To: <1110292630.5352.8.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> Message-ID: <20050308161643.GC12089@redhat.com> Anthony Green wrote: > I see that tomcat5 is in rawhide now - thanks Gary! You're welcome :) > I started it up, and saw the process running until I tried to > view a page, then the process died. Here are the contents of > /var/log/tomcat5/catalina.out. Any ideas? Not a clue, sorry: I haven't tried running it at all yet! I just needed it built in time for FC4t1... Cheers, Gary From aph at redhat.com Tue Mar 8 17:55:01 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Mar 2005 17:55:01 +0000 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <422DC9D1.5090702@redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> Message-ID: <16941.59125.399536.230873@cuddles.cambridge.redhat.com> Bryce McKinlay writes: > > Startup time is also an issue - we should be able to beat the JVM easily > here but currently we arn't. It would be worth profiling the startup > sequence to see if any obvious bottlenecks can be identified. The unwinding fixes aren't all in yet. Unwinding accounted for about 16% of startup time in the case of jonas, and I exepct Eclipse would be similar. Andrew. From aph at redhat.com Tue Mar 8 17:56:31 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Mar 2005 17:56:31 +0000 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <16941.59125.399536.230873@cuddles.cambridge.redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> <16941.59125.399536.230873@cuddles.cambridge.redhat.com> Message-ID: <16941.59215.388324.855820@cuddles.cambridge.redhat.com> Andrew Haley writes: > Bryce McKinlay writes: > > > > Startup time is also an issue - we should be able to beat the JVM easily > > here but currently we arn't. It would be worth profiling the startup > > sequence to see if any obvious bottlenecks can be identified. > > The unwinding fixes aren't all in yet. Unwinding accounted for about > 16% 60% > of startup time in the case of jonas, and I exepct Eclipse would > be similar. > > Andrew. From overholt at redhat.com Tue Mar 8 18:01:55 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 8 Mar 2005 13:01:55 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <422DC9D1.5090702@redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> Message-ID: <20050308180155.GG30854@redhat.com> * Bryce McKinlay [2005-03-08 10:55]: > > My last eclipse -O2 attempt was a few weeks ago, and some fixes have > gone in to GCJ since then. At this point it should be possible to > compile most of the .jar's with -O2, but there are likely to still be > optimization bugs that cause eclipse to misbehave or crash when it is > built with -O2. I just successfully built all of our jars to .sos with O2 and things ran! I didn't do much testing, but a simple Hello, world works. Now to see if this works on the other architectures ... > Is resources.jar still used entirely uncompiled? We should perhaps > concentrate on that bug first. Yes. Yes, perhaps we should. Andrew From Nicolas.Mailhot at laPoste.net Tue Mar 8 18:13:21 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Mar 2005 19:13:21 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: <1110294932.10073.2.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> Message-ID: <1110305601.25559.14.camel@rousalka.dyndns.org> Le mardi 08 mars 2005 ? 07:15 -0800, Anthony Green a ?crit : > On Tue, 2005-03-08 at 09:48 -0500, Vadim Nasardinov wrote: > > Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your > > machine? > > lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm > lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm > > Bah. Ok, the java-1.4.2-gcj-compat spec file says: > > Provides: jndi, jdbc-stdext > > So, do we need to play tricks for these, like I suggested for jta? Yep. The jvm framework does not actually cares about the rpm provides. What it wants is a jar in the places it scans (a symlink to another jar is fine). Typically for an in-jvm implementation you have to put a symlink in /usr/lib/jvm-exports/my_jvm_name/ to the jar providing the implementation in /usr/lib/jvm/my_jvm_name/ The symlink must have the standard name the apps want (in this case jdbc-stdext.jar and jndi.jar) This way the common scripts don't require any deep knowledge about every single jvm layout or capabilities - it's the jvm packager responsibility to create the few symlinks in its package that will inform the rest of the system of what his jvm can actually do. (this was originally done because IBM and SUN jvms had very different layouts but it should help even more for gcj since it does not even share the same roots as these other two). When stuff moves in-jvm all you have to do is create a symlink with the same name the jar in /usr/share/java used to have and you're done (plus of course add the relevant provides to the spec). Symlinks in /usr/lib/jvm-exports/my_jvm_name/ have priority wrt to stuff in /usr/share/java so you can even install simultaneously a jvm that absolutely want to use its own implementation and another that relies on the external /usr/share/java one. (this is all part of the JPackage framework - when in doubt you can consult the policy document in jpackage-utils %doc or ask on the jpackage-discuss ML) Regards, -- Nicolas Mailhot -------------- 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 Mar 8 18:13:59 2005 From: tromey at redhat.com (Tom Tromey) Date: 08 Mar 2005 11:13:59 -0700 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110222368.6220.39.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> Message-ID: >>>>> "Phil" == Phil Muldoon writes: Phil> Anybody else in the community have any comments on this, or other Phil> proposals? I'd like to get the ball rolling on this, and we can maybe Phil> get the implementation working before May and the final Fedora 4 Phil> release. I think the key point is that whatever we do has to be supported by eclipse.org. Any other way means maintaining our own build system. Ideally building an RPM for an Eclipse plugin should be nearly completely automatic. I don't see why we couldn't achieve this... but it depends on upstream cooperation. Tom From Nicolas.Mailhot at laPoste.net Tue Mar 8 18:17:48 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Mar 2005 19:17:48 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: <200503080948.11924@vadim.nasardinov> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> Message-ID: <1110305869.25559.20.camel@rousalka.dyndns.org> Le mardi 08 mars 2005 ? 09:48 -0500, Vadim Nasardinov a ?crit : > On Tuesday 08 March 2005 09:37, Anthony Green wrote: > > I started it up, and saw the process running until I tried to view a > > page, then the process died. Here are the contents > > of /var/log/tomcat5/catalina.out. Any ideas? > > > > Caused by: java.io.FileNotFoundException: > > /usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or > > directory) BTW it's wonderful that gcj actually gives a meaningful error on dangling symlinks instead of the strange crashes proprietary JVMs are prone to. Regards, -- Nicolas Mailhot -------------- 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 Mar 8 18:20:37 2005 From: tromey at redhat.com (Tom Tromey) Date: 08 Mar 2005 11:20:37 -0700 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <422DC9D1.5090702@redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> Message-ID: Bryce> Is resources.jar still used entirely uncompiled? We Bryce> should perhaps concentrate on that bug first. I think this bug is still undiagnosed. Bryce> Startup time is also an issue - we should be able to beat the JVM Bryce> easily here but currently we arn't. It would be worth profiling the Bryce> startup sequence to see if any obvious bottlenecks can be identified. Given Andrew's results from profiling jonas, I would venture to guess that stack trace performance is a problem. Last time we looked at Eclipse startup performance, the single biggest improvement was in this area. (People sometimes ask why Eclipse startup time matters. The performance of some other Eclipse operations, like opening a perspective, is related to the startup time -- a lot of the same sort of work happens. Improve startup time and you improve some other visible things in Eclipse.) Tom From pmuldoon at redhat.com Tue Mar 8 18:27:46 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 08 Mar 2005 12:27:46 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> Message-ID: <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> On Tue, 2005-03-08 at 11:13 -0700, Tom Tromey wrote: > >>>>> "Phil" == Phil Muldoon writes: > > Phil> Anybody else in the community have any comments on this, or other > Phil> proposals? I'd like to get the ball rolling on this, and we can maybe > Phil> get the implementation working before May and the final Fedora 4 > Phil> release. > > I think the key point is that whatever we do has to be supported by > eclipse.org. Any other way means maintaining our own build system. It's going to have to work with releng plug-ins then, as that is their build approach. Releng plug-ins produce tarballs now on a Linux platform, so we are halfway there. The releng plug-ins are fairly atomic in nature too, so it is all good. This is completely different to how jpackage.org build eclipse-* rpms, so pick one or the other I guess. > Ideally building an RPM for an Eclipse plug-in should be nearly > completely automatic. I don't see why we couldn't achieve this... but > it depends on upstream cooperation. Ben has some patches on eclipse.org (Ben can you post the direct link here), but I don't think it has seen any eclipse maintainer traffic. :( In building the RPM, are you proposing the the releng plug-in should deliver an RPM, or just a tarball like it delivers now? I can see merit in both ways, but how we would be add on all the %post/%postun stuff, and the actual jar -> so building bits on an automatic releng approach? All that stuff is pretty Fedora specific. If it is as it is now, the SPEC files for eclipse-* are totally generic in nature (were written that way), so it is sort of automatic. Not automatic enough, though ;) Regards Phil > > Tom > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From tromey at redhat.com Tue Mar 8 18:34:00 2005 From: tromey at redhat.com (Tom Tromey) Date: 08 Mar 2005 11:34:00 -0700 Subject: [fedora-java] tomcat5 In-Reply-To: <1110294932.10073.2.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm Anthony> Bah. Ok, the java-1.4.2-gcj-compat spec file says: Anthony> Provides: jndi, jdbc-stdext Anthony> So, do we need to play tricks for these, like I suggested for jta? When I look at my JDK installs, I don't see separate jdbc or jndi jars. Did something change here? (This machine is still on FC2...) Plus, afaik, jndi is in j2se. Tom From fitzsim at redhat.com Tue Mar 8 18:49:22 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 08 Mar 2005 13:49:22 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110294932.10073.2.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> Message-ID: <1110307762.23370.121.camel@tortoise.toronto.redhat.com> On Tue, 2005-03-08 at 07:15 -0800, Anthony Green wrote: >On Tue, 2005-03-08 at 09:48 -0500, Vadim Nasardinov wrote: >> Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your >> machine? > >lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm >lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm > >Bah. Ok, the java-1.4.2-gcj-compat spec file says: > >Provides: jndi, jdbc-stdext > Yeah, as far as I know, these are just empty provides right now. We need to fill them in with actual jars -- the question is, where do the free implementations come from? Tom From Nicolas.Mailhot at laPoste.net Tue Mar 8 19:11:54 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Mar 2005 20:11:54 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> Message-ID: <1110309115.25559.57.camel@rousalka.dyndns.org> Le mardi 08 mars 2005 ? 11:34 -0700, Tom Tromey a ?crit : > >>>>> "Anthony" == Anthony Green writes: > > Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm > Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm > > Anthony> Bah. Ok, the java-1.4.2-gcj-compat spec file says: > Anthony> Provides: jndi, jdbc-stdext > Anthony> So, do we need to play tricks for these, like I suggested for jta? > > When I look at my JDK installs, I don't see separate jdbc or jndi jars. > Did something change here? (This machine is still on FC2...) > Plus, afaik, jndi is in j2se. Tomcat5 was originally packaged for java 1.3.x - at that time jdbc and jndi lived outside the JVM. It's a testament to the framework strength that the same package works without changes on java 1.4.x. I agree now that all the JVMs JPackage supports include these bits both the requires and the symlinks seeds could be removed from the package. You have to remember though things move in-jvm every release and it's mightily nice to be able to hide these changes from the packages so you don't have to rewrite specs all the time (and you can use the same packages with a 1.x.y jvm and a 1.x+1.z jvm - think when Red Hat includes preview versions of the next gcc release along the current one in RHEL or FC) Of course pass must be able to use either the old out-of-jvm jar or the new in-jvm one without rebuild. This is usually the case for big projects like Tomcat. Regards, -- Nicolas Mailhot -------------- 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 Mar 8 19:24:32 2005 From: tromey at redhat.com (Tom Tromey) Date: 08 Mar 2005 12:24:32 -0700 Subject: [fedora-java] tomcat5 In-Reply-To: <1110309115.25559.57.camel@rousalka.dyndns.org> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> Message-ID: >>>>> "Nicolas" == Nicolas Mailhot writes: Nicolas> You have to remember though things move in-jvm every release Nicolas> and it's mightily nice to be able to hide these changes from Nicolas> the packages so you don't have to rewrite specs all the time Yeah... actually I'm fine with leaving things as they are. I just wasn't sure where these symlinks should point for libgcj. But it sounds like just pointing them at libgcj.jar should work. Tom From Nicolas.Mailhot at laPoste.net Tue Mar 8 19:40:29 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Mar 2005 20:40:29 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> Message-ID: <1110310831.25559.61.camel@rousalka.dyndns.org> Le mardi 08 mars 2005 ? 12:24 -0700, Tom Tromey a ?crit : > >>>>> "Nicolas" == Nicolas Mailhot writes: > > Nicolas> You have to remember though things move in-jvm every release > Nicolas> and it's mightily nice to be able to hide these changes from > Nicolas> the packages so you don't have to rewrite specs all the time > > Yeah... actually I'm fine with leaving things as they are. I just > wasn't sure where these symlinks should point for libgcj. But it > sounds like just pointing them at libgcj.jar should work. The symlinks are actually just a security (yes the jvm includes stuff we need). You can probably point them to any jar you like - if the stuff in internal to the jvm it'll be added to the classpath anyway. It's nicer to point them to the real implementation though, if only to document the jvm internal layout. regards, -- Nicolas Mailhot -------------- 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 bkonrath at redhat.com Tue Mar 8 20:39:58 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 08 Mar 2005 15:39:58 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> Message-ID: <1110314398.5527.61.camel@town.toronto.redhat.com> On Tue, 2005-03-08 at 12:27 -0600, Phil Muldoon wrote: > On Tue, 2005-03-08 at 11:13 -0700, Tom Tromey wrote: > > I think the key point is that whatever we do has to be supported by > > eclipse.org. Any other way means maintaining our own build system. > > It's going to have to work with releng plug-ins then, as that is their > build approach. Releng plug-ins produce tarballs now on a Linux > platform, so we are halfway there. The releng plug-ins are fairly > atomic in nature too, so it is all good. This is completely different to > how jpackage.org build eclipse-* rpms, so pick one or the other I guess. My proposal is definitely more in line with the releng build approach. For the first part of the proposal, I want to give the releng process the ability to generate a srcIncluded zips [1] for all plugins. This zip file would be very similar to what we generate ourselves right now. Part of this solution involves coming up with a way to build native code in an automatic way - at least from the perspective of the person building the plugin. Patches for this are in bugzilla but it needs a little more work (see below). For second part of the proposal, I want to extend this work so that plugins and features can generate the same srcIncluded zip without the need for a releng plugin. IMO, releng plugins are only needed if you want automatic builds of some kind - nightly builds or whatever. A lot of the open source plugins that I have come across generate their releases by calling one of the targets in the generated build.xml. So I'd like to add a target to the generated build.xml will make a srcIncluded zip. BTW, I updated the proposal again if you're interested. [1] zip files will be used because there are problems with eclipse and non-GNU tar. > > Ideally building an RPM for an Eclipse plug-in should be nearly > > completely automatic. I don't see why we couldn't achieve this... but > > it depends on upstream cooperation. > > Ben has some patches on eclipse.org (Ben can you post the direct link > here), but I don't think it has seen any eclipse maintainer traffic. :( The patches are posted here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=71637 I'm just waiting for some comments so that I can finish this part off. I suspect if I post a message to the releng mailing list now that my proposal is a little more developed, I would get a response. I've been distracted by this native eclipse stuff :) > In building the RPM, are you proposing the the releng plug-in should > deliver an RPM, or just a tarball like it delivers now? I can see merit > in both ways, but how we would be add on all the %post/%postun stuff, > and the actual jar -> so building bits on an automatic releng approach? > All that stuff is pretty Fedora specific. > > If it is as it is now, the SPEC files for eclipse-* are totally generic > in nature (were written that way), so it is sort of automatic. Not > automatic enough, though ;) If we get my proposed solution upstream, the spec files would become more generic - it might even be possible to write a small script to automatically package plugins. Cheers, Ben From jorton at redhat.com Tue Mar 8 20:56:19 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 8 Mar 2005 20:56:19 +0000 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <20050308154406.GC30854@redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> <20050308154406.GC30854@redhat.com> Message-ID: <20050308205618.GA19940@redhat.com> On Tue, Mar 08, 2005 at 10:44:06AM -0500, Andrew Overholt wrote: > * Anthony Green [2005-03-08 07:34]: ... > > This is troubling. This looks like the Eclipse compiler is broken on > > ia64. But surely we're using that compiler to build other things right > > now. Does anybody here know? > > There's a gcc backend bug (most likely) on ia64 right now so I can't build > Eclipse on it. We still have an older ecj build on ia64, though, so j-g-c > can build on it. We will have eclipse-ecj when I can build it on ia64. > > gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 So do I need to file a bug on this issue in Red Hat bugzilla or are is this "in progress"? I can't enable the Subversion javahl bindings until this is fixed. joe From pmuldoon at redhat.com Tue Mar 8 21:22:12 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 08 Mar 2005 15:22:12 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110314398.5527.61.camel@town.toronto.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> <1110314398.5527.61.camel@town.toronto.redhat.com> Message-ID: <1110316932.6768.40.camel@dhcp-12.hsv.redhat.com> On Tue, 2005-03-08 at 15:39 -0500, Ben Konrath wrote: > On Tue, 2005-03-08 at 12:27 -0600, Phil Muldoon wrote: > > On Tue, 2005-03-08 at 11:13 -0700, Tom Tromey wrote: > > > I think the key point is that whatever we do has to be supported by > > > eclipse.org. Any other way means maintaining our own build system. > > > > It's going to have to work with releng plug-ins then, as that is their > > build approach. Releng plug-ins produce tarballs now on a Linux > > platform, so we are halfway there. The releng plug-ins are fairly > > atomic in nature too, so it is all good. This is completely different to > > how jpackage.org build eclipse-* rpms, so pick one or the other I guess. > > My proposal is definitely more in line with the releng build approach. > For the first part of the proposal, I want to give the releng process > the ability to generate a srcIncluded zips [1] for all plugins. This zip > file would be very similar to what we generate ourselves right now. Part > of this solution involves coming up with a way to build native code in > an automatic way - at least from the perspective of the person building > the plugin. Patches for this are in bugzilla but it needs a little more > work (see below). Ok, just to make sure we are on the same track here. There are two definitions of native code when we talk about releng plugin stuff. Are you talking about when the project itself has to generate native code (like the CDT does for some bits, like the linux/win32/solaris etc fragments), which we have to do in the SPEC files manually (instead of using the packaged prebuilt .so's). Or the second definition, where we compile all the produced jars to .so's with gcj in the spec file? I suspect you are talking about the first, (fwiw I think the second case should always remain in the spec files). > > In building the RPM, are you proposing the the releng plug-in should > > deliver an RPM, or just a tarball like it delivers now? I can see merit > > in both ways, but how we would be add on all the %post/%postun stuff, > > and the actual jar -> so building bits on an automatic releng approach? > > All that stuff is pretty Fedora specific. > > > > If it is as it is now, the SPEC files for eclipse-* are totally generic > > in nature (were written that way), so it is sort of automatic. Not > > automatic enough, though ;) > > If we get my proposed solution upstream, the spec files would become > more generic - it might even be possible to write a small script to > automatically package plugins. I thought about doing this when I wrote up the original native plugin spec files for changelog/cdt etc, but each project is too quirky in its own little way. We might get to where you are proposing, it would sure be nice! This list sure has been busy today, which is great. Go-go fedora-devel- java-list! Phil From ziga.mahkovec at klika.si Tue Mar 8 21:32:17 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Tue, 08 Mar 2005 22:32:17 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110105522.15251.49.camel@localhost.localdomain> References: <1110105522.15251.49.camel@localhost.localdomain> Message-ID: <1110317537.10580.7.camel@localhost> On Sun, 2005-03-06 at 02:42 -0800, Anthony Green wrote: > ant and javac aren't currently using the natively-built Eclipse > compiler. > > We need to add something like the following to /usr/bin/ant in order to > pick up the .so files: > > [...] > > This will shave minutes off of the build times for some packages. I compared the compilation times for a simple HelloWorld class: ecj | ecj-native | jikes ------------------------------------------------------------- real 0m8.462s | real 0m8.624s | real 0m0.101s user 0m7.791s | user 0m8.230s | user 0m0.048s sys 0m0.093s | sys 0m0.083s | sys 0m0.006s (warm startups) I wanted to run the same test for the GNU Classpath library, but ecj kept throwing an internal compiler error (with or without your patch; I'll file a bug report). Anyway, the error is thrown after 32 seconds, while jikes compiles the entire library in 11 seconds. I suppose ecj would also profit from -O2? -- Ziga From bkonrath at redhat.com Tue Mar 8 21:41:21 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 08 Mar 2005 16:41:21 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110316932.6768.40.camel@dhcp-12.hsv.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> <1110314398.5527.61.camel@town.toronto.redhat.com> <1110316932.6768.40.camel@dhcp-12.hsv.redhat.com> Message-ID: <1110318081.5457.4.camel@town.toronto.redhat.com> On Tue, 2005-03-08 at 15:22 -0600, Phil Muldoon wrote: > Ok, just to make sure we are on the same track here. There are two > definitions of native code when we talk about releng plugin stuff. Are > you talking about when the project itself has to generate native code > (like the CDT does for some bits, like the linux/win32/solaris etc > fragments), which we have to do in the SPEC files manually (instead of > using the packaged prebuilt .so's). > > Or the second definition, where we compile all the produced jars > to .so's with gcj in the spec file? > > I suspect you are talking about the first, (fwiw I think the second case > should always remain in the spec files). Yeah, your suspicion is correct, I was referring to the first case you listed. I agree that the gcj jar -> so compilation should remain in the spec file. Cheers, Ben From mckinlay at redhat.com Tue Mar 8 23:01:25 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Tue, 08 Mar 2005 18:01:25 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110317537.10580.7.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> Message-ID: <422E2EC5.6060907@redhat.com> Ziga Mahkovec wrote: >I compared the compilation times for a simple HelloWorld class: > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 0m8.462s | real 0m8.624s | real 0m0.101s >user 0m7.791s | user 0m8.230s | user 0m0.048s >sys 0m0.093s | sys 0m0.083s | sys 0m0.006s > >(warm startups) > >I wanted to run the same test for the GNU Classpath library, but ecj >kept throwing an internal compiler error (with or without your patch; >I'll file a bug report). Anyway, the error is thrown after 32 seconds, >while jikes compiles the entire library in 11 seconds. > >I suppose ecj would also profit from -O2? > > Something is wrong here. It looks like your ecj is running interpreted both in the "ecj" and "ecj-native" cases. Bryce From ziga.mahkovec at klika.si Tue Mar 8 23:41:25 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 00:41:25 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <422E2EC5.6060907@redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> Message-ID: <1110325286.10580.11.camel@localhost> On Tue, 2005-03-08 at 18:01 -0500, Bryce McKinlay wrote: > Ziga Mahkovec wrote: > >I compared the compilation times for a simple HelloWorld class: > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 0m8.462s | real 0m8.624s | real 0m0.101s > >user 0m7.791s | user 0m8.230s | user 0m0.048s > >sys 0m0.093s | sys 0m0.083s | sys 0m0.006s > > > > [...] > > > Something is wrong here. It looks like your ecj is running interpreted > both in the "ecj" and "ecj-native" cases. $ rpm -q libgcj eclipse-ecj libgcj-4.0.0-0.30 eclipse-ecj-3.1.0_fc-0.M5.10 $ gcj-dbtool -l /usr/lib/eclipse/eclipse.db | wc -l 19865 $ export CLASSPATH=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar $ time gij -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db \ com.sun.tools.javac.Main HelloWorld.java real 0m8.687s user 0m8.591s sys 0m0.091s And strace indicates that eclipse.db is opened. Is there anything else I can check? -- Ziga From fitzsim at redhat.com Wed Mar 9 03:41:20 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 08 Mar 2005 22:41:20 -0500 Subject: [fedora-java] libgcj javadoc rpm In-Reply-To: <1109988666.7344.67.camel@localhost.localdomain> References: <1109988666.7344.67.camel@localhost.localdomain> Message-ID: <1110339680.23370.135.camel@tortoise.toronto.redhat.com> On Fri, 2005-03-04 at 18:11 -0800, Anthony Green wrote: >I just experimented with creating a noarch RPM for libgcj HTML javadoc. > >It uses gjdoc to generate HTML from the src.zip rawhide libgcj installs. >I don't know if this is the best way to go about it, but it was >convenient. > >I've placed the SRPM here for comment: > >http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm [3k] > >The RPM itself is 16MB, and it seems I'm out of space on >people.redhat.com. > >Comments and suggestions welcome.... > The plan is to ship the geronimo specs RPM, which includes a JTA implementation. This will happen in about a week, when Fernando packages it. Tom >Thanks, > >AG > > >-- >fedora-devel-java-list mailing list >fedora-devel-java-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From green at redhat.com Wed Mar 9 08:56:13 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 00:56:13 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <1110307762.23370.121.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> Message-ID: <1110358573.5536.0.camel@localhost.localdomain> On Tue, 2005-03-08 at 13:49 -0500, Thomas Fitzsimmons wrote: > > > >Bah. Ok, the java-1.4.2-gcj-compat spec file says: > > > >Provides: jndi, jdbc-stdext > > > > Yeah, as far as I know, these are just empty provides right now. We > need to fill them in with actual jars -- the question is, where do the > free implementations come from? Aren't they already in libgcj.jar? The only problem is how to make them available as jndi.jar and jdbc-stdext.jar (I guess). AG From green at redhat.com Wed Mar 9 08:57:23 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 00:57:23 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> Message-ID: <1110358643.5536.2.camel@localhost.localdomain> On Tue, 2005-03-08 at 12:24 -0700, Tom Tromey wrote: > >>>>> "Nicolas" == Nicolas Mailhot writes: > > Nicolas> You have to remember though things move in-jvm every release > Nicolas> and it's mightily nice to be able to hide these changes from > Nicolas> the packages so you don't have to rewrite specs all the time > > Yeah... actually I'm fine with leaving things as they are. I just > wasn't sure where these symlinks should point for libgcj. But it > sounds like just pointing them at libgcj.jar should work. Are you sure this won't cause problems for proprietary VMs when they want to load jndi.jar? They'll be looking at a jar file with all of the core classes. AG From green at redhat.com Wed Mar 9 09:04:24 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 01:04:24 -0800 Subject: [fedora-java] libgcj javadoc rpm In-Reply-To: <1110339680.23370.135.camel@tortoise.toronto.redhat.com> References: <1109988666.7344.67.camel@localhost.localdomain> <1110339680.23370.135.camel@tortoise.toronto.redhat.com> Message-ID: <1110359064.5536.10.camel@localhost.localdomain> (This thread was actually about javadoc for libgcj, but....) On Tue, 2005-03-08 at 22:41 -0500, Thomas Fitzsimmons wrote: > The plan is to ship the geronimo specs RPM, which includes a JTA > implementation. This will happen in about a week, when Fernando > packages it. We don't really need this for gcj, since libgcj already includes a JTA implementation. The only question is how to make the jta jar file available. I've been proposing extracting the bytecode from libgcj and putting it into a new jar file somewhere (the GCC spec file maybe). tromey just suggesting symlinking libgcj.jar to the missing jar files, and there's another proposal to create and use brand new RPMs (from libgcj/classpath source, or geronimo). AG From nicolas.mailhot at laposte.net Wed Mar 9 10:10:07 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 Mar 2005 11:10:07 +0100 (CET) Subject: [fedora-java] tomcat5 In-Reply-To: <1110358643.5536.2.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> <1110358643.5536.2.camel@localhost.localdomain> Message-ID: <27986.192.54.193.137.1110363007.squirrel@rousalka.dyndns.org> On Mer 9 mars 2005 9:57, Anthony Green a ?crit : > On Tue, 2005-03-08 at 12:24 -0700, Tom Tromey wrote: >> >>>>> "Nicolas" == Nicolas Mailhot writes: >> >> Nicolas> You have to remember though things move in-jvm every release >> Nicolas> and it's mightily nice to be able to hide these changes from >> Nicolas> the packages so you don't have to rewrite specs all the time >> >> Yeah... actually I'm fine with leaving things as they are. I just >> wasn't sure where these symlinks should point for libgcj. But it >> sounds like just pointing them at libgcj.jar should work. > > Are you sure this won't cause problems for proprietary VMs when they > want to load jndi.jar? They'll be looking at a jar file with all of the > core classes. That's why you put the symlinks in a very particular location (_NOT_ /usr/share/java) that is only inspected buy the common classpath scripts if the corresponding JVM is used. This is one of the main differences between Debian packaging and JPackage packaging - jars are not lumped in a single directory, they are isolated in separate parts of the filesystem to make sure they are never exposed to the wrong jvm. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Mar 9 10:12:21 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 Mar 2005 11:12:21 +0100 (CET) Subject: [fedora-java] tomcat5 In-Reply-To: <1110358573.5536.0.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> Message-ID: <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> On Mer 9 mars 2005 9:56, Anthony Green a ?crit : > On Tue, 2005-03-08 at 13:49 -0500, Thomas Fitzsimmons wrote: >> > >> >Bah. Ok, the java-1.4.2-gcj-compat spec file says: >> > >> >Provides: jndi, jdbc-stdext >> > >> >> Yeah, as far as I know, these are just empty provides right now. We >> need to fill them in with actual jars -- the question is, where do the >> free implementations come from? > > Aren't they already in libgcj.jar? The only problem is how to make them > available as jndi.jar and jdbc-stdext.jar (I guess). A look at how JPackage packages other JVMs (closed stuff I know:() would be pretty enlightening I think. I know the documentation can be hard to grasp without concrete examples. Regards, -- Nicolas Mailhot From bob.deblier at telenet.be Wed Mar 9 11:34:49 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Wed, 09 Mar 2005 12:34:49 +0100 Subject: [fedora-java] Self Introduction - Bob Deblier Message-ID: <1110368089.5528.16.camel@orion> Hi all, I'm the author of the BeeCrypt crypto library (already in Fedora, used by RPM), and as previously announced at FOSDEM 2005 in the GNU Classpath developer room, currently working on reviving a Java CSP which will use BeeCrypt's native routines. What I'm looking for is advice on the best approach to integrate building a CSP jar file, deriving native interface headers from multiple classes, followed by compiling a C shared library with the native code. My tentative approach is using autoconf to figure out if either gcj/gcjh or javac/javah is available, generate a build.xml file for Apache Ant. I have this working for Sun's JDK. Support for gcj should be easier once libgcj contains javax.crypto - is this planned for 4.0? Sincerely, Bob Deblier From gbenson at redhat.com Wed Mar 9 11:39:29 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 9 Mar 2005 11:39:29 +0000 Subject: [fedora-java] tomcat5 In-Reply-To: <1110310831.25559.61.camel@rousalka.dyndns.org> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> <1110310831.25559.61.camel@rousalka.dyndns.org> Message-ID: <20050309113928.GA5206@redhat.com> Nicolas Mailhot wrote: > Le mardi 08 mars 2005 ? 12:24 -0700, Tom Tromey a ?crit : > > >>>>> "Nicolas" == Nicolas Mailhot writes: > > > > Nicolas> You have to remember though things move in-jvm every > > Nicolas> release and it's mightily nice to be able to hide these > > Nicolas> changes from the packages so you don't have to rewrite > > Nicolas> specs all the time > > > > Yeah... actually I'm fine with leaving things as they are. I just > > wasn't sure where these symlinks should point for libgcj. But it > > sounds like just pointing them at libgcj.jar should work. > > The symlinks are actually just a security (yes the jvm includes > stuff we need). You can probably point them to any jar you like - if > the stuff in internal to the jvm it'll be added to the classpath > anyway. > > It's nicer to point them to the real implementation though, if only > to document the jvm internal layout. Would it be better perhaps to replace the symlinks with empty jar files? Or maybe jarfiles containing only a README to indicate that the classes that would be in there are now in the core classpath? Cheers, Gary From aph at redhat.com Wed Mar 9 11:41:41 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 11:41:41 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110325286.10580.11.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> Message-ID: <16942.57589.638526.568285@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Tue, 2005-03-08 at 18:01 -0500, Bryce McKinlay wrote: > > Ziga Mahkovec wrote: > > >I compared the compilation times for a simple HelloWorld class: > > > > > >ecj | ecj-native | jikes > > >------------------------------------------------------------- > > >real 0m8.462s | real 0m8.624s | real 0m0.101s > > >user 0m7.791s | user 0m8.230s | user 0m0.048s > > >sys 0m0.093s | sys 0m0.083s | sys 0m0.006s > > > > > > [...] > > > > > Something is wrong here. It looks like your ecj is running interpreted > > both in the "ecj" and "ecj-native" cases. > > $ rpm -q libgcj eclipse-ecj > libgcj-4.0.0-0.30 > eclipse-ecj-3.1.0_fc-0.M5.10 > $ gcj-dbtool -l /usr/lib/eclipse/eclipse.db | wc -l > 19865 > $ export CLASSPATH=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar > $ time gij -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db \ > com.sun.tools.javac.Main HelloWorld.java > > real 0m8.687s > user 0m8.591s > sys 0m0.091s > > > And strace indicates that eclipse.db is opened. Is there anything else > I can check? time gij -verbose:class ... Andrew. From aph at redhat.com Wed Mar 9 11:44:41 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 11:44:41 +0000 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <1110368089.5528.16.camel@orion> References: <1110368089.5528.16.camel@orion> Message-ID: <16942.57769.529784.160252@cuddles.cambridge.redhat.com> Bob Deblier writes: > > I'm the author of the BeeCrypt crypto library (already in Fedora, > used by RPM), and as previously announced at FOSDEM 2005 in the GNU > Classpath developer room, currently working on reviving a Java CSP > which will use BeeCrypt's native routines. Hello again. > What I'm looking for is advice on the best approach to integrate > building a CSP jar file, deriving native interface headers from > multiple classes, followed by compiling a C shared library with the > native code. Sounds good. This will be a once only job, will it? > My tentative approach is using autoconf to figure out if either gcj/gcjh > or javac/javah is available, generate a build.xml file for Apache Ant. I > have this working for Sun's JDK. Support for gcj should be easier once > libgcj contains javax.crypto - is this planned for 4.0? It seems to be there. Is there anything specific that you think might be missing? Andrew. From bob.deblier at telenet.be Wed Mar 9 12:11:01 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Wed, 09 Mar 2005 13:11:01 +0100 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <16942.57769.529784.160252@cuddles.cambridge.redhat.com> References: <1110368089.5528.16.camel@orion> <16942.57769.529784.160252@cuddles.cambridge.redhat.com> Message-ID: <1110370261.5528.29.camel@orion> On Wed, 2005-03-09 at 11:44 +0000, Andrew Haley wrote: > > at I'm looking for is advice on the best approach to integrate > > building a CSP jar file, deriving native interface headers from > > multiple classes, followed by compiling a C shared library with the > > native code. > > Sounds good. This will be a once only job, will it? Actually, what you suggest makes sense: headers to be generated once by me and included in the cvs and tarball - they shouldn't change. I was doing the following: - figure out which build system is available - generate the jar file with Ant - generate the header files from the jar file with Ant - compile the shared library > > My tentative approach is using autoconf to figure out if either gcj/gcjh > > or javac/javah is available, generate a build.xml file for Apache Ant. I > > have this working for Sun's JDK. Support for gcj should be easier once > > libgcj contains javax.crypto - is this planned for 4.0? > > It seems to be there. Is there anything specific that you think might > be missing? It's not in version 3.4.3-2 and probably should have investigated libgcj-4.0.0 before asking ;) Thanks, Bob From nicolas.mailhot at laposte.net Wed Mar 9 12:50:17 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 Mar 2005 13:50:17 +0100 (CET) Subject: [fedora-java] tomcat5 In-Reply-To: <20050309113928.GA5206@redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> <1110310831.25559.61.camel@rousalka.dyndns.org> <20050309113928.GA5206@redhat.com> Message-ID: <3287.192.54.193.137.1110372617.squirrel@rousalka.dyndns.org> On Mer 9 mars 2005 12:39, Gary Benson a ?crit : > Nicolas Mailhot wrote: >> The symlinks are actually just a security (yes the jvm includes >> stuff we need). You can probably point them to any jar you like - if >> the stuff in internal to the jvm it'll be added to the classpath >> anyway. >> >> It's nicer to point them to the real implementation though, if only >> to document the jvm internal layout. > > Would it be better perhaps to replace the symlinks with empty jar > files? Or maybe jarfiles containing only a README to indicate that > the classes that would be in there are now in the core classpath? Both would work - the classpath builder only cares about finding a file with the right name in the right place, and jvms only require real jar files (they don't handle well files with .jar extensions that are not a jar archive). I like symlinking the bits which provide the extension better (sometimes when you need to debug a crash it's convenient to have a symlink that shows you for example that the xml parser inside IBM jvms is just some xerces version), but that might only be pedantic me. I must say that if the problem is no one knows where the gcj bits that do jndi are it's a bit worrying in itself ;) Regards, -- Nicolas Mailhot From gbenson at redhat.com Wed Mar 9 12:50:58 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 9 Mar 2005 12:50:58 +0000 Subject: [fedora-java] Java Package Naming In-Reply-To: <421D44D4.2050703@carwyn.com> References: <421D44D4.2050703@carwyn.com> Message-ID: <20050309125058.GB5206@redhat.com> My apologies for taking so long to reply to this: mail to this list was ending up in another folder, and I only noticed yesterday. Carwyn Edwards wrote: > Q1. What are Fedora planning to do in relation to release tag naming > and jpp packages? > > At the moment Rawhide is using jpp_(fc|rh). > This seems a little at odds with the draft Fedora naming guidelines > (I know they've only just been written in draft :-)). There are no plans to deviate from the Xjpp_Yfc scheme we are currently using. We need to keep the Xjpp so that version comparisons work between JPackage and Fedora packages, and we need the Yfc to allow Fedora packages to be rebuilt to fix Fedora issues without requiring a corresponding rebuild in JPackage. This ought to be documented in the naming guidelines, and I'll look into it. > The motivation for this question is to do with our desire to ship > local modifications to jpp packages and still have a sensible > upgrade path. Up to now I've been able to simply tack on a suffix to > the jpp version. If however another upstream repo (FC) is also using > the suffix approach then things start to get interesting :-) > (1jpp_3fc vs 1jpp.1.local) I can't see adding another suffix causing a problem. > Q2. Are Fedora going to feed packages upstream as a priority then > tweak them for their local purposes afterwards? Another way of > asking this is - will FC Java packages that could also end up in > JPackage always going to have a Xjpp prefix in the release tag? If > not then things like this can happen: Yes, they'll always have the tag. Without it version comparisons between other JPackages would not give the required result. Besides, no Fedora package can be _identical_ to its corresponding JPackage so long as JPackages define Vendor tags and the like. Cheers, Gary [ gbenson at redhat.com ][ I am Red Hat ][ http://inauspicious.org/ ] From kuzman at gmail.com Wed Mar 9 12:51:43 2005 From: kuzman at gmail.com (Jeff Morgan) Date: Wed, 9 Mar 2005 07:51:43 -0500 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <1110368089.5528.16.camel@orion> References: <1110368089.5528.16.camel@orion> Message-ID: <28864c7b05030904512546c575@mail.gmail.com> On Wed, 09 Mar 2005 12:34:49 +0100, Bob Deblier wrote: > My tentative approach is using autoconf to figure out if either gcj/gcjh > or javac/javah is available, generate a build.xml file for Apache Ant. I > have this working for Sun's JDK. Support for gcj should be easier once > libgcj contains javax.crypto - is this planned for 4.0? Bob, why would you using autoconf to detect the correct libs, progs, and setup your makefiles only to generate a build.xml and invoke ant? To me it seems like you are introducting additional complexity and dependencies but I may be wrong. -- Jeffrey Morgan "The highest reward for a man's toil is not what he gets for it, but what he becomes by it" - Jon Ruskin From gbenson at redhat.com Wed Mar 9 12:52:29 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 9 Mar 2005 12:52:29 +0000 Subject: [fedora-java] tomcat5 In-Reply-To: <3287.192.54.193.137.1110372617.squirrel@rousalka.dyndns.org> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> <1110310831.25559.61.camel@rousalka.dyndns.org> <20050309113928.GA5206@redhat.com> <3287.192.54.193.137.1110372617.squirrel@rousalka.dyndns.org> Message-ID: <20050309125229.GC5206@redhat.com> Nicolas Mailhot wrote: > I like symlinking the bits which provide the extension better > (sometimes when you need to debug a crash it's convenient to have a > symlink that shows you for example that the xml parser inside IBM > jvms is just some xerces version), but that might only be pedantic > me. No, sounds reasonable to me. Cheers, Gary From bob.deblier at telenet.be Wed Mar 9 13:31:42 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Wed, 09 Mar 2005 14:31:42 +0100 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <28864c7b05030904512546c575@mail.gmail.com> References: <1110368089.5528.16.camel@orion> <28864c7b05030904512546c575@mail.gmail.com> Message-ID: <1110375102.5528.35.camel@orion> On Wed, 2005-03-09 at 07:51 -0500, Jeff Morgan wrote: > On Wed, 09 Mar 2005 12:34:49 +0100, Bob Deblier wrote: > > My tentative approach is using autoconf to figure out if either gcj/gcjh > > or javac/javah is available, generate a build.xml file for Apache Ant. I > > have this working for Sun's JDK. Support for gcj should be easier once > > libgcj contains javax.crypto - is this planned for 4.0? > > Bob, why would you using autoconf to detect the correct libs, progs, > and setup your makefiles only to generate a build.xml and invoke > ant? To me it seems like you are introducting additional complexity > and dependencies but I may be wrong. I started with generating build.xml to fill in the proper 'src' and 'build' directory properties; the next step was trying to detect which programs are available to build the jar. Bob From ziga.mahkovec at klika.si Wed Mar 9 13:38:59 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 14:38:59 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <16942.57589.638526.568285@cuddles.cambridge.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> Message-ID: <1110375539.5587.31.camel@localhost> On Wed, 2005-03-09 at 11:41 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > > Something is wrong here. It looks like your ecj is running interpreted > > > both in the "ecj" and "ecj-native" cases. > > > > [...] > > > > And strace indicates that eclipse.db is opened. Is there anything else > > I can check? > > time gij -verbose:class ... Thanks Andrew, I put the steps and log files here: http://www.bootchart.org/misc/ecj/ecj-native.html It seems that ecj was actually running native in both cases (with or without gnu.gcj.precompiled.db.path). Which, looking at the source code for com.sun.tools.javac.Main, seems right: @71 loader = new URLClassLoader(new URL[] { new URL("gcjlib://" + Config.ECJLIB_INST_DIR + "/" + libname)}); (libname being "lib-org-eclipse-jdt.so") Moving lib-org-eclipse-jdt.so out of the way speeds up gij/ecj considerably. Shouldn't precompiled libraries be configured in runtime, as opposed to in Main.java? And I'm not sure why it's actually faster when running interpreted. -- Ziga From aph at redhat.com Wed Mar 9 14:08:56 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 14:08:56 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110375539.5587.31.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> Message-ID: <16943.888.428446.685556@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Wed, 2005-03-09 at 11:41 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > > Something is wrong here. It looks like your ecj is running interpreted > > > > both in the "ecj" and "ecj-native" cases. > > > > > > [...] > > > > > > And strace indicates that eclipse.db is opened. Is there anything else > > > I can check? > > > > time gij -verbose:class ... > > Thanks Andrew, I put the steps and log files here: > http://www.bootchart.org/misc/ecj/ecj-native.html You didn't try -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without jdtcore.jar.so. > It seems that ecj was actually running native in both cases (with or > without gnu.gcj.precompiled.db.path). Which, looking at the source code > for com.sun.tools.javac.Main, seems right: > > @71 > loader = new URLClassLoader(new URL[] { > new URL("gcjlib://" + Config.ECJLIB_INST_DIR + "/" + libname)}); > > (libname being "lib-org-eclipse-jdt.so") > > Moving lib-org-eclipse-jdt.so out of the way speeds up gij/ecj > considerably. > > Shouldn't precompiled libraries be configured in runtime, as opposed to > in Main.java? And I'm not sure why it's actually faster when running > interpreted. This is bizarre. Profiling would tell us. Andrew. From ziga.mahkovec at klika.si Wed Mar 9 14:39:03 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 15:39:03 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <16943.888.428446.685556@cuddles.cambridge.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> Message-ID: <1110379143.5587.41.camel@localhost> On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > Thanks Andrew, I put the steps and log files here: > > http://www.bootchart.org/misc/ecj/ecj-native.html > > You didn't try > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > jdtcore.jar.so. Updated page. I guess this is the same as running interpreted, since most of the class lookups fail. I'll also try changing tools.jar to use the standard class loader instead and see if it changes anything. -- Ziga From aph at redhat.com Wed Mar 9 14:44:39 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 14:44:39 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110379143.5587.41.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> Message-ID: <16943.3031.961762.318989@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > Thanks Andrew, I put the steps and log files here: > > > http://www.bootchart.org/misc/ecj/ecj-native.html > > > > You didn't try > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > > jdtcore.jar.so. > > Updated page. I guess this is the same as running interpreted, since > most of the class lookups fail. It is: it seems that you don't have a precompiled version of /usr/share/java/jdtcore.jar in your eclipse.db. Either that, or the corresponding precompiled library isn't readable. We only fall back to loading bytecode if something fails. Andrew. From ziga.mahkovec at klika.si Wed Mar 9 14:59:23 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 15:59:23 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <16943.3031.961762.318989@cuddles.cambridge.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> Message-ID: <1110380363.5587.49.camel@localhost> On Wed, 2005-03-09 at 14:44 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > > > Ziga Mahkovec writes: > > > > Thanks Andrew, I put the steps and log files here: > > > > http://www.bootchart.org/misc/ecj/ecj-native.html > > > > > > You didn't try > > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > > > jdtcore.jar.so. > > > > Updated page. I guess this is the same as running interpreted, since > > most of the class lookups fail. > > It is: it seems that you don't have a precompiled version of > /usr/share/java/jdtcore.jar in your eclipse.db. Either that, or the > corresponding precompiled library isn't readable. The corresponding library is /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so right? I do have it in eclipse.db, but for the last two tests I renamed it, in order to force tools.jar to not use the gcjlib:// class loader. That's why I didn't include the additional test (gnu.gcj.precompiled.db.path without jdtcore.jar.so) in the first place. -- Ziga From aph at redhat.com Wed Mar 9 15:04:12 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 15:04:12 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110380363.5587.49.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> Message-ID: <16943.4204.355394.783901@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Wed, 2005-03-09 at 14:44 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > > > > Ziga Mahkovec writes: > > > > > Thanks Andrew, I put the steps and log files here: > > > > > http://www.bootchart.org/misc/ecj/ecj-native.html > > > > > > > > You didn't try > > > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > > > > jdtcore.jar.so. > > > > > > Updated page. I guess this is the same as running interpreted, since > > > most of the class lookups fail. > > > > It is: it seems that you don't have a precompiled version of > > /usr/share/java/jdtcore.jar in your eclipse.db. Either that, or the > > corresponding precompiled library isn't readable. > > The corresponding library > is /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so > right? I would guess so, but I don't know. > I do have it in eclipse.db, but for the last two tests I renamed it, in > order to force tools.jar to not use the gcjlib:// class loader. I see. Of course, I have no idea why tools.jar is attempting to use the gcjlib:// class loader, or why it is so slow when it does. It really should not explicitly use this class loader. > That's why I didn't include the additional test > (gnu.gcj.precompiled.db.path without jdtcore.jar.so) in the first > place. Yes, I see. Do you by any chance happen to have oprofile? Andrew. From green at redhat.com Wed Mar 9 15:25:04 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 07:25:04 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> Message-ID: <1110381905.5536.19.camel@localhost.localdomain> On Wed, 2005-03-09 at 11:12 +0100, Nicolas Mailhot wrote: > A look at how JPackage packages other JVMs (closed stuff I know:() would > be pretty enlightening I think. I know the documentation can be hard to > grasp without concrete examples. Ok, I think the answer is that java-gcj-compat needs to create the following symlinks... # ls -l /usr/lib/jvm-exports/java-1.4.2-gcj-1.4.2.0/ total 12 lrwxrwxrwx 1 root root 32 Mar 9 07:13 jaas.jar -> /usr/share/java/libgcj-4.0.0.jar lrwxrwxrwx 1 root root 32 Mar 9 07:11 jdbc-stdext.jar -> /usr/share/java/libgcj-4.0.0.jar lrwxrwxrwx 1 root root 32 Mar 9 07:11 jndi.jar -> /usr/share/java/libgcj-4.0.0.jar fitzsim: do you agree? Now tomcat5 gets a lot further, and we hit something new.... # cat /var/log/tomcat5/catalina.out Bootstrap: Class loader creation threw exception java.lang.NoClassDefFoundError: while resolving class: javax.management.MBeanServerFactory 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.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) at org.apache.catalina.startup.Bootstrap.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.ClassNotFoundException: mx4j.log.Logger not found in gnu.gcj.runtime.SystemClassLoader{urls=[], parent=gnu.gcj.runtime.VMClassLoader{urls=[file:/usr/share/java/ext/com-sun-tools-doclets-Taglet-0.7.1.jar], 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.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.6.0.0) ...8 more We have this class installed, so presumably the class loader's class path is wrong somehow. AG From fitzsim at redhat.com Wed Mar 9 16:24:07 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 11:24:07 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110381905.5536.19.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> Message-ID: <1110385447.23370.149.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 07:25 -0800, Anthony Green wrote: >On Wed, 2005-03-09 at 11:12 +0100, Nicolas Mailhot wrote: >> A look at how JPackage packages other JVMs (closed stuff I know:() would >> be pretty enlightening I think. I know the documentation can be hard to >> grasp without concrete examples. > >Ok, I think the answer is that java-gcj-compat needs to create the >following symlinks... > ># ls -l /usr/lib/jvm-exports/java-1.4.2-gcj-1.4.2.0/ >total 12 >lrwxrwxrwx 1 root root 32 Mar 9 07:13 jaas.jar -> /usr/share/java/libgcj-4.0.0.jar >lrwxrwxrwx 1 root root 32 Mar 9 07:11 jdbc-stdext.jar -> /usr/share/java/libgcj-4.0.0.jar >lrwxrwxrwx 1 root root 32 Mar 9 07:11 jndi.jar -> /usr/share/java/libgcj-4.0.0.jar > >fitzsim: do you agree? > I've got new java-1.4.2-gcj-compat packages here that add these symlinks. I'm holding off building them into beehive until FC4test1 has branched. >Now tomcat5 gets a lot further, and we hit something new.... > ># cat /var/log/tomcat5/catalina.out >Bootstrap: Class loader creation threw exception >java.lang.NoClassDefFoundError: while resolving class: javax.management.MBeanServerFactory > 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.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) > at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) > at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) > at org.apache.catalina.startup.Bootstrap.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.ClassNotFoundException: mx4j.log.Logger not found in gnu.gcj.runtime.SystemClassLoader{urls=[], parent=gnu.gcj.runtime.VMClassLoader{urls=[file:/usr/share/java/ext/com-sun-tools-doclets-Taglet-0.7.1.jar], parent=null}} I've been seeing that message too. First of all, why does the urls field of VMClassLoader not print *all* jars in the extensions directory? Is this a libgcj bug? The other annoying thing is the difference between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. We either need to change the JPackage standard to point to /usr/share/java/ext or we need to hard-code /usr/share/java-ext and /usr/lib/java-ext into libgcj as extensions directories. Defining java.ext.dirs in all the wrapper scripts is turning out to be quite fragile. In this case the mx4j jar probably installs in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. Tom From fitzsim at redhat.com Wed Mar 9 16:38:42 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 11:38:42 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <16943.4204.355394.783901@cuddles.cambridge.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> Message-ID: <1110386322.23370.159.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 15:04 +0000, Andrew Haley wrote: >Ziga Mahkovec writes: > > On Wed, 2005-03-09 at 14:44 +0000, Andrew Haley wrote: > > > Ziga Mahkovec writes: > > > > On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > > > > > Ziga Mahkovec writes: > > > > > > Thanks Andrew, I put the steps and log files here: > > > > > > http://www.bootchart.org/misc/ecj/ecj-native.html > > > > > > > > > > You didn't try > > > > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > > > > > jdtcore.jar.so. > > > > > > > > Updated page. I guess this is the same as running interpreted, since > > > > most of the class lookups fail. > > > > > > It is: it seems that you don't have a precompiled version of > > > /usr/share/java/jdtcore.jar in your eclipse.db. Either that, or the > > > corresponding precompiled library isn't readable. > > > > The corresponding library > > is /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so > > right? > >I would guess so, but I don't know. > > > I do have it in eclipse.db, but for the last two tests I renamed it, in > > order to force tools.jar to not use the gcjlib:// class loader. > >I see. Of course, I have no idea why tools.jar is attempting to use >the gcjlib:// class loader, or why it is so slow when it does. It >really should not explicitly use this class loader. > I doesn't any more. We were doing that to avoid having to always add jdtcore.jar to the classpath. I also have no idea why it's so slow but I did notice a significant performance hit when compared to interpreted mode. Ziga, you can get the sources for java-gcj-compat from sources.redhat.com: cvs -d :pserver:anoncvs at sources.redhat.com:/cvs/rhug co java-gcj-compat I've removed gcjlib:// loading in favour of using the database, so when everything's set up properly ecj should run natively using jdtcore.jar.so. Tom From green at redhat.com Wed Mar 9 17:20:20 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 09:20:20 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <1110385447.23370.149.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> Message-ID: <1110388820.5536.24.camel@localhost.localdomain> On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: > I've been seeing that message too. First of all, why does the urls > field of VMClassLoader not print *all* jars in the extensions directory? > Is this a libgcj bug? It certainly looks that way. > The other annoying thing is the difference > between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. > We either need to change the JPackage standard to point > to /usr/share/java/ext or we need to hard-code /usr/share/java-ext > and /usr/lib/java-ext into libgcj as extensions directories. Defining > java.ext.dirs in all the wrapper scripts is turning out to be quite > fragile. In this case the mx4j jar probably installs > in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting > set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. I don't think that's really the problem, since mx4j doesn't install in any extensions directory. It probably should for gcj at least, since it's included in Sun's rt.jar. But it seems that gcj should have it's own extension directory. jmx is also set up to use "alternatives". I don't know what the right answer is. Suggestions? AG From vadimn at redhat.com Wed Mar 9 17:31:25 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Wed, 9 Mar 2005 12:31:25 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110388820.5536.24.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> Message-ID: <200503091231.25707@vadim.nasardinov> On Wednesday 09 March 2005 12:20, Anthony Green wrote: > I don't think that's really the problem, since mx4j doesn't install > in any extensions directory. It probably should for gcj at least, > since it's included in Sun's rt.jar. This doesn't parse. What's included in Sun's rt.jar? MX4J? From green at redhat.com Wed Mar 9 17:51:04 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 09:51:04 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <200503091231.25707@vadim.nasardinov> References: <1110292630.5352.8.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> <200503091231.25707@vadim.nasardinov> Message-ID: <1110390664.5536.26.camel@localhost.localdomain> On Wed, 2005-03-09 at 12:31 -0500, Vadim Nasardinov wrote: > On Wednesday 09 March 2005 12:20, Anthony Green wrote: > > I don't think that's really the problem, since mx4j doesn't install > > in any extensions directory. It probably should for gcj at least, > > since it's included in Sun's rt.jar. > > This doesn't parse. What's included in Sun's rt.jar? MX4J? Yes, it looks that way. AG From vadimn at redhat.com Wed Mar 9 18:03:12 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Wed, 9 Mar 2005 13:03:12 -0500 Subject: JMX and JMX Remote (was: Re: [fedora-java] tomcat5) In-Reply-To: <1110390664.5536.26.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503091231.25707@vadim.nasardinov> <1110390664.5536.26.camel@localhost.localdomain> Message-ID: <200503091303.12133@vadim.nasardinov> On Wednesday 09 March 2005 12:51, Anthony Green wrote: > > This doesn't parse. What's included in Sun's rt.jar? MX4J? > > Yes, it looks that way. It doesn't quite look that way from where I sit. MX4J is an implementation of JMX and JMX Remote. These *are* included in J2SE 1.5 (5.0): http://java.sun.com/j2se/1.5.0/docs/api/javax/management/package-frame.html http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/package-frame.html However, they are not part of J2SE 1.4: http://java.sun.com/j2se/1.4.2/docs/api/overview-frame.html You have to download these separately, if you want to use Sun's reference implementation under JDK 1.4: http://java.sun.com/products/JavaManagement/download.html Are we both looking at the same thing? From Nicolas.Mailhot at laPoste.net Wed Mar 9 18:03:19 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 09 Mar 2005 19:03:19 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: <1110390664.5536.26.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> <200503091231.25707@vadim.nasardinov> <1110390664.5536.26.camel@localhost.localdomain> Message-ID: <1110391399.3276.2.camel@rousalka.dyndns.org> Le mercredi 09 mars 2005 ? 09:51 -0800, Anthony Green a ?crit : > On Wed, 2005-03-09 at 12:31 -0500, Vadim Nasardinov wrote: > > On Wednesday 09 March 2005 12:20, Anthony Green wrote: > > > I don't think that's really the problem, since mx4j doesn't install > > > in any extensions directory. It probably should for gcj at least, > > > since it's included in Sun's rt.jar. > > > > This doesn't parse. What's included in Sun's rt.jar? MX4J? > > Yes, it looks that way. Are you sure you're not talking about jmx (http://java.sun.com/products/JavaManagement/ ?) I'd be astounded if Sun dropped its own implementation for a FOSS clone. Regards, -- Nicolas Mailhot -------------- 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 fitzsim at redhat.com Wed Mar 9 18:17:15 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 13:17:15 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110388820.5536.24.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> Message-ID: <1110392235.23370.166.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 09:20 -0800, Anthony Green wrote: >On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: >> I've been seeing that message too. First of all, why does the urls >> field of VMClassLoader not print *all* jars in the extensions directory? >> Is this a libgcj bug? > >It certainly looks that way. > >> The other annoying thing is the difference >> between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. >> We either need to change the JPackage standard to point >> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext >> and /usr/lib/java-ext into libgcj as extensions directories. Defining >> java.ext.dirs in all the wrapper scripts is turning out to be quite >> fragile. In this case the mx4j jar probably installs >> in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting >> set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. > >I don't think that's really the problem, since mx4j doesn't install in >any extensions directory. It probably should for gcj at least, since >it's included in Sun's rt.jar. > >But it seems that gcj should have it's own extension directory. > That's a good idea. Then we wouldn't have all these problems associated with trying to match Sun's JAR layouts (e.g. classpathx-mail embedding an inetlib implementation, ugh). We could just create jar file symlinks (mostly to libgcj.jar) for programs that look for the actual jars. Everything else they needed (e.g. providers) would transparently be included on CLASSPATH by way of the gcj extensions directory. In fact, we could just keep using /usr/share/java/ext for that purpose. What are the ramifications of putting jars in the extension directories? Tom From fitzsim at redhat.com Wed Mar 9 18:27:42 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 13:27:42 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110392235.23370.166.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> <1110392235.23370.166.camel@tortoise.toronto.redhat.com> Message-ID: <1110392862.23370.173.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 13:17 -0500, Thomas Fitzsimmons wrote: >On Wed, 2005-03-09 at 09:20 -0800, Anthony Green wrote: >>On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: >>> I've been seeing that message too. First of all, why does the urls >>> field of VMClassLoader not print *all* jars in the extensions directory? >>> Is this a libgcj bug? >> >>It certainly looks that way. >> >>> The other annoying thing is the difference >>> between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. >>> We either need to change the JPackage standard to point >>> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext >>> and /usr/lib/java-ext into libgcj as extensions directories. Defining >>> java.ext.dirs in all the wrapper scripts is turning out to be quite >>> fragile. In this case the mx4j jar probably installs >>> in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting >>> set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. >> >>I don't think that's really the problem, since mx4j doesn't install in >>any extensions directory. It probably should for gcj at least, since >>it's included in Sun's rt.jar. >> >>But it seems that gcj should have it's own extension directory. >> > >That's a good idea. Then we wouldn't have all these problems associated >with trying to match Sun's JAR layouts (e.g. classpathx-mail embedding >an inetlib implementation, ugh). We could just create jar file symlinks >(mostly to libgcj.jar) for programs that look for the actual jars. >Everything else they needed (e.g. providers) would transparently be >included on CLASSPATH by way of the gcj extensions directory. In fact, >we could just keep using /usr/share/java/ext for that purpose. What are >the ramifications of putting jars in the extension directories? > I guess there's a problem with this from the JPackage-purity perspective. Should the JPackage conventions mandate putting jar files in /usr/share/java/ext, where they're necessary for gcj inter-operation? Tom From tromey at redhat.com Wed Mar 9 18:34:32 2005 From: tromey at redhat.com (Tom Tromey) Date: 09 Mar 2005 11:34:32 -0700 Subject: [fedora-java] tomcat5 In-Reply-To: <1110385447.23370.149.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> Message-ID: >>>>> "Tom" == Thomas Fitzsimmons writes: Tom> I've been seeing that message too. First of all, why does the urls Tom> field of VMClassLoader not print *all* jars in the extensions directory? I looked into this. The problem is, URLClassLoader caches the toString() result but does not reset it when a new URL is added. Whoops. All the jars definitely do end up in there though, at least in my simple test. Tom> We either need to change the JPackage standard to point Tom> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext Tom> and /usr/lib/java-ext into libgcj as extensions directories. We can easily add a configuration option for this. If we only need one directory we could just have our RPM install a symlink (the compiled-in extdir is not created by the gcc install process). Tom From green at redhat.com Wed Mar 9 18:36:16 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 10:36:16 -0800 Subject: JMX and JMX Remote (was: Re: [fedora-java] tomcat5) In-Reply-To: <200503091303.12133@vadim.nasardinov> References: <1110292630.5352.8.camel@localhost.localdomain> <200503091231.25707@vadim.nasardinov> <1110390664.5536.26.camel@localhost.localdomain> <200503091303.12133@vadim.nasardinov> Message-ID: <1110393376.5536.28.camel@localhost.localdomain> On Wed, 2005-03-09 at 13:03 -0500, Vadim Nasardinov wrote: > Are we both looking at the same thing? Ah, right - I was looking at a 1.5 system. AG From aph at redhat.com Wed Mar 9 18:47:23 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 18:47:23 +0000 Subject: [fedora-java] tomcat5 In-Reply-To: References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> Message-ID: <16943.17595.907330.871405@cuddles.cambridge.redhat.com> Tom Tromey writes: > >>>>> "Tom" == Thomas Fitzsimmons writes: > > Tom> I've been seeing that message too. First of all, why does the urls > Tom> field of VMClassLoader not print *all* jars in the extensions directory? > > I looked into this. The problem is, URLClassLoader caches the > toString() result but does not reset it when a new URL is added. > Whoops. Where's this? Andrew. From Nicolas.Mailhot at laPoste.net Wed Mar 9 18:47:33 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 09 Mar 2005 19:47:33 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: <1110392235.23370.166.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> <1110392235.23370.166.camel@tortoise.toronto.redhat.com> Message-ID: <1110394058.3276.12.camel@rousalka.dyndns.org> Le mercredi 09 mars 2005 ? 13:17 -0500, Thomas Fitzsimmons a ?crit : > On Wed, 2005-03-09 at 09:20 -0800, Anthony Green wrote: > >On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: > >> I've been seeing that message too. First of all, why does the urls > >> field of VMClassLoader not print *all* jars in the extensions directory? > >> Is this a libgcj bug? > > > >It certainly looks that way. > > > >> The other annoying thing is the difference > >> between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. > >> We either need to change the JPackage standard to point > >> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext > >> and /usr/lib/java-ext into libgcj as extensions directories. Defining > >> java.ext.dirs in all the wrapper scripts is turning out to be quite > >> fragile. In this case the mx4j jar probably installs > >> in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting > >> set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. > > > >I don't think that's really the problem, since mx4j doesn't install in > >any extensions directory. It probably should for gcj at least, since > >it's included in Sun's rt.jar. > > > >But it seems that gcj should have it's own extension directory. > > > > That's a good idea. Then we wouldn't have all these problems associated > with trying to match Sun's JAR layouts (e.g. classpathx-mail embedding > an inetlib implementation, ugh). We could just create jar file symlinks > (mostly to libgcj.jar) for programs that look for the actual jars. > Everything else they needed (e.g. providers) would transparently be > included on CLASSPATH by way of the gcj extensions directory. In fact, > we could just keep using /usr/share/java/ext for that purpose. What are > the ramifications of putting jars in the extension directories? Please don't use /usr/share/java/ext. You'll get into big problems the day two gcj versions are deployed in parallel (think gcc4) if they share the same extension dir. It's much easier to have separate dirs (possibly with symlinks pointing to a common pool) than to handle things like "I want to include all the jars in this dir except this one which is used by another version". This being said, the way JPackage does stuff is not fixed in stone, it can change for the next release if people think it could get better. (only please remember we have already a full repo built around the current rules, so don't ask for changes just for cosmetic value) Regards, -- Nicolas Mailhot -------------- 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 aph at redhat.com Wed Mar 9 19:10:00 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 19:10:00 +0000 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <1110370261.5528.29.camel@orion> References: <1110368089.5528.16.camel@orion> <16942.57769.529784.160252@cuddles.cambridge.redhat.com> <1110370261.5528.29.camel@orion> Message-ID: <16943.18952.421815.801158@cuddles.cambridge.redhat.com> Bob Deblier writes: > On Wed, 2005-03-09 at 11:44 +0000, Andrew Haley wrote: > > > at I'm looking for is advice on the best approach to integrate > > > building a CSP jar file, deriving native interface headers from > > > multiple classes, followed by compiling a C shared library with the > > > native code. > > > > Sounds good. This will be a once only job, will it? > > Actually, what you suggest makes sense: headers to be generated once by > me and included in the cvs and tarball - they shouldn't change. I was > doing the following: > - figure out which build system is available > - generate the jar file with Ant > - generate the header files from the jar file with Ant > - compile the shared library > > > > My tentative approach is using autoconf to figure out if either gcj/gcjh > > > or javac/javah is available, generate a build.xml file for Apache Ant. I > > > have this working for Sun's JDK. Support for gcj should be easier once > > > libgcj contains javax.crypto - is this planned for 4.0? > > > > It seems to be there. Is there anything specific that you think might > > be missing? > > It's not in version 3.4.3-2 and probably should have investigated > libgcj-4.0.0 before asking ;) Don't take my word for it! Please have a look to see if what you need is there. I am not an expert in this area. Andrew. From rmoseley at redhat.com Wed Mar 9 20:39:57 2005 From: rmoseley at redhat.com (Rick Moseley) Date: Wed, 09 Mar 2005 14:39:57 -0600 Subject: [fedora-java] Interesting articles on Java/Eclipse Message-ID: <422F5F1D.8040909@redhat.com> JAVA VS. MICROSOFT .NET DEBATE RAGES LAS VEGAS -- After describing Java as a stable technology with no great surprises likely to come, Java experts during a conference panel session fielded questions about the competitive power of Microsoft's rival .Net platform. http://newsletter.infoworld.com/t?ctl=C1872C:1F60395 ====================================================================== IBM: ECLIPSE FACES CHALLENGES AHEAD BURLINGAME, CALIF. - Eclipse will have to deal with its own success and the challenges that success presents, said Lee Nackman, a CTO and vice president at IBM Rational Software who was involved in founding the open source platform. http://newsletter.infoworld.com/t?ctl=C18729:1F60395 ====================================================================== JAVA STAVING OFF .NET, SPRING FOUNDER SAYS LAS VEGAS -- J2EE technology is in a very healthy state, staving off the rival .Net platform and fostering innovation, said Rod Johnson, founder of the open source Spring Framework for Java development, in a presentation on Friday. http://newsletter.infoworld.com/t?ctl=C1872A:1F60395 ====================================================================== ECLIPSE CHIEF TALKS UP PROJECTS, AWAITS SUN AND MICROSOFT The Eclipse Foundation for open source tools held its technical conference, EclipseCon 2005, in Burlingame, Calif., the week of Feb. 28. Stressing its momentum, the organization touted participation frrm vendors such as BEA Systems, Borland Socqftware, Computer Associates International, and Sybase. Mike Milinkovich, a former Oracle vice president of technical services, became the first executive director of the independent foundation when Eclipse was spun out of IBM last year. InfoWorld Editor at Large Paul Krill discussed Eclipse goings-on and impacts with Milinkovich. http://newsletter.infoworld.com/t?ctl=C1872D:1F60395 ====================================================================== From green at redhat.com Wed Mar 9 21:01:37 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 13:01:37 -0800 Subject: mx4j (Was: [fedora-java] tomcat5) In-Reply-To: <1110381905.5536.19.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> Message-ID: <1110402097.5536.40.camel@localhost.localdomain> I looked at this a little further... On Wed, 2005-03-09 at 07:25 -0800, Anthony Green wrote: > Now tomcat5 gets a lot further, and we hit something new.... > > # cat /var/log/tomcat5/catalina.out > Bootstrap: Class loader creation threw exception > java.lang.NoClassDefFoundError: while resolving class: javax.management.MBeanServerFactory > 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.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) > at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) > at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) > at org.apache.catalina.startup.Bootstrap.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.ClassNotFoundException: mx4j.log.Logger not found in gnu.gcj.runtime.SystemClassLoader{urls=[], parent=gnu.gcj.runtime.VMClassLoader{urls=[file:/usr/share/java/ext/com-sun-tools-doclets-Taglet-0.7.1.jar], 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.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.6.0.0) > ...8 more The tomcat5 startup script uses JPackage's rebuild-jar-repository script to construct a directory of jar files for the server to use. One of these is [jmxri].jar. So it symlinks to /usr/share/java/jmxri.jar, which is itself a symlink since jmx appears to be managed by alternatives. We eventually get to /usr/share/java/mx4j/mx4j-jmx.jar. Unfortunately, this jar has external dependencies on other jar files in /usr/share/java/mx4j. How is rebuild-jar-repository or tomcat5 supposed to know this? We end up with an incomplete jar repository, which is causing this problem. Is there a good and simple solution to this problem? AG From tromey at redhat.com Wed Mar 9 21:06:50 2005 From: tromey at redhat.com (Tom Tromey) Date: 09 Mar 2005 14:06:50 -0700 Subject: [fedora-java] tomcat5 In-Reply-To: <16943.17595.907330.871405@cuddles.cambridge.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <16943.17595.907330.871405@cuddles.cambridge.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: >> I looked into this. The problem is, URLClassLoader caches the >> toString() result but does not reset it when a new URL is added. >> Whoops. Andrew> Where's this? We talked about this on irc but I thought I'd follow-up for the record. It is just a small bug in URLClassLoader; addURL has to clear the cached toString() result. This is now fixed in libgcj and classpath. Tom From ziga.mahkovec at klika.si Wed Mar 9 21:24:15 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 22:24:15 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110386322.23370.159.camel@tortoise.toronto.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> Message-ID: <1110403455.5553.11.camel@localhost> On Wed, 2005-03-09 at 11:38 -0500, Thomas Fitzsimmons wrote: > On Wed, 2005-03-09 at 15:04 +0000, Andrew Haley wrote: > >I see. Of course, I have no idea why tools.jar is attempting to use > >the gcjlib:// class loader, or why it is so slow when it does. It > >really should not explicitly use this class loader. > > I doesn't any more. We were doing that to avoid having to always add > jdtcore.jar to the classpath. I also have no idea why it's so slow but > I did notice a significant performance hit when compared to interpreted > mode. > > Ziga, you can get the sources for java-gcj-compat from > sources.redhat.com: Ah, much better, thanks. Here are the revised times (BTW, that's a 1.5GHz Pentium M): HelloWorld ecj | ecj-native | jikes ------------------------------------------------------------- real 0m1.863s | real 0m1.614s | real 0m0.067s user 0m1.758s | user 0m1.536s | user 0m0.050s sys 0m0.103s | sys 0m0.076s | sys 0m0.012s GNU Classpath (cd lib; make) ecj | ecj-native | jikes ------------------------------------------------------------- real 1m24.539s | real 0m24.552s | real 0m9.439s user 1m23.157s | user 0m23.047s | user 0m7.486s sys 0m1.142s | sys 0m1.139s | sys 0m0.771s Note that classpath sources need a tiny hack to keep ecj from crashing. But that looks like an upstream Eclipse bug, since I could reproduce it running ecj with java-1.5.0-sun. Andrew, I don't suppose you still need oprofile data (or are there other places where gcjlib:// loading might be a problem)? -- Ziga From tromey at redhat.com Wed Mar 9 21:22:49 2005 From: tromey at redhat.com (Tom Tromey) Date: 09 Mar 2005 14:22:49 -0700 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <1110368089.5528.16.camel@orion> References: <1110368089.5528.16.camel@orion> Message-ID: >>>>> "Bob" == Bob Deblier writes: Bob> Support for gcj should be easier once Bob> libgcj contains javax.crypto - is this planned for 4.0? Yes, it is in there. If your native library uses jni, and you have java-gcj-compat installed, you can build your code against gcj using the same build.xml that you would use for the jdk. This is the simplest way to go. (Well, aside from building a .so and registering it... that needs gcj-specific code of course) If you want to use CNI, to avoid the JNI performance penalty, then you have to do more work. Tom From mckinlay at redhat.com Wed Mar 9 21:31:38 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Wed, 09 Mar 2005 16:31:38 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110403455.5553.11.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> Message-ID: <422F6B3A.5080402@redhat.com> Ziga Mahkovec wrote: >Ah, much better, thanks. Here are the revised times (BTW, that's a >1.5GHz Pentium M): > >HelloWorld > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 0m1.863s | real 0m1.614s | real 0m0.067s >user 0m1.758s | user 0m1.536s | user 0m0.050s >sys 0m0.103s | sys 0m0.076s | sys 0m0.012s > > >GNU Classpath (cd lib; make) > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 1m24.539s | real 0m24.552s | real 0m9.439s >user 1m23.157s | user 0m23.047s | user 0m7.486s >sys 0m1.142s | sys 0m1.139s | sys 0m0.771s > > >Note that classpath sources need a tiny hack to keep ecj from crashing. >But that looks like an upstream Eclipse bug, since I could reproduce it >running ecj with java-1.5.0-sun. > >Andrew, I don't suppose you still need oprofile data (or are there other >places where gcjlib:// loading might be a problem)? > > The ecj-native times still look somewhat slow. Back in the RHUG days, a gcj-compiled ecj was faster than jikes at building classpath. Perhaps the BC-ABI stuff is slowing us down a bit. Bryce From fitzsim at redhat.com Wed Mar 9 21:32:11 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 16:32:11 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110403455.5553.11.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> Message-ID: <1110403931.23370.178.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 22:24 +0100, Ziga Mahkovec wrote: >On Wed, 2005-03-09 at 11:38 -0500, Thomas Fitzsimmons wrote: >> On Wed, 2005-03-09 at 15:04 +0000, Andrew Haley wrote: >> >I see. Of course, I have no idea why tools.jar is attempting to use >> >the gcjlib:// class loader, or why it is so slow when it does. It >> >really should not explicitly use this class loader. >> >> I doesn't any more. We were doing that to avoid having to always add >> jdtcore.jar to the classpath. I also have no idea why it's so slow but >> I did notice a significant performance hit when compared to interpreted >> mode. >> >> Ziga, you can get the sources for java-gcj-compat from >> sources.redhat.com: > >Ah, much better, thanks. Here are the revised times (BTW, that's a >1.5GHz Pentium M): > >HelloWorld > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 0m1.863s | real 0m1.614s | real 0m0.067s >user 0m1.758s | user 0m1.536s | user 0m0.050s >sys 0m0.103s | sys 0m0.076s | sys 0m0.012s > > >GNU Classpath (cd lib; make) > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 1m24.539s | real 0m24.552s | real 0m9.439s >user 1m23.157s | user 0m23.047s | user 0m7.486s >sys 0m1.142s | sys 0m1.139s | sys 0m0.771s > > What release of eclipse-ecj are you using? Just recently we were able to build Eclipse with -O2 on x86. I'm not sure if the new packages have hit rawhide yet. Tom From ziga.mahkovec at klika.si Wed Mar 9 21:46:43 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 22:46:43 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110403931.23370.178.camel@tortoise.toronto.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> <1110403931.23370.178.camel@tortoise.toronto.redhat.com> Message-ID: <1110404803.5553.17.camel@localhost> On Wed, 2005-03-09 at 16:32 -0500, Thomas Fitzsimmons wrote: > On Wed, 2005-03-09 at 22:24 +0100, Ziga Mahkovec wrote: > >GNU Classpath (cd lib; make) > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 1m24.539s | real 0m24.552s | real 0m9.439s > >user 1m23.157s | user 0m23.047s | user 0m7.486s > >sys 0m1.142s | sys 0m1.139s | sys 0m0.771s > > What release of eclipse-ecj are you using? Just recently we were able > to build Eclipse with -O2 on x86. I'm not sure if the new packages have > hit rawhide yet. eclipse-ecj-3.1.0_fc-0.M5.10, which is currently in rawhide. I'll give the new packages a try once they land there; I'm not building the beast myself though, no way :) -- Ziga From fitzsim at redhat.com Wed Mar 9 22:01:45 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 17:01:45 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110403931.23370.178.camel@tortoise.toronto.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> <1110403931.23370.178.camel@tortoise.toronto.redhat.com> Message-ID: <1110405705.23370.182.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 16:32 -0500, Thomas Fitzsimmons wrote: >On Wed, 2005-03-09 at 22:24 +0100, Ziga Mahkovec wrote: >>On Wed, 2005-03-09 at 11:38 -0500, Thomas Fitzsimmons wrote: >>> On Wed, 2005-03-09 at 15:04 +0000, Andrew Haley wrote: >>> >I see. Of course, I have no idea why tools.jar is attempting to use >>> >the gcjlib:// class loader, or why it is so slow when it does. It >>> >really should not explicitly use this class loader. >>> >>> I doesn't any more. We were doing that to avoid having to always add >>> jdtcore.jar to the classpath. I also have no idea why it's so slow but >>> I did notice a significant performance hit when compared to interpreted >>> mode. >>> >>> Ziga, you can get the sources for java-gcj-compat from >>> sources.redhat.com: >> >>Ah, much better, thanks. Here are the revised times (BTW, that's a >>1.5GHz Pentium M): >> >>HelloWorld >> >>ecj | ecj-native | jikes >>------------------------------------------------------------- >>real 0m1.863s | real 0m1.614s | real 0m0.067s >>user 0m1.758s | user 0m1.536s | user 0m0.050s >>sys 0m0.103s | sys 0m0.076s | sys 0m0.012s >> >> >>GNU Classpath (cd lib; make) >> >>ecj | ecj-native | jikes >>------------------------------------------------------------- >>real 1m24.539s | real 0m24.552s | real 0m9.439s >>user 1m23.157s | user 0m23.047s | user 0m7.486s >>sys 0m1.142s | sys 0m1.139s | sys 0m0.771s >> >> > >What release of eclipse-ecj are you using? Just recently we were able >to build Eclipse with -O2 on x86. I'm not sure if the new packages have >hit rawhide yet. > They'll be in rawhide tomorrow. Release 3.1.0_fc-0.M5.12 or 3.1.0_fc-0.M5.13. Tom From bob.deblier at telenet.be Thu Mar 10 06:08:19 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Thu, 10 Mar 2005 07:08:19 +0100 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: References: <1110368089.5528.16.camel@orion> Message-ID: <1110434900.5521.1.camel@orion> On Wed, 2005-03-09 at 14:22 -0700, Tom Tromey wrote: > >>>>> "Bob" == Bob Deblier writes: > > Bob> Support for gcj should be easier once > Bob> libgcj contains javax.crypto - is this planned for 4.0? > > Yes, it is in there. > If your native library uses jni, and you have java-gcj-compat > installed, you can build your code against gcj using the same > build.xml that you would use for the jdk. This is the simplest way > to go. (Well, aside from building a .so and registering it... that > needs gcj-specific code of course) > > If you want to use CNI, to avoid the JNI performance penalty, then > you have to do more work. > > Tom Tom, Thanks for the tips. Right now I'm using JNI but will investigate CNI. Sincerely, Bob From aph at redhat.com Thu Mar 10 12:05:07 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Mar 2005 12:05:07 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <422F6B3A.5080402@redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> <422F6B3A.5080402@redhat.com> Message-ID: <16944.14323.685133.873228@cuddles.cambridge.redhat.com> Bryce McKinlay writes: > Ziga Mahkovec wrote: > > >Ah, much better, thanks. Here are the revised times (BTW, that's a > >1.5GHz Pentium M): > > > >HelloWorld > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 0m1.863s | real 0m1.614s | real 0m0.067s > >user 0m1.758s | user 0m1.536s | user 0m0.050s > >sys 0m0.103s | sys 0m0.076s | sys 0m0.012s > > > > > >GNU Classpath (cd lib; make) > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 1m24.539s | real 0m24.552s | real 0m9.439s > >user 1m23.157s | user 0m23.047s | user 0m7.486s > >sys 0m1.142s | sys 0m1.139s | sys 0m0.771s > > > > > >Note that classpath sources need a tiny hack to keep ecj from crashing. > >But that looks like an upstream Eclipse bug, since I could reproduce it > >running ecj with java-1.5.0-sun. > > > >Andrew, I don't suppose you still need oprofile data (or are there other > >places where gcjlib:// loading might be a problem)? It's not so very important now, but it is still interesting. By the way, if you're not used to oprofile: the docs make it look heinously difficult to use, but it's really very easy! The only hard part is reading the docs... I do sudo sh -c 'opcontrol --reset ; opcontrol --start'; ./a.out trash flibber poo; sudo sh -c 'opcontrol --stop' to measure a job, then sudo opreport -l to get the report. It's really that easy. The trouble with very short runtimes like this one is that you might not have enough samples. > The ecj-native times still look somewhat slow. Back in the RHUG days, a > gcj-compiled ecj was faster than jikes at building classpath. Perhaps > the BC-ABI stuff is slowing us down a bit. Yeah. Oprofile might still be interesting. Andrew. From caolanm at redhat.com Thu Mar 10 14:13:17 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 10 Mar 2005 14:13:17 +0000 Subject: [fedora-java] latest gcj (gcc4) and OOo 1.9.84 news Message-ID: <1110463997.9665.8.camel@sheol.homelinux.org> I did another round of testing to see what additionally works or doesn't in OOo2 with gcj from gcc4, and its big progress, which is most excellent. I've enabled the new stuff which is working in OOo workspace gcj3. There are a handful of remaining problems, various temporary workaround patches and testcases where applicable at http://people.redhat.com/caolanm/java/ 1. ooo patched rhino fails to build with gcj tar xvzf rhino15R4.tar.gz cd rhino1_5R4/ patch -p3 < ../rhino1_5R4.patch ant -Dbuild.compiler=gcj -f build.xml ERROR in rhino1_5R4/toolsrc/org/mozilla/javascript/tools/debugger/Main.java (at line 449) [javac] int pos = viewToModel(new Point(popup.x, popup.y)); the scripting module also depends on this rhino module submitted as rh#150772#. I bet this is trivial to fix. 2. complicated problem I don't understand in wizards component registration :-( submitted as rh#150650# temp ooo side wizards.workaround.patch to get past registration 3. canvas module fails to compile a missing "java.awt.Frame.createBufferStrategy" implementation ? 4. gcj's libjawt contains a reference to undefined LINK_ReallyLinkKnownClass Thomas Fitzsimmons is taking care of it. temp ooo side libjawt.workaround.patch to not checkdll bean for gcj, this is a relatively trivial thing as well. ---- unimportant stuff ---- 5. sandbox uses sun.applet.AppletAudioClip and other sun.foo classes, not important, its really a deprecated module 6. sj2 uses some sandbox things so some parts cannot be built, apparently this module is being cleaned up to remove some of this, again not important. From fitzsim at redhat.com Thu Mar 10 16:04:24 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Mar 2005 11:04:24 -0500 Subject: [fedora-java] latest gcj (gcc4) and OOo 1.9.84 news In-Reply-To: <1110463997.9665.8.camel@sheol.homelinux.org> References: <1110463997.9665.8.camel@sheol.homelinux.org> Message-ID: <1110470665.23370.232.camel@tortoise.toronto.redhat.com> On Thu, 2005-03-10 at 14:13 +0000, Caolan McNamara wrote: >I did another round of testing to see what additionally works or doesn't >in OOo2 with gcj from gcc4, and its big progress, which is most >excellent. I've enabled the new stuff which is working in OOo workspace >gcj3. There are a handful of remaining problems, various temporary >workaround patches and testcases where applicable at >http://people.redhat.com/caolanm/java/ > >1. ooo patched rhino fails to build with gcj > >tar xvzf rhino15R4.tar.gz >cd rhino1_5R4/ >patch -p3 < ../rhino1_5R4.patch >ant -Dbuild.compiler=gcj -f build.xml > >ERROR in >rhino1_5R4/toolsrc/org/mozilla/javascript/tools/debugger/Main.java (at >line 449) >[javac] int pos = viewToModel(new Point(popup.x, popup.y)); > >the scripting module also depends on this rhino module >submitted as rh#150772#. I bet this is trivial to fix. > OK, I'll look at this. >2. complicated problem I don't understand in wizards component >registration :-( > submitted as rh#150650# > temp ooo side wizards.workaround.patch to get past registration > >3. canvas module fails to compile > a missing "java.awt.Frame.createBufferStrategy" implementation ? > Can you file a bug for this in RH bugzilla and assign it to me? I'll work on it. >4. gcj's libjawt contains a reference to undefined >LINK_ReallyLinkKnownClass > Thomas Fitzsimmons is taking care of it. > temp ooo side libjawt.workaround.patch to not checkdll bean for >gcj, this is a relatively trivial thing as well. > I'll fix this on GCC HEAD today. >---- unimportant stuff ---- > >5. sandbox uses sun.applet.AppletAudioClip and other sun.foo classes, >not important, its really a deprecated module > I'll see if Tritonus implements this class. If so, I'll package it. I know this is less important but we need Tritonus anyway. Tom From robilad at kaffe.org Thu Mar 10 17:13:18 2005 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 10 Mar 2005 18:13:18 +0100 Subject: [tools-jdk] Re: [fedora-java] latest gcj (gcc4) and OOo 1.9.84 news In-Reply-To: <1110470665.23370.232.camel@tortoise.toronto.redhat.com> References: <1110463997.9665.8.camel@sheol.homelinux.org> <1110470665.23370.232.camel@tortoise.toronto.redhat.com> Message-ID: <4230802E.9090202@kaffe.org> Thomas Fitzsimmons wrote: >>5. sandbox uses sun.applet.AppletAudioClip and other sun.foo classes, >>not important, its really a deprecated module >> > > > I'll see if Tritonus implements this class. If so, I'll package it. I > know this is less important but we need Tritonus anyway. It doesn't afaik. The ooo code there should be really updated to use a sane API or kicked out of the default build. cheers, dalibor topic From tromey at redhat.com Thu Mar 10 18:24:41 2005 From: tromey at redhat.com (Tom Tromey) Date: 10 Mar 2005 11:24:41 -0700 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <20050308205618.GA19940@redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> <20050308154406.GC30854@redhat.com> <20050308205618.GA19940@redhat.com> Message-ID: >>>>> "Joe" == Joe Orton writes: >> gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 Joe> So do I need to file a bug on this issue in Red Hat bugzilla or are is Joe> this "in progress"? I can't enable the Subversion javahl bindings until Joe> this is fixed. Andrew Haley has a list of "gcc bugs we would like fixed in gcc 4.0". I forwarded this to him. He's going to try to get a gcc hacker at RH to fix these (though I don't actually know what criteria he's using to decide what to ask for...). Tom From aph at redhat.com Thu Mar 10 18:31:18 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Mar 2005 18:31:18 +0000 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> <20050308154406.GC30854@redhat.com> <20050308205618.GA19940@redhat.com> Message-ID: <16944.37494.605901.82584@cuddles.cambridge.redhat.com> Tom Tromey writes: > >>>>> "Joe" == Joe Orton writes: > > >> gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 > > Joe> So do I need to file a bug on this issue in Red Hat bugzilla or are is > Joe> this "in progress"? I can't enable the Subversion javahl bindings until > Joe> this is fixed. > > Andrew Haley has a list of "gcc bugs we would like fixed in gcc > 4.0". I forwarded this to him. He's going to try to get a gcc > hacker at RH to fix these (though I don't actually know what > criteria he's using to decide what to ask for...). At the moment, my criterion is "kills a significant number of gcj apps or renders some other feature, such as debugging, useless." Andrew. From fitzsim at redhat.com Thu Mar 10 19:34:54 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Mar 2005 14:34:54 -0500 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <16944.37494.605901.82584@cuddles.cambridge.redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> <20050308154406.GC30854@redhat.com> <20050308205618.GA19940@redhat.com> <16944.37494.605901.82584@cuddles.cambridge.redhat.com> Message-ID: <1110483294.23370.238.camel@tortoise.toronto.redhat.com> On Thu, 2005-03-10 at 18:31 +0000, Andrew Haley wrote: >Tom Tromey writes: > > >>>>> "Joe" == Joe Orton writes: > > > > >> gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 > > > > Joe> So do I need to file a bug on this issue in Red Hat bugzilla or are is > > Joe> this "in progress"? I can't enable the Subversion javahl bindings until > > Joe> this is fixed. > > > > Andrew Haley has a list of "gcc bugs we would like fixed in gcc > > 4.0". I forwarded this to him. He's going to try to get a gcc > > hacker at RH to fix these (though I don't actually know what > > criteria he's using to decide what to ask for...). > >At the moment, my criterion is "kills a significant number of gcj apps >or renders some other feature, such as debugging, useless." > You may want to add this one, since it prevents building eclipse on ia64: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 Tom From ziga.mahkovec at klika.si Fri Mar 11 09:14:48 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 10:14:48 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance Message-ID: <1110532488.5506.1.camel@localhost> I noticed that installing the eclipse-* packages takes really long (around 10 minutes on my laptop). Most of time is spent running gcj- dbtool, doing lots of disk IO. This seemed a bit unusual and after inspecting the gcj-dbtool sources, I found out that in resizeMap(), a new PersistentByteMap is created for each jar package that is added -- amounting to almost 150 several-MB temporary files created. I don't think this was intentional. The attached patch cuts my installation time for eclipse-platform from 7m17s to 1m35s. I've verified that eclipse.db is identical to the old database, so hopefully the patch doesn't break anything. -- Ziga -------------- next part -------------- A non-text attachment was scrubbed... Name: gcj_dbtool.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: From aph at redhat.com Fri Mar 11 10:02:05 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 10:02:05 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <1110532488.5506.1.camel@localhost> References: <1110532488.5506.1.camel@localhost> Message-ID: <16945.27805.194200.716704@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > I noticed that installing the eclipse-* packages takes really long > (around 10 minutes on my laptop). Most of time is spent running gcj- > dbtool, doing lots of disk IO. > > This seemed a bit unusual and after inspecting the gcj-dbtool sources, I > found out that in resizeMap(), a new PersistentByteMap is created for > each jar package that is added -- amounting to almost 150 several-MB > temporary files created. I don't think this was intentional. > > The attached patch cuts my installation time for eclipse-platform from > 7m17s to 1m35s. I've verified that eclipse.db is identical to the old > database, so hopefully the patch doesn't break anything. This is wrong. Other running applications may be accessing a .db file while it is in place, and it is not safe to modify it. The right technique is to copy the old file to a new one, add to the new one, and then rename it. Any processes that have the old one mapped will continue to use it. The problem is that the Eclipse installer is doing things in a very inefficient way. The most efficient way is to generate a separate map for each jar file, and then merge them all at the end. This is very fast. It also has the advantage that the resulting file is more compact. Andrew. From ziga.mahkovec at klika.si Fri Mar 11 10:25:03 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 11:25:03 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.27805.194200.716704@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> Message-ID: <1110536703.5506.34.camel@localhost> On Fri, 2005-03-11 at 10:02 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > This seemed a bit unusual and after inspecting the gcj-dbtool sources, I > > found out that in resizeMap(), a new PersistentByteMap is created for > > each jar package that is added -- amounting to almost 150 several-MB > > temporary files created. I don't think this was intentional. > > This is wrong. > > Other running applications may be accessing a .db file while it is in > place, and it is not safe to modify it. The right technique is to > copy the old file to a new one, add to the new one, and then rename > it. Any processes that have the old one mapped will continue to use > it. Ah, I hadn't thought about that. Probably because this happens during installation, where the database was just created, so I wouldn't expect any consumers yet. But I see your point; this could be a problem for deferred installations of certain eclipse packages. > The problem is that the Eclipse installer is doing things in a very > inefficient way. The most efficient way is to generate a separate map > for each jar file, and then merge them all at the end. This is very > fast. It also has the advantage that the resulting file is more > compact. Maybe this could be further improved by creating a single separate map for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch which triggers the behavior in the patch). Then, only two maps would have to be merged, avoiding the need to create 150 separate maps. -- Ziga From aph at redhat.com Fri Mar 11 10:29:12 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 10:29:12 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <1110536703.5506.34.camel@localhost> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> Message-ID: <16945.29432.336537.26255@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Fri, 2005-03-11 at 10:02 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > This seemed a bit unusual and after inspecting the gcj-dbtool sources, I > > > found out that in resizeMap(), a new PersistentByteMap is created for > > > each jar package that is added -- amounting to almost 150 several-MB > > > temporary files created. I don't think this was intentional. > > > > This is wrong. > > > > Other running applications may be accessing a .db file while it is in > > place, and it is not safe to modify it. The right technique is to > > copy the old file to a new one, add to the new one, and then rename > > it. Any processes that have the old one mapped will continue to use > > it. > > Ah, I hadn't thought about that. Probably because this happens during > installation, where the database was just created, so I wouldn't expect > any consumers yet. But I see your point; this could be a problem for > deferred installations of certain eclipse packages. The gcj-dbtool isn't just used by Eclipse. It has to be safe when adding a jar in a live system. > > The problem is that the Eclipse installer is doing things in a very > > inefficient way. The most efficient way is to generate a separate map > > for each jar file, and then merge them all at the end. This is very > > fast. It also has the advantage that the resulting file is more > > compact. > > Maybe this could be further improved by creating a single separate map > for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch > which triggers the behavior in the patch). Then, only two maps would > have to be merged, avoiding the need to create 150 separate maps. What's the problem with creating 150 separate maps? I don't get it. Andrew. From ziga.mahkovec at klika.si Fri Mar 11 10:37:35 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 11:37:35 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.29432.336537.26255@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> Message-ID: <1110537455.5506.40.camel@localhost> On Fri, 2005-03-11 at 10:29 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > Maybe this could be further improved by creating a single separate map > > for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch > > which triggers the behavior in the patch). Then, only two maps would > > have to be merged, avoiding the need to create 150 separate maps. > > What's the problem with creating 150 separate maps? I don't get it. Fragmentation I guess. Each new map would have to over-allocate enough space for a jar file to avoid resizing. And somehow a single map seems like a cleaner solution. But those are minor issues. Any improvement over the current situation would help. -- Ziga From aph at redhat.com Fri Mar 11 11:30:50 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 11:30:50 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <1110537455.5506.40.camel@localhost> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> <1110537455.5506.40.camel@localhost> Message-ID: <16945.33130.208463.355228@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Fri, 2005-03-11 at 10:29 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > Maybe this could be further improved by creating a single separate map > > > for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch > > > which triggers the behavior in the patch). Then, only two maps would > > > have to be merged, avoiding the need to create 150 separate maps. > > > > What's the problem with creating 150 separate maps? I don't get it. > > Fragmentation I guess. Each new map would have to over-allocate enough > space for a jar file to avoid resizing. No, I don't think that would be a problem. Each file will be sized to be just big enough, and the resulting merged map will also be just big enough. (The existing code could be made more efficient, I grant you: it's silly to create a small map that instantly gets resized.) > And somehow a single map seems like a cleaner solution. But those > are minor issues. Any improvement over the current situation would > help. It should be just fine. Try it. When used as I describe, almost all of the time is spent reading the jar files, not creating the maps. There's nothing you can do about the maps that will make the process any faster. When building jonas, which has 28871 classes in 239 jar files, the whole process takes 1m1.140s on my box. I am very loath to add "unsafe" flags to any program, particularly when there's a simple alternative. Andrew. From overholt at redhat.com Fri Mar 11 13:31:45 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 11 Mar 2005 08:31:45 -0500 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.27805.194200.716704@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> Message-ID: <20050311133145.GB31511@redhat.com> * Andrew Haley [2005-03-11 05:03]: > The problem is that the Eclipse installer is doing things in a very > inefficient way. It would have been nice to hear this before :) > The most efficient way is to generate a separate map for each jar file, > and then merge them all at the end. This is very fast. It also has the > advantage that the resulting file is more compact. The other problem here is that Tom Tromey's -f flag has yet to land in our gcj RPMs. That will allow us to create the dbs in %install and then just merge them in %post so the end user will only see the merging and not the actual creation. Andrew From aph at redhat.com Fri Mar 11 13:34:49 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 13:34:49 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <20050311133145.GB31511@redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <20050311133145.GB31511@redhat.com> Message-ID: <16945.40569.120786.533480@cuddles.cambridge.redhat.com> Andrew Overholt writes: > * Andrew Haley [2005-03-11 05:03]: > > The problem is that the Eclipse installer is doing things in a very > > inefficient way. > > It would have been nice to hear this before :) We're in the development phase. Things change... > > The most efficient way is to generate a separate map for each jar file, > > and then merge them all at the end. This is very fast. It also has the > > advantage that the resulting file is more compact. > > The other problem here is that Tom Tromey's -f flag has yet to land in our > gcj RPMs. That will allow us to create the dbs in %install and then just > merge them in %post so the end user will only see the merging and not the > actual creation. OK. Andrew. From ziga.mahkovec at klika.si Fri Mar 11 13:37:20 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 14:37:20 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.33130.208463.355228@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> <1110537455.5506.40.camel@localhost> <16945.33130.208463.355228@cuddles.cambridge.redhat.com> Message-ID: <1110548240.5506.61.camel@localhost> On Fri, 2005-03-11 at 11:30 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > And somehow a single map seems like a cleaner solution. But those > > are minor issues. Any improvement over the current situation would > > help. > > It should be just fine. Try it. > > When used as I describe, almost all of the time is spent reading the > jar files, not creating the maps. There's nothing you can do about > the maps that will make the process any faster. When building jonas, > which has 28871 classes in 239 jar files, the whole process takes > 1m1.140s on my box. Sounds great, thanks for all the clarifications! Just one final question (I promise (-:). Would it be possible (and make sense) to move the "gcj-dbtool -a" stage from %post to %install? I'm thinking the build system has enough information to compile the map -- when installing the package, only merging would then take place. This would offload most of the disk IO to the build system. -- Ziga From ziga.mahkovec at klika.si Fri Mar 11 13:40:20 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 14:40:20 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <1110548240.5506.61.camel@localhost> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> <1110537455.5506.40.camel@localhost> <16945.33130.208463.355228@cuddles.cambridge.redhat.com> <1110548240.5506.61.camel@localhost> Message-ID: <1110548420.5506.63.camel@localhost> On Fri, 2005-03-11 at 14:37 +0100, Ziga Mahkovec wrote: > Would it be possible (and make sense) to move the "gcj-dbtool -a" > stage from %post to %install? Oops, must read all mail before replying, never mind :) -- Ziga From vadimn at redhat.com Fri Mar 11 13:52:36 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 11 Mar 2005 08:52:36 -0500 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.27805.194200.716704@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> Message-ID: <200503110852.36433@vadim.nasardinov> On Friday 11 March 2005 05:02, Andrew Haley wrote: > The right technique is to copy the old file to a new one, add to the > new one, and then rename it. Do we have a mechanism in place to enforce serialization of two or more concurrent attempts to apply this technique? From aph at redhat.com Fri Mar 11 13:56:49 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 13:56:49 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <200503110852.36433@vadim.nasardinov> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <200503110852.36433@vadim.nasardinov> Message-ID: <16945.41889.361626.167343@cuddles.cambridge.redhat.com> Vadim Nasardinov writes: > On Friday 11 March 2005 05:02, Andrew Haley wrote: > > The right technique is to copy the old file to a new one, add to the > > new one, and then rename it. > > Do we have a mechanism in place to enforce serialization of two or > more concurrent attempts to apply this technique? No. You'd have to be trying to install two packages simultaneously for this to happen. Don't Do That. Andrew. From vadimn at redhat.com Fri Mar 11 14:06:57 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 11 Mar 2005 09:06:57 -0500 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.41889.361626.167343@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <200503110852.36433@vadim.nasardinov> <16945.41889.361626.167343@cuddles.cambridge.redhat.com> Message-ID: <200503110906.57764@vadim.nasardinov> On Friday 11 March 2005 08:56, Andrew Haley wrote: > > Do we have a mechanism in place to enforce serialization of two > > or more concurrent attempts to apply this technique? > > No. You'd have to be trying to install two packages simultaneously > for this to happen. Don't Do That. I wasn't going to, but someone else might. I'm fine with that. Someone else might not be. So, the assumption is that the only way to modify the db is by installing/uninstalling RPMs. Is that correct? From aph at redhat.com Fri Mar 11 14:10:28 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 14:10:28 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <200503110906.57764@vadim.nasardinov> References: <1110532488.5506.1.camel@localhost> <200503110852.36433@vadim.nasardinov> <16945.41889.361626.167343@cuddles.cambridge.redhat.com> <200503110906.57764@vadim.nasardinov> Message-ID: <16945.42708.714025.343393@cuddles.cambridge.redhat.com> Vadim Nasardinov writes: > On Friday 11 March 2005 08:56, Andrew Haley wrote: > > > Do we have a mechanism in place to enforce serialization of two > > > or more concurrent attempts to apply this technique? > > > > No. You'd have to be trying to install two packages simultaneously > > for this to happen. Don't Do That. > > I wasn't going to, but someone else might. I'm fine with that. > Someone else might not be. > > So, the assumption is that the only way to modify the db is by > installing/uninstalling RPMs. Is that correct? No, not at all. The assumption is that if you're adding a package to the common shared region, or indeed removing one, it's not a good idea to try doing several at the same time. I'm sure it's possible to do filesystem locking if anyone thing this is necessary. The problem is, of course, that someone might want to do more than one update. Andrew. From tromey at redhat.com Fri Mar 11 17:49:18 2005 From: tromey at redhat.com (Tom Tromey) Date: 11 Mar 2005 10:49:18 -0700 Subject: [fedora-java] default .db for gij Message-ID: FYI, I checked in a patch to gcc that sets the default database for gij. Once this is put in the gcc RPM, you won't need to set the .db on the gij command line. You can use "gcj-dbtool -p" in your spec file to get the name of the default .db. Jakub, libgcj will build and install a default .db. However, I'm not sure we really want to have this file owned by the gcc RPM. It is going to be modified by other RPMs as they are installed... what is the usual thing to do in this situation? Tom From walters at redhat.com Fri Mar 11 18:04:19 2005 From: walters at redhat.com (Colin Walters) Date: Fri, 11 Mar 2005 13:04:19 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: References: Message-ID: <1110564260.4138.1.camel@nexus.verbum.private> On Fri, 2005-03-11 at 10:49 -0700, Tom Tromey wrote: > Jakub, libgcj will build and install a default .db. However, I'm not > sure we really want to have this file owned by the gcc RPM. It is > going to be modified by other RPMs as they are installed... what is > the usual thing to do in this situation? Conceptually it's just a cache right? Why not put it in /var/cache/ somewhere? From pmuldoon at redhat.com Fri Mar 11 18:06:50 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Fri, 11 Mar 2005 12:06:50 -0600 Subject: [fedora-java] default .db for gij In-Reply-To: References: Message-ID: <1110564410.5956.10.camel@localhost.localdomain> On the central db idea (as opposed to having each application having their own db), what happens on a partial disk failure, and e2fsck can't recover inodes that belong to the db? Reinstall all gcj built rpms? How would the user know what to do in that scenario? Do we keep a gzipped backup tucked away somewhere? Also, where would you put it? I imagine it would have to go somewhere on root say /usr/lib? If you put it, I dunno, in /var or somewhere like that, a mount failure would render all gcj apps back to fall back to interpretated. Just two questions that quickly occurred to me. The db almost sounds like it is going to become something akin to a registry like Windows has; I'm not saying that is a bad thing, but a single bad inode can spoil the party. ;) Regards Phil On Fri, 2005-03-11 at 10:49 -0700, Tom Tromey wrote: > FYI, I checked in a patch to gcc that sets the default database for > gij. Once this is put in the gcc RPM, you won't need to set the .db > on the gij command line. > > You can use "gcj-dbtool -p" in your spec file to get the name of the > default .db. > > > Jakub, libgcj will build and install a default .db. However, I'm not > sure we really want to have this file owned by the gcc RPM. It is > going to be modified by other RPMs as they are installed... what is > the usual thing to do in this situation? > > Tom > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From jakub at redhat.com Fri Mar 11 18:11:51 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 11 Mar 2005 13:11:51 -0500 Subject: [fedora-java] Re: default .db for gij In-Reply-To: References: Message-ID: <20050311181151.GB853@devserv.devel.redhat.com> On Fri, Mar 11, 2005 at 10:49:18AM -0700, Tom Tromey wrote: > FYI, I checked in a patch to gcc that sets the default database for > gij. Once this is put in the gcc RPM, you won't need to set the .db > on the gij command line. > > You can use "gcj-dbtool -p" in your spec file to get the name of the > default .db. > > Jakub, libgcj will build and install a default .db. However, I'm not > sure we really want to have this file owned by the gcc RPM. It is > going to be modified by other RPMs as they are installed... what is > the usual thing to do in this situation? It can be say %ghost %config file, populated at libgcj's %post time (as well as %post of other packages). Now, if you are storing full paths of shared libraries, I guess it needs to live in /usr/$LIB/java/ somewhere (so that there are separate 32-bit and 64-bit .db's on say x86-64, ppc*, s390* etc.). Or do you have one .db instead with flags for which ABI a particular library is (like say /etc/ld.so.cache has)? Jakub From aph at redhat.com Fri Mar 11 18:14:04 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 18:14:04 +0000 Subject: [fedora-java] default .db for gij In-Reply-To: <1110564410.5956.10.camel@localhost.localdomain> References: <1110564410.5956.10.camel@localhost.localdomain> Message-ID: <16945.57324.907497.479934@cuddles.cambridge.redhat.com> Phil Muldoon writes: > On the central db idea (as opposed to having each application having > their own db), what happens on a partial disk failure, and e2fsck can't > recover inodes that belong to the db? Reinstall all gcj built rpms? No. Whenever an rpm is installed, the %post should *rebuild* the db from each application's db. It's just a cache. > Also, where would you put it? I imagine it would have to go somewhere > on root say /usr/lib? If you put it, I dunno, in /var or somewhere like > that, a mount failure would render all gcj apps back to fall back to > interpretated. /var/cache/somewhere sounds like a good idea for the central db. Andrew. From tromey at redhat.com Fri Mar 11 18:46:41 2005 From: tromey at redhat.com (Tom Tromey) Date: 11 Mar 2005 11:46:41 -0700 Subject: [fedora-java] Re: default .db for gij In-Reply-To: <20050311181151.GB853@devserv.devel.redhat.com> References: <20050311181151.GB853@devserv.devel.redhat.com> Message-ID: Jakub> Now, if you are storing full paths of shared libraries, I guess Jakub> it needs to live in /usr/$LIB/java/ somewhere (so that there are Jakub> separate 32-bit and 64-bit .db's on say x86-64, ppc*, s390* etc.). Yes, it stores full paths. Right now the default is: ## Where the standard .db file is found. dbexecdir = $(libdir)/gcj- at gcc_version@ ## Name of the default .db. db_name = classmap.db Colin> Conceptually it's just a cache right? Why not put it in Colin> /var/cache/ somewhere? That is fine by me. I think I'd have to resurrect the patch to add a gcc configure option for this, since it seems weird to look in /var/cache in a typical gcc build... ordinarily we're constrained to $prefix. Whatever the gcc and java project packaging folks want here, I will implement. Just let me know. Tom From dmalcolm at redhat.com Fri Mar 11 19:03:10 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 11 Mar 2005 14:03:10 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: <16945.57324.907497.479934@cuddles.cambridge.redhat.com> References: <1110564410.5956.10.camel@localhost.localdomain> <16945.57324.907497.479934@cuddles.cambridge.redhat.com> Message-ID: <1110567790.30553.22.camel@cassandra.boston.redhat.com> On Fri, 2005-03-11 at 18:14 +0000, Andrew Haley wrote: >Phil Muldoon writes: > > On the central db idea (as opposed to having each application having > > their own db), what happens on a partial disk failure, and e2fsck can't > > recover inodes that belong to the db? Reinstall all gcj built rpms? > >No. Whenever an rpm is installed, the %post should *rebuild* the db >from each application's db. It's just a cache. Does this get amortized so that you don't regenerate it for each package in a transaction? Otherwise are we getting O(n^2) work? Dave Malcolm From aph at redhat.com Fri Mar 11 19:04:53 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 19:04:53 +0000 Subject: [fedora-java] default .db for gij In-Reply-To: <1110567790.30553.22.camel@cassandra.boston.redhat.com> References: <1110564410.5956.10.camel@localhost.localdomain> <16945.57324.907497.479934@cuddles.cambridge.redhat.com> <1110567790.30553.22.camel@cassandra.boston.redhat.com> Message-ID: <16945.60373.560272.506562@cuddles.cambridge.redhat.com> David Malcolm writes: > On Fri, 2005-03-11 at 18:14 +0000, Andrew Haley wrote: > >Phil Muldoon writes: > > > On the central db idea (as opposed to having each application having > > > their own db), what happens on a partial disk failure, and e2fsck can't > > > recover inodes that belong to the db? Reinstall all gcj built rpms? > > > >No. Whenever an rpm is installed, the %post should *rebuild* the db > >from each application's db. It's just a cache. > Does this get amortized so that you don't regenerate it for each package > in a transaction? Otherwise are we getting O(n^2) work? It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles and 40,000 classes. Andrew. From vadimn at redhat.com Fri Mar 11 19:46:00 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 11 Mar 2005 14:46:00 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: <16945.60373.560272.506562@cuddles.cambridge.redhat.com> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> Message-ID: <200503111446.00980@vadim.nasardinov> On Friday 11 March 2005 14:04, Andrew Haley wrote: > > Does this get amortized so that you don't regenerate it for each package > > in a transaction? Otherwise are we getting O(n^2) work? > > It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles > and 40,000 classes. That doesn't answer his question though, does it? From tromey at redhat.com Fri Mar 11 20:02:49 2005 From: tromey at redhat.com (Tom Tromey) Date: 11 Mar 2005 13:02:49 -0700 Subject: [fedora-java] default .db for gij In-Reply-To: <16945.57324.907497.479934@cuddles.cambridge.redhat.com> References: <1110564410.5956.10.camel@localhost.localdomain> <16945.57324.907497.479934@cuddles.cambridge.redhat.com> Message-ID: Phil> On the central db idea (as opposed to having each application having Phil> their own db), what happens on a partial disk failure, and e2fsck can't Phil> recover inodes that belong to the db? Reinstall all gcj built rpms? Andrew> No. Whenever an rpm is installed, the %post should *rebuild* the db Andrew> from each application's db. It's just a cache. One thing we've discussed on irc is having either rpm macro support or a script somewhere to do this. The latter is nice if your .db does get hosed -- you could just run the script to fix it. AFAIK this isn't definitively assigned to someone to do yet. And, we would have to decide where to install this thing and what package ought to own it. Tom From tromey at redhat.com Fri Mar 11 20:04:42 2005 From: tromey at redhat.com (Tom Tromey) Date: 11 Mar 2005 13:04:42 -0700 Subject: [fedora-java] default .db for gij In-Reply-To: <200503111446.00980@vadim.nasardinov> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> Message-ID: >> > Does this get amortized so that you don't regenerate it for each package >> > in a transaction? Otherwise are we getting O(n^2) work? >> >> It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles >> and 40,000 classes. Vadim> That doesn't answer his question though, does it? Yeah, the answer right now is "no, we are doing O(n^2) work". At install time we could just merge new .db files into the master .db. Doing this at uninstall time would require more hacks to gcj-dbtool, I think. Maybe it doesn't matter though. Tom From aph at redhat.com Fri Mar 11 20:11:51 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 20:11:51 +0000 Subject: [fedora-java] default .db for gij In-Reply-To: <200503111446.00980@vadim.nasardinov> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> Message-ID: <16945.64391.971735.79620@cuddles.cambridge.redhat.com> Vadim Nasardinov writes: > On Friday 11 March 2005 14:04, Andrew Haley wrote: > > > Does this get amortized so that you don't regenerate it for each package > > > in a transaction? Otherwise are we getting O(n^2) work? > > > > It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles > > and 40,000 classes. > > That doesn't answer his question though, does it? No, it doesn't, but it does suggest that it's a second order effect and so probably not worth worrying about for the time being. There is an N^2 effect, yes. But if we're to do anything more sophisticated maybe RPM will have to have some sort of new functionality. Andrew. From aph at redhat.com Fri Mar 11 20:13:57 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 20:13:57 +0000 Subject: [fedora-java] default .db for gij In-Reply-To: References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> Message-ID: <16945.64517.617603.20926@cuddles.cambridge.redhat.com> Tom Tromey writes: > >> > Does this get amortized so that you don't regenerate it for each package > >> > in a transaction? Otherwise are we getting O(n^2) work? > >> > >> It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles > >> and 40,000 classes. > > Vadim> That doesn't answer his question though, does it? > > Yeah, the answer right now is "no, we are doing O(n^2) work". > > At install time we could just merge new .db files into the master .db. We could, but that requires locking for concurrent access. Probably not a good idea. Andrew. From dmalcolm at redhat.com Fri Mar 11 21:11:02 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 11 Mar 2005 16:11:02 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: <16945.64391.971735.79620@cuddles.cambridge.redhat.com> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> <16945.64391.971735.79620@cuddles.cambridge.redhat.com> Message-ID: <1110575462.30553.35.camel@cassandra.boston.redhat.com> On Fri, 2005-03-11 at 20:11 +0000, Andrew Haley wrote: >Vadim Nasardinov writes: > > On Friday 11 March 2005 14:04, Andrew Haley wrote: > > > > Does this get amortized so that you don't regenerate it for each package > > > > in a transaction? Otherwise are we getting O(n^2) work? > > > > > > It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles > > > and 40,000 classes. > > > > That doesn't answer his question though, does it? > >No, it doesn't, but it does suggest that it's a second order effect >and so probably not worth worrying about for the time being. > >There is an N^2 effect, yes. But if we're to do anything more >sophisticated maybe RPM will have to have some sort of new >functionality. Yeah, I was just being paranoid. IIRC we had some problems on the desktop when regenerating mimetype databases, and scrollkeeper for documentation. I think scrollkeeper was the big offender here, since it wasn't fast, and its database regeneration hook used to bring RPM to its knees (successively regenerating the database for package 1, then for package 2, etc all the way through a transaction) From mckinlay at redhat.com Fri Mar 11 21:24:02 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Fri, 11 Mar 2005 16:24:02 -0500 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.33130.208463.355228@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> <1110537455.5506.40.camel@localhost> <16945.33130.208463.355228@cuddles.cambridge.redhat.com> Message-ID: <42320C72.5060705@redhat.com> Andrew Haley wrote: >It should be just fine. Try it. > >When used as I describe, almost all of the time is spent reading the >jar files, not creating the maps. There's nothing you can do about >the maps that will make the process any faster. > > We can have gcj generate the signature for each bytecode class and put it into class metadata at compilation time. That way gcj-dbtool won't need the .jar's. Bryce From dmalcolm at redhat.com Fri Mar 11 21:27:25 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 11 Mar 2005 16:27:25 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: <1110575462.30553.35.camel@cassandra.boston.redhat.com> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> <16945.64391.971735.79620@cuddles.cambridge.redhat.com> <1110575462.30553.35.camel@cassandra.boston.redhat.com> Message-ID: <1110576445.30553.38.camel@cassandra.boston.redhat.com> On Fri, 2005-03-11 at 16:11 -0500, David Malcolm wrote: >On Fri, 2005-03-11 at 20:11 +0000, Andrew Haley wrote: >>Vadim Nasardinov writes: >> > On Friday 11 March 2005 14:04, Andrew Haley wrote: >> > > > Does this get amortized so that you don't regenerate it for each package >> > > > in a transaction? Otherwise are we getting O(n^2) work? >> > > >> > > It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles >> > > and 40,000 classes. >> > >> > That doesn't answer his question though, does it? >> >>No, it doesn't, but it does suggest that it's a second order effect >>and so probably not worth worrying about for the time being. >> >>There is an N^2 effect, yes. But if we're to do anything more >>sophisticated maybe RPM will have to have some sort of new >>functionality. > >Yeah, I was just being paranoid. IIRC we had some problems on the >desktop when regenerating mimetype databases, and scrollkeeper for >documentation. I think scrollkeeper was the big offender here, since it >wasn't fast, and its database regeneration hook used to bring RPM to its >knees (successively regenerating the database for package 1, then for >package 2, etc all the way through a transaction) /me fears he has started something bad here; premature optimization is the root of all evil. From ziga.mahkovec at klika.si Fri Mar 11 22:30:43 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 23:30:43 +0100 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) Message-ID: <1110580244.2342.18.camel@localhost> I upgraded to libgcj-4.0.0-0.32 and eclipse-ecj-3.1.0_fc-0.M5.12. The results for compiling classpath: ecj | ecj-native | jikes ------------------------------------------------------------- real 1m31.786s | real 0m16.207s | real 0m8.423s user 1m22.796s | user 0m14.925s | user 0m7.052s sys 0m1.369s | sys 0m1.020s | sys 0m0.755s (ecj-native went from 24.5s to 16.2s as a result of -O2) I also uploaded oprofiles for ecj[1], ecj-native[2] and ecj-native-with- the-old-gcjlib-tools-jar[3]. Note that I'm running a Centrino so the oprofile driver falls back to timer interrupt mode. [1] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj.log [2] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native.log [3] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native-gcjlib.log -- Ziga From dpaun at rogers.com Fri Mar 11 23:00:40 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Fri, 11 Mar 2005 18:00:40 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: References: Message-ID: <20050311230040.GD5762@rogers.com> On Fri, Mar 11, 2005 at 10:49:18AM -0700, Tom Tromey wrote: > Jakub, libgcj will build and install a default .db. However, I'm not > sure we really want to have this file owned by the gcc RPM. It is > going to be modified by other RPMs as they are installed... what is > the usual thing to do in this situation? Why not install the different .db's into a database.d/ directory like we do for a bunch of things now (like /etc/profile.d). This would make adding/deleting from it much simpler, and it would also help a lot to avoid the O(n^2) recompilation step since we can recompile just based on file timestamps. The dir.d/ stuff works very well in practice, let's be consistent and use it everywhere it applies. -- Dimi. From green at redhat.com Sat Mar 12 00:23:03 2005 From: green at redhat.com (Anthony Green) Date: Fri, 11 Mar 2005 16:23:03 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 Message-ID: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> Here's a solution to jmx problem in rawhide. I hope somebody (gbenson?) can apply it and rebuild the RPMs. Thanks! AG -------- Forwarded Message -------- From: Anthony Green To: Discussion about JPackage project Subject: Re: [JPackage-discuss] [Fwd: mx4j (Was: [fedora-java] tomcat5)] Date: Fri, 11 Mar 2005 16:13:28 -0800 On Fri, 2005-03-11 at 10:43 -0500, Fernando Nasser wrote: > The javamail package already has a 'javamail-monolithic' subpackage with > such a jar file and we are about to do the same for classpathx-mail. > > Following the trend we should have a 'mx4j-monolithic' subpackage. Actually, it turns out that this jar (or something close to it) already exists. The only problem is that the spec file is using "mx4j-jmx.jar" for the alternative instead of just "mx4j.jar". Somebody just needs to apply this patch and rebuild. tomcat5 also needs to be rebuilt, since it actually copies the jmxri alternative jar file into itself as part of the build procedure. AG *** mx4j.spec~ 2005-03-07 01:56:29.000000000 -0800 --- mx4j.spec 2005-03-11 15:36:58.000000000 -0800 *************** *** 209,219 **** rm -f %{_javadir}/%{name}.jar %post ! /usr/sbin/update-alternatives --install %{_javadir}/jmxri.jar jmxri %{_javadir}/%{name}/%{name}-jmx.jar 0 %postun if [ "$1" = "0" ]; then ! /usr/sbin/update-alternatives --remove jmxri %{_javadir}/%{name}/%{name}-jmx.jar fi --- 209,219 ---- rm -f %{_javadir}/%{name}.jar %post ! /usr/sbin/update-alternatives --install %{_javadir}/jmxri.jar jmxri %{_javadir}/%{name}/%{name}.jar 0 %postun if [ "$1" = "0" ]; then ! /usr/sbin/update-alternatives --remove jmxri %{_javadir}/%{name}/%{name}.jar fi AG From aph at redhat.com Sat Mar 12 11:55:05 2005 From: aph at redhat.com (Andrew Haley) Date: Sat, 12 Mar 2005 11:55:05 +0000 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <1110580244.2342.18.camel@localhost> References: <1110580244.2342.18.camel@localhost> Message-ID: <16946.55449.39039.200659@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > I upgraded to libgcj-4.0.0-0.32 and eclipse-ecj-3.1.0_fc-0.M5.12. > The results for compiling classpath: > > ecj | ecj-native | jikes > ------------------------------------------------------------- > real 1m31.786s | real 0m16.207s | real 0m8.423s > user 1m22.796s | user 0m14.925s | user 0m7.052s > sys 0m1.369s | sys 0m1.020s | sys 0m0.755s > > (ecj-native went from 24.5s to 16.2s as a result of -O2) > > I also uploaded oprofiles for ecj[1], ecj-native[2] and ecj-native-with- > the-old-gcjlib-tools-jar[3]. > > Note that I'm running a Centrino so the oprofile driver falls back to > timer interrupt mode. > > [1] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj.log > [2] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native.log > [3] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native-gcjlib.log Thank you very much for doing this. It's very useful. Jikes is famously fast, so I'm fairly pleased to see we're close. It says here: "[Jikes] is astoundingly fast -- hundreds of thousands of lines of code per minute (about ten times faster than other compilers)" There are some surprises here. Is ecj fully interpreted code? _Jv_InterpMethod::run seems only to take 0.0036% of the time. I'm going to investigate some more. I'm sure that ecj-native isn't purely native code, because of this line: 399 2.2024 libgcj.so.6.0.0 _Jv_BytecodeVerifier::verify_instructions_0() which is weird. Thanks again, Andrew. From gbenson at redhat.com Mon Mar 14 14:12:33 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Mar 2005 14:12:33 +0000 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050314141232.GC14998@redhat.com> I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make JPackage patches. Cheers, Gary Anthony Green wrote: > Here's a solution to jmx problem in rawhide. I hope somebody > (gbenson?) can apply it and rebuild the RPMs. > > Thanks! > > AG > > -------- Forwarded Message -------- > From: Anthony Green > To: Discussion about JPackage project > Subject: Re: [JPackage-discuss] [Fwd: mx4j (Was: [fedora-java] tomcat5)] > Date: Fri, 11 Mar 2005 16:13:28 -0800 > On Fri, 2005-03-11 at 10:43 -0500, Fernando Nasser wrote: > > The javamail package already has a 'javamail-monolithic' subpackage with > > such a jar file and we are about to do the same for classpathx-mail. > > > > Following the trend we should have a 'mx4j-monolithic' subpackage. > > Actually, it turns out that this jar (or something close to it) already > exists. The only problem is that the spec file is using "mx4j-jmx.jar" > for the alternative instead of just "mx4j.jar". > > Somebody just needs to apply this patch and rebuild. tomcat5 also needs > to be rebuilt, since it actually copies the jmxri alternative jar file > into itself as part of the build procedure. > > AG > > > *** mx4j.spec~ 2005-03-07 01:56:29.000000000 -0800 > --- mx4j.spec 2005-03-11 15:36:58.000000000 -0800 > *************** > *** 209,219 **** > rm -f %{_javadir}/%{name}.jar > > %post > ! /usr/sbin/update-alternatives --install %{_javadir}/jmxri.jar jmxri %{_javadir}/%{name}/%{name}-jmx.jar 0 > > %postun > if [ "$1" = "0" ]; then > ! /usr/sbin/update-alternatives --remove jmxri %{_javadir}/%{name}/%{name}-jmx.jar > fi > > > --- 209,219 ---- > rm -f %{_javadir}/%{name}.jar > > %post > ! /usr/sbin/update-alternatives --install %{_javadir}/jmxri.jar jmxri %{_javadir}/%{name}/%{name}.jar 0 > > %postun > if [ "$1" = "0" ]; then > ! /usr/sbin/update-alternatives --remove jmxri %{_javadir}/%{name}/%{name}.jar > fi > > > > > AG From green at redhat.com Mon Mar 14 15:40:08 2005 From: green at redhat.com (Anthony Green) Date: Mon, 14 Mar 2005 07:40:08 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <20050314141232.GC14998@redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> Message-ID: <1110814808.5273.5.camel@localhost.localdomain> On Mon, 2005-03-14 at 14:12 +0000, Gary Benson wrote: > I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and > tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make > JPackage patches. OK, thanks. I don't see it in rawhide yet. Do you know how long this takes? AG From overholt at redhat.com Mon Mar 14 15:50:36 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 14 Mar 2005 10:50:36 -0500 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110814808.5273.5.camel@localhost.localdomain> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110814808.5273.5.camel@localhost.localdomain> Message-ID: <20050314155036.GA27584@redhat.com> * Anthony Green [2005-03-14 10:47]: > On Mon, 2005-03-14 at 14:12 +0000, Gary Benson wrote: > > I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and > > tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make > > JPackage patches. > > OK, thanks. I don't see it in rawhide yet. Do you know how long this > takes? I think the push happens at 5:30 AM EST each day and it takes a few hours. I could be wrong, though. Andrew From Nicolas.Mailhot at laPoste.net Mon Mar 14 19:13:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 14 Mar 2005 20:13:07 +0100 Subject: [fedora-java] Re: [JPackage-discuss] XSLT limitations (was: Re: Recursive Classpath Thing) In-Reply-To: <20050314160948.GF14998@redhat.com> References: <1110404694.5536.42.camel@localhost.localdomain> <20050314111515.GB14998@redhat.com> <6013.192.54.193.137.1110799386.squirrel@rousalka.dyndns.org> <200503140841.38596@vadim.nasardinov> <11685.192.54.193.137.1110808665.squirrel@rousalka.dyndns.org> <20050314141450.GD14998@redhat.com> <10539.192.54.193.137.1110810361.squirrel@rousalka.dyndns.org> <20050314144424.GE14998@redhat.com> <12365.192.54.193.137.1110812247.squirrel@rousalka.dyndns.org> <20050314160948.GF14998@redhat.com> Message-ID: <1110827589.2046.52.camel@rousalka.dyndns.org> Le lundi 14 mars 2005 ? 16:09 +0000, Gary Benson a ?crit : > Before I jump in feet first, can I clarify what the ultimate goal is. > As far as I see it, currently the command "build-classpath bcel" will > print out "/usr/share/java/bcel.jar". You would like it to print out > "/usr/share/java/regexp.jar:/usr/share/java/bcel.jar". Am I correct? Ok, you asked it you'll get it;) CC-ing fedora-devel-java, Steve Cohen (who also expressed some interest lately) and the common java packaging list (since I do believe this is larger than JPackage alone and is cojapas material at least). The ultimate goal as you write is to generate a classic /usr/share/java/regexp.jar:/usr/share/java/bcel.jar classpath (or populate a directory with jar symlinks, those being the two main ways an application creates its own classpath). A lot of people me included feel you can't create classpathes like this from the jar files alone, and you need additional metadata, probably in standalone files like is already the case for various Unix systems. There is broad agreement on what those files should contain. A lesser number of people want these standalone files to be in XML. I'm among this group, mainly because we will have to deal with windows users at some point and I don't even want to deal with problems like CRLF in 2005. I'll describe now broadly what I personally think these XML files contents should be. The thing that converts these files to the aforementioned path is left to your discretion. Like you rightly wrote, once such an engine is written and proves the validity of the approach it can be rewritten in other langages. The main thing is not to have to rewrite all the description files all the times, and keep the output stable so startup scripts do not need rewriting either. 1. a single XML file should describe one classpath unit provided by a given project. 2. a classpath unit is most of the times a jar file or a set of jar files. But it is not always the case : it can also contain stuff like property files, xml files, even sometimes resources like sound files, icons, etc 3. on some platforms all those files are lumped in a single per-app dir. On others like Linux common conventions like the FHS mandate separation of configuration and data parts 4. likewise on multi-user systems separate users must be able to overload the configuration parts transparently 5. lastly while the configuration of an infrastructure is often system-wide in scope, sometimes it's very useful to be able to overload it on a per-app basis (a common example would be log4j - you don't want all the apps in the system share the same log files, even if you want them to share the log4j code) 6. therefore while a classpath unit descriptor should list the files that compose it, exact file location should be left to separate policy files (for example given a set of files search the jars in /usr/share/java, the .properties in the same dir then ~/.java then /etc/java, etc) 7. when a classpath unit is an implementation of a common java infrastructure like jmx it should declare it 8. this means the possibility of simultaneous installations of several implementations of the same thing on a given system exists. While some objective factors like jvm compatibility (I'll get to this point later) can be used to choose a particular implementations, sometimes you'll just have several valid choices. It is probably very dangerous to let classpath units self-declare their relative priorities (everyone would want to be king). Therefore we need separate policy files that list implementation priorities (probably distro specific, maybe overloadable by the user, should list all known implementations to be effective and the system then should choose between the implementations actually present) 9. a particular classpath unit must list all the other classpath units it depends on. Some of them might be mandatory (won't work without them) others might be opportunistic (use them if they're here, if not the app will still work without them) 10. a particular classpath unit might use jni and require a particular library to be in the app library path (now since we've already decided to output a java classpath, I don't know if it's better to do such resolution in a separate utility that takes a classpath in input and outputs a LD_LIBRARY_PATH, if you use the same command to output one of them depending on a CLI parameter or if you always output two lines, one with the classpath the other with the LD_LIBRARY_PATH. And apps like tomcat that want directories of jars are yet another problem) 11. a particular classpath unit might use some features of the java langage only found on some java language versions and require the jvm to support them 12. a particular classpath unit might work with some jvms only - the extreme case being in-jvm implementations that only work with a single jvm (yes I think in-jvm libraries need to be covered by the xml descriptors too) 13 sometimes you may need to generate your classpath in separate bits (for example an ant build.xml where some targets require additional jars like junit - they'll need their path in pieces but the pieces must be compatible with each other) 14 sometimes a classpath unit has a direct influence on some othe jvm parameters like memory sizing 15 you need to handle classpath unit versionning- given the problem scope managing version ranges is probably best. 16 lots of other considerations that are eluding me right now but will come to light later. The main point is classpath building is _hard_, this is largely hidden by the fact classpathes are by and large manually written right now, but if we want to automate this we must remember it. When writing a classpath builder you have to remember you may need to add some rules later, so under-specifying is probably a bad idea. Given all this the xml files I started working on looked like this : And this : The exact element hierarchy can be probably hammered on while writing the actual implementation. As long as all the elements are present in the files mass syntax changing can be handled by xslt later. I hope I haven't disgusted you and you still want to work on the problem. If you still have questions don't hesitate to ask. For now I'm closing this post before writing a novel. Regards, -- Nicolas Mailhot -------------- 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 green at redhat.com Tue Mar 15 15:40:38 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 07:40:38 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <20050314141232.GC14998@redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> Message-ID: <1110901238.7168.21.camel@localhost.localdomain> On Mon, 2005-03-14 at 14:12 +0000, Gary Benson wrote: > I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and > tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make > JPackage patches. Ok, thanks - that fixed the jmxri problem. tomcat5 still doesn't run out of the box. You need to do this first: $ cd /usr/lib/jvm-exports/java-1.4.2-gcj $ ln -s /usr/share/java/libgcj-4.0.0.jar jaas.jar $ ln -s /usr/share/java/libgcj-4.0.0.jar jdbc-stdext.jar $ ln -s /usr/share/java/libgcj-4.0.0.jar jndi.jar $ ln -s /usr/share/java/libgcj-4.0.0.jar jta.jar fitzsim has gcj-java-compat patches for this (except for the jta line), but it sounded like he wanted to wait until after FC4test1 was branched before putting them in. Tom: why? But now I'm seeing JSP related problems. Our java compiler doesn't recognize the -extdirs option it's being passed. I had no problem when I tried JSP sample programs before this (on a different machine). Did you tweak anything else? AG From overholt at redhat.com Tue Mar 15 17:36:27 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 12:36:27 -0500 Subject: [fedora-java] failing jar compilation Message-ID: <20050315173627.GB29844@redhat.com> Hi, Eclipse has now changed their build procedures to bootstrap like so: A. build ecj itself with a pre-existing java compiler B. build ecj with output 1. C. use output of 2. to build rest of Eclipse We've modified like this: 1. a. build "franken-ecj" with gcj -C b. natively-compile 1a. 2. a. use output of 1. to build ecj a la A. above b. natively-compile 2a. 3. a. use output of 2. to build ecj a la B. above b. natively-compile 3b. 4. use output of 3. to build rest of Eclipse However, with both gcc head and our latest gcc-java RPMs (gcc-java-4.0.0-0.33), 3b. is failing for me: $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o ecj.withecj.jar.so ecj.withecj.jar org/eclipse/jdt/core/CheckDebugAttributes.java: In class 'org.eclipse.jdt.core.CheckDebugAttributes': org/eclipse/jdt/core/CheckDebugAttributes.java: In constructor '()': org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=5: premature end of bytecode org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: premature end of bytecode org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: branch to middle of instruction org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=5: premature end of bytecode org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: premature end of bytecode org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=7: stack sizes differ org/eclipse/jdt/core/CheckDebugAttributes.java:0: internal compiler error: Segmentation fault As opposed to: $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o ecj.withjavac.jar.so ecj.withjavac.jar $ Anyone have any ideas? I've put the two jars at [1] until I can narrow it down for a proper bug report. Andrew [1] http://people.redhat.com/overholt/ecj.withecj.jar http://people.redhat.com/overholt/ecj.withjavac.jar From green at redhat.com Tue Mar 15 18:38:05 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 10:38:05 -0800 Subject: [fedora-java] failing jar compilation In-Reply-To: <20050315173627.GB29844@redhat.com> References: <20050315173627.GB29844@redhat.com> Message-ID: <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-15 at 12:36 -0500, Andrew Overholt wrote: > Hi, > > Eclipse has now changed their build procedures to bootstrap like so: > > A. build ecj itself with a pre-existing java compiler > B. build ecj with output 1. > C. use output of 2. to build rest of Eclipse > > We've modified like this: > > 1. a. build "franken-ecj" with gcj -C > b. natively-compile 1a. > 2. a. use output of 1. to build ecj a la A. above > b. natively-compile 2a. > 3. a. use output of 2. to build ecj a la B. above > b. natively-compile 3b. > 4. use output of 3. to build rest of Eclipse > > However, with both gcc head and our latest gcc-java RPMs > (gcc-java-4.0.0-0.33), 3b. is failing for me: Why bother compiling to bytecode in the stage 1? We can avoid this bug by simply compiling straight to native code from the java source. AG From overholt at redhat.com Tue Mar 15 18:46:30 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 13:46:30 -0500 Subject: [fedora-java] failing jar compilation In-Reply-To: <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050315184630.GD29844@redhat.com> * Anthony Green [2005-03-15 13:43]: > On Tue, 2005-03-15 at 12:36 -0500, Andrew Overholt wrote: > > 1. a. build "franken-ecj" with gcj -C > > b. natively-compile 1a. > Why bother compiling to bytecode in the stage 1? We can avoid this bug > by simply compiling straight to native code from the java source. Yeah, good one. I'll do that. Andrew From overholt at redhat.com Tue Mar 15 18:50:08 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 13:50:08 -0500 Subject: [fedora-java] failing jar compilation In-Reply-To: <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050315185008.GE29844@redhat.com> * Anthony Green [2005-03-15 13:43]: > > Why bother compiling to bytecode in the stage 1? We can avoid this bug > by simply compiling straight to native code from the java source. Actually, on second thought, I don't know if this will work. We need the system's java-gcj-compat to use the ecj we've just built (with gcj) and the only way I can think of doing this is by setting GCJ_PROPERTIES. I guess I could compile the stuff to a binary called "javac" and set PATH=.:$PATH, but I'm not sure some of the stuff provided by java-gcj-compat won't fail. Andrew From fitzsim at redhat.com Tue Mar 15 18:55:34 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 15 Mar 2005 13:55:34 -0500 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110901238.7168.21.camel@localhost.localdomain> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110901238.7168.21.camel@localhost.localdomain> Message-ID: <1110912934.3852.5.camel@tortoise.toronto.redhat.com> On Tue, 2005-03-15 at 07:40 -0800, Anthony Green wrote: > On Mon, 2005-03-14 at 14:12 +0000, Gary Benson wrote: > > I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and > > tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make > > JPackage patches. > > Ok, thanks - that fixed the jmxri problem. > > tomcat5 still doesn't run out of the box. You need to do this first: > > $ cd /usr/lib/jvm-exports/java-1.4.2-gcj > $ ln -s /usr/share/java/libgcj-4.0.0.jar jaas.jar > $ ln -s /usr/share/java/libgcj-4.0.0.jar jdbc-stdext.jar > $ ln -s /usr/share/java/libgcj-4.0.0.jar jndi.jar > $ ln -s /usr/share/java/libgcj-4.0.0.jar jta.jar > > fitzsim has gcj-java-compat patches for this (except for the jta line), > but it sounded like he wanted to wait until after FC4test1 was branched > before putting them in. Tom: why? > I didn't want to destabilize things right before FC4test1, since I made a bunch of changes to support adding security providers. I'll commit them today. > But now I'm seeing JSP related problems. Our java compiler doesn't > recognize the -extdirs option it's being passed. I had no problem when > I tried JSP sample programs before this (on a different machine). Did > you tweak anything else? > I committed your -extdirs patches to java-gcj-compat -- I'm not sure if they would cause JSP failures though. Tom > AG > > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From overholt at redhat.com Tue Mar 15 19:35:21 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 14:35:21 -0500 Subject: [fedora-java] Re: Eclipse on s390{,x} In-Reply-To: <1109805346.5081.6.camel@localhost.localdomain> References: <20050302211247.GD29000@redhat.com> <1109805346.5081.6.camel@localhost.localdomain> Message-ID: <20050315193521.GF29844@redhat.com> * Ben Konrath [2005-03-02 18:15]: > > On Wed, 2005-02-03 at 16:12 -0500, Andrew Overholt wrote: > > > Ideally we'd contribute this work back upstream to the Eclipse Foundation, > > but I think Ben Konrath mentioned something about doing that requiring > > machines or builds or something? Ben, any comments on that? > > Here are the upstream instructions: > > http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-releng-home/contributingEclipsePorts.html?rev=HEAD&content-type=text/html > > I'm not sure if anybody is doing this right now, but I have seen > references indicating that contributed builds will be available in the > near future. I did the work to patch for building on s390 and s390x. I don't know oif we'll be able to contribute the builds back, though, 'cause we don't have any machines (outside of the build ones) on which we can run tests. Andrew From overholt at redhat.com Tue Mar 15 19:39:17 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 14:39:17 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> Message-ID: <20050315193916.GH29844@redhat.com> * Tom Tromey [2005-03-08 13:25]: > Bryce> Is resources.jar still used entirely uncompiled? We > Bryce> should perhaps concentrate on that bug first. > > I think this bug is still undiagnosed. Actually, it seems to work now (on i386 and ppc, at least)! Andrew From green at redhat.com Tue Mar 15 20:08:06 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 12:08:06 -0800 Subject: [fedora-java] failing jar compilation In-Reply-To: <20050315185008.GE29844@redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050315185008.GE29844@redhat.com> Message-ID: <1110917286.5879.2.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-15 at 13:50 -0500, Andrew Overholt wrote: > * Anthony Green [2005-03-15 13:43]: > > > > Why bother compiling to bytecode in the stage 1? We can avoid this bug > > by simply compiling straight to native code from the java source. > > Actually, on second thought, I don't know if this will work. We need the > system's java-gcj-compat to use the ecj we've just built (with gcj) and the > only way I can think of doing this is by setting GCJ_PROPERTIES. > > I guess I could compile the stuff to a binary called "javac" and set > PATH=.:$PATH, but I'm not sure some of the stuff provided by > java-gcj-compat won't fail. I'm not sure I understand. For the stage2 build, were you expecting to use java-gcj-compat and a classmap database to get the stage1 built compiler? In that case you could simple compile the stage1 bytecode _after_ you build the native code. AG From green at redhat.com Tue Mar 15 20:14:32 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 12:14:32 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110912934.3852.5.camel@tortoise.toronto.redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110901238.7168.21.camel@localhost.localdomain> <1110912934.3852.5.camel@tortoise.toronto.redhat.com> Message-ID: <1110917673.5879.6.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-15 at 13:55 -0500, Thomas Fitzsimmons wrote: > > tomcat5 still doesn't run out of the box. You need to do this first: > > > > $ cd /usr/lib/jvm-exports/java-1.4.2-gcj > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jaas.jar > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jdbc-stdext.jar > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jndi.jar > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jta.jar [snip] > I didn't want to destabilize things right before FC4test1, since I made > a bunch of changes to support adding security providers. I'll commit > them today. Could also please add the jta.jar symlink, and make java-gcj-compat Provide jta? [snip] > > I committed your -extdirs patches to java-gcj-compat -- I'm not sure if > they would cause JSP failures though. I don't know either. I may have time to look into this tomorrow. AG From fitzsim at redhat.com Tue Mar 15 21:16:42 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 15 Mar 2005 16:16:42 -0500 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110917673.5879.6.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110901238.7168.21.camel@localhost.localdomain> <1110912934.3852.5.camel@tortoise.toronto.redhat.com> <1110917673.5879.6.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1110921402.3852.9.camel@tortoise.toronto.redhat.com> On Tue, 2005-03-15 at 12:14 -0800, Anthony Green wrote: > On Tue, 2005-03-15 at 13:55 -0500, Thomas Fitzsimmons wrote: > > > tomcat5 still doesn't run out of the box. You need to do this first: > > > > > > $ cd /usr/lib/jvm-exports/java-1.4.2-gcj > > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jaas.jar > > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jdbc-stdext.jar > > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jndi.jar > > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jta.jar > [snip] > > I didn't want to destabilize things right before FC4test1, since I made > > a bunch of changes to support adding security providers. I'll commit > > them today. > > Could also please add the jta.jar symlink, and make java-gcj-compat > Provide jta? > Done. Try java-1.4.2-gcj-compat-1.4.2.0-40jpp_11rh. Tom From overholt at redhat.com Tue Mar 15 21:58:34 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 16:58:34 -0500 Subject: [fedora-java] failing jar compilation In-Reply-To: <1110917286.5879.2.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050315185008.GE29844@redhat.com> <1110917286.5879.2.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050315215834.GK29844@redhat.com> * Anthony Green [2005-03-15 15:16]: > On Tue, 2005-03-15 at 13:50 -0500, Andrew Overholt wrote: > > * Anthony Green [2005-03-15 13:43]: > > > > > > Why bother compiling to bytecode in the stage 1? We can avoid this bug > > > by simply compiling straight to native code from the java source. > > > > Actually, on second thought, I don't know if this will work. We need the > > system's java-gcj-compat to use the ecj we've just built (with gcj) and the > > only way I can think of doing this is by setting GCJ_PROPERTIES. > > > > I guess I could compile the stuff to a binary called "javac" and set > > PATH=.:$PATH, but I'm not sure some of the stuff provided by > > java-gcj-compat won't fail. > > I'm not sure I understand. For the stage2 build, were you expecting to > use java-gcj-compat and a classmap database to get the stage1 built > compiler? Yes. > In that case you could simple compile the stage1 bytecode _after_ you > build the native code. :) Good point. I will try that. Does anyone have any comments about my original problem? That's stopping me from progressing with this since and it means that I can't build eclipse right now. Andrew From green at redhat.com Tue Mar 15 22:08:16 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 14:08:16 -0800 Subject: [fedora-java] failing jar compilation In-Reply-To: <20050315215834.GK29844@redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050315185008.GE29844@redhat.com> <1110917286.5879.2.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050315215834.GK29844@redhat.com> Message-ID: <1110924496.5879.32.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-15 at 16:58 -0500, Andrew Overholt wrote: > Does anyone have any comments about my original problem? That's stopping > me from progressing with this since and it means that I can't build eclipse > right now. Oh man - I'm sorry. I totally misread your mail. I thought it was 1b that was failing, not 3b. Ignore everything I wrote in this thread :-) I have no idea what the problem is. It might be worth running that bytecode through another verifier to see if the bytecode really is wrong. AG From overholt at redhat.com Wed Mar 16 00:55:54 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 19:55:54 -0500 Subject: [fedora-java] Eclipse launcher icon.xpm Message-ID: <20050316005554.GB27876@redhat.com> Hi, I encountered a problem with the Eclipse build procedure a while back where it was getting confused on non-x86{,_64} platforms with icon.xpm. One of the Eclipse developers is asking for input on the situation since apparently icon.xpm doesn't do anything on linux. Does anyone know anything about this? https://bugs.eclipse.org/bugs/show_bug.cgi?id=86848 Thanks, Andrew From overholt at redhat.com Wed Mar 16 01:01:07 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 20:01:07 -0500 Subject: [fedora-java] "Notable features of FC4test1 include:" Message-ID: <20050316010107.GC27876@redhat.com> At [1]: "Notable features of FC4test1 include: [...] . The Eclipse IDE included along with some featured plugins . A solid foundation of Java packages for developers (ant, gcj, tomcat, struts, more classpath stuff) and the ability to possibly run Java apps through gij. [...]" :) Andrew [1] http://www.linuxcompatible.org/story43567.html From mark at klomp.org Wed Mar 16 09:57:47 2005 From: mark at klomp.org (Mark Wielaard) Date: Wed, 16 Mar 2005 10:57:47 +0100 Subject: [fedora-java] "Notable features of FC4test1 include:" In-Reply-To: <20050316010107.GC27876@redhat.com> References: <20050316010107.GC27876@redhat.com> Message-ID: <1110967067.4612.6.camel@localhost.localdomain> Hi, On Tue, 2005-03-15 at 20:01 -0500, Andrew Overholt wrote: > At [1]: > > "Notable features of FC4test1 include: > [...] > . The Eclipse IDE included along with some featured plugins > . A solid foundation of Java packages for developers (ant, gcj, tomcat, > struts, more classpath stuff) and the ability to possibly run Java apps > through gij. > [...]" > > :) And at [2] one of the comments is just: "Well, I'm going to try just for the super cool GCJ support" What I found interesting and encouraging was: . gcc 4.0 as the primary system compiler If that works well and all packages in the system have already been compiled with 4.0 then we are a lot closer to the new gcc release then I had realised. Awesome! Keep up the good work, Mark [2] http://lwn.net/Articles/127694/ -------------- 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 aph at redhat.com Wed Mar 16 11:17:01 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Mar 2005 11:17:01 +0000 Subject: [fedora-java] failing jar compilation In-Reply-To: <20050315173627.GB29844@redhat.com> References: <20050315173627.GB29844@redhat.com> Message-ID: <16952.5549.112273.756948@cuddles.cambridge.redhat.com> Andrew Overholt writes: > > However, with both gcc head and our latest gcc-java RPMs > (gcc-java-4.0.0-0.33), 3b. is failing for me: > > $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o ecj.withecj.jar.so ecj.withecj.jar > org/eclipse/jdt/core/CheckDebugAttributes.java: In class 'org.eclipse.jdt.core.CheckDebugAttributes': > org/eclipse/jdt/core/CheckDebugAttributes.java: In constructor '()': > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=5: premature end of bytecode > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: premature end of bytecode > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: branch to middle of instruction > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=5: premature end of bytecode > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: premature end of bytecode > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=7: stack sizes differ > org/eclipse/jdt/core/CheckDebugAttributes.java:0: internal compiler error: Segmentation fault > > As opposed to: > > $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o ecj.withjavac.jar.so ecj.withjavac.jar > $ > > Anyone have any ideas? I've put the two jars at [1] until I can narrow it > down for a proper bug report. > > Andrew > > [1] > http://people.redhat.com/overholt/ecj.withecj.jar > http://people.redhat.com/overholt/ecj.withjavac.jar $ fastjar tf ~/ecj.withecj.jar | sort META-INF/ META-INF/MANIFEST.MF org/ org/eclipse/ org/eclipse/jdt/ org/eclipse/jdt/core/ org/eclipse/jdt/core/CheckDebugAttributes.class org/eclipse/jdt/core/CheckDebugAttributes.class Yeah. I know gcj should give a better error message. Nonetheless, the cause of the problem is pretty obvious. Andrew. From rmoseley at redhat.com Wed Mar 16 13:26:12 2005 From: rmoseley at redhat.com (Rick Moseley) Date: Wed, 16 Mar 2005 07:26:12 -0600 Subject: [fedora-java] Eclipse launcher icon.xpm In-Reply-To: <20050316005554.GB27876@redhat.com> References: <20050316005554.GB27876@redhat.com> Message-ID: <423833F4.6070502@redhat.com> Andrew Overholt wrote: >Hi, > >I encountered a problem with the Eclipse build procedure a while back where >it was getting confused on non-x86{,_64} platforms with icon.xpm. One of >the Eclipse developers is asking for input on the situation since >apparently icon.xpm doesn't do anything on linux. Does anyone know >anything about this? > > During my recent travels through the wondrous world of Eclipse icons trying to figure out how to make our own icon appearance more consistent in response to https://bugzilla.redhat.com/beta/show_bug.cgi?id=146484 I could not find where this icon.xpm was used. It is a 48x48 pixel icon, so it is fairly large and there are not many of that size used in Eclipse. Most of the icons used are of the 16x16 pixel variety and it seems each plugin has its own icon set. *Most* of the time the Eclipse icon is named "eclipse16.gif" or just "eclipse.gif" inside these plugins, so it is basically a nightmare if someone wants to replace with their own set. Rick >https://bugs.eclipse.org/bugs/show_bug.cgi?id=86848 > >Thanks, > >Andrew > >-- >fedora-devel-java-list mailing list >fedora-devel-java-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > > From green at redhat.com Wed Mar 16 16:21:12 2005 From: green at redhat.com (Anthony Green) Date: Wed, 16 Mar 2005 08:21:12 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110921402.3852.9.camel@tortoise.toronto.redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110901238.7168.21.camel@localhost.localdomain> <1110912934.3852.5.camel@tortoise.toronto.redhat.com> <1110917673.5879.6.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1110921402.3852.9.camel@tortoise.toronto.redhat.com> Message-ID: <1110990072.7229.10.camel@localhost.localdomain> On Tue, 2005-03-15 at 16:16 -0500, Thomas Fitzsimmons wrote: > Done. Try java-1.4.2-gcj-compat-1.4.2.0-40jpp_11rh. I just updated and it appears to work now without manual intervention. Just run... $ service tomcat5 start and, after a few seconds, point your browser at http://localhost:8080/ Thanks! AG From sopwith at redhat.com Wed Mar 16 17:28:00 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 16 Mar 2005 12:28:00 -0500 Subject: [fedora-java] Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-extras-list - For users and developers of Fedora Extras fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-tools-list - For discussions about the toolchain (gcc, gdb, etc...) within Fedora fedora-devel-java-list - For discussions about Java-related Fedora development fedora-patches-list - For submitting patches to Fedora maintainers, and used in line with BugWeek fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-marketing-list - For discussions about marketing and expanding the Fedora user base fedora-de-list - For discussions about Fedora in the German language fedora-es-list - For discussions about Fedora in the Spanish language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From tromey at redhat.com Wed Mar 16 18:52:16 2005 From: tromey at redhat.com (Tom Tromey) Date: 16 Mar 2005 11:52:16 -0700 Subject: [fedora-java] failing jar compilation In-Reply-To: <16952.5549.112273.756948@cuddles.cambridge.redhat.com> References: <20050315173627.GB29844@redhat.com> <16952.5549.112273.756948@cuddles.cambridge.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: Andrew> org/eclipse/jdt/core/CheckDebugAttributes.class Andrew> org/eclipse/jdt/core/CheckDebugAttributes.class Andrew> Yeah. I know gcj should give a better error message. Nonetheless, the Andrew> cause of the problem is pretty obvious. I filed this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20502 Tom From green at redhat.com Thu Mar 17 04:34:35 2005 From: green at redhat.com (Anthony Green) Date: Wed, 16 Mar 2005 20:34:35 -0800 Subject: [fedora-java] mod_jk Message-ID: <1111034075.5269.3.camel@localhost.localdomain> I just noticed that we don't build jk (from tomcat5) or package mod_jk (or should that be jk2/mod_jk2?). It seems weird to package tomcat5, but not the Apache httpd connector. Is it too late to squeeze into FC4? AG From shiva at sewingwitch.com Thu Mar 17 05:43:23 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 16 Mar 2005 21:43:23 -0800 Subject: [fedora-java] mod_jk In-Reply-To: <1111034075.5269.3.camel@localhost.localdomain> References: <1111034075.5269.3.camel@localhost.localdomain> Message-ID: --On Wednesday, March 16, 2005 8:34 PM -0800 Anthony Green wrote: > I just noticed that we don't build jk (from tomcat5) or package mod_jk > (or should that be jk2/mod_jk2?). It seems weird to package tomcat5, > but not the Apache httpd connector. Is it too late to squeeze into FC4? FC2 included mod_jk2, which is now deprecated. >From : ># jk2 is a refactoring of mod_jk and uses the Apache Portable Runtime ># (apr). But due to lack of developer interest, it is unsupported. The ># alternative is mod_jk or mod_proxy_ajp. mod_jk is great and should be ># used for production. It is getting fixes as needed (which is now rare). >From : > JK2 has been put in maintainer mode and no further development will take > place. The reason for shutting down JK2 development was the lack of > developers interest. Other reason was lack of users interest in adopting > JK2, caused by configuration complexity when compared to JK. > > JK2 will have it's successor within core Apache2.1/2.2 distribution. We > have developed new proxy_ajp that is an addition to the mod_proxy and > uses Tomcat's AJP protocol stack. It is developped in httpd-2.1 and > integrated in it. We have also developed a new proxy_balancer module for > load balancing http and ajp protocol stacks. > > JK will be fully supported for all other web servers. The next JK release > is planned for the end of November. Lots of code from JK2 has been ported > to JK From Nicolas.Mailhot at laPoste.net Thu Mar 17 07:00:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 17 Mar 2005 08:00:07 +0100 Subject: [fedora-java] mod_jk In-Reply-To: References: <1111034075.5269.3.camel@localhost.localdomain> Message-ID: <1111042807.439.2.camel@rousalka.dyndns.org> Le mercredi 16 mars 2005 ? 21:43 -0800, Kenneth Porter a ?crit : > --On Wednesday, March 16, 2005 8:34 PM -0800 Anthony Green > wrote: > > > I just noticed that we don't build jk (from tomcat5) or package mod_jk > > (or should that be jk2/mod_jk2?). It seems weird to package tomcat5, > > but not the Apache httpd connector. Is it too late to squeeze into FC4? > > FC2 included mod_jk2, which is now deprecated. But jk1 should be fine - it survived several rewrite attempts, the latest being jk2. jk1 is still actively developed and maintained, with regular releases. Never understood why FC went for jk2 myself. Regards, -- Nicolas Mailhot -------------- 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 fernando at lozano.eti.br Thu Mar 17 14:01:00 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Thu, 17 Mar 2005 11:01:00 -0300 Subject: [fedora-java] mod_jk In-Reply-To: <1111034075.5269.3.camel@localhost.localdomain> References: <1111034075.5269.3.camel@localhost.localdomain> Message-ID: <42398D9C.2000504@lozano.eti.br> Hi Anthony, >I just noticed that we don't build jk (from tomcat5) or package mod_jk >(or should that be jk2/mod_jk2?). It seems weird to package tomcat5, >but not the Apache httpd connector. Is it too late to squeeze into FC4? > > This is not the http connector, it is the ajp connector. It is necessary only if you want apache to serve as a front-end for tomcat, say when a site needs to run both jsp and php, or you want apache to load balance many tomcat instances. I would like to have it, but it is not strictly necessary to run java web apps using tomcat. []s, Fernando Lozano From shiva at sewingwitch.com Thu Mar 17 14:46:15 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 17 Mar 2005 06:46:15 -0800 Subject: [fedora-java] mod_jk In-Reply-To: <42398D9C.2000504@lozano.eti.br> References: <1111034075.5269.3.camel@localhost.localdomain> <42398D9C.2000504@lozano.eti.br> Message-ID: --On Thursday, March 17, 2005 11:01 AM -0300 Fernando Lozano wrote: > This is not the http connector, it is the ajp connector. It is necessary > only if you want apache to serve as a front-end for tomcat, say when a > site needs to run both jsp and php, or you want apache to load balance > many tomcat instances. I would like to have it, but it is not strictly > necessary to run java web apps using tomcat. But it is necessary if, like me, you're serving a "regular" web site and need to integrate somebody's Java app. I've been running Apache/PHP for some time and now want to run DataVision and the cookbook for web integration calls for Tomcat. (Right now I'm stuck trying to figure out how to map a URI to the dvwebapp example application.) From nicolas.mailhot at laposte.net Thu Mar 17 15:09:59 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 17 Mar 2005 16:09:59 +0100 (CET) Subject: [fedora-java] mod_jk In-Reply-To: References: <1111034075.5269.3.camel@localhost.localdomain> <42398D9C.2000504@lozano.eti.br> Message-ID: <60566.192.54.193.35.1111072199.squirrel@rousalka.dyndns.org> On Jeu 17 mars 2005 15:46, Kenneth Porter a ?crit : > But it is necessary if, like me, you're serving a "regular" web site and > need to integrate somebody's Java app. I've been running Apache/PHP for > some time and now want to run DataVision > and the cookbook for web integration > calls for Tomcat. (Right now I'm > stuck trying to figure out how to map a URI to the dvwebapp example > application.) You have good mod_jk packages at JPackage. Probably nothing built for FC4T1, but the srpms should rebuild just fine. They should be pretty up-to-date, latest jk1 version or the previous one. Regards, -- Nicolas Mailhot From shiva at sewingwitch.com Thu Mar 17 15:18:30 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 17 Mar 2005 07:18:30 -0800 Subject: [fedora-java] mod_jk In-Reply-To: <60566.192.54.193.35.1111072199.squirrel@rousalka.dyndns.org> References: <1111034075.5269.3.camel@localhost.localdomain> <42398D9C.2000504@lozano.eti.br> <60566.192.54.193.35.1111072199.squirrel@rousalka.dyndns.org> Message-ID: <213B60E1D37FC37938A0C494@[10.169.6.246]> --On Thursday, March 17, 2005 4:09 PM +0100 Nicolas Mailhot wrote: > You have good mod_jk packages at JPackage. Probably nothing built for > FC4T1, but the srpms should rebuild just fine. > > They should be pretty up-to-date, latest jk1 version or the previous one. As I said, I'm just getting my feet wet with Java. (I've been able to read it for some time, to follow magazine articles, but never deployed anything.) (I'm using FC2, but do pull SRPMs from Rawhide and other repositories.) I hadn't seen before. Thanks for the pointer. From fernando at lozano.eti.br Thu Mar 17 15:42:13 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Thu, 17 Mar 2005 12:42:13 -0300 Subject: [fedora-java] mod_jk In-Reply-To: References: <1111034075.5269.3.camel@localhost.localdomain> <42398D9C.2000504@lozano.eti.br> Message-ID: <4239A555.9040001@lozano.eti.br> Hi Kenneth, >> This is not the http connector, it is the ajp connector. It is necessary >> only if you want apache to serve as a front-end for tomcat, say when a >> site needs to run both jsp and php, or you want apache to load balance >> many tomcat instances. I would like to have it, but it is not strictly >> necessary to run java web apps using tomcat. > > > But it is necessary if, like me, you're serving a "regular" web site > and need to integrate somebody's Java app. That's what I told. :-) []s, Fernando Lozano From overholt at redhat.com Thu Mar 17 21:08:34 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 17 Mar 2005 16:08:34 -0500 Subject: [fedora-java] Fedora "Project"? Message-ID: <20050317210834.GC31481@redhat.com> What do people think about having all the java stuff as a "project" like, for example, Stateless Linux or Anaconda Installer at http://fedora.redhat.com/projects/ ? Andrew From green at redhat.com Thu Mar 17 21:18:56 2005 From: green at redhat.com (Anthony Green) Date: Thu, 17 Mar 2005 13:18:56 -0800 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <20050317210834.GC31481@redhat.com> References: <20050317210834.GC31481@redhat.com> Message-ID: <1111094336.5269.33.camel@localhost.localdomain> On Thu, 2005-03-17 at 16:08 -0500, Andrew Overholt wrote: > What do people think about having all the java stuff as a "project" like, > for example, Stateless Linux or Anaconda Installer at > http://fedora.redhat.com/projects/ > ? Yes, this is a good idea - although I'm not sure it mean anything more than having a web site. But that's definitely valuable for publicizing our efforts. AG From dmalcolm at redhat.com Thu Mar 17 22:37:03 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 17 Mar 2005 17:37:03 -0500 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <20050317210834.GC31481@redhat.com> References: <20050317210834.GC31481@redhat.com> Message-ID: <1111099024.5361.128.camel@cassandra.boston.redhat.com> On Thu, 2005-03-17 at 16:08 -0500, Andrew Overholt wrote: > What do people think about having all the java stuff as a "project" like, > for example, Stateless Linux or Anaconda Installer at > http://fedora.redhat.com/projects/ > ? > Maybe have a wiki page (as well or instead? not sure) since it's so much easier for outside contributors? http://fedoraproject.org/wiki/ From talios at gmail.com Thu Mar 17 22:41:34 2005 From: talios at gmail.com (Mark Derricutt) Date: Fri, 18 Mar 2005 11:41:34 +1300 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <1111099024.5361.128.camel@cassandra.boston.redhat.com> References: <20050317210834.GC31481@redhat.com> <1111099024.5361.128.camel@cassandra.boston.redhat.com> Message-ID: <5184347f05031714411aa3f7af@mail.gmail.com> How would this "project" differ than whats going on the JPackae project. I've not really followed too closely "Fedora java" as opposed to "Fedoras use of JPackage" ( I'm really beginning to dislike GMail actually ). From fernando at lozano.eti.br Thu Mar 17 23:48:02 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Thu, 17 Mar 2005 20:48:02 -0300 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <5184347f05031714411aa3f7af@mail.gmail.com> References: <20050317210834.GC31481@redhat.com> <1111099024.5361.128.camel@cassandra.boston.redhat.com> <5184347f05031714411aa3f7af@mail.gmail.com> Message-ID: <423A1732.6040501@lozano.eti.br> Hi, I think a fedora-java project visible on the fedora main page (and including a wiki) would be very nice. It involves a lot of packages and high-visibility applications like Eclipse and Tomcat. But as I understand fedora-java is very different from JPackage. Most packages there need Sun Java, but fedora-java is built around gcj and native compilation. Please enlightem me if I am wrong. []s, Fernando Lozano From tromey at redhat.com Fri Mar 18 00:26:25 2005 From: tromey at redhat.com (Tom Tromey) Date: 17 Mar 2005 17:26:25 -0700 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1109465599.8854.32.camel@localhost> References: <20050225164858.GH19850@redhat.com> <1109465599.8854.32.camel@localhost> Message-ID: >>>>> "Ziga" == Ziga Mahkovec writes: Ziga> I gave these a spin and they work great. The only problem I had so far Ziga> was with opening XML files. I attached a sample file (a web application Ziga> descriptor) which, when opened in Eclipse, produces the attached Ziga> exception. Any XML file with a DOCTYPE seems to trigger this. Ziga> !MESSAGE Unable to initialize editor: org.eclipse.ui.DefaultTextEditor java.net.MalformedURLException: Absolute URL required with null context I forwarded this to Chris Burdess and he wrote a fix that is in GNU Classpath. I could send the patch if someone wants to test it. Otherwise it will have to wait until I get my tree back in a sane state so I can try it out. Tom From pmuldoon at redhat.com Fri Mar 18 04:36:17 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 17 Mar 2005 22:36:17 -0600 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <20050317210834.GC31481@redhat.com> References: <20050317210834.GC31481@redhat.com> Message-ID: <1111120578.5779.13.camel@localhost.localdomain> I think it is good idea, especially as it will lend a focus to specific aims of Java on Fedora. Regards Phil On Thu, 2005-03-17 at 16:08 -0500, Andrew Overholt wrote: > What do people think about having all the java stuff as a "project" like, > for example, Stateless Linux or Anaconda Installer at > http://fedora.redhat.com/projects/ > ? > > Andrew > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From bkonrath at redhat.com Fri Mar 18 04:59:43 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 17 Mar 2005 23:59:43 -0500 Subject: [fedora-java] generating a cdt 3.0 tarball Message-ID: <1111121983.30148.6.camel@town.toronto.redhat.com> Hey Phil/Rick, Here are some updated instructions for generating the CDT 3.0M5 tarball. I couldn't actually find the 3.0 tag so I just put "**3.0TAG**" in the sed line so you'll have to track it down (if it exists). If the repo hasn't been tagged, then we're stuck with HEAD I suppose. % mkdir temp && cd temp % /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse % mkdir home % cvs -d :pserver:anonymous dev eclipse org:/home/tools co \ org.eclipse.cdt-releng/org.eclipse.cdt.releng % cd org.eclipse.cdt-releng/org.eclipse.cdt.releng % sed --in-place 's/HEAD/**3.0TAG**/' maps/cdt.map % java -cp ../../SDK/startup.jar \ -Duser.home=../../home \ org.eclipse.core.launcher.Main \ -application org.eclipse.ant.core.antRunner \ -buildfile build.xml \ -DbaseLocation=/user/share/eclipse \ -DdontUnzip=true fetch % cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz org.eclipse.cdt.releng I just tried this from HEAD and it seems to be be working with gij now! If you have any problems, feel free to ping me. Cheers, Ben From pmuldoon at redhat.com Fri Mar 18 05:16:02 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 17 Mar 2005 23:16:02 -0600 Subject: [fedora-java] Re: generating a cdt 3.0 tarball In-Reply-To: <1111121983.30148.6.camel@town.toronto.redhat.com> References: <1111121983.30148.6.camel@town.toronto.redhat.com> Message-ID: <1111122963.5779.33.camel@localhost.localdomain> Ben Thanks for the changes to the existing procedure. CDT 3.0M5 does not seem be out just yet. But we'll roll a new rpm as soon as it is. Regards Phil On Thu, 2005-03-17 at 23:59 -0500, Ben Konrath wrote: > Hey Phil/Rick, > > Here are some updated instructions for generating the CDT 3.0M5 tarball. > I couldn't actually find the 3.0 tag so I just put "**3.0TAG**" in the > sed line so you'll have to track it down (if it exists). If the repo > hasn't been tagged, then we're stuck with HEAD I suppose. > > % mkdir temp && cd temp > % /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse > % mkdir home > % cvs -d :pserver:anonymous dev eclipse org:/home/tools co \ > org.eclipse.cdt-releng/org.eclipse.cdt.releng > % cd org.eclipse.cdt-releng/org.eclipse.cdt.releng > % sed --in-place 's/HEAD/**3.0TAG**/' maps/cdt.map > % java -cp ../../SDK/startup.jar \ > -Duser.home=../../home \ > org.eclipse.core.launcher.Main \ > -application org.eclipse.ant.core.antRunner \ > -buildfile build.xml \ > -DbaseLocation=/user/share/eclipse \ > -DdontUnzip=true fetch > % cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz org.eclipse.cdt.releng > > I just tried this from HEAD and it seems to be be working with gij now! > If you have any problems, feel free to ping me. > > Cheers, Ben > From ziga.mahkovec at klika.si Fri Mar 18 10:06:25 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 18 Mar 2005 11:06:25 +0100 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: References: <20050225164858.GH19850@redhat.com> <1109465599.8854.32.camel@localhost> Message-ID: <1111140385.5383.8.camel@localhost> On Thu, 2005-03-17 at 17:26 -0700, Tom Tromey wrote: > >>>>> "Ziga" == Ziga Mahkovec writes: > > Ziga> I gave these a spin and they work great. The only problem I had so far > Ziga> was with opening XML files. I attached a sample file (a web application > Ziga> descriptor) which, when opened in Eclipse, produces the attached > Ziga> exception. Any XML file with a DOCTYPE seems to trigger this. > > Ziga> !MESSAGE Unable to initialize editor: org.eclipse.ui.DefaultTextEditor java.net.MalformedURLException: Absolute URL required with null context > > I forwarded this to Chris Burdess and he wrote a fix that is in GNU > Classpath. > > I could send the patch if someone wants to test it. Otherwise it will > have to wait until I get my tree back in a sane state so I can try it > out. I'd be willing to test the patch. Given that this was actually a native compilation issue[1] (it works fine in interpreted mode), does this patch work around a compiler issue? [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149915 -- Ziga From bennet at redhat.com Fri Mar 18 12:40:07 2005 From: bennet at redhat.com (Karen Bennet) Date: Fri, 18 Mar 2005 07:40:07 -0500 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <20050317210834.GC31481@redhat.com> References: <20050317210834.GC31481@redhat.com> Message-ID: <423ACC27.1080901@redhat.com> We are restructuring and documenting what a fedora project means, this will be posted shortly to the fedora community, However, having fedora-java launched as a first 'created' project under these guidelines is a great idea. We might need to call it something other then java though, so welcome suggestions. Andrew Overholt wrote: >What do people think about having all the java stuff as a "project" like, >for example, Stateless Linux or Anaconda Installer at >http://fedora.redhat.com/projects/ >? > >Andrew > >-- >fedora-devel-java-list mailing list >fedora-devel-java-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > > From rmoseley at redhat.com Fri Mar 18 14:10:07 2005 From: rmoseley at redhat.com (Rick Moseley) Date: Fri, 18 Mar 2005 08:10:07 -0600 Subject: [fedora-java] Re: generating a cdt 3.0 tarball In-Reply-To: <1111122963.5779.33.camel@localhost.localdomain> References: <1111121983.30148.6.camel@town.toronto.redhat.com> <1111122963.5779.33.camel@localhost.localdomain> Message-ID: <423AE13F.9020707@redhat.com> Phil Muldoon wrote: >Ben > >Thanks for the changes to the existing procedure. CDT 3.0M5 does not >seem be out just yet. But we'll roll a new rpm as soon as it is. > > They released these tarballs: http://download.eclipse.org/tools/cdt/builds/3.0.0/I.I200503160300 which they claim on the mailing list to be 3.0M5 tarballs. See this thread on cdt-dev: cdt-dev] CDT3.0 M5 candidate (build I200503150300) sanity test : Red Flag >Regards > >Phil > >On Thu, 2005-03-17 at 23:59 -0500, Ben Konrath wrote: > > >>Hey Phil/Rick, >> >>Here are some updated instructions for generating the CDT 3.0M5 tarball. >>I couldn't actually find the 3.0 tag so I just put "**3.0TAG**" in the >>sed line so you'll have to track it down (if it exists). If the repo >>hasn't been tagged, then we're stuck with HEAD I suppose. >> >>% mkdir temp && cd temp >>% /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse >>% mkdir home >>% cvs -d :pserver:anonymous dev eclipse org:/home/tools co \ >> org.eclipse.cdt-releng/org.eclipse.cdt.releng >>% cd org.eclipse.cdt-releng/org.eclipse.cdt.releng >>% sed --in-place 's/HEAD/**3.0TAG**/' maps/cdt.map >>% java -cp ../../SDK/startup.jar \ >> -Duser.home=../../home \ >> org.eclipse.core.launcher.Main \ >> -application org.eclipse.ant.core.antRunner \ >> -buildfile build.xml \ >> -DbaseLocation=/user/share/eclipse \ >> -DdontUnzip=true fetch >>% cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz org.eclipse.cdt.releng >> >>I just tried this from HEAD and it seems to be be working with gij now! >>If you have any problems, feel free to ping me. >> >>Cheers, Ben >> >> Thanks for the write-up Ben, good work there. Rick >> >> > > > From rmoseley at redhat.com Fri Mar 18 15:47:24 2005 From: rmoseley at redhat.com (Rick Moseley) Date: Fri, 18 Mar 2005 09:47:24 -0600 Subject: [fedora-java] Re: generating a cdt 3.0 tarball In-Reply-To: <423AE13F.9020707@redhat.com> References: <1111121983.30148.6.camel@town.toronto.redhat.com> <1111122963.5779.33.camel@localhost.localdomain> <423AE13F.9020707@redhat.com> Message-ID: <423AF80C.8040605@redhat.com> Rick Moseley wrote: > Phil Muldoon wrote: > >> Ben >> >> Thanks for the changes to the existing procedure. CDT 3.0M5 does not >> seem be out just yet. But we'll roll a new rpm as soon as it is. >> >> > They released these tarballs: > > http://download.eclipse.org/tools/cdt/builds/3.0.0/I.I200503160300 > > which they claim on the mailing list to be 3.0M5 tarballs. See this > thread on > cdt-dev: > > cdt-dev] CDT3.0 M5 candidate (build I200503150300) sanity test : Red > Flag > >> Regards >> >> Phil >> >> On Thu, 2005-03-17 at 23:59 -0500, Ben Konrath wrote: >> >> >>> Hey Phil/Rick, >>> Here are some updated instructions for generating the CDT 3.0M5 >>> tarball. >>> I couldn't actually find the 3.0 tag so I just put "**3.0TAG**" in the >> I see from an e-mail from Doug Schaefer today on cdt-dev that he will be labeling the repository M5 sometime today. >>> >>> sed line so you'll have to track it down (if it exists). If the repo >>> hasn't been tagged, then we're stuck with HEAD I suppose. >>> >>> % mkdir temp && cd temp % >>> /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse >>> % mkdir home >>> % cvs -d :pserver:anonymous dev eclipse org:/home/tools co \ >>> org.eclipse.cdt-releng/org.eclipse.cdt.releng >>> % cd org.eclipse.cdt-releng/org.eclipse.cdt.releng >>> % sed --in-place 's/HEAD/**3.0TAG**/' maps/cdt.map >>> % java -cp ../../SDK/startup.jar \ >>> -Duser.home=../../home \ org.eclipse.core.launcher.Main \ >>> -application org.eclipse.ant.core.antRunner \ >>> -buildfile build.xml \ >>> -DbaseLocation=/user/share/eclipse \ >>> -DdontUnzip=true fetch >>> % cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz >>> org.eclipse.cdt.releng >>> >>> I just tried this from HEAD and it seems to be be working with gij now! >>> If you have any problems, feel free to ping me. >>> Cheers, Ben >>> >> > Thanks for the write-up Ben, good work there. > > Rick > >>> >> >> >> >> > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From mark at klomp.org Sun Mar 20 21:12:07 2005 From: mark at klomp.org (Mark Wielaard) Date: Sun, 20 Mar 2005 22:12:07 +0100 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <423ACC27.1080901@redhat.com> References: <20050317210834.GC31481@redhat.com> <423ACC27.1080901@redhat.com> Message-ID: <1111353127.22259.346.camel@localhost.localdomain> Hi, On Fri, 2005-03-18 at 07:40 -0500, Karen Bennet wrote: > We might need to call it something other then java though, > so welcome suggestions. FYI attached is an email exchange from the debian-java mailinglist on this same subject. Michael Koch is a gcj and GNU Classpath hacker and Dalibor Topic is a Kaffe hacker. Obviously as GNU Classpath maintainer I am also biased and would call it after the classpath project. Please feel free to call it the "Fedora Classpath Community Project" if you like. But maybe "fedora-gcj" is more appropriate since you are currently building everything to native with gcj anyway. If you need some infrastructure to collaborate on any fedora packaging initiatives around gcj/classpath, like a wiki setup, quicker then the restructuring of the fedora project guidelines takes then we are happy to offer you space on our http://developer.classpath.org/ machine (in the understanding that it will migrate back to the official fedora mothership when it is ready of course). 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 -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 5679 URL: -------------- 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 Nicolas.Mailhot at laPoste.net Sun Mar 20 21:56:33 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 20 Mar 2005 22:56:33 +0100 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <1111353127.22259.346.camel@localhost.localdomain> References: <20050317210834.GC31481@redhat.com> <423ACC27.1080901@redhat.com> <1111353127.22259.346.camel@localhost.localdomain> Message-ID: <1111355793.26693.6.camel@rousalka.dyndns.org> Le dimanche 20 mars 2005 ? 22:12 +0100, Mark Wielaard a ?crit : > Hi, > > On Fri, 2005-03-18 at 07:40 -0500, Karen Bennet wrote: > > We might need to call it something other then java though, > > so welcome suggestions. > > FYI attached is an email exchange from the debian-java mailinglist on > this same subject. Michael Koch is a gcj and GNU Classpath hacker and > Dalibor Topic is a Kaffe hacker. Obviously as GNU Classpath maintainer I > am also biased and would call it after the classpath project. Please > feel free to call it the "Fedora Classpath Community Project" if you > like. But maybe "fedora-gcj" is more appropriate since you are currently > building everything to native with gcj anyway. And if someone wants a sexy name instead please do not make a stupid pun like eclipse. Some people are too smart for their own good by far. -- Nicolas Mailhot -------------- 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 Mon Mar 21 17:43:03 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Mar 2005 12:43:03 -0500 Subject: [fedora-java] ant + ecj Message-ID: <20050321174303.GG25886@redhat.com> Hi, Robin Green was asking on IRC about this: http://sources.redhat.com/ml/rhug-rhats/2004-05/msg00002.html Is this in our latest ant? If not, can we put it there? Is this affected by us not having a "ecj" executable? Should I make one? Andrew "so many questions" Overholt From gbenson at redhat.com Mon Mar 21 18:02:57 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 21 Mar 2005 18:02:57 +0000 Subject: [fedora-java] ant + ecj In-Reply-To: <20050321174303.GG25886@redhat.com> References: <20050321174303.GG25886@redhat.com> Message-ID: <20050321180256.GG14935@redhat.com> Andrew Overholt wrote: > Robin Green was asking on IRC about this: > > http://sources.redhat.com/ml/rhug-rhats/2004-05/msg00002.html > > Is this in our latest ant? If not, can we put it there? Is this > affected by us not having a "ecj" executable? Should I make one? I think this happens by dint of java-gcj-compat. Gary From ziga.mahkovec at klika.si Mon Mar 21 18:10:25 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Mon, 21 Mar 2005 19:10:25 +0100 Subject: [fedora-java] ant + ecj In-Reply-To: <20050321174303.GG25886@redhat.com> References: <20050321174303.GG25886@redhat.com> Message-ID: <1111428625.5960.11.camel@localhost> On Mon, 2005-03-21 at 12:43 -0500, Andrew Overholt wrote: > Robin Green was asking on IRC about this: > > http://sources.redhat.com/ml/rhug-rhats/2004-05/msg00002.html > > Is this in our latest ant? If not, can we put it there? Is this affected > by us not having a "ecj" executable? Should I make one? This doesn't look like it requires an ecj executable, but having one would still be useful. GNU Classpath for example expects to find /usr/bin/ecj when configured --with-ecj. Right now I just create a link: /usr/bin/ecj -> /usr/lib/jvm/java-gcj/bin/javac -- Ziga From pmuldoon at redhat.com Mon Mar 21 19:07:40 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 21 Mar 2005 13:07:40 -0600 Subject: [fedora-java] gcj-db directory and merge/update scripts Message-ID: <1111432060.5777.13.camel@localhost.localdomain> Lets pin down where we want to put the application .db's that will be merged into the main gcj db. We are about the make changes to the Eclipse spec files to take advantage of the new central .db idea. How about something like: /var/cache/gcj-db-{gcj-version-no} or something to that effect? Will them main db go in there, and how should we structure the directory structure in here to avoid name collisions? I'm presuming we would want all application db's in there too. Also we need a script that does the merge in a generic way, that all spec files can call in %post (to merge their db in with the main db). How should we write this, and also, where should it be put. Should GCC own this too? Just a few things to get the discussion moving, and make some decisions on these few things. Regards Phil From greenrd at presidium.org Mon Mar 21 20:18:23 2005 From: greenrd at presidium.org (Robin Green) Date: Mon, 21 Mar 2005 20:18:23 +0000 Subject: [fedora-java] Re: ant + ecj References: <20050321174303.GG25886@redhat.com> Message-ID: On Mon, 21 Mar 2005 12:43:03 -0500, Andrew Overholt wrote: > Robin Green was asking on IRC about this: > > http://sources.redhat.com/ml/rhug-rhats/2004-05/msg00002.html > > Is this in our latest ant? I've now discovered that this isn't necessary. Eclipse have already provided jdtCompilerAdapter.jar which does precisely the same thing. To use it, simply put jdtCompilerAdapter.jar and jdtcore.jar (both located in /usr/share/eclipse/plugins/org.eclipse.jdt.core_*) on the classpath and tell ant to use it, e.g. by ant -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter From green at redhat.com Tue Mar 22 00:07:06 2005 From: green at redhat.com (Anthony Green) Date: Mon, 21 Mar 2005 16:07:06 -0800 Subject: [fedora-java] gcj-db directory and merge/update scripts In-Reply-To: <1111432060.5777.13.camel@localhost.localdomain> References: <1111432060.5777.13.camel@localhost.localdomain> Message-ID: <1111450027.5177.23.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Mon, 2005-03-21 at 13:07 -0600, Phil Muldoon wrote: > Lets pin down where we want to put the application .db's that will be > merged into the main gcj db. We are about the make changes to the > Eclipse spec files to take advantage of the new central .db idea. > > How about something like: > > /var/cache/gcj-db-{gcj-version-no} or something to that effect? I think Jakub pointed out that this was a bad idea since it doesn't work for multi-ABI systems. I believe that he proposed placing this in /usr/$LIB, where $LIB is ABI dependent, or adding an ABI key to the database. The first option is certainly less work. AG From pmuldoon at redhat.com Tue Mar 22 06:18:12 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 22 Mar 2005 00:18:12 -0600 Subject: [fedora-java] gcj-db directory and merge/update scripts In-Reply-To: <1111450027.5177.23.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1111432060.5777.13.camel@localhost.localdomain> <1111450027.5177.23.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111472292.5782.14.camel@localhost.localdomain> On Mon, 2005-03-21 at 16:07 -0800, Anthony Green wrote: > On Mon, 2005-03-21 at 13:07 -0600, Phil Muldoon wrote: > > Lets pin down where we want to put the application .db's that will be > > merged into the main gcj db. We are about the make changes to the > > Eclipse spec files to take advantage of the new central .db idea. > > > > How about something like: > > > > /var/cache/gcj-db-{gcj-version-no} or something to that effect? > > I think Jakub pointed out that this was a bad idea since it doesn't work > for multi-ABI systems. I believe that he proposed placing this > in /usr/$LIB, where $LIB is ABI dependent, or adding an ABI key to the > database. The first option is certainly less work. That will work for me. I'm ambivalent to the actual location, as long as we can agree on somewhere. ;) Something like /usr/$LIB/gcj-db-{version}? I think the reason behind the version (I'm guessing from previous talks) is to avoid issues if the db changes format. As Tom mentioned, all the applications .dbs have to reside in some standard location to deal with %uninstall of any rpm that previously merged in a db to the master db. As Eclipse seems to be the only consumer of the db's in Core at the moment (maybe Jonas in the future?), maybe this sort of thing should be talked about on Extras too, based on a the presumption that eventually we shall see many consumers popping up there? Well, hopefully. Regards Phil From overholt at redhat.com Tue Mar 22 17:13:50 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 22 Mar 2005 12:13:50 -0500 Subject: [fedora-java] db merging script Message-ID: <20050322171350.GC10152@redhat.com> This is a crude example of what we could have, but it's what I've got so far: %post -n %{libname}-gtk2 if ![ -e `gcj-dbtool -p` ]; then dirname `gcj-dbtool -p` | xargs mkdir -p; gcj-dbtool -n `gcj-dbtool -p`; fi if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` fi %postun %{libname}-gtk2 if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` fi I'm not even sure if what I have will work. I'd just like to start the discussion about how best to do it. Anthony Green has raised valid concerns about multilib systems. Andrew From tromey at redhat.com Tue Mar 22 18:48:19 2005 From: tromey at redhat.com (Tom Tromey) Date: 22 Mar 2005 11:48:19 -0700 Subject: [fedora-java] db merging script In-Reply-To: <20050322171350.GC10152@redhat.com> References: <20050322171350.GC10152@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: Andrew> This is a crude example of what we could have, but it's what Andrew> I've got so far: Looks ok overall. I would probably put the result of `gcj-dbtool -p` into a shell variable. Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` Andrew> fi Is %{name} the name of the current RPM? If so then I think this is incorrect. We need to merge everything into the master .db. Andrew> I'm not even sure if what I have will work. I'd just like to start the Andrew> discussion about how best to do it. Can we get this in somewhere as an RPM macro? And, if so, where? jpackage-utils? java-gcj-compat? Andrew> Anthony Green has raised valid concerns Andrew> about multilib systems. I looked at the current gcc4.spec a little. It seems to me that we will have to just put the host architecture name into the path to the .db file. Assuming that would work, I don't really know about RPM multilibs. I CC'd Jakub for advice. Jakub, what should we do to make the built-in .db file work with multilibs? I will implement whatever it is we need. Tom From overholt at redhat.com Tue Mar 22 18:58:26 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 22 Mar 2005 13:58:26 -0500 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> Message-ID: <20050322185826.GF10152@redhat.com> * Tom Tromey [2005-03-22 13:55]: > > Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then > Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` > Andrew> fi > > Is %{name} the name of the current RPM? > If so then I think this is incorrect. We need to merge everything > into the master .db. We're merging into the master .db but until we sort out where to put the other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings. Andrew From green at redhat.com Tue Mar 22 19:01:48 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 11:01:48 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050322185826.GF10152@redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322185826.GF10152@redhat.com> Message-ID: <1111518108.5163.3.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 13:58 -0500, Andrew Overholt wrote: > We're merging into the master .db but until we sort out where to put the > other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings. How about in a directory called `gcj-dbtool -p`.d ? AG From pmuldoon at redhat.com Tue Mar 22 19:06:29 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 22 Mar 2005 13:06:29 -0600 Subject: [fedora-java] db merging script In-Reply-To: <20050322185826.GF10152@redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322185826.GF10152@redhat.com> Message-ID: <1111518390.5670.19.camel@dhcp-12.hsv.redhat.com> On Tue, 2005-03-22 at 13:58 -0500, Andrew Overholt wrote: > * Tom Tromey [2005-03-22 13:55]: > > > > Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then > > Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` > > Andrew> fi > > > > Is %{name} the name of the current RPM? > > If so then I think this is incorrect. We need to merge everything > > into the master .db. > > We're merging into the master .db but until we sort out where to put the > other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings. Other than Anthony Green's response, there's not much opinion on that yet it seems. Maybe asking the question was premature; it's something I'd like to figure out sooner rather than later, though. The only other thing was the `find %{_libdir}/%{name}/mappings -name \*.db` potentially producing a list of db's that is to big to fit in the argument buffer, and that may make an incorrect merge. What are the advantages of an rpmacro over just placing a merge shell script in /usr/bin? Regards Phil From jakub at redhat.com Tue Mar 22 19:20:49 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 22 Mar 2005 14:20:49 -0500 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> Message-ID: <20050322192048.GU32746@devserv.devel.redhat.com> On Tue, Mar 22, 2005 at 11:48:19AM -0700, Tom Tromey wrote: > Andrew> Anthony Green has raised valid concerns > Andrew> about multilib systems. > > I looked at the current gcc4.spec a little. It seems to me that we > will have to just put the host architecture name into the path to the > .db file. Assuming that would work, I don't really know about RPM > multilibs. > > I CC'd Jakub for advice. Jakub, what should we do to make the > built-in .db file work with multilibs? I will implement whatever it > is we need. Well, first you want to decide whether you want one master .db file or one .db file per architecture. One master .db file might be a tiny bit slower (since the .db file will be bigger), but might be easier for users (e.g. gcj-dbtool -p would be usable). You just need to pick up some magic values for the architectures (say for ELF architectures you can e.g. use the EM_* constants ored with ELFCLASS{32,64} shifted up or something), add code that at configure or compile time stores the current arch magic number into libgcj.so (or wherever the code that will parse the .db file lives) and code into gcj-dbtool to compute the magic value for a given shared library. With per-arch .db you could e.g. store the file into /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be gcc $CFLAGS -print-multi-os-directory (well, even better the path would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with gcj-dbtool -p . The first approach is what e.g. ldconfig/ld.so use. Jakub From green at redhat.com Tue Mar 22 19:39:14 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 11:39:14 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050322192048.GU32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> Message-ID: <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote: > With per-arch .db you could e.g. store the file into > /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be > gcc $CFLAGS -print-multi-os-directory (well, even better the path > would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` > string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with > gcj-dbtool -p . I'm not sure I understand this second part. What's wrong with... /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db ? "gcj-dbtool -p " sounds hard to implement. AG From jakub at redhat.com Tue Mar 22 19:50:43 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 22 Mar 2005 14:50:43 -0500 Subject: [fedora-java] db merging script In-Reply-To: <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050322195043.GV32746@devserv.devel.redhat.com> On Tue, Mar 22, 2005 at 11:39:14AM -0800, Anthony Green wrote: > On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote: > > With per-arch .db you could e.g. store the file into > > /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be > > gcc $CFLAGS -print-multi-os-directory (well, even better the path > > would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` > > string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with > > gcj-dbtool -p . > > I'm not sure I understand this second part. > > What's wrong with... > > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db > > ? > > "gcj-dbtool -p " sounds hard to implement. You mean that gcj-dbtool -p would print /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db and you'd need to pass that through shell after making sure $CC and $CFLAGS are properly defined? Then you'd put the burden on rpm packagers, because in rpm %post $RPM_OPT_FLAGS certainly aren't set (and, you shouldn't require gcc to be installed just to install Java packages). Reminds me, gcj-dbtool should be probably moved from gcc-java subpackage to libgcj now that it is used not only during compile time. Jakub From aph at redhat.com Tue Mar 22 19:58:53 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Mar 2005 19:58:53 +0000 Subject: [fedora-java] db merging script In-Reply-To: <20050322195043.GV32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> Message-ID: <16960.30973.362032.296471@cuddles.cambridge.redhat.com> Jakub Jelinek writes: > On Tue, Mar 22, 2005 at 11:39:14AM -0800, Anthony Green wrote: > > On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote: > > > With per-arch .db you could e.g. store the file into > > > /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be > > > gcc $CFLAGS -print-multi-os-directory (well, even better the path > > > would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` > > > string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with > > > gcj-dbtool -p . > > > > I'm not sure I understand this second part. > > > > What's wrong with... > > > > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db > > > > ? > > > > "gcj-dbtool -p " sounds hard to implement. > > You mean that gcj-dbtool -p would print > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db > and you'd need to pass that through shell after making sure $CC and $CFLAGS > are properly defined? gcj-dbtool is a target program, part of libgcj. So, on a multi-arch system, would there not be two gcj-dbtools, linked against different libgcjs? And, each one would print its *own* directory. Andrew. From jakub at redhat.com Tue Mar 22 20:06:00 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 22 Mar 2005 15:06:00 -0500 Subject: [fedora-java] db merging script In-Reply-To: <16960.30973.362032.296471@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> Message-ID: <20050322200600.GW32746@devserv.devel.redhat.com> On Tue, Mar 22, 2005 at 07:58:53PM +0000, Andrew Haley wrote: > > You mean that gcj-dbtool -p would print > > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db > > and you'd need to pass that through shell after making sure $CC and $CFLAGS > > are properly defined? > > gcj-dbtool is a target program, part of libgcj. So, on a multi-arch > system, would there not be two gcj-dbtools, linked against different > libgcjs? And, each one would print its *own* directory. On multi-arch systems, there is usually just one set of binaries and one or two sets of libraries. If you want 2 gcj-dbtool programs, that's of course possible, but you need to decide where to install them (e.g. /usr/libexec/gcj/$LIB/gcj-dbtool ), but then all the programs that want to use gcj-dbtool need to figure out which one they want to call. For %post this location wouldn't be that hard, rpm %post would just call /usr/libexec/gcj/%{_lib}/gcj-dbtool -p ... But, will you require all Makefiles that deal with gcj-dbtool to call /usr/libexec/gcj/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-dbtool ? Certainly, one master .db file, although it will need some work inside gcj-dbtool and libgcj.so, will make things far easier for the users and developers. Jakub From aph at redhat.com Tue Mar 22 20:11:10 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Mar 2005 20:11:10 +0000 Subject: [fedora-java] db merging script In-Reply-To: <20050322200600.GW32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> Message-ID: <16960.31710.508597.276038@cuddles.cambridge.redhat.com> Jakub Jelinek writes: > > Certainly, one master .db file, although it will need some work inside > gcj-dbtool and libgcj.so, will make things far easier for the users and > developers. That's impossible. The .db is a mapping from bytecode to shared objects, and there is no guarantee that if a class exists in lib/foo.so it will also exist in lib64/foo.so. However, that class might well exist in lib64/bar.so. Andrew. From green at redhat.com Tue Mar 22 20:10:57 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 12:10:57 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050322195043.GV32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> Message-ID: <1111522257.5163.32.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 14:50 -0500, Jakub Jelinek wrote: > You mean that gcj-dbtool -p would print > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db > and you'd need to pass that through shell after making sure $CC and $CFLAGS > are properly defined? > Then you'd put the burden on rpm packagers, because in rpm %post > $RPM_OPT_FLAGS certainly aren't set (and, you shouldn't require > gcc to be installed just to install Java packages). This shouldn't require gcc at install time. We can create the application specific classmaps at build time, and simply merge them at install time. AG From jakub at redhat.com Tue Mar 22 20:22:22 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 22 Mar 2005 15:22:22 -0500 Subject: [fedora-java] db merging script In-Reply-To: <16960.31710.508597.276038@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> <16960.31710.508597.276038@cuddles.cambridge.redhat.com> Message-ID: <20050322202221.GX32746@devserv.devel.redhat.com> On Tue, Mar 22, 2005 at 08:11:10PM +0000, Andrew Haley wrote: > Jakub Jelinek writes: > > > > Certainly, one master .db file, although it will need some work inside > > gcj-dbtool and libgcj.so, will make things far easier for the users and > > developers. > > That's impossible. > > The .db is a mapping from bytecode to shared objects, and there is no > guarantee that if a class exists in lib/foo.so it will also exist in > lib64/foo.so. However, that class might well exist in lib64/bar.so. Why impossible? If can be a mapping from pair to shared objects... Jakub From aph at redhat.com Tue Mar 22 20:44:26 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Mar 2005 20:44:26 +0000 Subject: [fedora-java] db merging script In-Reply-To: <20050322202221.GX32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> <16960.31710.508597.276038@cuddles.cambridge.redhat.com> <20050322202221.GX32746@devserv.devel.redhat.com> Message-ID: <16960.33706.680838.813211@cuddles.cambridge.redhat.com> Jakub Jelinek writes: > On Tue, Mar 22, 2005 at 08:11:10PM +0000, Andrew Haley wrote: > > Jakub Jelinek writes: > > > > > > Certainly, one master .db file, although it will need some work inside > > > gcj-dbtool and libgcj.so, will make things far easier for the users and > > > developers. > > > > That's impossible. > > > > The .db is a mapping from bytecode to shared objects, and there is no > > guarantee that if a class exists in lib/foo.so it will also exist in > > lib64/foo.so. However, that class might well exist in lib64/bar.so. > > Why impossible? If can be a mapping from pair to > shared objects... Oh, what a horrible idea. Yes, that would work, I suppose. It doesn't scale well, though. I would have thought it easier just to give the db an appropriate name for the arch. We don't use fat libraries, so why create fat databases? The reasoning is exactly the same. Andrew. From green at redhat.com Tue Mar 22 22:26:45 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 14:26:45 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050322171350.GC10152@redhat.com> References: <20050322171350.GC10152@redhat.com> Message-ID: <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Here's a real-world example from the servletapi5 spec file. It currently assumes that we should be using `gcj-dbtool -p`. Comments/suggestions welcome. *** servletapi5.spec 2004-11-04 06:41:06.000000000 -0800 --- servletapi5.spec.new 2005-03-22 14:23:54.964489184 -0800 *************** *** 3,9 **** %define name %{base_name}%{major_version} %define full_name jakarta-%{base_name} %define version 5.0.18 ! %define release 1jpp_3fc %define section free Name: %{name} --- 3,9 ---- %define name %{base_name}%{major_version} %define full_name jakarta-%{base_name} %define version 5.0.18 ! %define release 1jpp_4fc %define section free Name: %{name} *************** *** 23,29 **** BuildRequires: xerces-j2, xml-commons-apis BuildRequires: jpackage-utils >= 1.5.30 BuildRequires: java-javadoc - BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot #Obsoletes: servlet4 #Obsoletes: servlet23 --- 23,28 ---- *************** *** 66,79 **** --- 65,91 ---- ant dist -Dservletapi.build=build -Dservletapi.dist=dist popd + # Generate native code. + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar + gcj-dbtool -n jspapi-%{version}.db + gcj-dbtool -f jspapi-%{version}.db jsr152/dist/lib/jsp-api.jar %{_libdir}/libjspapi-%{version}.jar.so + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o lib%{name}-%{version}.jar.so jsr154/dist/lib/servlet-api.jar + gcj-dbtool -n %{name}-%{version}.db + gcj-dbtool -f %{name}-%{version}.db jsr154/dist/lib/servlet-api.jar %{_libdir}/lib%{name}-%{version}.jar.so %install cd jakarta-tomcat-%{version}-src/jakarta-servletapi-5 # jars install -d -m 755 $RPM_BUILD_ROOT%{_javadir} + install -d -m 755 $RPM_BUILD_ROOT%{_libdir} + install -d -m 755 $RPM_BUILD_ROOT`gcj-dbtool -p`.d install -m 644 jsr152/dist/lib/jsp-api.jar $RPM_BUILD_ROOT%{_javadir}/jspapi-%{version}.jar install -m 644 jsr154/dist/lib/servlet-api.jar $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar + install -m 644 libjspapi-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/libjspapi-%{version}.jar.so + install -m 644 lib%{name}-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/lib%{name}-%{version}.jar.so + install -m 644 jspapi-%{version}.db $RPM_BUILD_ROOT`gcj-dbtool -p`.d/jspapi-%{version}.db + install -m 644 %{name}-%{version}.db $RPM_BUILD_ROOT`gcj-dbtool -p`.d/%{name}-%{version}.db (cd $RPM_BUILD_ROOT%{_javadir} && for jar in *-%{version}*; do ln -sf ${jar} `echo $jar| sed "s|-%{version}||g"`; done) *************** *** 94,105 **** --- 106,125 ---- %post update-alternatives --install %{_javadir}/servlet.jar servlet %{_javadir}/%{name}-%{version}.jar 50 #update-alternatives --install %{_javadir}/jsp.jar jsp %{_javadir}/jsp-api-%{version}.jar 50 + DB=`gcj-dbtool -p` + rm -f $DB + gcj-dbtool -n $DB + (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) %postun if [ "$1" = "0" ]; then update-alternatives --remove servlet %{_javadir}/%{name}-%{version}.jar # update-alternatives --remove jsp %{_javadir}/jsp-api-%{version}.jar fi + DB=`gcj-dbtool -p` + rm -f $DB + gcj-dbtool -n $DB + (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) %post javadoc rm -f %{_javadocdir}/%{name} *************** *** 110,115 **** --- 130,136 ---- %files %defattr(-,root,root) %doc LICENSE + %{_libdir}/* %{_javadir}/* %files javadoc *************** *** 121,126 **** --- 142,150 ---- %changelog + * Tue Mar 22 2005 Anthony Green 0:5.0.18-1jpp_4fc + - Generate native libraries. + * Thu Nov 4 2004 Gary Benson 0:5.0.18-1jpp_3fc - Build into Fedora. From pmuldoon at redhat.com Tue Mar 22 22:41:19 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 22 Mar 2005 16:41:19 -0600 Subject: [fedora-java] db merging script In-Reply-To: <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> > %post > update-alternatives --install %{_javadir}/servlet.jar servlet %{_javadir}/%{name}-%{version}.jar 50 > #update-alternatives --install %{_javadir}/jsp.jar jsp %{_javadir}/jsp-api-%{version}.jar 50 > + DB=`gcj-dbtool -p` > + rm -f $DB > + gcj-dbtool -n $DB > + (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) I think it was Tom who suggested we should have some structure below the location of the db location to allow for name collisions. Will the: (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) account for $DB.d/foo/foo.jar.so and $DB.d/bar/bar.jar.so and so on? Regards Phil From green at redhat.com Tue Mar 22 22:46:20 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 14:46:20 -0800 Subject: [fedora-java] db merging script In-Reply-To: <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> Message-ID: <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 16:41 -0600, Phil Muldoon wrote: > I think it was Tom who suggested we should have some structure below the > location of the db location to allow for name collisions. Will the: > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) > > account for > > $DB.d/foo/foo.jar.so > > and > > $DB.d/bar/bar.jar.so > > and so on? No, but I think we should be using versioned names so, in theory, there should be no collisions. # ls -l /usr/lib/gcj-4.0.0/classmap.db.d/ total 2832 -rw-r--r-- 1 root root 1441792 Mar 22 14:19 jspapi-5.0.18.db -rw-r--r-- 1 root root 1441792 Mar 22 14:19 servletapi5-5.0.18.db BTW, I also think we should prefix the libs with "lib" and make them versioned. # ls -l /usr/lib/libjspapi-5.0.18.jar.so -rw-r--r-- 1 root root 300642 Mar 22 14:19 /usr/lib/libjspapi-5.0.18.jar.so This will make them usable for explicit linking, and make up a little bit for the fact that we don't have real so name versioning. AG From pmuldoon at redhat.com Tue Mar 22 23:13:16 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 22 Mar 2005 17:13:16 -0600 Subject: [fedora-java] db merging script In-Reply-To: <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111533196.5670.74.camel@dhcp-12.hsv.redhat.com> On Tue, 2005-03-22 at 14:46 -0800, Anthony Green wrote: > On Tue, 2005-03-22 at 16:41 -0600, Phil Muldoon wrote: > > I think it was Tom who suggested we should have some structure below the > > location of the db location to allow for name collisions. Will the: > > > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) > > > > account for > > > > $DB.d/foo/foo.jar.so > > > > and > > > > $DB.d/bar/bar.jar.so > > > > and so on? > > No, but I think we should be using versioned names so, in theory, there > should be no collisions. Okay, my example was wrong (s/jar.so/db), but I take your point. Right now appending version is something we don't do (because we can safely assume with our db and our location we won't have collision). Something to keep in mind. As long as it is tied with the version of the rpm then it should be cool. Maybe there are other issues here, but I can't think of any. I can't be sure but I think the merge automatically deletes the destination "merge to" database, so there theoretically could be an issue with the size of the argument list provided from the ls . to xargs there. Not sure if this is something we should worry about in reality or not Regards Phil From green at redhat.com Tue Mar 22 23:42:22 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 15:42:22 -0800 Subject: [fedora-java] db merging script In-Reply-To: <1111533196.5670.74.camel@dhcp-12.hsv.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111533196.5670.74.camel@dhcp-12.hsv.redhat.com> Message-ID: <1111534943.5163.79.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 17:13 -0600, Phil Muldoon wrote: > I can't be sure but I think the merge automatically deletes the > destination "merge to" database, so there theoretically could be an > issue with the size of the argument list provided from the ls . to xargs > there. Not sure if this is something we should worry about in reality or > not Oh, yes, you're right. gcj-dbtool seems to create a temporary db and then copies it on top of the real one once complete. Given that, I think this would work: DB=`gcj-dbtool -p` rm -f $DB gcj-dbtool -n $DB (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) [note the extra $DB on that last line] AG From green at redhat.com Wed Mar 23 03:27:11 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 19:27:11 -0800 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> Message-ID: <1111548431.5248.30.camel@localhost.localdomain> On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote: > I CC'd Jakub for advice. Jakub, what should we do to make the > built-in .db file work with multilibs? I will implement whatever it > is we need. After looking at this for a bit, I recommend the following: "gcj-dbtool -p" operates as usual (for no special reason) "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db This is convenient because it is easy to implement and easy to use. The %post and %postun spec file sections can simply do: DB=`gcj-dbtool -p %{_libdir}` and use DB for the database name. Presumably rpm will make sure that _libdir refers to the correct lib directory for the target ABI. AG From bryan at about.com Wed Mar 23 13:08:03 2005 From: bryan at about.com (Susan M. Taylor) Date: Wed, 23 Mar 2005 13:08:03 +0000 Subject: [fedora-java] Rolex for $249.99 Message-ID: <006b01c52fa9$251d1485$dbe6a75b@about.com> REPLICA WATCH MODELS Rolex, Patek Philippe, Bvlgari Cartier, Gucci, Franck Muller .. and 25 other most famous manufacturers. http://www.coolwatches.biz All for only $249.99! _________________________________________________________________________ To change your mail preferences, go here: http://www.signoffcorp.biz/uns.htm _________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From overholt at redhat.com Wed Mar 23 15:59:07 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 23 Mar 2005 10:59:07 -0500 Subject: [fedora-java] Eclipse plugins and .dbs Message-ID: <20050323155907.GA10099@redhat.com> I've attached a patch for the changelog plugin. This will fix up the native-compilation situation until everything's sorted out. Andrew -------------- next part -------------- Index: eclipse-changelog.spec =================================================================== RCS file: /cvs/dist/rpms/eclipse-changelog/devel/eclipse-changelog.spec,v retrieving revision 1.22 diff -u -p -r1.22 eclipse-changelog.spec --- eclipse-changelog.spec 10 Mar 2005 21:55:06 -0000 1.22 +++ eclipse-changelog.spec 23 Mar 2005 15:58:25 -0000 @@ -20,11 +20,12 @@ ExclusiveArch: i386 ppc x86_64 Summary: %{pkg_summary} Name: %{eclipse_name}-changelog Version: %{changelog_majmin}.%{changelog_micro}_fc -Release: 17 +Release: 18 License: EPL (Eclipse Public License) Group: Text Editors/Integrated Development Environments (IDE) URL: http://www.redhat.com -Requires: eclipse-ui +Requires: eclipse-platform +Requires: gcc-java # Note that following the Eclipse Releng process we do not distribute a # real .tar.gz file. Instead, you must build it by hand. The way to do @@ -107,9 +108,6 @@ for file in $(pwd)/com.redhat.eclipse.ch # Once compiled, we don't care about the jar (it's still in the original tar) rm $jarname - - # Create a text mapping of the jar <-->so mapping for later use. - echo %{eclipse_base}/plugins/$jarname::%{eclipse_lib_base}/plugins/$jarname.so >> %{name}.jarswithnativelibs done ;; esac @@ -141,10 +139,13 @@ gcj-dbtool -n $RPM_BUILD_ROOT/%{eclipse_ # Create plugins directory in eclipse lib base install -d -m755 $RPM_BUILD_ROOT/%{eclipse_lib_base}/plugins/ -cd $nativehome/eclipse/plugins +# Populate db with mappings +for j in `find $RPM_BUILD_ROOT/%{eclipse_base} -name \*.jar`; do + gcj-dbtool -f $RPM_BUILD_ROOT%{eclipse_lib_base}/mappings/changelog.db \ + $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; +done; -# Install the text jar <--> so mapping we created when we compiled -install -m644 %{name}.jarswithnativelibs $RPM_BUILD_ROOT/%{eclipse_lib_base} +cd $nativehome/eclipse/plugins # Copy the .so(s) we created earlier into the build root for file in `find . -type f -name *.so`; do @@ -153,23 +154,24 @@ for file in `find . -type f -name *.so`; done %post - -# Populate db with mappings -for j in `cat %{eclipse_lib_base}/%{name}.jarswithnativelibs`; do - gcj-dbtool -a %{eclipse_lib_base}/mappings/changelog.db `echo $j | sed "s/::/ /"` -done - # Merge all dbs together after install +dbLocation=`gcj-dbtool -p` +if ! [ -e $dbLocation ]; then + dirname $dbLocation | xargs mkdir -p + gcj-dbtool -n $dbLocation +fi + if [ -n "`find %{eclipse_lib_base}/mappings -name \*.db`" ]; then - gcj-dbtool -m %{eclipse_lib_base}/eclipse.db `find %{eclipse_lib_base}/mappings -name \*.db` + gcj-dbtool -m $dbLocation `find %{eclipse_lib_base}/mappings -name \*.db` $dbLocation fi %postun # After uninstall has removed our db, again merge the dbs # to remove our entries +dbLocation=`gcj-dbtool -p` if [ -n "`find %{eclipse_lib_base}/mappings -name \*.db`" ]; then - gcj-dbtool -m %{eclipse_lib_base}/eclipse.db `find %{eclipse_lib_base}/mappings -name \*.db` + gcj-dbtool -m $dbLocation `find %{eclipse_lib_base}/mappings -name \*.db` $dbLocation fi %clean @@ -181,9 +183,13 @@ rm -rf ${RPM_BUILD_ROOT} %{eclipse_base}/plugins/com.redhat.eclipse.changelog* %{eclipse_lib_base}/plugins/com.redhat.eclipse.changelog* %{eclipse_lib_base}/mappings/changelog.db -%{eclipse_lib_base}/%{name}.jarswithnativelibs %changelog +* Wed Mar 23 2005 Andrew Overholt 2.0.1_fc-18 +- Update with new gcj-dbtool stuff. +- Fix Requires. +- Remove *.jarswithnativelibs. + * Thu Mar 10 2005 Phil Muldoon 2.0.1-17 - Redo arches - Clean up BuildRequires From pmuldoon at redhat.com Wed Mar 23 16:04:48 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Wed, 23 Mar 2005 10:04:48 -0600 Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: <20050323155907.GA10099@redhat.com> References: <20050323155907.GA10099@redhat.com> Message-ID: <1111593888.5797.2.camel@localhost.localdomain> Andrew Cool. I'll merge and test build the plugin, and see how it does. Looks fine from an Eclipse point of view. Regards Phil On Wed, 2005-03-23 at 10:59 -0500, Andrew Overholt wrote: > I've attached a patch for the changelog plugin. This will fix up the > native-compilation situation until everything's sorted out. > > Andrew > -- > 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 Wed Mar 23 18:42:38 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Mar 2005 18:42:38 +0000 Subject: [fedora-java] db merging script In-Reply-To: <1111548431.5248.30.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111548431.5248.30.camel@localhost.localdomain> Message-ID: <16961.47262.192111.759933@cuddles.cambridge.redhat.com> Anthony Green writes: > On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote: > > I CC'd Jakub for advice. Jakub, what should we do to make the > > built-in .db file work with multilibs? I will implement whatever it > > is we need. > > After looking at this for a bit, I recommend the following: > > "gcj-dbtool -p" operates as usual (for no special reason) > "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db > > This is convenient because it is easy to implement and easy to use. > > The %post and %postun spec file sections can simply do: > > DB=`gcj-dbtool -p %{_libdir}` > > and use DB for the database name. Presumably rpm will make sure that > _libdir refers to the correct lib directory for the target ABI. That sounds pleasingly simple. Andrew. From overholt at redhat.com Wed Mar 23 18:53:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 23 Mar 2005 13:53:14 -0500 Subject: [fedora-java] db merging script In-Reply-To: <1111548431.5248.30.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111548431.5248.30.camel@localhost.localdomain> Message-ID: <20050323185314.GA10509@redhat.com> * Anthony Green [2005-03-22 22:32]: > On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote: > > I CC'd Jakub for advice. Jakub, what should we do to make the > > built-in .db file work with multilibs? I will implement whatever it > > is we need. > > After looking at this for a bit, I recommend the following: > > "gcj-dbtool -p" operates as usual (for no special reason) > "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db > > This is convenient because it is easy to implement and easy to use. > > The %post and %postun spec file sections can simply do: > > DB=`gcj-dbtool -p %{_libdir}` > > and use DB for the database name. Presumably rpm will make sure that > _libdir refers to the correct lib directory for the target ABI. This sounds good. Can we put a database subdirectory at the same location? LIBDIR/gcj-VERSION/classmap.d Andrew From green at redhat.com Wed Mar 23 19:22:52 2005 From: green at redhat.com (Anthony Green) Date: Wed, 23 Mar 2005 11:22:52 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050323185314.GA10509@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111548431.5248.30.camel@localhost.localdomain> <20050323185314.GA10509@redhat.com> Message-ID: <1111605772.5432.1.camel@localhost.localdomain> On Wed, 2005-03-23 at 13:53 -0500, Andrew Overholt wrote: > > The %post and %postun spec file sections can simply do: > > > > DB=`gcj-dbtool -p %{_libdir}` > > > > and use DB for the database name. Presumably rpm will make sure that > > _libdir refers to the correct lib directory for the target ABI. > > This sounds good. Can we put a database subdirectory at the same location? > > LIBDIR/gcj-VERSION/classmap.d Yes - in my spec file proposal I used $DB.d. AG From tromey at redhat.com Thu Mar 24 00:25:46 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:25:46 -0700 Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: <20050323155907.GA10099@redhat.com> References: <20050323155907.GA10099@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: Andrew> -Requires: eclipse-ui Andrew> +Requires: eclipse-platform Andrew> +Requires: gcc-java You probably just want to BuildRequires this, and then Require whatever tag all the JREs provide. That way people could still install eclipse and a proprietary JRE. (Perhaps jusst requiring eclipse-platform is enough, and that in turn ought to require the JRE... I dunno.) Tom From tromey at redhat.com Thu Mar 24 00:33:13 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:33:13 -0700 Subject: [fedora-java] db merging script In-Reply-To: <20050322200600.GW32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> Message-ID: >>>>> "Jakub" == Jakub Jelinek writes: Jakub> On multi-arch systems, there is usually just one set of binaries and one Jakub> or two sets of libraries. Programs like 'gcj-dbtool' and 'gij' are linked against a specific libgcj.so. If there is only one set of binaries, then it seems like we don't need to bother with multilib at all, since it will only ever be possible to use one particular libgcj.so -- the one 'gij' is linked to. At least, that is true in the common case... e.g., eclipse, which in the end invokes 'gij' at startup. Or am I missing some magic that lets us pick libraries at runtime? I don't know how this could work, but I'm ready to be enlightened :-) Tom From pmuldoon at redhat.com Thu Mar 24 00:40:30 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Wed, 23 Mar 2005 18:40:30 -0600 Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: References: <20050323155907.GA10099@redhat.com> Message-ID: <1111624830.12175.25.camel@localhost.localdomain> This was in response to bz 151866 (I think. I added Requires: gcc-java to the new cdt rpm). It's because in %post/%postun we need gcj-dbtool to merge. Regards Phil On Wed, 2005-03-23 at 17:25 -0700, Tom Tromey wrote: > >>>>> "Andrew" == Andrew Overholt writes: > > Andrew> -Requires: eclipse-ui > Andrew> +Requires: eclipse-platform > Andrew> +Requires: gcc-java > > You probably just want to BuildRequires this, and then Require > whatever tag all the JREs provide. That way people could still > install eclipse and a proprietary JRE. (Perhaps jusst requiring > eclipse-platform is enough, and that in turn ought to require the > JRE... I dunno.) > > Tom > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From tromey at redhat.com Thu Mar 24 00:37:35 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:37:35 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111518390.5670.19.camel@dhcp-12.hsv.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322185826.GF10152@redhat.com> <1111518390.5670.19.camel@dhcp-12.hsv.redhat.com> Message-ID: >>>>> "Phil" == Phil Muldoon writes: Phil> What are the advantages of an rpmacro over just placing a merge shell Phil> script in /usr/bin? Just that it doesn't show up in the user's $PATH. I don't know if that is a plus or a minus, honestly. Wherever it ends up, it needs a sensible name. Tom From tromey at redhat.com Thu Mar 24 00:41:30 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:41:30 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> No, but I think we should be using versioned names so, in Anthony> theory, there should be no collisions. The name would have to include both the package name and the jar name in the package. It doesn't matter to me what particular naming convention we pick, as long as it is reasonably sensible and easy to automate... we can spell that with a '-' or a '/' :-) The reason I opted for subdirectories is just that programs like eclipse already use them. It presents an obvious mapping from the .jar structure to the .so cache, and we know it cannot clash as the original package has no clashes. Anthony> This will make them usable for explicit linking, and make up a little Anthony> bit for the fact that we don't have real so name versioning. Yeah, this is attractive, at least for some of the libraries. Tom From tromey at redhat.com Thu Mar 24 00:44:16 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:44:16 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> Here's a real-world example from the servletapi5 spec file. It Anthony> currently assumes that we should be using `gcj-dbtool -p`. Anthony> Comments/suggestions welcome. Anthony> + # Generate native code. Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar Anthony> + gcj-dbtool -n jspapi-%{version}.db [ ...] If it isn't too unwieldy, I would like to see this whole section replaced by a single call to some shell script to automate the find-compile-db loop. My goal is to make gcj-izing a jpackage RPM utterly trivial... Tom From pmuldoon at redhat.com Thu Mar 24 00:55:39 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Wed, 23 Mar 2005 18:55:39 -0600 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111625739.12175.31.camel@localhost.localdomain> > If it isn't too unwieldy, I would like to see this whole section > replaced by a single call to some shell script to automate the > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > utterly trivial... Andrew Overholt and I mused around with creating a wiki page somewhere along the lines of "How to build your Java project with GCJ and package it to rpm", and highlight some of the pitfalls, and strategies involved here (that our group encountered with Eclipse). I'm not sure if Fedora Core has a semi official wiki somewhere, but it is something I would like to do. Also another wiki on how to debug your natively built Java app. Hopefully that would help any Extra's project find the right path; and make things even easier. Regards Phil From fitzsim at redhat.com Thu Mar 24 00:58:41 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 23 Mar 2005 19:58:41 -0500 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111625921.11419.30.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote: > >>>>> "Anthony" == Anthony Green writes: > > Anthony> Here's a real-world example from the servletapi5 spec file. It > Anthony> currently assumes that we should be using `gcj-dbtool -p`. > Anthony> Comments/suggestions welcome. > > Anthony> + # Generate native code. > Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar > Anthony> + gcj-dbtool -n jspapi-%{version}.db > [ ...] > > If it isn't too unwieldy, I would like to see this whole section > replaced by a single call to some shell script to automate the > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > utterly trivial... > If someone sends me the script I can add it to java-1.4.2-gcj-compat. Tom From tromey at redhat.com Thu Mar 24 01:45:42 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 18:45:42 -0700 Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: <1111624830.12175.25.camel@localhost.localdomain> References: <20050323155907.GA10099@redhat.com> <1111624830.12175.25.camel@localhost.localdomain> Message-ID: >>>>> "Phil" == Phil Muldoon writes: Phil> This was in response to bz 151866 (I think. I added Requires: gcc-java Phil> to the new cdt rpm). It's because in %post/%postun we need gcj-dbtool to Phil> merge. Ah, thanks... I didn't realize that. That does seem like a drawback of the current approach. Short of rewriting gcj-dbtool in plain old C, though, there's not much to be done about it. Tom From jakub at redhat.com Thu Mar 24 06:13:00 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 24 Mar 2005 01:13:00 -0500 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> Message-ID: <20050324061300.GB8801@devserv.devel.redhat.com> On Wed, Mar 23, 2005 at 05:33:13PM -0700, Tom Tromey wrote: > Programs like 'gcj-dbtool' and 'gij' are linked against a specific > libgcj.so. If there is only one set of binaries, then it seems like > we don't need to bother with multilib at all, since it will only ever > be possible to use one particular libgcj.so -- the one 'gij' is linked > to. At least, that is true in the common case... e.g., eclipse, which > in the end invokes 'gij' at startup. > > Or am I missing some magic that lets us pick libraries at runtime? > I don't know how this could work, but I'm ready to be enlightened :-) What prevents other programs to use libgcj.so (or now that there is libgij.so also libgij.so)? And when they do, you don't know if those programs will be 32-bit or 64-bit. Jakub From nicolas.mailhot at laposte.net Thu Mar 24 08:09:58 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Mar 2005 09:09:58 +0100 (CET) Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: References: <20050323155907.GA10099@redhat.com> Message-ID: <48686.192.54.193.35.1111651798.squirrel@rousalka.dyndns.org> On Jeu 24 mars 2005 1:25, Tom Tromey a ?crit : >>>>>> "Andrew" == Andrew Overholt writes: > > Andrew> -Requires: eclipse-ui > Andrew> +Requires: eclipse-platform > Andrew> +Requires: gcc-java > > You probably just want to BuildRequires this, and then Require > whatever tag all the JREs provide. That way people could still > install eclipse and a proprietary JRE. (Perhaps jusst requiring > eclipse-platform is enough, and that in turn ought to require the > JRE... I dunno JPP jres should provide java, and jpp jvms should provide java-devel (and versionned virtuals too should you require a particular java level) -- Nicolas Mailhot From aph at redhat.com Thu Mar 24 11:50:21 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 24 Mar 2005 11:50:21 +0000 Subject: [fedora-java] db merging script In-Reply-To: <20050324061300.GB8801@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> <20050324061300.GB8801@devserv.devel.redhat.com> Message-ID: <16962.43389.990081.17067@cuddles.cambridge.redhat.com> Jakub Jelinek writes: > On Wed, Mar 23, 2005 at 05:33:13PM -0700, Tom Tromey wrote: > > Programs like 'gcj-dbtool' and 'gij' are linked against a specific > > libgcj.so. If there is only one set of binaries, then it seems like > > we don't need to bother with multilib at all, since it will only ever > > be possible to use one particular libgcj.so -- the one 'gij' is linked > > to. At least, that is true in the common case... e.g., eclipse, which > > in the end invokes 'gij' at startup. > > > > Or am I missing some magic that lets us pick libraries at runtime? > > I don't know how this could work, but I'm ready to be enlightened :-) > > What prevents other programs to use libgcj.so (or now that there is > libgij.so also libgij.so)? Nothing. > And when they do, you don't know if those programs will be 32-bit or > 64-bit. I don't understand purpose of this comment. If there's a 32-bit multilib, the user will use -m32 at compile time, and that will link with the 32-bit library. Andrew. From phil at mkdoc.com Thu Mar 24 14:04:56 2005 From: phil at mkdoc.com (Phil Shaw) Date: Thu, 24 Mar 2005 14:04:56 -0000 Subject: [fedora-java] db merging script In-Reply-To: <1111625739.12175.31.camel@localhost.localdomain> References: Message-ID: <4242C908.23329.E1EE45A@localhost> On 23 Mar 2005, at 18:55, Phil Muldoon wrote: > Andrew Overholt and I mused around with creating a wiki page somewhere > along the lines of "How to build your Java project with GCJ and > package it to rpm", and highlight some of the pitfalls, and strategies > involved here (that our group encountered with Eclipse). I'm not sure > if Fedora Core has a semi official wiki somewhere, but it is something > I would like to do. Also another wiki on how to debug your natively > built Java app. Hopefully that would help any Extra's project find the > right path; and make things even easier. http://gcc.gnu.org/wiki/GCJ How about this? I would be interested in your notes. From overholt at redhat.com Thu Mar 24 15:46:42 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 24 Mar 2005 10:46:42 -0500 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <1110580244.2342.18.camel@localhost> References: <1110580244.2342.18.camel@localhost> Message-ID: <20050324154642.GA19233@redhat.com> Hi, I decided to do something similar to what Ziga had done. I took his HelloWorld.java [1] and compiled it with three incarnations of ecj: 1. java-gcj-compat's javac 2. an ecj made as in [2] 3. an ecj made as in [3] Quick and dirty results (see [4] for details): (average of 5 runs) | j-g-c's javac | ecj (from .java) | ecj (linked) ------------------------------------------------------------- real | 1.1724 s | 0.2812 s | 0.3804 s user | 1.0576 s | 0.217 s | 0.313 s sys | 0.1144 s | 0.0636 s | 0.0672 s I've attached the raw output of the time commands for all three tests. Andrew [1] http://www.bootchart.org/misc/ecj/HelloWorld.java [2] Note: this took a _long_ time ... maybe I did something wrong? (in an exploded Eclipse source tree (after rpmbuild --short-circuit -bp on our eclipse.spec) in plugins/org.eclipse.jdt.core/compiler: gcj -o ecj -I. --main=org.eclipse.jdt.internal.compiler.batch.Main -O2 \ `find -name \*.java -print0 | xargs -0` [3] gcj -O2 --main=org.eclipse.jdt.internal.compiler.batch.Main \ -Wl,-R,/usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0 \ /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so \ /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtCompilerAdapter.jar.so \ -o ecj.linked [4] export CLASSPATH=/usr/share/java/libgcj-4.0.0.jar time HelloWorld.java -------------- next part -------------- real 0m0.379s user 0m0.310s sys 0m0.068s real 0m0.381s user 0m0.317s sys 0m0.065s real 0m0.384s user 0m0.310s sys 0m0.073s real 0m0.383s user 0m0.316s sys 0m0.066s real 0m0.375s user 0m0.312s sys 0m0.064s -------------- next part -------------- real 0m0.277s user 0m0.210s sys 0m0.067s real 0m0.277s user 0m0.224s sys 0m0.052s real 0m0.279s user 0m0.198s sys 0m0.081s real 0m0.278s user 0m0.220s sys 0m0.057s real 0m0.295s user 0m0.233s sys 0m0.061s -------------- next part -------------- real 0m1.146s user 0m1.039s sys 0m0.107s real 0m1.170s user 0m1.051s sys 0m0.117s real 0m1.154s user 0m1.047s sys 0m0.107s real 0m1.159s user 0m1.044s sys 0m0.115s real 0m1.233s user 0m1.107s sys 0m0.126s From aph at redhat.com Thu Mar 24 15:51:14 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 24 Mar 2005 15:51:14 +0000 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <20050324154642.GA19233@redhat.com> References: <1110580244.2342.18.camel@localhost> <20050324154642.GA19233@redhat.com> Message-ID: <16962.57842.46886.603813@cuddles.cambridge.redhat.com> Andrew Overholt writes: > > I decided to do something similar to what Ziga had done. I took his > HelloWorld.java [1] and compiled it with three incarnations of ecj: Isn't this program to small to be a reasonable test? Andrew. From ziga.mahkovec at klika.si Thu Mar 24 16:18:04 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Thu, 24 Mar 2005 17:18:04 +0100 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <16962.57842.46886.603813@cuddles.cambridge.redhat.com> References: <1110580244.2342.18.camel@localhost> <20050324154642.GA19233@redhat.com> <16962.57842.46886.603813@cuddles.cambridge.redhat.com> Message-ID: <1111681084.5966.27.camel@localhost> On Thu, 2005-03-24 at 15:51 +0000, Andrew Haley wrote: > Andrew Overholt writes: > > > > I decided to do something similar to what Ziga had done. I took his > > HelloWorld.java [1] and compiled it with three incarnations of ecj: > > Isn't this program to small to be a reasonable test? Andrew, if you want to repeat the tests for GNU Classpath, here's what I did: 1. grab a classpath snapshot (or checkout from CVS) 2. ./configure --with-ecj 3. apply the attached patch to work around an ecj bug[1] 4. link /usr/bin/ecj to one of your incarnations 5. cd lib; time make 6. make clean, rinse, repeat If I understand correctly, any significant difference in these timings would indicate BC-ABI performance penalty? [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=88562 -- Ziga -------------- next part -------------- A non-text attachment was scrubbed... Name: ecj-crash.patch Type: text/x-patch Size: 857 bytes Desc: not available URL: From overholt at redhat.com Thu Mar 24 16:36:26 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 24 Mar 2005 11:36:26 -0500 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <1111681084.5966.27.camel@localhost> References: <1110580244.2342.18.camel@localhost> <20050324154642.GA19233@redhat.com> <16962.57842.46886.603813@cuddles.cambridge.redhat.com> <1111681084.5966.27.camel@localhost> Message-ID: <20050324163626.GA17909@redhat.com> * Ziga Mahkovec [2005-03-24 11:19]: > Andrew, if you want to repeat the tests for GNU Classpath, here's what I Cool, thanks. Here are two of the three results (the from-source ecj had some issues with relocation): ecj.linked: ---------- real 0m52.822s user 0m21.669s sys 0m2.018s java-gcj-compat's javac: ----------------------- real 1m5.062s user 0m24.139s sys 0m2.410s Andrew From green at redhat.com Thu Mar 24 23:14:35 2005 From: green at redhat.com (Anthony Green) Date: Thu, 24 Mar 2005 15:14:35 -0800 Subject: [fedora-java] db merging script In-Reply-To: <16961.47262.192111.759933@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111548431.5248.30.camel@localhost.localdomain> <16961.47262.192111.759933@cuddles.cambridge.redhat.com> Message-ID: <1111706076.17650.25.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Wed, 2005-03-23 at 18:42 +0000, Andrew Haley wrote: > Anthony Green writes: > > On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote: > > > I CC'd Jakub for advice. Jakub, what should we do to make the > > > built-in .db file work with multilibs? I will implement whatever it > > > is we need. > > > > After looking at this for a bit, I recommend the following: > > > > "gcj-dbtool -p" operates as usual (for no special reason) > > "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db [snip] > That sounds pleasingly simple. There's a patch waiting for approval now: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00886.html Hopefully it will find its way into rawhide update sometime soon. AG From green at redhat.com Fri Mar 25 01:25:51 2005 From: green at redhat.com (Anthony Green) Date: Thu, 24 Mar 2005 17:25:51 -0800 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote: > >>>>> "Anthony" == Anthony Green writes: > > Anthony> Here's a real-world example from the servletapi5 spec file. It > Anthony> currently assumes that we should be using `gcj-dbtool -p`. > Anthony> Comments/suggestions welcome. > > Anthony> + # Generate native code. > Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar > Anthony> + gcj-dbtool -n jspapi-%{version}.db > [ ...] > > If it isn't too unwieldy, I would like to see this whole section > replaced by a single call to some shell script to automate the > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > utterly trivial... hmmm.. what do you mean by "find" in find-compile-db? I don't think it's safe to simply compile and db-ify any .jar file in your build tree. The best we might hope for is probably something like... gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS SRC_JARFILE refers to the jar file we want to process. DEST_SO_NAME is the name we want to install it as. JPackages seem to use different build and install jar names in some cases, so we can't infer from SRC_JARFILE. And we should probably version the library name. BUILD_OPTIONS is needed because we want to pass in $RPM_OPT_FLAGS. I suppose the script can handle certain options, like -findirect- dispatch and -Wl,Bsymbolic. I'm not sure I'd call this utterly trivial. Is it enough of an improvement over what I suggested earlier? Then we could have another little script to replace: DB=`gcj-dbtool -p %{_libdir}` rm -f $DB gcj-dbtool -n $DB (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) Could these go in java-gcj-compat? Or maybe as RPM macros? AG From tromey at redhat.com Fri Mar 25 18:28:48 2005 From: tromey at redhat.com (Tom Tromey) Date: 25 Mar 2005 11:28:48 -0700 Subject: [fedora-java] db merging script In-Reply-To: <16962.43389.990081.17067@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> <20050324061300.GB8801@devserv.devel.redhat.com> <16962.43389.990081.17067@cuddles.cambridge.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: >> And when they do, you don't know if those programs will be 32-bit or >> 64-bit. Andrew> I don't understand purpose of this comment. If there's a 32-bit Andrew> multilib, the user will use -m32 at compile time, and that will link Andrew> with the 32-bit library. Jakub was responding to me, since I didn't see how people would end up using the non-default libgcj.so. But his point is that some program may link against it explicitly, or dlopen and use the invocation API. And so, since we can't predict now which library might be used on a fully installed system, we have to handle this somehow. Anthony's gcj-dbtool patch went in, so we can start trying this soon. (FWIW I also didn't like the idea of having the ABI recorded in the .db.) Have we worked everything out now? We solved the multilib problem, and there seems to be a consensus on where to put the .so cache. Tom From tromey at redhat.com Fri Mar 25 18:33:43 2005 From: tromey at redhat.com (Tom Tromey) Date: 25 Mar 2005 11:33:43 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: >>>>> "Anthony" == Anthony Green writes: >> If it isn't too unwieldy, I would like to see this whole section >> replaced by a single call to some shell script to automate the >> find-compile-db loop. My goal is to make gcj-izing a jpackage RPM >> utterly trivial... Anthony> hmmm.. what do you mean by "find" in find-compile-db? I Anthony> don't think it's safe to simply compile and db-ify any .jar Anthony> file in your build tree. I was thinking we would do this in %install, by compiling every jar (or war or ...) we found in the install tree. But maybe it is ugly not to do in %build -- in which case, yeah, we need to do more manually. Anthony> The best we might hope for is probably something like... Anthony> gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS Anthony> I'm not sure I'd call this utterly trivial. Is it enough of an Anthony> improvement over what I suggested earlier? One thing that is nice about it is we can unpack and compile war files in the script. I suppose if we wanted we could also purge non-.class files from jars here as well, at least until gcj gets an option to do this. Anthony> Then we could have another little script to replace: Anthony> DB=`gcj-dbtool -p %{_libdir}` Anthony> rm -f $DB Anthony> gcj-dbtool -n $DB Anthony> (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) Anthony> Could these go in java-gcj-compat? Or maybe as RPM macros? Yeah, Tom F. offered to put them as scripts in java-gcj-compat. Let's do that for the time being. Tom From tromey at redhat.com Fri Mar 25 18:42:29 2005 From: tromey at redhat.com (Tom Tromey) Date: 25 Mar 2005 11:42:29 -0700 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <1111681084.5966.27.camel@localhost> References: <1110580244.2342.18.camel@localhost> <20050324154642.GA19233@redhat.com> <16962.57842.46886.603813@cuddles.cambridge.redhat.com> <1111681084.5966.27.camel@localhost> Message-ID: >>>>> "Ziga" == Ziga Mahkovec writes: Ziga> If I understand correctly, any significant difference in these timings Ziga> would indicate BC-ABI performance penalty? There are actually two variables hiding here: in case [3], not only is (e.g.) jdtcore.jar.so compiled with the BC-ABI, but it is also compiled from .class files and not .java source. The latter can sometimes have a performance impact. I would suggest adding another case, namely compiling the .jar files with the C++ ABI to see how that changes things (note that at the moment you can't compile .java source using the BC-ABI, as that part of the compiler is unfinished). It would also be interesting to see oprofile results for these runs. Tom From green at redhat.com Fri Mar 25 18:56:07 2005 From: green at redhat.com (Anthony Green) Date: Fri, 25 Mar 2005 10:56:07 -0800 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111776967.5243.9.camel@localhost.localdomain> On Fri, 2005-03-25 at 11:33 -0700, Tom Tromey wrote: > Anthony> hmmm.. what do you mean by "find" in find-compile-db? I > Anthony> don't think it's safe to simply compile and db-ify any .jar > Anthony> file in your build tree. > > I was thinking we would do this in %install, by compiling every jar > (or war or ...) we found in the install tree. But maybe it is ugly > not to do in %build -- in which case, yeah, we need to do more > manually. I don't think we'll get much support for compiling these at install time: (1) as Jakub recently pointed out, it would require gcj to be installed just to install java applications. (2) releng types have told us that slowing down the install by compiling things at install time is a non-starter. AG From tromey at redhat.com Fri Mar 25 19:13:37 2005 From: tromey at redhat.com (Tom Tromey) Date: 25 Mar 2005 12:13:37 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111776967.5243.9.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111776967.5243.9.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: >> I was thinking we would do this in %install, by compiling every jar >> (or war or ...) we found in the install tree. But maybe it is ugly >> not to do in %build -- in which case, yeah, we need to do more >> manually. Anthony> I don't think we'll get much support for compiling these at install Anthony> time: There's some terminology confusion here. As I understand RPM, which is not much, '%install' is a step that is run while building the RPM itself. %build does the "building", and %install puts the results into an install tree. Then RPM uses %files to figure out how to break down the install tree into different binary RPMs. There are other sections you can specify if you want some script to be run when the RPM itself is installed. Tom From kms at passback.co.uk Fri Mar 25 20:32:50 2005 From: kms at passback.co.uk (Keith Sharp) Date: Fri, 25 Mar 2005 20:32:50 +0000 Subject: [fedora-java] Eclipse Problems - Create a "Standard Make C Project" Message-ID: <1111782771.15096.16.camel@animal.passback.co.uk> Hello, When I try to create a new "Standard Make C Project" it fails at the last stage of the wizard, when I click finish, by displaying a dialog box that says "Project cannot be created Reason: Internal Error:". All the dialog has is an ok button! I can create a "Managed Make C Project" with no problems. Any thoughts on how to debug this further? I am running FC4T1 with Eclipse updated to latest Rawhide: $ rpm -qa eclipse\* eclipse-cdt-3.0.0_fc-0.M5.1 eclipse-changelog-2.0.1_fc-18 eclipse-ecj-3.1.0_fc-0.M5.13 eclipse-pde-devel-3.1.0_fc-0.M5.13 eclipse-pde-3.1.0_fc-0.M5.13 eclipse-platform-3.1.0_fc-0.M5.13 eclipse-jdt-3.1.0_fc-0.M5.13 eclipse-platform-devel-3.1.0_fc-0.M5.13 eclipse-pydev-0.9.0_fc-4 eclipse-jdt-devel-3.1.0_fc-0.M5.13 eclipse-bugzilla-0.1.0_fc-8 Thanks, keith. From bkonrath at redhat.com Fri Mar 25 21:01:13 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Fri, 25 Mar 2005 16:01:13 -0500 Subject: [fedora-java] Eclipse Problems - Create a "Standard Make C Project" In-Reply-To: <1111782771.15096.16.camel@animal.passback.co.uk> References: <1111782771.15096.16.camel@animal.passback.co.uk> Message-ID: <20050325210113.GD23490@town.toronto.redhat.com> Hi Keith, On Fri, Mar 25, 2005 at 08:32:50PM +0000, Keith Sharp wrote: > Hello, > > When I try to create a new "Standard Make C Project" it fails at the > last stage of the wizard, when I click finish, by displaying a dialog > box that says "Project cannot be created Reason: Internal Error:". All > the dialog has is an ok button! I can create a "Managed Make C Project" > with no problems. I'm actually in the middle of tracking this one down. We've come up with a hack that would allow you to create "standard make" project but you would not be able to change some (possibly all) of the project settings. I'll apply this hack if we can't sort out this stuff in a few days. If you have a minute, could file a bug in the Red Hat bugzilla about this? Thanks, Ben From zbalevsky at limepeer.com Fri Mar 25 21:12:39 2005 From: zbalevsky at limepeer.com (zbalevsky) Date: Fri, 25 Mar 2005 16:12:39 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 Message-ID: <42447EC7.4000109@limepeer.com> Greetings, I looked around bugzilla but there wasn't anything similar to this bug. Every time I start the native eclipse, the entire computer freezes as soon as it passes the splash screen. Hard reset is the only thing that works from that point on. I tried starting the regular eclipse 3.1M5 with gij and the result was the same; regular eclipse runs fine on the Sun jvm. This is an i386 fc4t1 system updated to the latest rawhide (from last night). Are there any options I can pass to either gij or the eclipse binary that will make it print some debugging info? From pmuldoon at redhat.com Fri Mar 25 21:12:47 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Fri, 25 Mar 2005 15:12:47 -0600 Subject: [fedora-java] Eclipse Problems - Create a "Standard Make C Project" In-Reply-To: <1111782771.15096.16.camel@animal.passback.co.uk> References: <1111782771.15096.16.camel@animal.passback.co.uk> Message-ID: <1111785167.5808.10.camel@localhost.localdomain> Keith As ben mentioned, we are tracking (and attempting to fix) this bug. You can still use managed make projects as normal. We should have a fix in a few days. Incidentally, this only happens when you attempt to create a brand new standard project. If you have existing projects (or pull in from CVS), the rest of the CDT appears to work fine. Anyway, file a bug, so we can start some tracking on it. Regards Phil On Fri, 2005-03-25 at 20:32 +0000, Keith Sharp wrote: > Hello, > > When I try to create a new "Standard Make C Project" it fails at the > last stage of the wizard, when I click finish, by displaying a dialog > box that says "Project cannot be created Reason: Internal Error:". All > the dialog has is an ok button! I can create a "Managed Make C Project" > with no problems. > > Any thoughts on how to debug this further? I am running FC4T1 with > Eclipse updated to latest Rawhide: > > $ rpm -qa eclipse\* > eclipse-cdt-3.0.0_fc-0.M5.1 > eclipse-changelog-2.0.1_fc-18 > eclipse-ecj-3.1.0_fc-0.M5.13 > eclipse-pde-devel-3.1.0_fc-0.M5.13 > eclipse-pde-3.1.0_fc-0.M5.13 > eclipse-platform-3.1.0_fc-0.M5.13 > eclipse-jdt-3.1.0_fc-0.M5.13 > eclipse-platform-devel-3.1.0_fc-0.M5.13 > eclipse-pydev-0.9.0_fc-4 > eclipse-jdt-devel-3.1.0_fc-0.M5.13 > eclipse-bugzilla-0.1.0_fc-8 > > Thanks, > > keith. > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From bkonrath at redhat.com Fri Mar 25 21:25:57 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Fri, 25 Mar 2005 16:25:57 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <42447EC7.4000109@limepeer.com> References: <42447EC7.4000109@limepeer.com> Message-ID: <20050325212556.GA3809@town.toronto.redhat.com> On Fri, Mar 25, 2005 at 04:12:39PM -0500, zbalevsky wrote: > Greetings, > > I looked around bugzilla but there wasn't anything similar to this bug. > Every time I start the native eclipse, the entire computer freezes as > soon as it passes the splash screen. Hard reset is the only thing that > works from that point on. I tried starting the regular eclipse 3.1M5 > with gij and the result was the same; regular eclipse runs fine on the > Sun jvm. > > This is an i386 fc4t1 system updated to the latest rawhide (from last > night). Are there any options I can pass to either gij or the eclipse > binary that will make it print some debugging info? Yes, on the eclipse side of things you can run: eclipse -consolelog -debug I'd be interested to see what this prints out. Cheers, Ben From zbalevsky at limepeer.com Fri Mar 25 21:49:40 2005 From: zbalevsky at limepeer.com (zbalevsky) Date: Fri, 25 Mar 2005 16:49:40 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <20050325212556.GA3809@town.toronto.redhat.com> References: <42447EC7.4000109@limepeer.com> <20050325212556.GA3809@town.toronto.redhat.com> Message-ID: <42448774.9040704@limepeer.com> Ben Konrath wrote: >On Fri, Mar 25, 2005 at 04:12:39PM -0500, zbalevsky wrote: > > >>Greetings, >> >>I looked around bugzilla but there wasn't anything similar to this bug. >>Every time I start the native eclipse, the entire computer freezes as >>soon as it passes the splash screen. Hard reset is the only thing that >>works from that point on. I tried starting the regular eclipse 3.1M5 >>with gij and the result was the same; regular eclipse runs fine on the >>Sun jvm. >> >>This is an i386 fc4t1 system updated to the latest rawhide (from last >>night). Are there any options I can pass to either gij or the eclipse >>binary that will make it print some debugging info? >> >> > >Yes, on the eclipse side of things you can run: > >eclipse -consolelog -debug > >I'd be interested to see what this prints out. > >Cheers, Ben > > I'm attaching the logfile. It is possible that some of the last messages did not make it to disk when the system froze. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.txt URL: From bkonrath at redhat.com Sat Mar 26 01:41:38 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Fri, 25 Mar 2005 20:41:38 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <42448774.9040704@limepeer.com> References: <42447EC7.4000109@limepeer.com> <20050325212556.GA3809@town.toronto.redhat.com> <42448774.9040704@limepeer.com> Message-ID: <20050326014138.GB3809@town.toronto.redhat.com> On Fri, Mar 25, 2005 at 04:49:40PM -0500, zbalevsky wrote: > I'm attaching the logfile. It is possible that some of the last > messages did not make it to disk when the system froze. Yeah, your right that doesn't show anything. I remember having the same problem a couple of weeks ago but I could not reproduce it reliably. Can you try running eclipse again with a clean workspace and a clean configuration directory? To do this you should first move the configuration files out of the way: mv ~/.eclipse{,.bak} Normally it's safe to just delete this directory, but it would be useful for us to see if this is causing problems. Now to run eclipse with a clean workspace, just do: eclipse -consolelog -debug -data path/to/workspace/ Note: the workspace shouldn't exist, eclipse will create a new directory if nothing is there. Cheers, Ben From zbalevsky at limepeer.com Sat Mar 26 04:56:55 2005 From: zbalevsky at limepeer.com (zbalevsky) Date: Fri, 25 Mar 2005 23:56:55 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <20050326014138.GB3809@town.toronto.redhat.com> References: <42447EC7.4000109@limepeer.com> <20050325212556.GA3809@town.toronto.redhat.com> <42448774.9040704@limepeer.com> <20050326014138.GB3809@town.toronto.redhat.com> Message-ID: <4244EB97.40209@limepeer.com> Ben Konrath wrote: >On Fri, Mar 25, 2005 at 04:49:40PM -0500, zbalevsky wrote: > > >>I'm attaching the logfile. It is possible that some of the last >>messages did not make it to disk when the system froze. >> >> > >Yeah, your right that doesn't show anything. I remember having the >same problem a couple of weeks ago but I could not reproduce it >reliably. Can you try running eclipse again with a clean workspace and a >clean configuration directory? > >To do this you should first move the configuration files out of the way: > >mv ~/.eclipse{,.bak} > >Normally it's safe to just delete this directory, but it would be useful >for us to see if this is causing problems. Now to run eclipse with a >clean workspace, just do: > >eclipse -consolelog -debug -data path/to/workspace/ > >Note: the workspace shouldn't exist, eclipse will create a new >directory if nothing is there. > >Cheers, Ben > >-- > Hi again, I'm attaching a log of a freeze when the workspace does not exist. I really don't think this is an eclipse problem since when I ran it under strace -ff everything went fine (albeit excruciatingly slow). Any idea where I can take this issue next? gcj / gij / kernel people? If I open a bugzilla will it end up being redirected here? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.eclipse2 URL: From tadej.janez at tadej.hicsalta.si Sat Mar 26 10:09:39 2005 From: tadej.janez at tadej.hicsalta.si (Tadej =?iso-8859-2?Q?Jane=BE?=) Date: Sat, 26 Mar 2005 11:09:39 +0100 Subject: [fedora-java] db merging script In-Reply-To: <1111625739.12175.31.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111625739.12175.31.camel@localhost.localdomain> Message-ID: <1111831779.5456.7.camel@localhost.localdomain> On Wed, 2005-03-23 at 18:55 -0600, Phil Muldoon wrote: > Andrew Overholt and I mused around with creating a wiki page somewhere > along the lines of "How to build your Java project with GCJ and package > it to rpm", and highlight some of the pitfalls, and strategies involved > here (that our group encountered with Eclipse). I'm not sure if Fedora > Core has a semi official wiki somewhere, but it is something I would > like to do. Also another wiki on how to debug your natively built Java > app. Hopefully that would help any Extra's project find the right path; > and make things even easier. I think that would be very useful. Maybe you could add it to http://fedoraproject.org/wiki/ ? Thanks, Tadej -- Tadej Jane? From kms at passback.co.uk Sat Mar 26 10:48:04 2005 From: kms at passback.co.uk (Keith Sharp) Date: Sat, 26 Mar 2005 10:48:04 +0000 Subject: [fedora-java] Eclipse Problems - Create a "Standard Make C Project" In-Reply-To: <1111785167.5808.10.camel@localhost.localdomain> References: <1111782771.15096.16.camel@animal.passback.co.uk> <1111785167.5808.10.camel@localhost.localdomain> Message-ID: <1111834085.27888.0.camel@animal.passback.co.uk> On Fri, 2005-03-25 at 15:12 -0600, Phil Muldoon wrote: > Keith > > As ben mentioned, we are tracking (and attempting to fix) this bug. You > can still use managed make projects as normal. We should have a fix in a > few days. Incidentally, this only happens when you attempt to create a > brand new standard project. If you have existing projects (or pull in > from CVS), the rest of the CDT appears to work fine. > > Anyway, file a bug, so we can start some tracking on it. Created #152206 Keith. From pmuldoon at redhat.com Sat Mar 26 20:29:55 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sat, 26 Mar 2005 14:29:55 -0600 Subject: [fedora-java] db merging script In-Reply-To: <1111831779.5456.7.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111625739.12175.31.camel@localhost.localdomain> <1111831779.5456.7.camel@localhost.localdomain> Message-ID: <1111868995.5808.1.camel@localhost.localdomain> On Sat, 2005-03-26 at 11:09 +0100, Tadej Jane? wrote: > I think that would be very useful. > > Maybe you could add it to http://fedoraproject.org/wiki/ ? > > Thanks, > > Tadej > On Thu, 2005-03-24 at 14:04 +0000, Phil Shaw wrote: > http://gcc.gnu.org/wiki/GCJ > > How about this? I would be interested in your notes. Okay, when the current rush has died down, I'll write something up, and post it to both sites. Regards Phil From djo at coconut-palm-software.com Sun Mar 27 03:41:55 2005 From: djo at coconut-palm-software.com (David J. Orme) Date: Sat, 26 Mar 2005 21:41:55 -0600 Subject: [fedora-java] db merging script In-Reply-To: <1111868995.5808.1.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111625739.12175.31.camel@localhost.localdomain> <1111831779.5456.7.camel@localhost.localdomain> <1111868995.5808.1.camel@localhost.localdomain> Message-ID: <42462B83.4010509@coconut-palm-software.com> Phil, If you could post here when you've done that, I'd be most appreciative. Regards, Dave Orme Phil Muldoon wrote: >On Sat, 2005-03-26 at 11:09 +0100, Tadej Jane? wrote: > > >>I think that would be very useful. >> >>Maybe you could add it to http://fedoraproject.org/wiki/ ? >> >>Thanks, >> >>Tadej >> >> >> > >On Thu, 2005-03-24 at 14:04 +0000, Phil Shaw wrote: > > > >>http://gcc.gnu.org/wiki/GCJ >> >>How about this? I would be interested in your notes. >> >> > >Okay, when the current rush has died down, I'll write something up, and >post it to both sites. > > >Regards > >Phil > > >-- >fedora-devel-java-list mailing list >fedora-devel-java-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > > -- Got Java? Use db4objects! PGP Public Key (for confidential communications): http://www.coconut-palm-software.com/~djo/public_key.txt From jdesbonnet at gmail.com Sun Mar 27 12:45:30 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Sun, 27 Mar 2005 13:45:30 +0100 Subject: [fedora-java] DBus and Java Message-ID: <1cef3e9505032704453b2ff07d@mail.gmail.com> I understand that the long term plan with Fedora is to expose all system configuration information via DBus. Are there any Java bindings for this yet? Part of the reason I ask is I'm wondering what is (or will be) the correct way to query locally installed RPMs. Thanks, Joe. From greenrd at presidium.org Sun Mar 27 12:56:05 2005 From: greenrd at presidium.org (Robin Green) Date: Sun, 27 Mar 2005 07:56:05 -0500 (EST) Subject: [fedora-java] DBus and Java In-Reply-To: <1cef3e9505032704453b2ff07d@mail.gmail.com> References: <1cef3e9505032704453b2ff07d@mail.gmail.com> Message-ID: On Sun, 27 Mar 2005, Joe Desbonnet wrote: > I understand that the long term plan with Fedora is to expose all > system configuration information via DBus. Are there any Java bindings > for this yet? > > Part of the reason I ask is I'm wondering what is (or will be) the > correct way to query locally installed RPMs. Can't you just use Process p = Runtime.exec ("rpm -q " + packageName) InputStream in = p.getInputStream (); // Read query results from in ? -- Robin From walters at redhat.com Sun Mar 27 13:03:04 2005 From: walters at redhat.com (Colin Walters) Date: Sun, 27 Mar 2005 08:03:04 -0500 Subject: [fedora-java] DBus and Java In-Reply-To: <1cef3e9505032704453b2ff07d@mail.gmail.com> References: <1cef3e9505032704453b2ff07d@mail.gmail.com> Message-ID: <1111928584.16952.28.camel@nexus.verbum.private> On Sun, 2005-03-27 at 13:45 +0100, Joe Desbonnet wrote: > I understand that the long term plan with Fedora is to expose all > system configuration information via DBus. I wouldn't say that, really. I don't think anyone is going to make a D-BUS service for exposing Apache configuration, for example. That's not to say it wouldn't be neat if it just happened, but I think it would be of less value than some other things we could be spending time on. > Are there any Java bindings > for this yet? Not yet, no. The Java-GNOME people are working on it though: http://lists.freedesktop.org/archives/dbus/2005-February/002180.html > Part of the reason I ask is I'm wondering what is (or will be) the > correct way to query locally installed RPMs. I think Robin's correct; your best bet now is just to invoke rpm. Alternatively there might be Java bindings to the librpm. From phil at mkdoc.com Sun Mar 27 17:20:57 2005 From: phil at mkdoc.com (Phil Shaw) Date: Sun, 27 Mar 2005 18:20:57 +0100 Subject: [fedora-java] DBus and Java In-Reply-To: <1111928584.16952.28.camel@nexus.verbum.private> References: <1cef3e9505032704453b2ff07d@mail.gmail.com> Message-ID: <4246F989.6840.1E456C5A@localhost> On 27 Mar 2005, at 8:03, Colin Walters wrote: > > Part of the reason I ask is I'm wondering what is (or will be) the > > correct way to query locally installed RPMs. > > I think Robin's correct; your best bet now is just to invoke rpm. > Alternatively there might be Java bindings to the librpm. I haven't used this, but found it by accident some time ago and bookmarked it. It might give the start you're after. From greenrd at presidium.org Sun Mar 27 17:23:54 2005 From: greenrd at presidium.org (Robin Green) Date: Sun, 27 Mar 2005 12:23:54 -0500 (EST) Subject: [fedora-java] DBus and Java In-Reply-To: <4246F989.6840.1E456C5A@localhost> References: <1cef3e9505032704453b2ff07d@mail.gmail.com> <4246F989.6840.1E456C5A@localhost> Message-ID: On Sun, 27 Mar 2005, Phil Shaw wrote: > I haven't used this, but found it by accident some time ago and > bookmarked it. It might give the start you're after. > > Also, I have hacked jrpm to support the rpm headers that older versions of yum use (newer versions use XML). Email me if you want that code. From tromey at redhat.com Mon Mar 28 21:12:04 2005 From: tromey at redhat.com (Tom Tromey) Date: 28 Mar 2005 14:12:04 -0700 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1111140385.5383.8.camel@localhost> References: <20050225164858.GH19850@redhat.com> <1109465599.8854.32.camel@localhost> <1111140385.5383.8.camel@localhost> Message-ID: >>>>> "Ziga" == Ziga Mahkovec writes: >> I could send the patch if someone wants to test it. Otherwise it will >> have to wait until I get my tree back in a sane state so I can try it >> out. Ziga> I'd be willing to test the patch. Given that this was actually a native Ziga> compilation issue[1] (it works fine in interpreted mode), does this Ziga> patch work around a compiler issue? Ziga> [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149915 Thanks for pointing this out. The reason I didn't send the patch is that it is purely on the runtime side, so probably wouldn't have helped. Tom From tjarvi at qbang.org Tue Mar 29 10:08:35 2005 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 29 Mar 2005 03:08:35 -0700 (MST) Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <42447EC7.4000109@limepeer.com> References: <42447EC7.4000109@limepeer.com> Message-ID: On Fri, 25 Mar 2005, zbalevsky wrote: > Greetings, > > I looked around bugzilla but there wasn't anything similar to this bug. > Every time I start the native eclipse, the entire computer freezes as soon as > it passes the splash screen. Hard reset is the only thing that works from > that point on. I tried starting the regular eclipse 3.1M5 with gij and the > result was the same; regular eclipse runs fine on the Sun jvm. > > This is an i386 fc4t1 system updated to the latest rawhide (from last night). > Are there any options I can pass to either gij or the eclipse binary that > will make it print some debugging info? > I found your post after filing a bug which sounds very similar. I had just been passivly following but have seen a bug like this for weeks. I finally decided to netdump and see if anyone had any ideas. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152386 -- Trent Jarvi From aph at redhat.com Tue Mar 29 20:54:34 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Mar 2005 21:54:34 +0100 Subject: [fedora-java] db merging script In-Reply-To: <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <16969.49290.344620.134371@cuddles.cambridge.redhat.com> Anthony Green writes: > On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote: > > >>>>> "Anthony" == Anthony Green writes: > > > > Anthony> Here's a real-world example from the servletapi5 spec file. It > > Anthony> currently assumes that we should be using `gcj-dbtool -p`. > > Anthony> Comments/suggestions welcome. > > > > Anthony> + # Generate native code. > > Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar > > Anthony> + gcj-dbtool -n jspapi-%{version}.db > > [ ...] > > > > If it isn't too unwieldy, I would like to see this whole section > > replaced by a single call to some shell script to automate the > > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > > utterly trivial... > > hmmm.. what do you mean by "find" in find-compile-db? I don't think > it's safe to simply compile and db-ify any .jar file in your build tree. > > The best we might hope for is probably something like... > > gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS > > SRC_JARFILE refers to the jar file we want to process. > > DEST_SO_NAME is the name we want to install it as. JPackages seem to > use different build and install jar names in some cases, so we can't > infer from SRC_JARFILE. And we should probably version the library > name. > > BUILD_OPTIONS is needed because we want to pass in $RPM_OPT_FLAGS. > I suppose the script can handle certain options, like -findirect- > dispatch and -Wl,Bsymbolic. > > I'm not sure I'd call this utterly trivial. Is it enough of an > improvement over what I suggested earlier? > > > Then we could have another little script to replace: > > DB=`gcj-dbtool -p %{_libdir}` > rm -f $DB I don't like this. Any process that starts during this time will fail because the .db is missing. The right way is to find everything and merge into the master. This is how it should work: DB=`gcj-dbtool -p %{_libdir}` (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) If we expect problems with command line lengths I'll fix gcj-dbtool to take the list from stdin. Andrew. From bkonrath at redhat.com Tue Mar 29 21:14:15 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 29 Mar 2005 16:14:15 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <4244EB97.40209@limepeer.com> References: <42447EC7.4000109@limepeer.com> <20050325212556.GA3809@town.toronto.redhat.com> <42448774.9040704@limepeer.com> <20050326014138.GB3809@town.toronto.redhat.com> <4244EB97.40209@limepeer.com> Message-ID: <1112130855.10339.26.camel@town.toronto.redhat.com> Hi, Sorry for the delay, I was offline for the latter part of the Easter holiday. On Fri, 2005-03-25 at 23:56 -0500, zbalevsky wrote: > I really don't think this is an eclipse problem since when I ran it > under strace -ff everything went fine (albeit excruciatingly slow). Any > idea where I can take this issue next? gcj / gij / kernel people? If I > open a bugzilla will it end up being redirected here? I agree, this probably isn't an Eclipse bug. Let's use the open bug to track this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152386 (Thanks for pointing this out Trent.) > !ENTRY org.eclipse.core.resources 4 567 2005-03-25 23:48:21.756 > !MESSAGE Conversion of persistent properties failed. > !SUBENTRY 1 org.eclipse.core.resources 4 271 2005-03-25 23:48:21.757 > !MESSAGE Could not create indexed cursor: /root/workspace/.metadata/.plugins/org.eclipse.core.resources/.root/.properties. > !STACK 0 > IndexedStoreException:Index not found. > at org.eclipse.core.internal.indexing.IndexedStore.getIndex(java.lang.String) (/usr/lib/eclipse/plugins/org.eclipse.core.resources.compatibility_3.1.0/compatibility.jar.so) > at org.eclipse.core.internal.properties.IndexedStoreWrapper.getIndex() (/usr/lib/eclipse/plugins/org.eclipse.core.resources.compatibility_3.1.0/compatibility.jar.so) This is a bug, but it is probably not the cause of your problem because I get the same exception but my machine but my machine doesn't crash. Cheers, Ben From overholt at redhat.com Tue Mar 29 22:48:16 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 29 Mar 2005 17:48:16 -0500 Subject: [fedora-java] db merging script In-Reply-To: <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050329224815.GB20638@redhat.com> * Anthony Green [2005-03-24 20:30]: > > If it isn't too unwieldy, I would like to see this whole section > > replaced by a single call to some shell script to automate the > > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > > utterly trivial... > The best we might hope for is probably something like... > > gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS > > Then we could have another little script to replace: > > DB=`gcj-dbtool -p %{_libdir}` > rm -f $DB > gcj-dbtool -n $DB > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) How about the attached three scripts? gcj-findandnativify.sh is kinda flaky, but it'll work well for us during the eclipse build procedure (I'm testing a build now). I've attached a patch to the current eclipse.spec and it simplifies things greatly. Comments welcome. > Could these go in java-gcj-compat? Or maybe as RPM macros? Tom Fitzsimmons has offered to put these in java-gcj-compat. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: gcj-findandnativify.sh Type: application/x-sh Size: 1019 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gcj-nativify.sh Type: application/x-sh Size: 435 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rebuildgcjdb.sh Type: application/x-sh Size: 298 bytes Desc: not available URL: -------------- next part -------------- --- eclipse.spec 2005-03-29 16:36:02.000000000 -0500 +++ eclipse.spec.new 2005-03-29 17:42:48.000000000 -0500 @@ -424,27 +424,12 @@ # Native build -- do -O2 on x86 and ppc only (for now) %ifarch %{ix86} ppc - mkdir -p $RPM_BUILD_ROOT%{_libdir}/%{name} - for j in `find -name \*.jar`; do - d=".%{_libdir}/%{name}/`dirname $j | sed 's:\./::'`"; - mkdir -p $d; - s=`echo $j | sed "s:\./::"`; - gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -O2 \ - -o $d/`basename $j`.so $j; - done + gcj-findandnativify.sh %{name} "$RPM_OPT_FLAGS -fPIC -fjni -O2" %else - mkdir -p $RPM_BUILD_ROOT%{_libdir}/%{name} - for j in `find -name \*.jar`; do - d=".%{_libdir}/%{name}/`dirname $j | sed 's:\./::'`"; - mkdir -p $d; - s=`echo $j | sed "s:\./::"`; - gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic \ - -o $d/`basename $j`.so $j; - done + gcj-findandnativify.sh %{name} "$RPM_OPT_FLAGS -fPIC -fjni" %endif -# Tar up the native libs -tar czvf ../%{name}-nativelycompiledjars.tar.gz .%{_libdir}/%{name} +mv %{name}.tar.gz .. popd @@ -466,12 +451,12 @@ install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/%{name} # Natively-compiled jars (shared libraries) -tar -C $RPM_BUILD_ROOT -zxf result/%{name}-nativelycompiledjars.tar.gz +tar -C $RPM_BUILD_ROOT -zxf result/%{name}.tar.gz install -d -m 755 $RPM_BUILD_ROOT%{_bindir} # Directory to hold all the .jar->.so mapping dbs -install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings +install -d -m 755 $RPM_BUILD_ROOT`gcj-dbtool -p %{_libdir}` # Eclipse binary mv $RPM_BUILD_ROOT%{_datadir}/%{name}/eclipse \ @@ -648,24 +633,25 @@ $RPM_BUILD_ROOT%{_datadir}/java/jdtcore.jar # Create the gcj dbs for libswt, ecj, platform, jdt, and pde -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/ecj.db 80000 -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/libswt3-gtk2.db 80000 -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/platform.db 80000 -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db 80000 -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/pde.db 80000 +gcjdbdir=`gcj-dbtool -p %{_libdir}` +gcj-dbtool -n $gcjdbdir/ecj.db 80000 +gcj-dbtool -n $gcjdbdir/libswt3-gtk2.db 80000 +gcj-dbtool -n $gcjdbdir/platform.db 80000 +gcj-dbtool -n $gcjdbdir/jdt.db 80000 +gcj-dbtool -n $gcjdbdir/pde.db 80000 # ecj db -gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/ecj.db \ +gcj-dbtool -f $gcjdbdir/ecj.db \ $RPM_BUILD_ROOT%{_datadir}/%{name}/plugins/org.eclipse.jdt.core_%{eclipse_majmin}.%{eclipse_micro}/jdtcore.jar \ %{_libdir}/%{name}/plugins/org.eclipse.jdt.core_%{eclipse_majmin}.%{eclipse_micro}/jdtcore.jar.so -gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/ecj.db \ +gcj-dbtool -f $gcjdbdir/ecj.db \ $RPM_BUILD_ROOT%{_datadir}/%{name}/plugins/org.eclipse.jdt.core_%{eclipse_majmin}.%{eclipse_micro}/jdtCompilerAdapter.jar \ %{_libdir}/%{name}/plugins/org.eclipse.jdt.core_%{eclipse_majmin}.%{eclipse_micro}/jdtCompilerAdapter.jar.so # jdt db for dir in `cat %{SOURCE7}`; do for j in `find $RPM_BUILD_ROOT/$dir -name \*.jar`; do - gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db \ + gcj-dbtool -f $gcjdbdir/jdt.db \ $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; done; done @@ -673,7 +659,7 @@ # pde db for dir in `cat %{SOURCE8}`; do for j in `find $RPM_BUILD_ROOT/$dir -name \*.jar`; do - gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db \ + gcj-dbtool -f $gcjdbdir/pde.db \ $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; done; done @@ -681,7 +667,7 @@ # platform db for dir in `cat %{SOURCE9}`; do for j in `find $RPM_BUILD_ROOT/$dir -name \*.jar`; do - gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db \ + gcj-dbtool -f $gcjdbdir/platform.db \ $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; done; done @@ -689,7 +675,7 @@ # swt db for dir in `cat %{SOURCE10}`; do for j in `find $RPM_BUILD_ROOT/$dir -name \*.jar`; do - gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db \ + gcj-dbtool -f $gcjdbdir/libswt3-gtk2.db \ $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; done; done @@ -698,97 +684,44 @@ rm -rf $RPM_BUILD_ROOT %post ecj -dbLocation=`gcj-dbtool -p` -if ! [ -e $dbLocation ]; then - dirname $dbLocation | xargs mkdir -p - gcj-dbtool -n $dbLocation -fi - -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %post jdt -dbLocation=`gcj-dbtool -p` -if ! [ -e $dbLocation ]; then - dirname $dbLocation | xargs mkdir -p - gcj-dbtool -n $dbLocation -fi - -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %post pde -dbLocation=`gcj-dbtool -p` -if ! [ -e $dbLocation ]; then - dirname $dbLocation | xargs mkdir -p - gcj-dbtool -n $dbLocation -fi - -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %post platform -dbLocation=`gcj-dbtool -p` -if ! [ -e $dbLocation ]; then - dirname $dbLocation | xargs mkdir -p - gcj-dbtool -n $dbLocation -fi +rebuildgcjdb.sh %{_libdir} -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi touch --no-create %{_datadir}/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then gtk-update-icon-cache %{_datadir}/icons/hicolor fi %post -n %{libname}-gtk2 -dbLocation=`gcj-dbtool -p` -mkdir -p `dirname $dbLocation` -if ! [ -e $dbLocation ]; then - gcj-dbtool -n $dbLocation -fi - -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %postun ecj -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %postun jdt -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %postun pde -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %postun platform -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} + touch --no-create %{_datadir}/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then gtk-update-icon-cache %{_datadir}/icons/hicolor fi %postun -n %{libname}-gtk2 -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} # FIXME: add the native directories to these lists %files ecj @@ -797,8 +730,7 @@ %{_datadir}/%{name}/plugins/org.eclipse.jdt.core_3.* %{_datadir}/java/jdtcore*.jar # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/ecj.db +`gcj-dbtool -p %{_libdir}`/ecj.db %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.core_3.1.0/jdtCompilerAdapter.jar.so @@ -816,8 +748,7 @@ %{_javadir}/swt-mozilla*.jar %{_javadir}/swt-cairo*.jar # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/libswt3-gtk2.db +`gcj-dbtool -p %{_libdir}`/libswt3-gtk2.db %ifarch alpha ia64 ppc64 sparc64 x86_64 %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.swt.gtk64_3.1.0/ws/gtk/swt-pi.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.swt.gtk64_3.1.0/ws/gtk/swt-mozilla.jar.so @@ -835,8 +766,7 @@ %files jdt -f %{name}-jdt.install %defattr(0644,root,root,0755) # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/jdt.db +`gcj-dbtool -p %{_libdir}`/libswt3-gtk2.db %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.debug.ui_3.1.0/jdiui.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.debug.ui_3.1.0/snippetsupport.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.debug_3.1.0/jdimodel.jar.so @@ -856,8 +786,7 @@ %files pde -f %{name}-pde.install %defattr(0644,root,root,0755) # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/pde.db +`gcj-dbtool -p %{_libdir}`/libswt3-gtk2.db %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.pde.build_3.1.0/lib/pdebuild-ant.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.pde.build_3.1.0/pdebuild.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.pde.core_3.1.0/pdecore.jar.so @@ -890,8 +819,7 @@ %{_datadir}/icons/*/*/apps/* %config(noreplace) %{_sysconfdir}/eclipse.conf # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/platform.db +`gcj-dbtool -p %{_libdir}`/libswt3-gtk2.db %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.ant.core_3.1.0/antsupport.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.compare_3.1.0/compare.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.core.boot_3.0.0/boot.jar.so From aph at redhat.com Wed Mar 30 15:10:37 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 30 Mar 2005 16:10:37 +0100 Subject: [fedora-java] db merging script In-Reply-To: <20050329224815.GB20638@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> Message-ID: <16970.49517.917898.99294@cuddles.cambridge.redhat.com> It's been pointed out to me that if we merge db's with the obvious (find . -name 'temp-*.db' | xargs gcj-dbtool -m $DB) we run the risk of failure if arg length exceeds the operating system limit, because xargs will call gcj-dbtool several times. The right way to fix this is to have gcj-dbtool read a list of files from stdin, which is what this patch does. (find . -name 'temp-*.db' | gcj-dbtool - -m $DB) Andrew. 2005-03-30 Andrew Haley * gnu/gcj/tools/gcj_dbtool/Main.java (Fileset): New class. (getFiles): New method. (main): Add "-" argument. Read list of files from stdin when merging map databases. (usage): Add "-" argument. Minor corrections. Index: Main.java =================================================================== RCS file: /cvs/gcc/gcc/libjava/gnu/gcj/tools/gcj_dbtool/Main.java,v retrieving revision 1.9 diff -c -2 -p -r1.9 Main.java *** Main.java 25 Mar 2005 00:38:43 -0000 1.9 --- Main.java 30 Mar 2005 15:04:15 -0000 *************** public class Main *** 23,27 **** --- 23,37 ---- public static void main (String[] s) { + boolean fileListFromStdin = false; insist (s.length >= 1); + + if (s[0].equals("-")) + { + fileListFromStdin = true; + String[] newArgs = new String[s.length - 1]; + System.arraycopy(s, 1, newArgs, 0, s.length - 1); + s = newArgs; + } + if (s[0].equals("-v") || s[0].equals("--version")) { *************** public class Main *** 146,151 **** { // Merge databases. ! insist (s.length >= 3); ! try { File database = new File(s[1]); --- 156,162 ---- { // Merge databases. ! insist (s.length >= 3 ! || fileListFromStdin && s.length == 2); ! try { File database = new File(s[1]); *************** public class Main *** 156,171 **** int newSize = 0; int newStringTableSize = 0; ! PersistentByteMap[] sourceMaps = new PersistentByteMap[s.length - 2]; // Scan all the input files, calculating worst case string // table and hash table use. ! for (int i = 2; i < s.length; i++) ! { ! PersistentByteMap b ! = new PersistentByteMap(new File(s[i]), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i - 2] = b; ! } newSize *= 1.5; // Scaling the new size by 1.5 results in --- 167,188 ---- int newSize = 0; int newStringTableSize = 0; ! Fileset files = getFiles(s, 2, fileListFromStdin); ! PersistentByteMap[] sourceMaps = new PersistentByteMap[files.size()]; ! // Scan all the input files, calculating worst case string // table and hash table use. ! { ! Iterator it = files.iterator(); ! int i = 0; ! while (it.hasNext()) ! { ! PersistentByteMap b ! = new PersistentByteMap((File)it.next(), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i++] = b; ! } ! } newSize *= 1.5; // Scaling the new size by 1.5 results in *************** public class Main *** 297,310 **** + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name"); } --- 314,329 ---- + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool [-] -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " If the first arg is -, read the list from stdin\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name" ! ); } *************** public class Main *** 406,409 **** --- 425,485 ---- return hexBytes.toString(); } + + + // Return a Fileset, either from a String array or from System.in, + // depending on fileListFromStdin. + private static final Fileset getFiles(String[] s, int startPos, + boolean fileListFromStdin) + { + if (fileListFromStdin) + return new Fileset(System.in); + else + return new Fileset(s, startPos, s.length); + } } + // A Fileset is a container for a set of files; it can be created + // either from a string array or from an input stream. + class Fileset + { + LinkedHashSet files = new LinkedHashSet(); + + Fileset (String[] s, int start, int end) + { + for (int i = start; i < end; i++) + { + files.add(new File(s[i])); + } + } + + Fileset (InputStream is) + { + Reader r = new BufferedReader(new InputStreamReader(is)); + StringBuffer buf = new StringBuffer(); + try + { + int chr; + while ((chr = r.read()) != -1) + buf.append((char)chr); + } + catch (IOException _) + { + } + StringTokenizer st = new StringTokenizer(buf.toString()); + while (st.hasMoreElements ()) + { + String name = st.nextToken (); + files.add(new File(name)); + } + } + + Iterator iterator() + { + return files.iterator(); + } + + int size() + { + return files.size(); + } + } From tromey at redhat.com Wed Mar 30 19:38:00 2005 From: tromey at redhat.com (Tom Tromey) Date: 30 Mar 2005 12:38:00 -0700 Subject: [fedora-java] db merging script In-Reply-To: <200503301519.j2UFJpAv024829@littlepinkcloud.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: Andrew> The right way to fix this is to have gcj-dbtool read a list of files Andrew> from stdin, which is what this patch does. Andrew> (find . -name 'temp-*.db' | gcj-dbtool - -m $DB) This needs a corresponding gcj.texi patch. Tom From aph at redhat.com Thu Mar 31 06:01:07 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Mar 2005 07:01:07 +0100 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> Message-ID: <16971.37411.793787.473750@cuddles.cambridge.redhat.com> Tom Tromey writes: > >>>>> "Andrew" == Andrew Haley writes: > > Andrew> The right way to fix this is to have gcj-dbtool read a list of files > Andrew> from stdin, which is what this patch does. > Andrew> (find . -name 'temp-*.db' | gcj-dbtool - -m $DB) > > This needs a corresponding gcj.texi patch. Yes, but I'm waiting for feedback before I write it. Andrew. From tromey at redhat.com Thu Mar 31 18:29:19 2005 From: tromey at redhat.com (Tom Tromey) Date: 31 Mar 2005 11:29:19 -0700 Subject: [fedora-java] db merging script In-Reply-To: <16971.37411.793787.473750@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> Message-ID: >> This needs a corresponding gcj.texi patch. Andrew> Yes, but I'm waiting for feedback before I write it. I think the idea is sound, and needed. I think we should also support reading "find -0" output, i.e. '\0'-separated strings. That would let us support file names with spaces in them, and other oddities. Tom From aph at redhat.com Thu Mar 31 18:42:51 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Mar 2005 19:42:51 +0100 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> Message-ID: <16972.17579.880662.402733@cuddles.cambridge.redhat.com> Tom Tromey writes: > >> This needs a corresponding gcj.texi patch. > > Andrew> Yes, but I'm waiting for feedback before I write it. > > I think the idea is sound, and needed. > > I think we should also support reading "find -0" output, > i.e. '\0'-separated strings. That would let us support file names > with spaces in them, and other oddities. Okay. This is why I like to wait for comments... So we have an additional "-0" arg to dbtool? Andrew. From overholt at redhat.com Tue Mar 1 00:23:11 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 28 Feb 2005 19:23:11 -0500 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1109631005.3809.43.camel@nexus.verbum.private> References: <20050225164858.GH19850@redhat.com> <1109631005.3809.43.camel@nexus.verbum.private> Message-ID: <20050301002311.GA32669@redhat.com> * Colin Walters [2005-02-28 17:54]: > On Fri, 2005-02-25 at 11:48 -0500, Andrew Overholt wrote: > >Hi, > > > >I'm having some platform and other issues building these in the build > >system, so in the meantime if anyone wants to try what will become the new > >3.1-series RPMs: > > > >http://people.redhat.com/overholt/eclipse/rpms/ > > It'd be nice if you could run createrepo in there. I would, but the platform issues and build system issues are almost resolved so they'll be in rawhide later this week. > Anyways, I tried the RPMs and they seem to work pretty well (at least > "Team Synchronizing" doesn't crash which helps a lot :)). Cool. Andrew From maillist at friendVU.com Tue Mar 1 04:52:59 2005 From: maillist at friendVU.com (NetSQL) Date: Mon, 28 Feb 2005 22:52:59 -0600 Subject: [fedora-java] Sun to host Online Live Q/A Conference on Java Application Deployment (WebStart) tmrw March 1st(Boycoting?) Message-ID: Some of you are familiar with limits of applets. Web start (JNLP) allows for a more of a rich user interface then what we can do w/ Applets and DHTML. But deploying Java, applets and applications over the internet can be a challenge, including security warnings for registered applications and installation of current version of java by non-computer savvy users of our applications (can your father in law install and launch a WebStart application?) The lead of Sun?s Java deployment team and usability experts (Mike Albers -J2SE UI expert will be there hopefully) will answer your questions at 11 AM California time and guide you. Here are the details of how to participate for FREE: http://java.sun.com/developer/community/chat Above link should be enough. More? Some people are *boycotting* the chat conference because of issues since about 2001(it appears that a individuals at Sun believe that they should PERVENT deployment ? that they are doing us a favor, listed here: http://lopica.sourceforge.net/faq.html One important issue was picked up here (Scary screen for registered applications) http://forums.java.net/jive/thread.jspa?threadID=315&tstart=0 Sun?s stance is that it?s RFE and will not address it with wide deployment of Java 6 (aka Mustang) in 2007, and not on JRE 1.4.x updates, and will not do word smiting to clarify the application is registered. Another issue is deploying/update Java by corporate end users at organizations that have a LAN admin. Sample ?applets? sites: http://www.sandrasf.com/sites One example of RiA is (click to run it) http://www.blogbridge.com/install/weekly/blogbridge.jnlp MacroMedia and MS Longhorn also have RiA kits, you can read this as intro to RiA: http://www.theserverside.com/articles/article.tss?l=RiA RiA will be major part of SoA ? Services. Server side Java will be limited w/o Client Side Java. You want to hear deployment answers from Sun people in charge? OK, tmrw. 11AM CA time (2PM? NY time) .V From peter.backlund at home.se Tue Mar 1 15:08:00 2005 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 01 Mar 2005 16:08:00 +0100 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <20050225164858.GH19850@redhat.com> References: <20050225164858.GH19850@redhat.com> Message-ID: <1109689681.19651.11.camel@localhost.localdomain> fre 2005-02-25 klockan 11:48 -0500 skrev Andrew Overholt: >Hi, > >I'm having some platform and other issues building these in the build >system, so in the meantime if anyone wants to try what will become the new >3.1-series RPMs: > >http://people.redhat.com/overholt/eclipse/rpms/ First of all, I just want to say that I've run those rpms too, and they work well. Team Synchronization Perspective now works, which is a big improvment over 3.0.1. I'd like to know why gij is needed at all, when Eclipse is (supposedly) compiled into a native binary? I noticed that both .jar and .so are shipped with the eclipse-* rpms. Is there a document explaining this strategy anywhere, or could you elaborate a little on this here on the list? I'm guessing it has to do with run-time loading of bytecode plugins? /Peter Backlund From green at redhat.com Wed Mar 2 17:26:11 2005 From: green at redhat.com (Anthony Green) Date: Wed, 02 Mar 2005 09:26:11 -0800 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1109689681.19651.11.camel@localhost.localdomain> References: <20050225164858.GH19850@redhat.com> <1109689681.19651.11.camel@localhost.localdomain> Message-ID: <1109784371.5467.15.camel@localhost.localdomain> On Tue, 2005-03-01 at 16:08 +0100, Peter Backlund wrote: > I'd like to know why gij is needed at all, when Eclipse is (supposedly) > compiled into a native binary? gij is just a tiny program that loads the requested class and invokes its main() method. It doesn't have any additional interpreter code above and beyond what's already in libgcj.so. There are a couple of approaches you can take to building a native executable with gcj. [1] Link your program together using "gcj --main=foo.bar.MainClass". This pretty much mirrors the C or C++ way of thinking. You end up with an executable whose "main()" is foo.bar.MainClass.main(). [2] Build your classes into .so files and load them on demand. This is what we're doing for Eclipse and (hopefully) all of the java programs in Eclipse. We use the tiny "gij" program to kick things off. It turns out that it's much simpler to get existing java programs to run using this second approach. For one thing, you can use all of the existing wrapper shell scripts and programs (/usr/bin/eclipse, /usr/bin/ant, etc) instead of having to create/link a new main executable. There are no real downsides to this approach either. AG From green at redhat.com Wed Mar 2 17:38:04 2005 From: green at redhat.com (Anthony Green) Date: Wed, 02 Mar 2005 09:38:04 -0800 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1109784371.5467.15.camel@localhost.localdomain> References: <20050225164858.GH19850@redhat.com> <1109689681.19651.11.camel@localhost.localdomain> <1109784371.5467.15.camel@localhost.localdomain> Message-ID: <1109785084.5467.18.camel@localhost.localdomain> On Wed, 2005-03-02 at 09:26 -0800, Anthony Green wrote: > [2] Build your classes into .so files and load them on demand. This > is > what we're doing for Eclipse and (hopefully) all of the java > programs in Eclipse. Bah. Of course I meant "all of the java programs in Fedora Core". AG From overholt at redhat.com Wed Mar 2 21:12:47 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 2 Mar 2005 16:12:47 -0500 Subject: [fedora-java] Eclipse on s390{,x} Message-ID: <20050302211247.GD29000@redhat.com> Hi, Anyone interested in working on $subj? Since we're using the Eclipse compiler as our bytecode compiler, the java stack is incomplete on platforms on which we don't build Eclipse. I don't know how easy this will be, but I'm hoping it's just a matter of adding the required files (ie. duplicating the work of, say, ia64 for s390 and ppc64 for s390x) and adding sections where appropriate. Ideally we'd contribute this work back upstream to the Eclipse Foundation, but I think Ben Konrath mentioned something about doing that requiring machines or builds or something? Ben, any comments on that? I don't have any machines on which to test this work, and I'll do it myself if no one is interested, but I thought I'd open the door if anyone wants to give it a shot. We should probably have it ASAP so that our platform coverage is complete. Andrew From tromey at redhat.com Wed Mar 2 21:55:39 2005 From: tromey at redhat.com (Tom Tromey) Date: 02 Mar 2005 14:55:39 -0700 Subject: [fedora-java] Eclipse on s390{,x} In-Reply-To: <20050302211247.GD29000@redhat.com> References: <20050302211247.GD29000@redhat.com> Message-ID: Andrew> I don't know how easy this will be, but I'm hoping it's just a Andrew> matter of adding the required files (ie. duplicating the work Andrew> of, say, ia64 for s390 and ppc64 for s390x) and adding Andrew> sections where appropriate. Yeah, probably. In one version of the spec file I just ran sed over the source tree like s/ia64/... that worked pretty well. Andrew> Ideally we'd contribute this work back upstream to the Eclipse Andrew> Foundation, but I think Ben Konrath mentioned something about Andrew> doing that requiring machines or builds or something? Ben, Andrew> any comments on that? Since eclipse.org checks in the JNI libraries, they require a build machine for every platform they release on. Tom From bkonrath at redhat.com Wed Mar 2 23:15:46 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Wed, 02 Mar 2005 18:15:46 -0500 Subject: [fedora-java] Re: Eclipse on s390{,x} In-Reply-To: <20050302211247.GD29000@redhat.com> References: <20050302211247.GD29000@redhat.com> Message-ID: <1109805346.5081.6.camel@localhost.localdomain> Hi Andrew, On Wed, 2005-02-03 at 16:12 -0500, Andrew Overholt wrote: > Ideally we'd contribute this work back upstream to the Eclipse Foundation, > but I think Ben Konrath mentioned something about doing that requiring > machines or builds or something? Ben, any comments on that? Here are the upstream instructions: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-releng-home/contributingEclipsePorts.html?rev=HEAD&content-type=text/html I'm not sure if anybody is doing this right now, but I have seen references indicating that contributed builds will be available in the near future. Cheers, Ben From lien at absolutemotion.com Thu Mar 3 06:49:26 2005 From: lien at absolutemotion.com (Jennifer A. Clark) Date: Thu, 03 Mar 2005 06:49:26 +0000 Subject: [fedora-java] Adobe Acrobat 6.0 - very low price Message-ID: <3d8301c51fbd$7b694ea1$4680b726@absolutemotion.com> Get all the software you ever imagined for wholesale prices! 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 $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 Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... To view full list of products go: http://www.softuniverse.biz Best regards, Jennifer Clark _____________________________________________________ To change your mail preferences, go: http://www.softuniverse.biz/uns.htm _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From overholt at redhat.com Fri Mar 4 16:11:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 4 Mar 2005 11:11:14 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide Message-ID: <20050304161114.GA17011@redhat.com> Hi, Some exciting new stuff has landed in rawhide over the past few days: eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! If you don't have it already, try something like this: yum --enablerepo=development install \ eclipse-{bugzilla,jdt,changelog,pydev} java-1.4.2-gcj-compat{,-devel,-src} eclipse-changelog is a plugin written by Phil Muldoon to write ChangeLog entries from within Eclipse. This started off as one of those "scratching an itch" projects that has grown into something incredibly useful. Phil's doing all his development out of CVS at sources.redhat.com. Jeff Pound was kind enough to grace the world with his HTML wizardry (it's better than I could have done :) and has put some instructions and information here: http://sources.redhat.com/eclipse eclipse-bugzilla is a plugin to interact with Bugzilla systems (duh). It was started by IBM and is now being developed by Jeff Pound here at Red Hat. It's a really great plugin and everyone has lots of cool plans for it. There's still lots of cool additions and integration with other plugins (like the ChangeLog plugin, for example) that could be done, so check it out from CVS (see URL above for instructions) and send Jeff patches and/or ideas. I've put some screenshots of the ChangeLog and Bugzilla plugins (and this message) here: http://overholt.ca/wp eclipse-pydev is the PyDev plugin (http://pydev.sourceforge.net/) packaged up. I haven't had much time to play with it myself, but it looks great and I know some python developers out there are excited to get started with it. As usual, if you find bugs, please file them in RH bugzilla under Product: Fedora Core, Version: devel, Component: eclipse. In other news, Michael Koch has started an effort to close the gap between Eclipse and projects that use the autotools. He's calling it antiauto and you can check it out here: http://www.kaffe.org/~mkoch/antiauto/ We've talked about doing an autotools plugin for a long time, but this fills the gap nicely in the meantime. Enjoy! Andrew From green at redhat.com Fri Mar 4 17:50:16 2005 From: green at redhat.com (Anthony Green) Date: Fri, 04 Mar 2005 09:50:16 -0800 Subject: [fedora-java] subversion java bindings Message-ID: <1109958617.7344.30.camel@localhost.localdomain> With a little subversion.spec tweaking, I have the rawhide subversion java bindings (svn-javahl.jar) and JNI library (libsvnjavahl-1.so) building out of the box right now. Nothing currently in FC depends on this library since the current spec file disables it, but I think it makes sense to turn it on since the Eclipse svn plugin uses it, as well various servlets people have developed and are using. It wants to install the jar file in /usr/lib/svn-javahl. Should we move this to /usr/share/java? That seems like the right thing to do. I suppose I can figure out the native build bits once I see how other packages are managing it. I've attached the changes for review... AG -------------- next part -------------- A non-text attachment was scrubbed... Name: subversion-java-spec.patch Type: text/x-patch Size: 3323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: subversion-java-ok.patch Type: text/x-patch Size: 527 bytes Desc: not available URL: From jorton at redhat.com Fri Mar 4 18:14:54 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 4 Mar 2005 18:14:54 +0000 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <1109958617.7344.30.camel@localhost.localdomain> References: <1109958617.7344.30.camel@localhost.localdomain> Message-ID: <20050304181454.GA999@redhat.com> On Fri, Mar 04, 2005 at 09:50:16AM -0800, Anthony Green wrote: > With a little subversion.spec tweaking, I have the rawhide subversion > java bindings (svn-javahl.jar) and JNI library (libsvnjavahl-1.so) > building out of the box right now. Great! This needs new BuildRequires too, presumably; gcc-java >= 4.0.0, or something? > Nothing currently in FC depends on this library since the current spec > file disables it, but I think it makes sense to turn it on since the > Eclipse svn plugin uses it, as well various servlets people have > developed and are using. Yup, we've had few requests for this. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135049 joe From green at redhat.com Fri Mar 4 18:29:42 2005 From: green at redhat.com (Anthony Green) Date: Fri, 04 Mar 2005 10:29:42 -0800 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <20050304181454.GA999@redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> Message-ID: <1109960982.7344.38.camel@localhost.localdomain> On Fri, 2005-03-04 at 18:14 +0000, Joe Orton wrote: > On Fri, Mar 04, 2005 at 09:50:16AM -0800, Anthony Green wrote: > > With a little subversion.spec tweaking, I have the rawhide subversion > > java bindings (svn-javahl.jar) and JNI library (libsvnjavahl-1.so) > > building out of the box right now. > > Great! This needs new BuildRequires too, presumably; gcc-java >= 4.0.0, > or something? There's a BuildPreReq for java-1.4.2-gcj-compat-devel which pulls in the right gcj bits. AG From ziga.mahkovec at klika.si Fri Mar 4 20:07:03 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 04 Mar 2005 21:07:03 +0100 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <20050304161114.GA17011@redhat.com> References: <20050304161114.GA17011@redhat.com> Message-ID: <1109966823.8252.9.camel@localhost> On Fri, 2005-03-04 at 11:11 -0500, Andrew Overholt wrote: > Some exciting new stuff has landed in rawhide over the past few days: > eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! If you don't have > it already, try something like this: > > yum --enablerepo=development install \ > eclipse-{bugzilla,jdt,changelog,pydev} java-1.4.2-gcj-compat{,-devel,-src} On a FC3 system with the latest gcc from rawhide (4.0.0-0.30), I get: $ yum --enablerepo=development install java-1.4.2-gcj-compat{,-devel} [...] Error: Missing Dependency: libgcj.so.5 is needed by package ecj ecj-3.1-0.M4.5 wasn't rebuilt so it probably uses the old %{gccsuffix}? -- Ziga From overholt at redhat.com Fri Mar 4 20:15:16 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 4 Mar 2005 15:15:16 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1109966823.8252.9.camel@localhost> References: <20050304161114.GA17011@redhat.com> <1109966823.8252.9.camel@localhost> Message-ID: <20050304201516.GI16343@redhat.com> * Ziga Mahkovec [2005-03-04 15:11]: > On Fri, 2005-03-04 at 11:11 -0500, Andrew Overholt wrote: > > Some exciting new stuff has landed in rawhide over the past few days: > > eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! If you don't have > > it already, try something like this: > > > > yum --enablerepo=development install \ > > eclipse-{bugzilla,jdt,changelog,pydev} java-1.4.2-gcj-compat{,-devel,-src} > > On a FC3 system with the latest gcc from rawhide (4.0.0-0.30), I get: > > $ yum --enablerepo=development install java-1.4.2-gcj-compat{,-devel} > [...] > Error: Missing Dependency: libgcj.so.5 is needed by package ecj > > > ecj-3.1-0.M4.5 wasn't rebuilt so it probably uses the old > %{gccsuffix}? ecj needs to go away, but we can't get rid of it until eclipse builds on all the platforms like it does. Try something this: rpm -e gcc-g77 libgcj4{,-devel} gcc4{,-java} java-1.4.2-gcj4-compat{,-devel} yum --enablerepo=development install eclipse-ecj yum --enablerepo=development install java-1.4.2-gcj-compat{,-devel} yum --enablerepo=development install eclipse-{jdt,bugzilla,changelog} Let me know how that goes. Andrew From green at redhat.com Sat Mar 5 02:11:06 2005 From: green at redhat.com (Anthony Green) Date: Fri, 04 Mar 2005 18:11:06 -0800 Subject: [fedora-java] libgcj javadoc rpm Message-ID: <1109988666.7344.67.camel@localhost.localdomain> I just experimented with creating a noarch RPM for libgcj HTML javadoc. It uses gjdoc to generate HTML from the src.zip rawhide libgcj installs. I don't know if this is the best way to go about it, but it was convenient. I've placed the SRPM here for comment: http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm [3k] The RPM itself is 16MB, and it seems I'm out of space on people.redhat.com. Comments and suggestions welcome.... Thanks, AG From pmuldoon at redhat.com Sat Mar 5 16:54:31 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sat, 05 Mar 2005 10:54:31 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <20050304161114.GA17011@redhat.com> References: <20050304161114.GA17011@redhat.com> Message-ID: <1110041671.7422.31.camel@localhost.localdomain> > Some exciting new stuff has landed in rawhide over the past few days: > eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! Also, as of last night, eclipse-cdt (C/C++ Development Environment for Eclipse) has been built and added. In addition, again as of last night, all of the plug-ins above have been built for the x86_64 architecture. > If you don't have it already, try something like this: > > yum --enablerepo=development install \ > eclipse-{bugzilla,jdt,changelog,pydev} java-1.4.2-gcj-compat{,-devel,-src} eclipse-{bugzilla,jdt,changelog,pydev,cdt} Regards Phil Muldoon From mlists at juma.me.uk Sat Mar 5 17:21:05 2005 From: mlists at juma.me.uk (Ismael Juma) Date: Sat, 05 Mar 2005 17:21:05 +0000 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110041671.7422.31.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> Message-ID: <4229EA81.5010904@juma.me.uk> Phil Muldoon wrote: > [snip] > Also, as of last night, eclipse-cdt (C/C++ Development Environment for > Eclipse) has been built and added. > [snip] Nice. :) According to the CDT Plan, CDT 3.0 Milestone 5 will be out on the 14th of March. As you are probably aware, this is the first Milestone for the 3.0 series but they named it M5 because it runs on Eclipse 3.1 M5. Are there plans to have this version on rawhide once it's out, or is the plan to have CDT 2.0.2 in FC4? Keep up the good work and thanks in advance. Regards, Ismael From pmuldoon at redhat.com Sat Mar 5 18:24:17 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sat, 05 Mar 2005 12:24:17 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <4229EA81.5010904@juma.me.uk> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <4229EA81.5010904@juma.me.uk> Message-ID: <1110047058.7422.45.camel@localhost.localdomain> On Sat, 2005-03-05 at 17:21 +0000, Ismael Juma wrote: > Phil Muldoon wrote: > > [snip] > > Also, as of last night, eclipse-cdt (C/C++ Development Environment for > > Eclipse) has been built and added. > > [snip] > > Nice. :) > > According to the CDT Plan, CDT 3.0 Milestone 5 will be out on the 14th > of March. As you are probably aware, this is the first Milestone for the > 3.0 series but they named it M5 because it runs on Eclipse 3.1 M5. Are > there plans to have this version on rawhide once it's out, or is the > plan to have CDT 2.0.2 in FC4? We put in 2.0.2 because that was the best option for the Fedora Core 4 - Test 1 deadline (we already had it packaged for RHEL, we just had to apply the native build smarts for FC4). We did try to get CDT 2.1 in for Test 1, but build bugs prevented us. However those are (mostly) solved now, and we have every intention of upgrading the CDT, if not to CDT 3.0, at least to 2.1 soon. Though as you mention that the CDT 3.0 M5 build is partnered to the Eclipse 3.1 M5 build, there is no barrier to us putting it in FC4 as long as it is fairly sensible/stable. I'll go look at the CDT 3.0 on Monday, and see how it does when we natively build it. I'll also go look at how the CDT 3.0 and Eclipse 3.1 schedules compare at the CDT site. Regards Phil > Keep up the good work and thanks in advance. > > Regards, > Ismael > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From ziga.mahkovec at klika.si Sat Mar 5 20:44:11 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Sat, 05 Mar 2005 21:44:11 +0100 Subject: [fedora-java] Automated Eclipse tests Message-ID: <1110055451.15721.13.camel@localhost> I've been playing with this but wanted to check here first: has anyone tried running the automated Eclipse tests against the native builds? I'm referring to the these tests: http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/automatedtesting.html http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/testResults.php -- Ziga From green at redhat.com Sun Mar 6 02:37:05 2005 From: green at redhat.com (Anthony Green) Date: Sat, 05 Mar 2005 18:37:05 -0800 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110041671.7422.31.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> Message-ID: <1110076625.15251.2.camel@localhost.localdomain> On Sat, 2005-03-05 at 10:54 -0600, Phil Muldoon wrote: > > Some exciting new stuff has landed in rawhide over the past few days: > > eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! > > Also, as of last night, eclipse-cdt (C/C++ Development Environment for > Eclipse) has been built and added. Hey Phil - are there any plans to package the GEF plugin? I'd like to use this Eclipse for my project, but it requires GEF. I looked at how you packaged the CDT plugin but I don't understand how you put the source tree together. AG From pmuldoon at redhat.com Sun Mar 6 04:04:02 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sat, 05 Mar 2005 22:04:02 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110076625.15251.2.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> Message-ID: <1110081842.5776.37.camel@localhost.localdomain> > Hey Phil - are there any plans to package the GEF plugin? I'd like to > use this Eclipse for my project, but it requires GEF. Not planned for Core, but I think it would be a great candidate for Extras. The GEF plug-in is already packaged for RHEL, so it would only be a matter of adding the native smarts to the GEF rpm. We were really limited by space in what we could put in Core :{ > I looked at how you packaged the CDT plugin but I don't understand how > you put the source tree together. The source tree is basically the releng plugin that all eclipse.org projects provide, with pre-fetched source. So the CDT group provide their own releng plugin, and we use it. All Eclipse hosted projects use this approach. You can find details on releng plug-ins here: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.releng.basebuilder/readme.html?rev=HEAD&content-type=text/html We have to make some alterations to the assumptions that those releng plug-ins make (they make the assumption that it is okay to cvs co -r {tag} the code right at build time - we disagree, due to various security/code quality/infrastructure issues); they also attempt to download an upstream Eclipse SDK to build against - again we disagreed and disabled. These changes are applied as a patch against the sdk/customTargets.xml, and the platform/customTargets.xml So basically we pre-fetch the CDT code (in results/) and disable cvs access in the releng plugin. Then we invoke a headless Eclipse via the PDE build scripts (See link above) which will compile the code and deliver a zip or tarball depending on platform. Next we take that tar ball, extract any jars and build them to .so. We build a database of each jar (actually classes in each jar) to -> .so and register them in a database with gcj-dbtool. Then at post, as each plugin is installed, we merge that plugin database with the main eclipse.db so the corresponding .so can be loaded for whatever .class is being executed. Links to the webcvs version of the CDT releng plugin are here: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-releng/? cvsroot=Tools_Project We've been debating this build approach (the pde builds) for awhile. Is it is good approach? That's up for debate; we've talked about changing it. Ben Konrath has been experimenting with a different build approach. Once the dust settles on test 1, this would be a good place to debate alternate build methods that a) don't stray too far away from the upstream build process and make it painful to integrate; b) allow friendlier third party building outside of rpm that does not require a week's learning about the pde build method. Regards Phil From bkonrath at redhat.com Sun Mar 6 06:36:36 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Sun, 6 Mar 2005 01:36:36 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110081842.5776.37.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> Message-ID: <20050306063636.GA26804@town.toronto.redhat.com> Hi Phil/Anthony, On Sat, 2005-05-03 at 22:04 -0600, Phil Muldoon wrote: > We have to make some alterations to the assumptions that those releng > plug-ins make (they make the assumption that it is okay to cvs co -r > {tag} the code right at build time - we disagree, due to various > security/code quality/infrastructure issues); they also attempt to > download an upstream Eclipse SDK to build against - again we disagreed > and disabled. These changes are applied as a patch against the > sdk/customTargets.xml, and the platform/customTargets.xml Just one small correction, an Eclipse releng plugin will not try to download the SDK. You are expected to have an SDK downloaded and unpacked before you start a build. So the only thing that needs to be disabled is the fetch target of the releng build.xml. > We've been debating this build approach (the pde builds) for awhile. Is > it is good approach? That's up for debate; we've talked about changing > it. Ben Konrath has been experimenting with a different build approach. > Once the dust settles on test 1, this would be a good place to debate > alternate build methods that a) don't stray too far away from the > upstream build process and make it painful to integrate; b) allow > friendlier third party building outside of rpm that does not require a > week's learning about the pde build method. I have a solution already in mind but it will take some upstream changes. I've done a bit of work towards this but I haven't had time to finish it off. If it's important, I can try bugging the Eclipse people again and see if I can get some traction. In case your interested, here's how I generated the cdt 2.1 tarball (unfortunately it doesn't build against eclipse 3.1M5a): % mkdir temp && cd temp % /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse % mkdir home % cvs -d :pserver:anonymous at dev.eclipse.org:/home/tools co -r CDT_2_1 \ org.eclipse.cdt-releng/org.eclipse.cdt.releng % cd org.eclipse.cdt-releng/org.eclipse.cdt.releng % sed --in-place 's/HEAD/CDT_2_1/' maps/cdt.map % java -cp ../../SDK/startup.jar org.eclipse.core.launcher.Main \ -application org.eclipse.ant.core.antRunner \ -buildfile build.xml \ -Dpde.build.scripts=../../SDK/plugins/org.eclipse.pde.build_3.1.0/scripts \ -Duser.home=../../home \ -DjavacFailOnError=true \ -DdontUnzip=true \ -DmapVersionTag=CDT_2_1 \ -v fetch % cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz org.eclipse.cdt.releng This method should work with other plugins on eclipse.org. If you have any question, feel free to ping me. Cheers, Ben From green at redhat.com Sun Mar 6 06:53:05 2005 From: green at redhat.com (Anthony Green) Date: Sat, 05 Mar 2005 22:53:05 -0800 Subject: [fedora-java] A free jta package Message-ID: <1110091985.15251.31.camel@localhost.localdomain> Here's another SRPM for FC consideration.... http://people.redhat.com/green/libgcj-jta-4.0.0-1.src.rpm This package Provides "jta", which is one of the nosrc RPMS in jpackage that many other things depend on. libgcj (and GNU Classpath) already include all of the classes and interfaces found in jta, but not as a separate .jar file. The separate jar file is important because packages depending on jta usually run "build-classpath jta" to find the jta jar file. The SRPM actually contains no source code. It simply extracts the javax.transaction classes from libgcj-4.0.0.jar and zips them up into libgcj-jta-4.0.0.jar (with a symlink to jta.jar). We create a simple noarch RPM since gij will use the native versions in libgcj anyway. This package should satisfy the needs of all jta users (even for non-gcj alternatives). Could somebody please review the spec file and slip it into FC? tomcat5 depends on it, among other things. AG From green at redhat.com Sun Mar 6 08:50:19 2005 From: green at redhat.com (Anthony Green) Date: Sun, 06 Mar 2005 00:50:19 -0800 Subject: [fedora-java] java-gcj-compat patch for extdirs support Message-ID: <1110099019.15251.37.camel@localhost.localdomain> Hey Tom, java-gcj-compat's javac currently ignores the extensions directory (as we've both discovered). The Eclipse compiler doesn't have an extensions directory option either, so we have to expand it manually. This is similar to what Eclipse's JDTCompilerAdapter class does for ant. AG -------------- next part -------------- A non-text attachment was scrubbed... Name: extdirs.patch Type: text/x-patch Size: 4235 bytes Desc: not available URL: From green at redhat.com Sun Mar 6 10:42:59 2005 From: green at redhat.com (Anthony Green) Date: Sun, 06 Mar 2005 02:42:59 -0800 Subject: [fedora-java] Using the natively-built Eclipse compiler Message-ID: <1110105522.15251.49.camel@localhost.localdomain> ant and javac aren't currently using the natively-built Eclipse compiler. We need to add something like the following to /usr/bin/ant in order to pick up the .so files: # diff -c /usr/bin/ant~ /usr/bin/ant *** /usr/bin/ant~ 2005-03-05 13:13:05.000000000 -0800 --- /usr/bin/ant 2005-03-06 02:19:55.000000000 -0800 *************** *** 230,235 **** --- 230,236 ---- if $JAVACMD -version 2>&1 | grep -q "gcj"; then if [ -f /usr/share/java/jdtcore.jar ]; then LOCALCLASSPATH="$LOCALCLASSPATH:/usr/share/java/jdtcore.jar" + ANT_OPTS="$ANT_OPTS -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db" fi fi (and something similar to java-gcj-compat's javac.in, see attached patch) This will shave minutes off of the build times for some packages. I forget what the plan is wrt the db. Maybe we'll have a global one. In any case, this will do in the meanwhile. (gbenson: could you please stick the above in apache-ant-javac-ecj.patch? This is where we really need it - thanks!) AG -------------- next part -------------- A non-text attachment was scrubbed... Name: use-native-ecj.patch Type: text/x-patch Size: 716 bytes Desc: not available URL: From joe at galway.net Sun Mar 6 16:18:29 2005 From: joe at galway.net (Joe Desbonnet) Date: Sun, 06 Mar 2005 16:18:29 +0000 Subject: [fedora-java] Java library to query/create RPM packages Message-ID: <422B2D55.4020202@galway.net> Is there any Java library that enables querying and creation of RPMs? Thanks, Joe. From pmuldoon at redhat.com Sun Mar 6 17:08:46 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sun, 06 Mar 2005 11:08:46 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <20050306063636.GA26804@town.toronto.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> Message-ID: <1110128926.5913.6.camel@localhost.localdomain> On Sun, 2005-03-06 at 01:36 -0500, Ben Konrath wrote: > Hi Phil/Anthony, > > On Sat, 2005-05-03 at 22:04 -0600, Phil Muldoon wrote: > > We have to make some alterations to the assumptions that those releng > > plug-ins make (they make the assumption that it is okay to cvs co -r > > {tag} the code right at build time - we disagree, due to various > > security/code quality/infrastructure issues); they also attempt to > > download an upstream Eclipse SDK to build against - again we disagreed > > and disabled. These changes are applied as a patch against the > > sdk/customTargets.xml, and the platform/customTargets.xml > > Just one small correction, an Eclipse releng plugin will not try to > download the SDK. You are expected to have an SDK downloaded and > unpacked before you start a build. So the only thing that needs to be > disabled is the fetch target of the releng build.xml. Some do, the CDT won't. Here is an example of a target in the GEF customTargets.xml: > It's was just an example of an assumption these scripts can make, though reading back in the mail I do see to making the case that all of them make them, so point taken ;) > > We've been debating this build approach (the pde builds) for awhile. Is > > it is good approach? That's up for debate; we've talked about changing > > it. Ben Konrath has been experimenting with a different build approach. > > Once the dust settles on test 1, this would be a good place to debate > > alternate build methods that a) don't stray too far away from the > > upstream build process and make it painful to integrate; b) allow > > friendlier third party building outside of rpm that does not require a > > week's learning about the pde build method. > > I have a solution already in mind but it will take some upstream > changes. I've done a bit of work towards this but I haven't had time to > finish it off. If it's important, I can try bugging the Eclipse people > again and see if I can get some traction. I'd like to try and see if there are other solutions from the list out there, before we move on to the Eclipse fellas. Who knows, someone might already have the perfect nirvana of build systems for releng plugins just waiting out there ;) Regards Phil From Nicolas.Mailhot at laPoste.net Sun Mar 6 17:44:41 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 06 Mar 2005 18:44:41 +0100 Subject: [fedora-java] Java library to query/create RPM packages In-Reply-To: <422B2D55.4020202@galway.net> References: <422B2D55.4020202@galway.net> Message-ID: <1110131087.26618.18.camel@rousalka.dyndns.org> Le dimanche 06 mars 2005 ? 16:18 +0000, Joe Desbonnet a ?crit : > Is there any Java library that enables querying and creation of RPMs? You can call rpm & build-classpath from ant. One of the (many) reasons build-classpath returns a well-formed java path is to allow result injection in ant (via path elements) Once you've got system-wide jar resolution you can generate specs dynamically via xslt. I wouldn't advise it though - it's a great way to shoot yourself in the foot. The easiest way is always to have a working ant build and pack the result in an rpm via an external spec file Regards, -- Nicolas Mailhot -------------- 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 talios at gmail.com Sun Mar 6 21:45:30 2005 From: talios at gmail.com (Mark Derricutt) Date: Mon, 7 Mar 2005 10:45:30 +1300 Subject: [fedora-java] Java library to query/create RPM packages In-Reply-To: <422B2D55.4020202@galway.net> References: <422B2D55.4020202@galway.net> Message-ID: <5184347f050306134547ece9f6@mail.gmail.com> Take alook at jRPM - http://jrpm.sourceforge.net Mark On Sun, 06 Mar 2005 16:18:29 +0000, Joe Desbonnet wrote: > Is there any Java library that enables querying and creation of RPMs? > Thanks, > Joe. > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > From tromey at redhat.com Sun Mar 6 23:50:02 2005 From: tromey at redhat.com (Tom Tromey) Date: 06 Mar 2005 16:50:02 -0700 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110105522.15251.49.camel@localhost.localdomain> References: <1110105522.15251.49.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> I forget what the plan is wrt the db. Maybe we'll have a global one. Yeah, the current consensus is a global one. The precise details of how it will be managed haven't been worked out. I suppose I ought to add this to libgcj configury soon. Tom From zbalevsky at limepeer.com Mon Mar 7 00:15:34 2005 From: zbalevsky at limepeer.com (zbalevsky) Date: Sun, 06 Mar 2005 19:15:34 -0500 Subject: [fedora-java] Self Introduction - Zlatin Balevsky Message-ID: <422B9D26.5020206@limepeer.com> Greetings, I'm a developer at Lime Wire LLC (the gnutella p2p client) and an avid Fedora fan. Although our product uses Swing heavily and hence won't be able to run on a free jvm anytime soon, I'm greatly interrested in helping liberate as much of java as possible. I'm specifically interrested in the gcj port of Eclipse and will most likely be contribute to that by testing and whatnot. Best Regards, Zlatin Balevsky From fitzsim at redhat.com Mon Mar 7 02:25:58 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 06 Mar 2005 21:25:58 -0500 Subject: [fedora-java] Re: java-gcj-compat patch for extdirs support In-Reply-To: <1110099019.15251.37.camel@localhost.localdomain> References: <1110099019.15251.37.camel@localhost.localdomain> Message-ID: <1110162358.3227.5.camel@rh-ibm-t41> On Sun, 2005-03-06 at 00:50 -0800, Anthony Green wrote: > Hey Tom, > > java-gcj-compat's javac currently ignores the extensions directory (as > we've both discovered). The Eclipse compiler doesn't have an > extensions directory option either, so we have to expand it manually. > This is similar to what Eclipse's JDTCompilerAdapter class does for ant. > Great, thanks! I just hit this problem myself tonight. I'll incorporate this into java-gcj-compat tomorrow. Tom From fitzsim at redhat.com Mon Mar 7 02:30:28 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 06 Mar 2005 21:30:28 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110105522.15251.49.camel@localhost.localdomain> References: <1110105522.15251.49.camel@localhost.localdomain> Message-ID: <1110162628.3227.11.camel@rh-ibm-t41> On Sun, 2005-03-06 at 02:42 -0800, Anthony Green wrote: > ant and javac aren't currently using the natively-built Eclipse > compiler. > javac in the latest java-gcj-compat does use the natively-built compiler actually, but it uses the old ABI and the gcjlib:// class loading mechanism. This patch is a better idea so I'll use it instead. Note that these changes wouldn't be required if we had a system-wide dbtool database. We really need to get support for this into libgcj's configury. Tom > We need to add something like the following to /usr/bin/ant in order to > pick up the .so files: > > # diff -c /usr/bin/ant~ /usr/bin/ant > *** /usr/bin/ant~ 2005-03-05 13:13:05.000000000 -0800 > --- /usr/bin/ant 2005-03-06 02:19:55.000000000 -0800 > *************** > *** 230,235 **** > --- 230,236 ---- > if $JAVACMD -version 2>&1 | grep -q "gcj"; then > if [ -f /usr/share/java/jdtcore.jar ]; then > LOCALCLASSPATH="$LOCALCLASSPATH:/usr/share/java/jdtcore.jar" > + ANT_OPTS="$ANT_OPTS -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db" > fi > fi > > (and something similar to java-gcj-compat's javac.in, see attached patch) > > This will shave minutes off of the build times for some packages. > > I forget what the plan is wrt the db. Maybe we'll have a global one. > In any case, this will do in the meanwhile. > > (gbenson: could you please stick the above in apache-ant-javac-ecj.patch? This is > where we really need it - thanks!) > > AG > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From tromey at redhat.com Sun Mar 6 23:50:02 2005 From: tromey at redhat.com (Tom Tromey) Date: 06 Mar 2005 16:50:02 -0700 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110105522.15251.49.camel@localhost.localdomain> References: <1110105522.15251.49.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> I forget what the plan is wrt the db. Maybe we'll have a global one. Yeah, the current consensus is a global one. The precise details of how it will be managed haven't been worked out. I suppose I ought to add this to libgcj configury soon. Tom From bkonrath at redhat.com Mon Mar 7 05:40:21 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Mon, 07 Mar 2005 00:40:21 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110128926.5913.6.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> Message-ID: <1110174021.7119.49.camel@town.toronto.redhat.com> On Sun, 2005-03-06 at 11:08 -0600, Phil Muldoon wrote: > Some do, the CDT won't. Here is an example of a target in the GEF > customTargets.xml: > > > > > > > > Oh sorry, my mistake, I haven't encountered this yet. This is good to know though. > I'd like to try and see if there are other solutions from the list out > there, before we move on to the Eclipse fellas. Who knows, someone might > already have the perfect nirvana of build systems for releng plugins > just waiting out there ;) Ok, but I'm not sure who else would have the same build requirements (besides other GNU/Linux distributors). Of course, anyone who has ideas is welcome to speak up :) Here is a list of the build methods that I've come up with, as well as my proposed solution (which I just updated about five minutes ago): http://people.redhat.com/bkonrath/eclipse/buildable-source-zips.html There is also a thread that I started on eclipse.org about this but you'll need to register if you want to read it: http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg02967.html Cheers, Ben From aluchko at redhat.com Mon Mar 7 07:40:36 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Mon, 07 Mar 2005 00:40:36 -0700 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <1110055451.15721.13.camel@localhost> References: <1110055451.15721.13.camel@localhost> Message-ID: <1110181236.28220.4.camel@localhost.localdomain> On Sat, 2005-03-05 at 21:44 +0100, Ziga Mahkovec wrote: > I've been playing with this but wanted to check here first: has anyone > tried running the automated Eclipse tests against the native builds? > > I'm referring to the these tests: > > http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/automatedtesting.html > http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/testResults.php > I'm in the process of finalizing a system to run the automated eclipse tests on our native builds. Right now it's down to a couple kinks in the test system and getting some kind of public server set up to show the results. The system should be ready in the next few days though I haven't looked into the public server yet (will start looking around Monday). Aaron From nicolas.mailhot at laposte.net Mon Mar 7 08:25:07 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Mar 2005 09:25:07 +0100 (CET) Subject: [fedora-java] Self Introduction - Zlatin Balevsky In-Reply-To: <422B9D26.5020206@limepeer.com> References: <422B9D26.5020206@limepeer.com> Message-ID: <14753.192.54.193.137.1110183907.squirrel@rousalka.dyndns.org> On Lun 7 mars 2005 1:15, zbalevsky a ?crit : > Greetings, > > I'm a developer at Lime Wire LLC (the gnutella p2p client) and an avid > Fedora fan. Although our product uses Swing heavily and hence won't be > able to run on a free jvm anytime soon, I'm greatly interrested in > helping liberate as much of java as possible. I think there are some Limewire bits in JPackage (probably outdated). Cleaning up the packages would help future Fedora inclusion (as long as it's closed JVM only it's JPackage stuff) Regards, -- Nicolas Mailhot From ziga.mahkovec at klika.si Mon Mar 7 15:17:48 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Mon, 07 Mar 2005 16:17:48 +0100 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <1110181236.28220.4.camel@localhost.localdomain> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> Message-ID: <1110208669.10581.11.camel@localhost> On Mon, 2005-03-07 at 00:40 -0700, Aaron Luchko wrote: > I'm in the process of finalizing a system to run the automated eclipse > tests on our native builds. Right now it's down to a couple kinks in > the test system and getting some kind of public server set up to show > the results. The system should be ready in the next few days though I > haven't looked into the public server yet (will start looking around > Monday). Great, thanks. I ran a subset of these tests and gcj did pretty well. Might be interesting to run the tests against a non-free JRE as well, for performance comparison. -- Ziga From pmuldoon at redhat.com Mon Mar 7 19:06:08 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 07 Mar 2005 13:06:08 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110174021.7119.49.camel@town.toronto.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> Message-ID: <1110222368.6220.39.camel@localhost.localdomain> > > Here is a list of the build methods that I've come up with, as well as > my proposed solution (which I just updated about five minutes ago): > > http://people.redhat.com/bkonrath/eclipse/buildable-source-zips.html I liked your proposed solution. I don't think adding the native step to the build.xml is a large burden, especially if there are already patches generated and pushed upstream. We can add those to the Fedora Eclipse while we wait. The releng plug-in being necessary is not a huge deal either. They are pretty standard now, and don't require much knowledge investment to get going. Also eclipse.org has standardized on the releng build method, so it should be in our best interest that all plug-ins that ship in Fedora Extras/Core should have one. If there are third party authors out there that don't have them, we can always assist as necessary. Anybody else in the community have any comments on this, or other proposals? I'd like to get the ball rolling on this, and we can maybe get the implementation working before May and the final Fedora 4 release. Regards Phil Muldoon From aluchko at redhat.com Mon Mar 7 22:20:38 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Mon, 07 Mar 2005 15:20:38 -0700 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <1110208669.10581.11.camel@localhost> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> Message-ID: <1110234039.5456.7.camel@localhost.localdomain> On Mon, 2005-03-07 at 16:17 +0100, Ziga Mahkovec wrote: > On Mon, 2005-03-07 at 00:40 -0700, Aaron Luchko wrote: > > I'm in the process of finalizing a system to run the automated eclipse > > tests on our native builds. Right now it's down to a couple kinks in > > the test system and getting some kind of public server set up to show > > the results. The system should be ready in the next few days though I > > haven't looked into the public server yet (will start looking around > > Monday). > > Great, thanks. I ran a subset of these tests and gcj did pretty well. > Might be interesting to run the tests against a non-free JRE as well, > for performance comparison. I've been pitting them up against the IBM and BEA jvms we have for the stuff we ship with RHEL-3, the last time I successfully ran them was with the last 3.0 we had, it didn't fare too badly other than debugging (no JDWP) though our stuff has changed quite a bit since then. Aaron From dpaun at rogers.com Tue Mar 8 03:15:04 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Mon, 7 Mar 2005 22:15:04 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <1110234039.5456.7.camel@localhost.localdomain> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> Message-ID: <20050308031504.GJ29253@rogers.com> On Mon, Mar 07, 2005 at 03:20:38PM -0700, Aaron Luchko wrote: > I've been pitting them up against the IBM and BEA jvms we have for the > stuff we ship with RHEL-3, the last time I successfully ran them was > with the last 3.0 we had, it didn't fare too badly other than debugging > (no JDWP) though our stuff has changed quite a bit since then. "didn't fare too badly" = faster, slower, about the same? Any hard numbers? -- Dimi. From jorton at redhat.com Tue Mar 8 11:00:12 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 8 Mar 2005 11:00:12 +0000 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <1109960982.7344.38.camel@localhost.localdomain> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> Message-ID: <20050308110012.GC2587@redhat.com> On Fri, Mar 04, 2005 at 10:29:42AM -0800, Anthony Green wrote: > On Fri, 2005-03-04 at 18:14 +0000, Joe Orton wrote: > > On Fri, Mar 04, 2005 at 09:50:16AM -0800, Anthony Green wrote: > > > With a little subversion.spec tweaking, I have the rawhide subversion > > > java bindings (svn-javahl.jar) and JNI library (libsvnjavahl-1.so) > > > building out of the box right now. > > > > Great! This needs new BuildRequires too, presumably; gcc-java >= 4.0.0, > > or something? > > There's a BuildPreReq for java-1.4.2-gcj-compat-devel which pulls in the > right gcj bits. Ah, sorry, I missed that. I committed this with a change to use the jdk_path macro which was unused otherwise. It built on i386 but didn't on at least ia64: + make javahl /usr/lib/jvm/java-1.4.2-gcj/bin/javac -d subversion/bindings/java/javahl/classes -classpath ... Missing resource : org/eclipse/jdt/internal/compiler/batch/messages.properties for locale en_US Exception in thread "main" java.lang.ExceptionInInitializerError <> Caused by: java.util.MissingResourceException: Bundle org.eclipse.jdt.internal.compiler.batch.messages not found <> make: *** [javahl-java] Error 1 error: Bad exit status from /usr/src/build/536680-ia64/install-tmp/rpm-tmp.80923 (%build) is that a compiler bug? joe From green at redhat.com Tue Mar 8 12:27:46 2005 From: green at redhat.com (Anthony Green) Date: Tue, 08 Mar 2005 04:27:46 -0800 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <20050308110012.GC2587@redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> Message-ID: <1110284867.5352.4.camel@localhost.localdomain> On Tue, 2005-03-08 at 11:00 +0000, Joe Orton wrote: > It built on i386 but didn't on at least ia64: > > + make javahl > /usr/lib/jvm/java-1.4.2-gcj/bin/javac -d > subversion/bindings/java/javahl/classes -classpath ... > Missing resource : > org/eclipse/jdt/internal/compiler/batch/messages.properties for locale > en_US > Exception in thread "main" java.lang.ExceptionInInitializerError > <> > Caused by: java.util.MissingResourceException: Bundle > org.eclipse.jdt.internal.compiler.batch.messages not found > <> > make: *** [javahl-java] Error 1 > error: Bad exit status from > /usr/src/build/536680-ia64/install-tmp/rpm-tmp.80923 (%build) > This is troubling. This looks like the Eclipse compiler is broken on ia64. But surely we're using that compiler to build other things right now. Does anybody here know? AG From green at redhat.com Tue Mar 8 14:37:09 2005 From: green at redhat.com (Anthony Green) Date: Tue, 08 Mar 2005 06:37:09 -0800 Subject: [fedora-java] tomcat5 Message-ID: <1110292630.5352.8.camel@localhost.localdomain> I see that tomcat5 is in rawhide now - thanks Gary! I started it up, and saw the process running until I tried to view a page, then the process died. Here are the contents of /var/log/tomcat5/catalina.out. Any ideas? Thanks, AG -------------- next part -------------- Bootstrap: Class loader creation threw exception java.lang.IllegalArgumentException: addRepositoryInternal: repository='file:/usr/share/tomcat5/common/lib/[jdbc-stdext].jar' at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(java.lang.String) (Unknown Source) at org.apache.catalina.loader.StandardClassLoader.StandardClassLoader(java.lang.String[]) (Unknown Source) at org.apache.catalina.startup.ClassLoaderFactory.createClassLoader(java.io.File[], java.io.File[], java.net.URL[], java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) at org.apache.catalina.startup.Bootstrap.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.io.FileNotFoundException: /usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or directory) at gnu.java.nio.channels.FileChannelImpl.open(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) at gnu.java.nio.channels.FileChannelImpl.FileChannelImpl(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) at java.io.RandomAccessFile.RandomAccessFile(java.lang.String, java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.util.zip.ZipFile.ZipFile(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.util.jar.JarFile.JarFile(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.util.jar.JarFile.JarFile(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(java.lang.String) (Unknown Source) ...8 more Bootstrap: Class loader creation threw exception java.lang.IllegalArgumentException: addRepositoryInternal: repository='file:/usr/share/tomcat5/common/lib/[jdbc-stdext].jar' at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(java.lang.String) (Unknown Source) at org.apache.catalina.loader.StandardClassLoader.StandardClassLoader(java.lang.String[]) (Unknown Source) at org.apache.catalina.startup.ClassLoaderFactory.createClassLoader(java.io.File[], java.io.File[], java.net.URL[], java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) at org.apache.catalina.startup.Bootstrap.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.io.FileNotFoundException: /usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or directory) at gnu.java.nio.channels.FileChannelImpl.open(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) at gnu.java.nio.channels.FileChannelImpl.FileChannelImpl(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) at java.io.RandomAccessFile.RandomAccessFile(java.lang.String, java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.util.zip.ZipFile.ZipFile(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.util.jar.JarFile.JarFile(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.util.jar.JarFile.JarFile(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(java.lang.String) (Unknown Source) ...8 more From vadimn at redhat.com Tue Mar 8 14:48:11 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Tue, 8 Mar 2005 09:48:11 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110292630.5352.8.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> Message-ID: <200503080948.11924@vadim.nasardinov> On Tuesday 08 March 2005 09:37, Anthony Green wrote: > I started it up, and saw the process running until I tried to view a > page, then the process died. Here are the contents > of /var/log/tomcat5/catalina.out. Any ideas? > > Caused by: java.io.FileNotFoundException: > /usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or > directory) > at gnu.java.nio.channels.FileChannelImpl.open(java.lang.String, int) (/usr/lib/libgcj.so.6.0.0) Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your machine? From green at redhat.com Tue Mar 8 15:15:32 2005 From: green at redhat.com (Anthony Green) Date: Tue, 08 Mar 2005 07:15:32 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <200503080948.11924@vadim.nasardinov> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> Message-ID: <1110294932.10073.2.camel@localhost.localdomain> On Tue, 2005-03-08 at 09:48 -0500, Vadim Nasardinov wrote: > Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your > machine? lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm Bah. Ok, the java-1.4.2-gcj-compat spec file says: Provides: jndi, jdbc-stdext So, do we need to play tricks for these, like I suggested for jta? AG From overholt at redhat.com Tue Mar 8 15:40:55 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 8 Mar 2005 10:40:55 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <20050308031504.GJ29253@rogers.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> Message-ID: <20050308154055.GB30854@redhat.com> CCing Bryce McKinlay * Dimitrie O. Paun [2005-03-07 22:16]: > On Mon, Mar 07, 2005 at 03:20:38PM -0700, Aaron Luchko wrote: > > I've been pitting them up against the IBM and BEA jvms we have for the > > stuff we ship with RHEL-3, the last time I successfully ran them was > > with the last 3.0 we had, it didn't fare too badly other than debugging > > (no JDWP) though our stuff has changed quite a bit since then. > > "didn't fare too badly" = faster, slower, about the same? Any hard numbers? I don't have any hard numbers, but things feel about the same or faster than with a proprietary JVM. The thing to remember is that we have no gcj optimizations turned on at this point. I know Bryce was working on it ... Bryce, do you have a status of that? Andrew From overholt at redhat.com Tue Mar 8 15:44:06 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 8 Mar 2005 10:44:06 -0500 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <1110284867.5352.4.camel@localhost.localdomain> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> Message-ID: <20050308154406.GC30854@redhat.com> * Anthony Green [2005-03-08 07:34]: > On Tue, 2005-03-08 at 11:00 +0000, Joe Orton wrote: > > It built on i386 but didn't on at least ia64: > > > > + make javahl > > /usr/lib/jvm/java-1.4.2-gcj/bin/javac -d > > subversion/bindings/java/javahl/classes -classpath ... > > Missing resource : > > org/eclipse/jdt/internal/compiler/batch/messages.properties for locale > > en_US > > Exception in thread "main" java.lang.ExceptionInInitializerError > > <> > > Caused by: java.util.MissingResourceException: Bundle > > org.eclipse.jdt.internal.compiler.batch.messages not found > > <> > > make: *** [javahl-java] Error 1 > > error: Bad exit status from > > /usr/src/build/536680-ia64/install-tmp/rpm-tmp.80923 (%build) > > > > This is troubling. This looks like the Eclipse compiler is broken on > ia64. But surely we're using that compiler to build other things right > now. Does anybody here know? There's a gcc backend bug (most likely) on ia64 right now so I can't build Eclipse on it. We still have an older ecj build on ia64, though, so j-g-c can build on it. We will have eclipse-ecj when I can build it on ia64. gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 Andrew From mckinlay at redhat.com Tue Mar 8 15:50:41 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Tue, 08 Mar 2005 10:50:41 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <20050308154055.GB30854@redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> Message-ID: <422DC9D1.5090702@redhat.com> Andrew Overholt wrote: >CCing Bryce McKinlay > >* Dimitrie O. Paun [2005-03-07 22:16]: > > >>On Mon, Mar 07, 2005 at 03:20:38PM -0700, Aaron Luchko wrote: >> >> >>>I've been pitting them up against the IBM and BEA jvms we have for the >>>stuff we ship with RHEL-3, the last time I successfully ran them was >>>with the last 3.0 we had, it didn't fare too badly other than debugging >>>(no JDWP) though our stuff has changed quite a bit since then. >>> >>> >>"didn't fare too badly" = faster, slower, about the same? Any hard numbers? >> >> > >I don't have any hard numbers, but things feel about the same or faster >than with a proprietary JVM. The thing to remember is that we have no gcj >optimizations turned on at this point. I know Bryce was working on it ... >Bryce, do you have a status of that? > My last eclipse -O2 attempt was a few weeks ago, and some fixes have gone in to GCJ since then. At this point it should be possible to compile most of the .jar's with -O2, but there are likely to still be optimization bugs that cause eclipse to misbehave or crash when it is built with -O2. Is resources.jar still used entirely uncompiled? We should perhaps concentrate on that bug first. Startup time is also an issue - we should be able to beat the JVM easily here but currently we arn't. It would be worth profiling the startup sequence to see if any obvious bottlenecks can be identified. Bryce From gbenson at redhat.com Tue Mar 8 16:16:46 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 8 Mar 2005 16:16:46 +0000 Subject: [fedora-java] Re: tomcat5 In-Reply-To: <1110292630.5352.8.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> Message-ID: <20050308161643.GC12089@redhat.com> Anthony Green wrote: > I see that tomcat5 is in rawhide now - thanks Gary! You're welcome :) > I started it up, and saw the process running until I tried to > view a page, then the process died. Here are the contents of > /var/log/tomcat5/catalina.out. Any ideas? Not a clue, sorry: I haven't tried running it at all yet! I just needed it built in time for FC4t1... Cheers, Gary From aph at redhat.com Tue Mar 8 17:55:01 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Mar 2005 17:55:01 +0000 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <422DC9D1.5090702@redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> Message-ID: <16941.59125.399536.230873@cuddles.cambridge.redhat.com> Bryce McKinlay writes: > > Startup time is also an issue - we should be able to beat the JVM easily > here but currently we arn't. It would be worth profiling the startup > sequence to see if any obvious bottlenecks can be identified. The unwinding fixes aren't all in yet. Unwinding accounted for about 16% of startup time in the case of jonas, and I exepct Eclipse would be similar. Andrew. From aph at redhat.com Tue Mar 8 17:56:31 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Mar 2005 17:56:31 +0000 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <16941.59125.399536.230873@cuddles.cambridge.redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> <16941.59125.399536.230873@cuddles.cambridge.redhat.com> Message-ID: <16941.59215.388324.855820@cuddles.cambridge.redhat.com> Andrew Haley writes: > Bryce McKinlay writes: > > > > Startup time is also an issue - we should be able to beat the JVM easily > > here but currently we arn't. It would be worth profiling the startup > > sequence to see if any obvious bottlenecks can be identified. > > The unwinding fixes aren't all in yet. Unwinding accounted for about > 16% 60% > of startup time in the case of jonas, and I exepct Eclipse would > be similar. > > Andrew. From overholt at redhat.com Tue Mar 8 18:01:55 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 8 Mar 2005 13:01:55 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <422DC9D1.5090702@redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> Message-ID: <20050308180155.GG30854@redhat.com> * Bryce McKinlay [2005-03-08 10:55]: > > My last eclipse -O2 attempt was a few weeks ago, and some fixes have > gone in to GCJ since then. At this point it should be possible to > compile most of the .jar's with -O2, but there are likely to still be > optimization bugs that cause eclipse to misbehave or crash when it is > built with -O2. I just successfully built all of our jars to .sos with O2 and things ran! I didn't do much testing, but a simple Hello, world works. Now to see if this works on the other architectures ... > Is resources.jar still used entirely uncompiled? We should perhaps > concentrate on that bug first. Yes. Yes, perhaps we should. Andrew From Nicolas.Mailhot at laPoste.net Tue Mar 8 18:13:21 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Mar 2005 19:13:21 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: <1110294932.10073.2.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> Message-ID: <1110305601.25559.14.camel@rousalka.dyndns.org> Le mardi 08 mars 2005 ? 07:15 -0800, Anthony Green a ?crit : > On Tue, 2005-03-08 at 09:48 -0500, Vadim Nasardinov wrote: > > Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your > > machine? > > lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm > lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm > > Bah. Ok, the java-1.4.2-gcj-compat spec file says: > > Provides: jndi, jdbc-stdext > > So, do we need to play tricks for these, like I suggested for jta? Yep. The jvm framework does not actually cares about the rpm provides. What it wants is a jar in the places it scans (a symlink to another jar is fine). Typically for an in-jvm implementation you have to put a symlink in /usr/lib/jvm-exports/my_jvm_name/ to the jar providing the implementation in /usr/lib/jvm/my_jvm_name/ The symlink must have the standard name the apps want (in this case jdbc-stdext.jar and jndi.jar) This way the common scripts don't require any deep knowledge about every single jvm layout or capabilities - it's the jvm packager responsibility to create the few symlinks in its package that will inform the rest of the system of what his jvm can actually do. (this was originally done because IBM and SUN jvms had very different layouts but it should help even more for gcj since it does not even share the same roots as these other two). When stuff moves in-jvm all you have to do is create a symlink with the same name the jar in /usr/share/java used to have and you're done (plus of course add the relevant provides to the spec). Symlinks in /usr/lib/jvm-exports/my_jvm_name/ have priority wrt to stuff in /usr/share/java so you can even install simultaneously a jvm that absolutely want to use its own implementation and another that relies on the external /usr/share/java one. (this is all part of the JPackage framework - when in doubt you can consult the policy document in jpackage-utils %doc or ask on the jpackage-discuss ML) Regards, -- Nicolas Mailhot -------------- 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 Mar 8 18:13:59 2005 From: tromey at redhat.com (Tom Tromey) Date: 08 Mar 2005 11:13:59 -0700 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110222368.6220.39.camel@localhost.localdomain> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> Message-ID: >>>>> "Phil" == Phil Muldoon writes: Phil> Anybody else in the community have any comments on this, or other Phil> proposals? I'd like to get the ball rolling on this, and we can maybe Phil> get the implementation working before May and the final Fedora 4 Phil> release. I think the key point is that whatever we do has to be supported by eclipse.org. Any other way means maintaining our own build system. Ideally building an RPM for an Eclipse plugin should be nearly completely automatic. I don't see why we couldn't achieve this... but it depends on upstream cooperation. Tom From Nicolas.Mailhot at laPoste.net Tue Mar 8 18:17:48 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Mar 2005 19:17:48 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: <200503080948.11924@vadim.nasardinov> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> Message-ID: <1110305869.25559.20.camel@rousalka.dyndns.org> Le mardi 08 mars 2005 ? 09:48 -0500, Vadim Nasardinov a ?crit : > On Tuesday 08 March 2005 09:37, Anthony Green wrote: > > I started it up, and saw the process running until I tried to view a > > page, then the process died. Here are the contents > > of /var/log/tomcat5/catalina.out. Any ideas? > > > > Caused by: java.io.FileNotFoundException: > > /usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or > > directory) BTW it's wonderful that gcj actually gives a meaningful error on dangling symlinks instead of the strange crashes proprietary JVMs are prone to. Regards, -- Nicolas Mailhot -------------- 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 Mar 8 18:20:37 2005 From: tromey at redhat.com (Tom Tromey) Date: 08 Mar 2005 11:20:37 -0700 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: <422DC9D1.5090702@redhat.com> References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> Message-ID: Bryce> Is resources.jar still used entirely uncompiled? We Bryce> should perhaps concentrate on that bug first. I think this bug is still undiagnosed. Bryce> Startup time is also an issue - we should be able to beat the JVM Bryce> easily here but currently we arn't. It would be worth profiling the Bryce> startup sequence to see if any obvious bottlenecks can be identified. Given Andrew's results from profiling jonas, I would venture to guess that stack trace performance is a problem. Last time we looked at Eclipse startup performance, the single biggest improvement was in this area. (People sometimes ask why Eclipse startup time matters. The performance of some other Eclipse operations, like opening a perspective, is related to the startup time -- a lot of the same sort of work happens. Improve startup time and you improve some other visible things in Eclipse.) Tom From pmuldoon at redhat.com Tue Mar 8 18:27:46 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 08 Mar 2005 12:27:46 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> Message-ID: <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> On Tue, 2005-03-08 at 11:13 -0700, Tom Tromey wrote: > >>>>> "Phil" == Phil Muldoon writes: > > Phil> Anybody else in the community have any comments on this, or other > Phil> proposals? I'd like to get the ball rolling on this, and we can maybe > Phil> get the implementation working before May and the final Fedora 4 > Phil> release. > > I think the key point is that whatever we do has to be supported by > eclipse.org. Any other way means maintaining our own build system. It's going to have to work with releng plug-ins then, as that is their build approach. Releng plug-ins produce tarballs now on a Linux platform, so we are halfway there. The releng plug-ins are fairly atomic in nature too, so it is all good. This is completely different to how jpackage.org build eclipse-* rpms, so pick one or the other I guess. > Ideally building an RPM for an Eclipse plug-in should be nearly > completely automatic. I don't see why we couldn't achieve this... but > it depends on upstream cooperation. Ben has some patches on eclipse.org (Ben can you post the direct link here), but I don't think it has seen any eclipse maintainer traffic. :( In building the RPM, are you proposing the the releng plug-in should deliver an RPM, or just a tarball like it delivers now? I can see merit in both ways, but how we would be add on all the %post/%postun stuff, and the actual jar -> so building bits on an automatic releng approach? All that stuff is pretty Fedora specific. If it is as it is now, the SPEC files for eclipse-* are totally generic in nature (were written that way), so it is sort of automatic. Not automatic enough, though ;) Regards Phil > > Tom > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From tromey at redhat.com Tue Mar 8 18:34:00 2005 From: tromey at redhat.com (Tom Tromey) Date: 08 Mar 2005 11:34:00 -0700 Subject: [fedora-java] tomcat5 In-Reply-To: <1110294932.10073.2.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm Anthony> Bah. Ok, the java-1.4.2-gcj-compat spec file says: Anthony> Provides: jndi, jdbc-stdext Anthony> So, do we need to play tricks for these, like I suggested for jta? When I look at my JDK installs, I don't see separate jdbc or jndi jars. Did something change here? (This machine is still on FC2...) Plus, afaik, jndi is in j2se. Tom From fitzsim at redhat.com Tue Mar 8 18:49:22 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 08 Mar 2005 13:49:22 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110294932.10073.2.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> Message-ID: <1110307762.23370.121.camel@tortoise.toronto.redhat.com> On Tue, 2005-03-08 at 07:15 -0800, Anthony Green wrote: >On Tue, 2005-03-08 at 09:48 -0500, Vadim Nasardinov wrote: >> Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your >> machine? > >lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm >lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm > >Bah. Ok, the java-1.4.2-gcj-compat spec file says: > >Provides: jndi, jdbc-stdext > Yeah, as far as I know, these are just empty provides right now. We need to fill them in with actual jars -- the question is, where do the free implementations come from? Tom From Nicolas.Mailhot at laPoste.net Tue Mar 8 19:11:54 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Mar 2005 20:11:54 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> Message-ID: <1110309115.25559.57.camel@rousalka.dyndns.org> Le mardi 08 mars 2005 ? 11:34 -0700, Tom Tromey a ?crit : > >>>>> "Anthony" == Anthony Green writes: > > Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar -> /could/not/find/extension/for/this/jvm > Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar -> /could/not/find/extension/for/this/jvm > > Anthony> Bah. Ok, the java-1.4.2-gcj-compat spec file says: > Anthony> Provides: jndi, jdbc-stdext > Anthony> So, do we need to play tricks for these, like I suggested for jta? > > When I look at my JDK installs, I don't see separate jdbc or jndi jars. > Did something change here? (This machine is still on FC2...) > Plus, afaik, jndi is in j2se. Tomcat5 was originally packaged for java 1.3.x - at that time jdbc and jndi lived outside the JVM. It's a testament to the framework strength that the same package works without changes on java 1.4.x. I agree now that all the JVMs JPackage supports include these bits both the requires and the symlinks seeds could be removed from the package. You have to remember though things move in-jvm every release and it's mightily nice to be able to hide these changes from the packages so you don't have to rewrite specs all the time (and you can use the same packages with a 1.x.y jvm and a 1.x+1.z jvm - think when Red Hat includes preview versions of the next gcc release along the current one in RHEL or FC) Of course pass must be able to use either the old out-of-jvm jar or the new in-jvm one without rebuild. This is usually the case for big projects like Tomcat. Regards, -- Nicolas Mailhot -------------- 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 Mar 8 19:24:32 2005 From: tromey at redhat.com (Tom Tromey) Date: 08 Mar 2005 12:24:32 -0700 Subject: [fedora-java] tomcat5 In-Reply-To: <1110309115.25559.57.camel@rousalka.dyndns.org> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> Message-ID: >>>>> "Nicolas" == Nicolas Mailhot writes: Nicolas> You have to remember though things move in-jvm every release Nicolas> and it's mightily nice to be able to hide these changes from Nicolas> the packages so you don't have to rewrite specs all the time Yeah... actually I'm fine with leaving things as they are. I just wasn't sure where these symlinks should point for libgcj. But it sounds like just pointing them at libgcj.jar should work. Tom From Nicolas.Mailhot at laPoste.net Tue Mar 8 19:40:29 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Mar 2005 20:40:29 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> Message-ID: <1110310831.25559.61.camel@rousalka.dyndns.org> Le mardi 08 mars 2005 ? 12:24 -0700, Tom Tromey a ?crit : > >>>>> "Nicolas" == Nicolas Mailhot writes: > > Nicolas> You have to remember though things move in-jvm every release > Nicolas> and it's mightily nice to be able to hide these changes from > Nicolas> the packages so you don't have to rewrite specs all the time > > Yeah... actually I'm fine with leaving things as they are. I just > wasn't sure where these symlinks should point for libgcj. But it > sounds like just pointing them at libgcj.jar should work. The symlinks are actually just a security (yes the jvm includes stuff we need). You can probably point them to any jar you like - if the stuff in internal to the jvm it'll be added to the classpath anyway. It's nicer to point them to the real implementation though, if only to document the jvm internal layout. regards, -- Nicolas Mailhot -------------- 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 bkonrath at redhat.com Tue Mar 8 20:39:58 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 08 Mar 2005 15:39:58 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> Message-ID: <1110314398.5527.61.camel@town.toronto.redhat.com> On Tue, 2005-03-08 at 12:27 -0600, Phil Muldoon wrote: > On Tue, 2005-03-08 at 11:13 -0700, Tom Tromey wrote: > > I think the key point is that whatever we do has to be supported by > > eclipse.org. Any other way means maintaining our own build system. > > It's going to have to work with releng plug-ins then, as that is their > build approach. Releng plug-ins produce tarballs now on a Linux > platform, so we are halfway there. The releng plug-ins are fairly > atomic in nature too, so it is all good. This is completely different to > how jpackage.org build eclipse-* rpms, so pick one or the other I guess. My proposal is definitely more in line with the releng build approach. For the first part of the proposal, I want to give the releng process the ability to generate a srcIncluded zips [1] for all plugins. This zip file would be very similar to what we generate ourselves right now. Part of this solution involves coming up with a way to build native code in an automatic way - at least from the perspective of the person building the plugin. Patches for this are in bugzilla but it needs a little more work (see below). For second part of the proposal, I want to extend this work so that plugins and features can generate the same srcIncluded zip without the need for a releng plugin. IMO, releng plugins are only needed if you want automatic builds of some kind - nightly builds or whatever. A lot of the open source plugins that I have come across generate their releases by calling one of the targets in the generated build.xml. So I'd like to add a target to the generated build.xml will make a srcIncluded zip. BTW, I updated the proposal again if you're interested. [1] zip files will be used because there are problems with eclipse and non-GNU tar. > > Ideally building an RPM for an Eclipse plug-in should be nearly > > completely automatic. I don't see why we couldn't achieve this... but > > it depends on upstream cooperation. > > Ben has some patches on eclipse.org (Ben can you post the direct link > here), but I don't think it has seen any eclipse maintainer traffic. :( The patches are posted here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=71637 I'm just waiting for some comments so that I can finish this part off. I suspect if I post a message to the releng mailing list now that my proposal is a little more developed, I would get a response. I've been distracted by this native eclipse stuff :) > In building the RPM, are you proposing the the releng plug-in should > deliver an RPM, or just a tarball like it delivers now? I can see merit > in both ways, but how we would be add on all the %post/%postun stuff, > and the actual jar -> so building bits on an automatic releng approach? > All that stuff is pretty Fedora specific. > > If it is as it is now, the SPEC files for eclipse-* are totally generic > in nature (were written that way), so it is sort of automatic. Not > automatic enough, though ;) If we get my proposed solution upstream, the spec files would become more generic - it might even be possible to write a small script to automatically package plugins. Cheers, Ben From jorton at redhat.com Tue Mar 8 20:56:19 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 8 Mar 2005 20:56:19 +0000 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <20050308154406.GC30854@redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> <20050308154406.GC30854@redhat.com> Message-ID: <20050308205618.GA19940@redhat.com> On Tue, Mar 08, 2005 at 10:44:06AM -0500, Andrew Overholt wrote: > * Anthony Green [2005-03-08 07:34]: ... > > This is troubling. This looks like the Eclipse compiler is broken on > > ia64. But surely we're using that compiler to build other things right > > now. Does anybody here know? > > There's a gcc backend bug (most likely) on ia64 right now so I can't build > Eclipse on it. We still have an older ecj build on ia64, though, so j-g-c > can build on it. We will have eclipse-ecj when I can build it on ia64. > > gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 So do I need to file a bug on this issue in Red Hat bugzilla or are is this "in progress"? I can't enable the Subversion javahl bindings until this is fixed. joe From pmuldoon at redhat.com Tue Mar 8 21:22:12 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 08 Mar 2005 15:22:12 -0600 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110314398.5527.61.camel@town.toronto.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> <1110314398.5527.61.camel@town.toronto.redhat.com> Message-ID: <1110316932.6768.40.camel@dhcp-12.hsv.redhat.com> On Tue, 2005-03-08 at 15:39 -0500, Ben Konrath wrote: > On Tue, 2005-03-08 at 12:27 -0600, Phil Muldoon wrote: > > On Tue, 2005-03-08 at 11:13 -0700, Tom Tromey wrote: > > > I think the key point is that whatever we do has to be supported by > > > eclipse.org. Any other way means maintaining our own build system. > > > > It's going to have to work with releng plug-ins then, as that is their > > build approach. Releng plug-ins produce tarballs now on a Linux > > platform, so we are halfway there. The releng plug-ins are fairly > > atomic in nature too, so it is all good. This is completely different to > > how jpackage.org build eclipse-* rpms, so pick one or the other I guess. > > My proposal is definitely more in line with the releng build approach. > For the first part of the proposal, I want to give the releng process > the ability to generate a srcIncluded zips [1] for all plugins. This zip > file would be very similar to what we generate ourselves right now. Part > of this solution involves coming up with a way to build native code in > an automatic way - at least from the perspective of the person building > the plugin. Patches for this are in bugzilla but it needs a little more > work (see below). Ok, just to make sure we are on the same track here. There are two definitions of native code when we talk about releng plugin stuff. Are you talking about when the project itself has to generate native code (like the CDT does for some bits, like the linux/win32/solaris etc fragments), which we have to do in the SPEC files manually (instead of using the packaged prebuilt .so's). Or the second definition, where we compile all the produced jars to .so's with gcj in the spec file? I suspect you are talking about the first, (fwiw I think the second case should always remain in the spec files). > > In building the RPM, are you proposing the the releng plug-in should > > deliver an RPM, or just a tarball like it delivers now? I can see merit > > in both ways, but how we would be add on all the %post/%postun stuff, > > and the actual jar -> so building bits on an automatic releng approach? > > All that stuff is pretty Fedora specific. > > > > If it is as it is now, the SPEC files for eclipse-* are totally generic > > in nature (were written that way), so it is sort of automatic. Not > > automatic enough, though ;) > > If we get my proposed solution upstream, the spec files would become > more generic - it might even be possible to write a small script to > automatically package plugins. I thought about doing this when I wrote up the original native plugin spec files for changelog/cdt etc, but each project is too quirky in its own little way. We might get to where you are proposing, it would sure be nice! This list sure has been busy today, which is great. Go-go fedora-devel- java-list! Phil From ziga.mahkovec at klika.si Tue Mar 8 21:32:17 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Tue, 08 Mar 2005 22:32:17 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110105522.15251.49.camel@localhost.localdomain> References: <1110105522.15251.49.camel@localhost.localdomain> Message-ID: <1110317537.10580.7.camel@localhost> On Sun, 2005-03-06 at 02:42 -0800, Anthony Green wrote: > ant and javac aren't currently using the natively-built Eclipse > compiler. > > We need to add something like the following to /usr/bin/ant in order to > pick up the .so files: > > [...] > > This will shave minutes off of the build times for some packages. I compared the compilation times for a simple HelloWorld class: ecj | ecj-native | jikes ------------------------------------------------------------- real 0m8.462s | real 0m8.624s | real 0m0.101s user 0m7.791s | user 0m8.230s | user 0m0.048s sys 0m0.093s | sys 0m0.083s | sys 0m0.006s (warm startups) I wanted to run the same test for the GNU Classpath library, but ecj kept throwing an internal compiler error (with or without your patch; I'll file a bug report). Anyway, the error is thrown after 32 seconds, while jikes compiles the entire library in 11 seconds. I suppose ecj would also profit from -O2? -- Ziga From bkonrath at redhat.com Tue Mar 8 21:41:21 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 08 Mar 2005 16:41:21 -0500 Subject: [fedora-java] New Eclipse stuff in rawhide In-Reply-To: <1110316932.6768.40.camel@dhcp-12.hsv.redhat.com> References: <20050304161114.GA17011@redhat.com> <1110041671.7422.31.camel@localhost.localdomain> <1110076625.15251.2.camel@localhost.localdomain> <1110081842.5776.37.camel@localhost.localdomain> <20050306063636.GA26804@town.toronto.redhat.com> <1110128926.5913.6.camel@localhost.localdomain> <1110174021.7119.49.camel@town.toronto.redhat.com> <1110222368.6220.39.camel@localhost.localdomain> <1110306466.6768.20.camel@dhcp-12.hsv.redhat.com> <1110314398.5527.61.camel@town.toronto.redhat.com> <1110316932.6768.40.camel@dhcp-12.hsv.redhat.com> Message-ID: <1110318081.5457.4.camel@town.toronto.redhat.com> On Tue, 2005-03-08 at 15:22 -0600, Phil Muldoon wrote: > Ok, just to make sure we are on the same track here. There are two > definitions of native code when we talk about releng plugin stuff. Are > you talking about when the project itself has to generate native code > (like the CDT does for some bits, like the linux/win32/solaris etc > fragments), which we have to do in the SPEC files manually (instead of > using the packaged prebuilt .so's). > > Or the second definition, where we compile all the produced jars > to .so's with gcj in the spec file? > > I suspect you are talking about the first, (fwiw I think the second case > should always remain in the spec files). Yeah, your suspicion is correct, I was referring to the first case you listed. I agree that the gcj jar -> so compilation should remain in the spec file. Cheers, Ben From mckinlay at redhat.com Tue Mar 8 23:01:25 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Tue, 08 Mar 2005 18:01:25 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110317537.10580.7.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> Message-ID: <422E2EC5.6060907@redhat.com> Ziga Mahkovec wrote: >I compared the compilation times for a simple HelloWorld class: > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 0m8.462s | real 0m8.624s | real 0m0.101s >user 0m7.791s | user 0m8.230s | user 0m0.048s >sys 0m0.093s | sys 0m0.083s | sys 0m0.006s > >(warm startups) > >I wanted to run the same test for the GNU Classpath library, but ecj >kept throwing an internal compiler error (with or without your patch; >I'll file a bug report). Anyway, the error is thrown after 32 seconds, >while jikes compiles the entire library in 11 seconds. > >I suppose ecj would also profit from -O2? > > Something is wrong here. It looks like your ecj is running interpreted both in the "ecj" and "ecj-native" cases. Bryce From ziga.mahkovec at klika.si Tue Mar 8 23:41:25 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 00:41:25 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <422E2EC5.6060907@redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> Message-ID: <1110325286.10580.11.camel@localhost> On Tue, 2005-03-08 at 18:01 -0500, Bryce McKinlay wrote: > Ziga Mahkovec wrote: > >I compared the compilation times for a simple HelloWorld class: > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 0m8.462s | real 0m8.624s | real 0m0.101s > >user 0m7.791s | user 0m8.230s | user 0m0.048s > >sys 0m0.093s | sys 0m0.083s | sys 0m0.006s > > > > [...] > > > Something is wrong here. It looks like your ecj is running interpreted > both in the "ecj" and "ecj-native" cases. $ rpm -q libgcj eclipse-ecj libgcj-4.0.0-0.30 eclipse-ecj-3.1.0_fc-0.M5.10 $ gcj-dbtool -l /usr/lib/eclipse/eclipse.db | wc -l 19865 $ export CLASSPATH=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar $ time gij -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db \ com.sun.tools.javac.Main HelloWorld.java real 0m8.687s user 0m8.591s sys 0m0.091s And strace indicates that eclipse.db is opened. Is there anything else I can check? -- Ziga From fitzsim at redhat.com Wed Mar 9 03:41:20 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 08 Mar 2005 22:41:20 -0500 Subject: [fedora-java] libgcj javadoc rpm In-Reply-To: <1109988666.7344.67.camel@localhost.localdomain> References: <1109988666.7344.67.camel@localhost.localdomain> Message-ID: <1110339680.23370.135.camel@tortoise.toronto.redhat.com> On Fri, 2005-03-04 at 18:11 -0800, Anthony Green wrote: >I just experimented with creating a noarch RPM for libgcj HTML javadoc. > >It uses gjdoc to generate HTML from the src.zip rawhide libgcj installs. >I don't know if this is the best way to go about it, but it was >convenient. > >I've placed the SRPM here for comment: > >http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm [3k] > >The RPM itself is 16MB, and it seems I'm out of space on >people.redhat.com. > >Comments and suggestions welcome.... > The plan is to ship the geronimo specs RPM, which includes a JTA implementation. This will happen in about a week, when Fernando packages it. Tom >Thanks, > >AG > > >-- >fedora-devel-java-list mailing list >fedora-devel-java-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From green at redhat.com Wed Mar 9 08:56:13 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 00:56:13 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <1110307762.23370.121.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> Message-ID: <1110358573.5536.0.camel@localhost.localdomain> On Tue, 2005-03-08 at 13:49 -0500, Thomas Fitzsimmons wrote: > > > >Bah. Ok, the java-1.4.2-gcj-compat spec file says: > > > >Provides: jndi, jdbc-stdext > > > > Yeah, as far as I know, these are just empty provides right now. We > need to fill them in with actual jars -- the question is, where do the > free implementations come from? Aren't they already in libgcj.jar? The only problem is how to make them available as jndi.jar and jdbc-stdext.jar (I guess). AG From green at redhat.com Wed Mar 9 08:57:23 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 00:57:23 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> Message-ID: <1110358643.5536.2.camel@localhost.localdomain> On Tue, 2005-03-08 at 12:24 -0700, Tom Tromey wrote: > >>>>> "Nicolas" == Nicolas Mailhot writes: > > Nicolas> You have to remember though things move in-jvm every release > Nicolas> and it's mightily nice to be able to hide these changes from > Nicolas> the packages so you don't have to rewrite specs all the time > > Yeah... actually I'm fine with leaving things as they are. I just > wasn't sure where these symlinks should point for libgcj. But it > sounds like just pointing them at libgcj.jar should work. Are you sure this won't cause problems for proprietary VMs when they want to load jndi.jar? They'll be looking at a jar file with all of the core classes. AG From green at redhat.com Wed Mar 9 09:04:24 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 01:04:24 -0800 Subject: [fedora-java] libgcj javadoc rpm In-Reply-To: <1110339680.23370.135.camel@tortoise.toronto.redhat.com> References: <1109988666.7344.67.camel@localhost.localdomain> <1110339680.23370.135.camel@tortoise.toronto.redhat.com> Message-ID: <1110359064.5536.10.camel@localhost.localdomain> (This thread was actually about javadoc for libgcj, but....) On Tue, 2005-03-08 at 22:41 -0500, Thomas Fitzsimmons wrote: > The plan is to ship the geronimo specs RPM, which includes a JTA > implementation. This will happen in about a week, when Fernando > packages it. We don't really need this for gcj, since libgcj already includes a JTA implementation. The only question is how to make the jta jar file available. I've been proposing extracting the bytecode from libgcj and putting it into a new jar file somewhere (the GCC spec file maybe). tromey just suggesting symlinking libgcj.jar to the missing jar files, and there's another proposal to create and use brand new RPMs (from libgcj/classpath source, or geronimo). AG From nicolas.mailhot at laposte.net Wed Mar 9 10:10:07 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 Mar 2005 11:10:07 +0100 (CET) Subject: [fedora-java] tomcat5 In-Reply-To: <1110358643.5536.2.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> <1110358643.5536.2.camel@localhost.localdomain> Message-ID: <27986.192.54.193.137.1110363007.squirrel@rousalka.dyndns.org> On Mer 9 mars 2005 9:57, Anthony Green a ?crit : > On Tue, 2005-03-08 at 12:24 -0700, Tom Tromey wrote: >> >>>>> "Nicolas" == Nicolas Mailhot writes: >> >> Nicolas> You have to remember though things move in-jvm every release >> Nicolas> and it's mightily nice to be able to hide these changes from >> Nicolas> the packages so you don't have to rewrite specs all the time >> >> Yeah... actually I'm fine with leaving things as they are. I just >> wasn't sure where these symlinks should point for libgcj. But it >> sounds like just pointing them at libgcj.jar should work. > > Are you sure this won't cause problems for proprietary VMs when they > want to load jndi.jar? They'll be looking at a jar file with all of the > core classes. That's why you put the symlinks in a very particular location (_NOT_ /usr/share/java) that is only inspected buy the common classpath scripts if the corresponding JVM is used. This is one of the main differences between Debian packaging and JPackage packaging - jars are not lumped in a single directory, they are isolated in separate parts of the filesystem to make sure they are never exposed to the wrong jvm. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Mar 9 10:12:21 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 Mar 2005 11:12:21 +0100 (CET) Subject: [fedora-java] tomcat5 In-Reply-To: <1110358573.5536.0.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> Message-ID: <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> On Mer 9 mars 2005 9:56, Anthony Green a ?crit : > On Tue, 2005-03-08 at 13:49 -0500, Thomas Fitzsimmons wrote: >> > >> >Bah. Ok, the java-1.4.2-gcj-compat spec file says: >> > >> >Provides: jndi, jdbc-stdext >> > >> >> Yeah, as far as I know, these are just empty provides right now. We >> need to fill them in with actual jars -- the question is, where do the >> free implementations come from? > > Aren't they already in libgcj.jar? The only problem is how to make them > available as jndi.jar and jdbc-stdext.jar (I guess). A look at how JPackage packages other JVMs (closed stuff I know:() would be pretty enlightening I think. I know the documentation can be hard to grasp without concrete examples. Regards, -- Nicolas Mailhot From bob.deblier at telenet.be Wed Mar 9 11:34:49 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Wed, 09 Mar 2005 12:34:49 +0100 Subject: [fedora-java] Self Introduction - Bob Deblier Message-ID: <1110368089.5528.16.camel@orion> Hi all, I'm the author of the BeeCrypt crypto library (already in Fedora, used by RPM), and as previously announced at FOSDEM 2005 in the GNU Classpath developer room, currently working on reviving a Java CSP which will use BeeCrypt's native routines. What I'm looking for is advice on the best approach to integrate building a CSP jar file, deriving native interface headers from multiple classes, followed by compiling a C shared library with the native code. My tentative approach is using autoconf to figure out if either gcj/gcjh or javac/javah is available, generate a build.xml file for Apache Ant. I have this working for Sun's JDK. Support for gcj should be easier once libgcj contains javax.crypto - is this planned for 4.0? Sincerely, Bob Deblier From gbenson at redhat.com Wed Mar 9 11:39:29 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 9 Mar 2005 11:39:29 +0000 Subject: [fedora-java] tomcat5 In-Reply-To: <1110310831.25559.61.camel@rousalka.dyndns.org> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> <1110310831.25559.61.camel@rousalka.dyndns.org> Message-ID: <20050309113928.GA5206@redhat.com> Nicolas Mailhot wrote: > Le mardi 08 mars 2005 ? 12:24 -0700, Tom Tromey a ?crit : > > >>>>> "Nicolas" == Nicolas Mailhot writes: > > > > Nicolas> You have to remember though things move in-jvm every > > Nicolas> release and it's mightily nice to be able to hide these > > Nicolas> changes from the packages so you don't have to rewrite > > Nicolas> specs all the time > > > > Yeah... actually I'm fine with leaving things as they are. I just > > wasn't sure where these symlinks should point for libgcj. But it > > sounds like just pointing them at libgcj.jar should work. > > The symlinks are actually just a security (yes the jvm includes > stuff we need). You can probably point them to any jar you like - if > the stuff in internal to the jvm it'll be added to the classpath > anyway. > > It's nicer to point them to the real implementation though, if only > to document the jvm internal layout. Would it be better perhaps to replace the symlinks with empty jar files? Or maybe jarfiles containing only a README to indicate that the classes that would be in there are now in the core classpath? Cheers, Gary From aph at redhat.com Wed Mar 9 11:41:41 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 11:41:41 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110325286.10580.11.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> Message-ID: <16942.57589.638526.568285@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Tue, 2005-03-08 at 18:01 -0500, Bryce McKinlay wrote: > > Ziga Mahkovec wrote: > > >I compared the compilation times for a simple HelloWorld class: > > > > > >ecj | ecj-native | jikes > > >------------------------------------------------------------- > > >real 0m8.462s | real 0m8.624s | real 0m0.101s > > >user 0m7.791s | user 0m8.230s | user 0m0.048s > > >sys 0m0.093s | sys 0m0.083s | sys 0m0.006s > > > > > > [...] > > > > > Something is wrong here. It looks like your ecj is running interpreted > > both in the "ecj" and "ecj-native" cases. > > $ rpm -q libgcj eclipse-ecj > libgcj-4.0.0-0.30 > eclipse-ecj-3.1.0_fc-0.M5.10 > $ gcj-dbtool -l /usr/lib/eclipse/eclipse.db | wc -l > 19865 > $ export CLASSPATH=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar > $ time gij -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db \ > com.sun.tools.javac.Main HelloWorld.java > > real 0m8.687s > user 0m8.591s > sys 0m0.091s > > > And strace indicates that eclipse.db is opened. Is there anything else > I can check? time gij -verbose:class ... Andrew. From aph at redhat.com Wed Mar 9 11:44:41 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 11:44:41 +0000 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <1110368089.5528.16.camel@orion> References: <1110368089.5528.16.camel@orion> Message-ID: <16942.57769.529784.160252@cuddles.cambridge.redhat.com> Bob Deblier writes: > > I'm the author of the BeeCrypt crypto library (already in Fedora, > used by RPM), and as previously announced at FOSDEM 2005 in the GNU > Classpath developer room, currently working on reviving a Java CSP > which will use BeeCrypt's native routines. Hello again. > What I'm looking for is advice on the best approach to integrate > building a CSP jar file, deriving native interface headers from > multiple classes, followed by compiling a C shared library with the > native code. Sounds good. This will be a once only job, will it? > My tentative approach is using autoconf to figure out if either gcj/gcjh > or javac/javah is available, generate a build.xml file for Apache Ant. I > have this working for Sun's JDK. Support for gcj should be easier once > libgcj contains javax.crypto - is this planned for 4.0? It seems to be there. Is there anything specific that you think might be missing? Andrew. From bob.deblier at telenet.be Wed Mar 9 12:11:01 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Wed, 09 Mar 2005 13:11:01 +0100 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <16942.57769.529784.160252@cuddles.cambridge.redhat.com> References: <1110368089.5528.16.camel@orion> <16942.57769.529784.160252@cuddles.cambridge.redhat.com> Message-ID: <1110370261.5528.29.camel@orion> On Wed, 2005-03-09 at 11:44 +0000, Andrew Haley wrote: > > at I'm looking for is advice on the best approach to integrate > > building a CSP jar file, deriving native interface headers from > > multiple classes, followed by compiling a C shared library with the > > native code. > > Sounds good. This will be a once only job, will it? Actually, what you suggest makes sense: headers to be generated once by me and included in the cvs and tarball - they shouldn't change. I was doing the following: - figure out which build system is available - generate the jar file with Ant - generate the header files from the jar file with Ant - compile the shared library > > My tentative approach is using autoconf to figure out if either gcj/gcjh > > or javac/javah is available, generate a build.xml file for Apache Ant. I > > have this working for Sun's JDK. Support for gcj should be easier once > > libgcj contains javax.crypto - is this planned for 4.0? > > It seems to be there. Is there anything specific that you think might > be missing? It's not in version 3.4.3-2 and probably should have investigated libgcj-4.0.0 before asking ;) Thanks, Bob From nicolas.mailhot at laposte.net Wed Mar 9 12:50:17 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 Mar 2005 13:50:17 +0100 (CET) Subject: [fedora-java] tomcat5 In-Reply-To: <20050309113928.GA5206@redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> <1110310831.25559.61.camel@rousalka.dyndns.org> <20050309113928.GA5206@redhat.com> Message-ID: <3287.192.54.193.137.1110372617.squirrel@rousalka.dyndns.org> On Mer 9 mars 2005 12:39, Gary Benson a ?crit : > Nicolas Mailhot wrote: >> The symlinks are actually just a security (yes the jvm includes >> stuff we need). You can probably point them to any jar you like - if >> the stuff in internal to the jvm it'll be added to the classpath >> anyway. >> >> It's nicer to point them to the real implementation though, if only >> to document the jvm internal layout. > > Would it be better perhaps to replace the symlinks with empty jar > files? Or maybe jarfiles containing only a README to indicate that > the classes that would be in there are now in the core classpath? Both would work - the classpath builder only cares about finding a file with the right name in the right place, and jvms only require real jar files (they don't handle well files with .jar extensions that are not a jar archive). I like symlinking the bits which provide the extension better (sometimes when you need to debug a crash it's convenient to have a symlink that shows you for example that the xml parser inside IBM jvms is just some xerces version), but that might only be pedantic me. I must say that if the problem is no one knows where the gcj bits that do jndi are it's a bit worrying in itself ;) Regards, -- Nicolas Mailhot From gbenson at redhat.com Wed Mar 9 12:50:58 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 9 Mar 2005 12:50:58 +0000 Subject: [fedora-java] Java Package Naming In-Reply-To: <421D44D4.2050703@carwyn.com> References: <421D44D4.2050703@carwyn.com> Message-ID: <20050309125058.GB5206@redhat.com> My apologies for taking so long to reply to this: mail to this list was ending up in another folder, and I only noticed yesterday. Carwyn Edwards wrote: > Q1. What are Fedora planning to do in relation to release tag naming > and jpp packages? > > At the moment Rawhide is using jpp_(fc|rh). > This seems a little at odds with the draft Fedora naming guidelines > (I know they've only just been written in draft :-)). There are no plans to deviate from the Xjpp_Yfc scheme we are currently using. We need to keep the Xjpp so that version comparisons work between JPackage and Fedora packages, and we need the Yfc to allow Fedora packages to be rebuilt to fix Fedora issues without requiring a corresponding rebuild in JPackage. This ought to be documented in the naming guidelines, and I'll look into it. > The motivation for this question is to do with our desire to ship > local modifications to jpp packages and still have a sensible > upgrade path. Up to now I've been able to simply tack on a suffix to > the jpp version. If however another upstream repo (FC) is also using > the suffix approach then things start to get interesting :-) > (1jpp_3fc vs 1jpp.1.local) I can't see adding another suffix causing a problem. > Q2. Are Fedora going to feed packages upstream as a priority then > tweak them for their local purposes afterwards? Another way of > asking this is - will FC Java packages that could also end up in > JPackage always going to have a Xjpp prefix in the release tag? If > not then things like this can happen: Yes, they'll always have the tag. Without it version comparisons between other JPackages would not give the required result. Besides, no Fedora package can be _identical_ to its corresponding JPackage so long as JPackages define Vendor tags and the like. Cheers, Gary [ gbenson at redhat.com ][ I am Red Hat ][ http://inauspicious.org/ ] From kuzman at gmail.com Wed Mar 9 12:51:43 2005 From: kuzman at gmail.com (Jeff Morgan) Date: Wed, 9 Mar 2005 07:51:43 -0500 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <1110368089.5528.16.camel@orion> References: <1110368089.5528.16.camel@orion> Message-ID: <28864c7b05030904512546c575@mail.gmail.com> On Wed, 09 Mar 2005 12:34:49 +0100, Bob Deblier wrote: > My tentative approach is using autoconf to figure out if either gcj/gcjh > or javac/javah is available, generate a build.xml file for Apache Ant. I > have this working for Sun's JDK. Support for gcj should be easier once > libgcj contains javax.crypto - is this planned for 4.0? Bob, why would you using autoconf to detect the correct libs, progs, and setup your makefiles only to generate a build.xml and invoke ant? To me it seems like you are introducting additional complexity and dependencies but I may be wrong. -- Jeffrey Morgan "The highest reward for a man's toil is not what he gets for it, but what he becomes by it" - Jon Ruskin From gbenson at redhat.com Wed Mar 9 12:52:29 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 9 Mar 2005 12:52:29 +0000 Subject: [fedora-java] tomcat5 In-Reply-To: <3287.192.54.193.137.1110372617.squirrel@rousalka.dyndns.org> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110309115.25559.57.camel@rousalka.dyndns.org> <1110310831.25559.61.camel@rousalka.dyndns.org> <20050309113928.GA5206@redhat.com> <3287.192.54.193.137.1110372617.squirrel@rousalka.dyndns.org> Message-ID: <20050309125229.GC5206@redhat.com> Nicolas Mailhot wrote: > I like symlinking the bits which provide the extension better > (sometimes when you need to debug a crash it's convenient to have a > symlink that shows you for example that the xml parser inside IBM > jvms is just some xerces version), but that might only be pedantic > me. No, sounds reasonable to me. Cheers, Gary From bob.deblier at telenet.be Wed Mar 9 13:31:42 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Wed, 09 Mar 2005 14:31:42 +0100 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <28864c7b05030904512546c575@mail.gmail.com> References: <1110368089.5528.16.camel@orion> <28864c7b05030904512546c575@mail.gmail.com> Message-ID: <1110375102.5528.35.camel@orion> On Wed, 2005-03-09 at 07:51 -0500, Jeff Morgan wrote: > On Wed, 09 Mar 2005 12:34:49 +0100, Bob Deblier wrote: > > My tentative approach is using autoconf to figure out if either gcj/gcjh > > or javac/javah is available, generate a build.xml file for Apache Ant. I > > have this working for Sun's JDK. Support for gcj should be easier once > > libgcj contains javax.crypto - is this planned for 4.0? > > Bob, why would you using autoconf to detect the correct libs, progs, > and setup your makefiles only to generate a build.xml and invoke > ant? To me it seems like you are introducting additional complexity > and dependencies but I may be wrong. I started with generating build.xml to fill in the proper 'src' and 'build' directory properties; the next step was trying to detect which programs are available to build the jar. Bob From ziga.mahkovec at klika.si Wed Mar 9 13:38:59 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 14:38:59 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <16942.57589.638526.568285@cuddles.cambridge.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> Message-ID: <1110375539.5587.31.camel@localhost> On Wed, 2005-03-09 at 11:41 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > > Something is wrong here. It looks like your ecj is running interpreted > > > both in the "ecj" and "ecj-native" cases. > > > > [...] > > > > And strace indicates that eclipse.db is opened. Is there anything else > > I can check? > > time gij -verbose:class ... Thanks Andrew, I put the steps and log files here: http://www.bootchart.org/misc/ecj/ecj-native.html It seems that ecj was actually running native in both cases (with or without gnu.gcj.precompiled.db.path). Which, looking at the source code for com.sun.tools.javac.Main, seems right: @71 loader = new URLClassLoader(new URL[] { new URL("gcjlib://" + Config.ECJLIB_INST_DIR + "/" + libname)}); (libname being "lib-org-eclipse-jdt.so") Moving lib-org-eclipse-jdt.so out of the way speeds up gij/ecj considerably. Shouldn't precompiled libraries be configured in runtime, as opposed to in Main.java? And I'm not sure why it's actually faster when running interpreted. -- Ziga From aph at redhat.com Wed Mar 9 14:08:56 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 14:08:56 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110375539.5587.31.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> Message-ID: <16943.888.428446.685556@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Wed, 2005-03-09 at 11:41 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > > Something is wrong here. It looks like your ecj is running interpreted > > > > both in the "ecj" and "ecj-native" cases. > > > > > > [...] > > > > > > And strace indicates that eclipse.db is opened. Is there anything else > > > I can check? > > > > time gij -verbose:class ... > > Thanks Andrew, I put the steps and log files here: > http://www.bootchart.org/misc/ecj/ecj-native.html You didn't try -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without jdtcore.jar.so. > It seems that ecj was actually running native in both cases (with or > without gnu.gcj.precompiled.db.path). Which, looking at the source code > for com.sun.tools.javac.Main, seems right: > > @71 > loader = new URLClassLoader(new URL[] { > new URL("gcjlib://" + Config.ECJLIB_INST_DIR + "/" + libname)}); > > (libname being "lib-org-eclipse-jdt.so") > > Moving lib-org-eclipse-jdt.so out of the way speeds up gij/ecj > considerably. > > Shouldn't precompiled libraries be configured in runtime, as opposed to > in Main.java? And I'm not sure why it's actually faster when running > interpreted. This is bizarre. Profiling would tell us. Andrew. From ziga.mahkovec at klika.si Wed Mar 9 14:39:03 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 15:39:03 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <16943.888.428446.685556@cuddles.cambridge.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> Message-ID: <1110379143.5587.41.camel@localhost> On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > Thanks Andrew, I put the steps and log files here: > > http://www.bootchart.org/misc/ecj/ecj-native.html > > You didn't try > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > jdtcore.jar.so. Updated page. I guess this is the same as running interpreted, since most of the class lookups fail. I'll also try changing tools.jar to use the standard class loader instead and see if it changes anything. -- Ziga From aph at redhat.com Wed Mar 9 14:44:39 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 14:44:39 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110379143.5587.41.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> Message-ID: <16943.3031.961762.318989@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > Thanks Andrew, I put the steps and log files here: > > > http://www.bootchart.org/misc/ecj/ecj-native.html > > > > You didn't try > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > > jdtcore.jar.so. > > Updated page. I guess this is the same as running interpreted, since > most of the class lookups fail. It is: it seems that you don't have a precompiled version of /usr/share/java/jdtcore.jar in your eclipse.db. Either that, or the corresponding precompiled library isn't readable. We only fall back to loading bytecode if something fails. Andrew. From ziga.mahkovec at klika.si Wed Mar 9 14:59:23 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 15:59:23 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <16943.3031.961762.318989@cuddles.cambridge.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> Message-ID: <1110380363.5587.49.camel@localhost> On Wed, 2005-03-09 at 14:44 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > > > Ziga Mahkovec writes: > > > > Thanks Andrew, I put the steps and log files here: > > > > http://www.bootchart.org/misc/ecj/ecj-native.html > > > > > > You didn't try > > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > > > jdtcore.jar.so. > > > > Updated page. I guess this is the same as running interpreted, since > > most of the class lookups fail. > > It is: it seems that you don't have a precompiled version of > /usr/share/java/jdtcore.jar in your eclipse.db. Either that, or the > corresponding precompiled library isn't readable. The corresponding library is /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so right? I do have it in eclipse.db, but for the last two tests I renamed it, in order to force tools.jar to not use the gcjlib:// class loader. That's why I didn't include the additional test (gnu.gcj.precompiled.db.path without jdtcore.jar.so) in the first place. -- Ziga From aph at redhat.com Wed Mar 9 15:04:12 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 15:04:12 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110380363.5587.49.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> Message-ID: <16943.4204.355394.783901@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Wed, 2005-03-09 at 14:44 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > > > > Ziga Mahkovec writes: > > > > > Thanks Andrew, I put the steps and log files here: > > > > > http://www.bootchart.org/misc/ecj/ecj-native.html > > > > > > > > You didn't try > > > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > > > > jdtcore.jar.so. > > > > > > Updated page. I guess this is the same as running interpreted, since > > > most of the class lookups fail. > > > > It is: it seems that you don't have a precompiled version of > > /usr/share/java/jdtcore.jar in your eclipse.db. Either that, or the > > corresponding precompiled library isn't readable. > > The corresponding library > is /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so > right? I would guess so, but I don't know. > I do have it in eclipse.db, but for the last two tests I renamed it, in > order to force tools.jar to not use the gcjlib:// class loader. I see. Of course, I have no idea why tools.jar is attempting to use the gcjlib:// class loader, or why it is so slow when it does. It really should not explicitly use this class loader. > That's why I didn't include the additional test > (gnu.gcj.precompiled.db.path without jdtcore.jar.so) in the first > place. Yes, I see. Do you by any chance happen to have oprofile? Andrew. From green at redhat.com Wed Mar 9 15:25:04 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 07:25:04 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> Message-ID: <1110381905.5536.19.camel@localhost.localdomain> On Wed, 2005-03-09 at 11:12 +0100, Nicolas Mailhot wrote: > A look at how JPackage packages other JVMs (closed stuff I know:() would > be pretty enlightening I think. I know the documentation can be hard to > grasp without concrete examples. Ok, I think the answer is that java-gcj-compat needs to create the following symlinks... # ls -l /usr/lib/jvm-exports/java-1.4.2-gcj-1.4.2.0/ total 12 lrwxrwxrwx 1 root root 32 Mar 9 07:13 jaas.jar -> /usr/share/java/libgcj-4.0.0.jar lrwxrwxrwx 1 root root 32 Mar 9 07:11 jdbc-stdext.jar -> /usr/share/java/libgcj-4.0.0.jar lrwxrwxrwx 1 root root 32 Mar 9 07:11 jndi.jar -> /usr/share/java/libgcj-4.0.0.jar fitzsim: do you agree? Now tomcat5 gets a lot further, and we hit something new.... # cat /var/log/tomcat5/catalina.out Bootstrap: Class loader creation threw exception java.lang.NoClassDefFoundError: while resolving class: javax.management.MBeanServerFactory 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.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) at org.apache.catalina.startup.Bootstrap.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.ClassNotFoundException: mx4j.log.Logger not found in gnu.gcj.runtime.SystemClassLoader{urls=[], parent=gnu.gcj.runtime.VMClassLoader{urls=[file:/usr/share/java/ext/com-sun-tools-doclets-Taglet-0.7.1.jar], 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.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.6.0.0) ...8 more We have this class installed, so presumably the class loader's class path is wrong somehow. AG From fitzsim at redhat.com Wed Mar 9 16:24:07 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 11:24:07 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110381905.5536.19.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> Message-ID: <1110385447.23370.149.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 07:25 -0800, Anthony Green wrote: >On Wed, 2005-03-09 at 11:12 +0100, Nicolas Mailhot wrote: >> A look at how JPackage packages other JVMs (closed stuff I know:() would >> be pretty enlightening I think. I know the documentation can be hard to >> grasp without concrete examples. > >Ok, I think the answer is that java-gcj-compat needs to create the >following symlinks... > ># ls -l /usr/lib/jvm-exports/java-1.4.2-gcj-1.4.2.0/ >total 12 >lrwxrwxrwx 1 root root 32 Mar 9 07:13 jaas.jar -> /usr/share/java/libgcj-4.0.0.jar >lrwxrwxrwx 1 root root 32 Mar 9 07:11 jdbc-stdext.jar -> /usr/share/java/libgcj-4.0.0.jar >lrwxrwxrwx 1 root root 32 Mar 9 07:11 jndi.jar -> /usr/share/java/libgcj-4.0.0.jar > >fitzsim: do you agree? > I've got new java-1.4.2-gcj-compat packages here that add these symlinks. I'm holding off building them into beehive until FC4test1 has branched. >Now tomcat5 gets a lot further, and we hit something new.... > ># cat /var/log/tomcat5/catalina.out >Bootstrap: Class loader creation threw exception >java.lang.NoClassDefFoundError: while resolving class: javax.management.MBeanServerFactory > 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.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) > at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) > at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) > at org.apache.catalina.startup.Bootstrap.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.ClassNotFoundException: mx4j.log.Logger not found in gnu.gcj.runtime.SystemClassLoader{urls=[], parent=gnu.gcj.runtime.VMClassLoader{urls=[file:/usr/share/java/ext/com-sun-tools-doclets-Taglet-0.7.1.jar], parent=null}} I've been seeing that message too. First of all, why does the urls field of VMClassLoader not print *all* jars in the extensions directory? Is this a libgcj bug? The other annoying thing is the difference between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. We either need to change the JPackage standard to point to /usr/share/java/ext or we need to hard-code /usr/share/java-ext and /usr/lib/java-ext into libgcj as extensions directories. Defining java.ext.dirs in all the wrapper scripts is turning out to be quite fragile. In this case the mx4j jar probably installs in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. Tom From fitzsim at redhat.com Wed Mar 9 16:38:42 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 11:38:42 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <16943.4204.355394.783901@cuddles.cambridge.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> Message-ID: <1110386322.23370.159.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 15:04 +0000, Andrew Haley wrote: >Ziga Mahkovec writes: > > On Wed, 2005-03-09 at 14:44 +0000, Andrew Haley wrote: > > > Ziga Mahkovec writes: > > > > On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > > > > > Ziga Mahkovec writes: > > > > > > Thanks Andrew, I put the steps and log files here: > > > > > > http://www.bootchart.org/misc/ecj/ecj-native.html > > > > > > > > > > You didn't try > > > > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > > > > > jdtcore.jar.so. > > > > > > > > Updated page. I guess this is the same as running interpreted, since > > > > most of the class lookups fail. > > > > > > It is: it seems that you don't have a precompiled version of > > > /usr/share/java/jdtcore.jar in your eclipse.db. Either that, or the > > > corresponding precompiled library isn't readable. > > > > The corresponding library > > is /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so > > right? > >I would guess so, but I don't know. > > > I do have it in eclipse.db, but for the last two tests I renamed it, in > > order to force tools.jar to not use the gcjlib:// class loader. > >I see. Of course, I have no idea why tools.jar is attempting to use >the gcjlib:// class loader, or why it is so slow when it does. It >really should not explicitly use this class loader. > I doesn't any more. We were doing that to avoid having to always add jdtcore.jar to the classpath. I also have no idea why it's so slow but I did notice a significant performance hit when compared to interpreted mode. Ziga, you can get the sources for java-gcj-compat from sources.redhat.com: cvs -d :pserver:anoncvs at sources.redhat.com:/cvs/rhug co java-gcj-compat I've removed gcjlib:// loading in favour of using the database, so when everything's set up properly ecj should run natively using jdtcore.jar.so. Tom From green at redhat.com Wed Mar 9 17:20:20 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 09:20:20 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <1110385447.23370.149.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> Message-ID: <1110388820.5536.24.camel@localhost.localdomain> On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: > I've been seeing that message too. First of all, why does the urls > field of VMClassLoader not print *all* jars in the extensions directory? > Is this a libgcj bug? It certainly looks that way. > The other annoying thing is the difference > between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. > We either need to change the JPackage standard to point > to /usr/share/java/ext or we need to hard-code /usr/share/java-ext > and /usr/lib/java-ext into libgcj as extensions directories. Defining > java.ext.dirs in all the wrapper scripts is turning out to be quite > fragile. In this case the mx4j jar probably installs > in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting > set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. I don't think that's really the problem, since mx4j doesn't install in any extensions directory. It probably should for gcj at least, since it's included in Sun's rt.jar. But it seems that gcj should have it's own extension directory. jmx is also set up to use "alternatives". I don't know what the right answer is. Suggestions? AG From vadimn at redhat.com Wed Mar 9 17:31:25 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Wed, 9 Mar 2005 12:31:25 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110388820.5536.24.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> Message-ID: <200503091231.25707@vadim.nasardinov> On Wednesday 09 March 2005 12:20, Anthony Green wrote: > I don't think that's really the problem, since mx4j doesn't install > in any extensions directory. It probably should for gcj at least, > since it's included in Sun's rt.jar. This doesn't parse. What's included in Sun's rt.jar? MX4J? From green at redhat.com Wed Mar 9 17:51:04 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 09:51:04 -0800 Subject: [fedora-java] tomcat5 In-Reply-To: <200503091231.25707@vadim.nasardinov> References: <1110292630.5352.8.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> <200503091231.25707@vadim.nasardinov> Message-ID: <1110390664.5536.26.camel@localhost.localdomain> On Wed, 2005-03-09 at 12:31 -0500, Vadim Nasardinov wrote: > On Wednesday 09 March 2005 12:20, Anthony Green wrote: > > I don't think that's really the problem, since mx4j doesn't install > > in any extensions directory. It probably should for gcj at least, > > since it's included in Sun's rt.jar. > > This doesn't parse. What's included in Sun's rt.jar? MX4J? Yes, it looks that way. AG From vadimn at redhat.com Wed Mar 9 18:03:12 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Wed, 9 Mar 2005 13:03:12 -0500 Subject: JMX and JMX Remote (was: Re: [fedora-java] tomcat5) In-Reply-To: <1110390664.5536.26.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503091231.25707@vadim.nasardinov> <1110390664.5536.26.camel@localhost.localdomain> Message-ID: <200503091303.12133@vadim.nasardinov> On Wednesday 09 March 2005 12:51, Anthony Green wrote: > > This doesn't parse. What's included in Sun's rt.jar? MX4J? > > Yes, it looks that way. It doesn't quite look that way from where I sit. MX4J is an implementation of JMX and JMX Remote. These *are* included in J2SE 1.5 (5.0): http://java.sun.com/j2se/1.5.0/docs/api/javax/management/package-frame.html http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/package-frame.html However, they are not part of J2SE 1.4: http://java.sun.com/j2se/1.4.2/docs/api/overview-frame.html You have to download these separately, if you want to use Sun's reference implementation under JDK 1.4: http://java.sun.com/products/JavaManagement/download.html Are we both looking at the same thing? From Nicolas.Mailhot at laPoste.net Wed Mar 9 18:03:19 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 09 Mar 2005 19:03:19 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: <1110390664.5536.26.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> <200503091231.25707@vadim.nasardinov> <1110390664.5536.26.camel@localhost.localdomain> Message-ID: <1110391399.3276.2.camel@rousalka.dyndns.org> Le mercredi 09 mars 2005 ? 09:51 -0800, Anthony Green a ?crit : > On Wed, 2005-03-09 at 12:31 -0500, Vadim Nasardinov wrote: > > On Wednesday 09 March 2005 12:20, Anthony Green wrote: > > > I don't think that's really the problem, since mx4j doesn't install > > > in any extensions directory. It probably should for gcj at least, > > > since it's included in Sun's rt.jar. > > > > This doesn't parse. What's included in Sun's rt.jar? MX4J? > > Yes, it looks that way. Are you sure you're not talking about jmx (http://java.sun.com/products/JavaManagement/ ?) I'd be astounded if Sun dropped its own implementation for a FOSS clone. Regards, -- Nicolas Mailhot -------------- 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 fitzsim at redhat.com Wed Mar 9 18:17:15 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 13:17:15 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110388820.5536.24.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> Message-ID: <1110392235.23370.166.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 09:20 -0800, Anthony Green wrote: >On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: >> I've been seeing that message too. First of all, why does the urls >> field of VMClassLoader not print *all* jars in the extensions directory? >> Is this a libgcj bug? > >It certainly looks that way. > >> The other annoying thing is the difference >> between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. >> We either need to change the JPackage standard to point >> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext >> and /usr/lib/java-ext into libgcj as extensions directories. Defining >> java.ext.dirs in all the wrapper scripts is turning out to be quite >> fragile. In this case the mx4j jar probably installs >> in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting >> set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. > >I don't think that's really the problem, since mx4j doesn't install in >any extensions directory. It probably should for gcj at least, since >it's included in Sun's rt.jar. > >But it seems that gcj should have it's own extension directory. > That's a good idea. Then we wouldn't have all these problems associated with trying to match Sun's JAR layouts (e.g. classpathx-mail embedding an inetlib implementation, ugh). We could just create jar file symlinks (mostly to libgcj.jar) for programs that look for the actual jars. Everything else they needed (e.g. providers) would transparently be included on CLASSPATH by way of the gcj extensions directory. In fact, we could just keep using /usr/share/java/ext for that purpose. What are the ramifications of putting jars in the extension directories? Tom From fitzsim at redhat.com Wed Mar 9 18:27:42 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 13:27:42 -0500 Subject: [fedora-java] tomcat5 In-Reply-To: <1110392235.23370.166.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> <1110392235.23370.166.camel@tortoise.toronto.redhat.com> Message-ID: <1110392862.23370.173.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 13:17 -0500, Thomas Fitzsimmons wrote: >On Wed, 2005-03-09 at 09:20 -0800, Anthony Green wrote: >>On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: >>> I've been seeing that message too. First of all, why does the urls >>> field of VMClassLoader not print *all* jars in the extensions directory? >>> Is this a libgcj bug? >> >>It certainly looks that way. >> >>> The other annoying thing is the difference >>> between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. >>> We either need to change the JPackage standard to point >>> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext >>> and /usr/lib/java-ext into libgcj as extensions directories. Defining >>> java.ext.dirs in all the wrapper scripts is turning out to be quite >>> fragile. In this case the mx4j jar probably installs >>> in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting >>> set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. >> >>I don't think that's really the problem, since mx4j doesn't install in >>any extensions directory. It probably should for gcj at least, since >>it's included in Sun's rt.jar. >> >>But it seems that gcj should have it's own extension directory. >> > >That's a good idea. Then we wouldn't have all these problems associated >with trying to match Sun's JAR layouts (e.g. classpathx-mail embedding >an inetlib implementation, ugh). We could just create jar file symlinks >(mostly to libgcj.jar) for programs that look for the actual jars. >Everything else they needed (e.g. providers) would transparently be >included on CLASSPATH by way of the gcj extensions directory. In fact, >we could just keep using /usr/share/java/ext for that purpose. What are >the ramifications of putting jars in the extension directories? > I guess there's a problem with this from the JPackage-purity perspective. Should the JPackage conventions mandate putting jar files in /usr/share/java/ext, where they're necessary for gcj inter-operation? Tom From tromey at redhat.com Wed Mar 9 18:34:32 2005 From: tromey at redhat.com (Tom Tromey) Date: 09 Mar 2005 11:34:32 -0700 Subject: [fedora-java] tomcat5 In-Reply-To: <1110385447.23370.149.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> Message-ID: >>>>> "Tom" == Thomas Fitzsimmons writes: Tom> I've been seeing that message too. First of all, why does the urls Tom> field of VMClassLoader not print *all* jars in the extensions directory? I looked into this. The problem is, URLClassLoader caches the toString() result but does not reset it when a new URL is added. Whoops. All the jars definitely do end up in there though, at least in my simple test. Tom> We either need to change the JPackage standard to point Tom> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext Tom> and /usr/lib/java-ext into libgcj as extensions directories. We can easily add a configuration option for this. If we only need one directory we could just have our RPM install a symlink (the compiled-in extdir is not created by the gcc install process). Tom From green at redhat.com Wed Mar 9 18:36:16 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 10:36:16 -0800 Subject: JMX and JMX Remote (was: Re: [fedora-java] tomcat5) In-Reply-To: <200503091303.12133@vadim.nasardinov> References: <1110292630.5352.8.camel@localhost.localdomain> <200503091231.25707@vadim.nasardinov> <1110390664.5536.26.camel@localhost.localdomain> <200503091303.12133@vadim.nasardinov> Message-ID: <1110393376.5536.28.camel@localhost.localdomain> On Wed, 2005-03-09 at 13:03 -0500, Vadim Nasardinov wrote: > Are we both looking at the same thing? Ah, right - I was looking at a 1.5 system. AG From aph at redhat.com Wed Mar 9 18:47:23 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 18:47:23 +0000 Subject: [fedora-java] tomcat5 In-Reply-To: References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> Message-ID: <16943.17595.907330.871405@cuddles.cambridge.redhat.com> Tom Tromey writes: > >>>>> "Tom" == Thomas Fitzsimmons writes: > > Tom> I've been seeing that message too. First of all, why does the urls > Tom> field of VMClassLoader not print *all* jars in the extensions directory? > > I looked into this. The problem is, URLClassLoader caches the > toString() result but does not reset it when a new URL is added. > Whoops. Where's this? Andrew. From Nicolas.Mailhot at laPoste.net Wed Mar 9 18:47:33 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 09 Mar 2005 19:47:33 +0100 Subject: [fedora-java] tomcat5 In-Reply-To: <1110392235.23370.166.camel@tortoise.toronto.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <1110388820.5536.24.camel@localhost.localdomain> <1110392235.23370.166.camel@tortoise.toronto.redhat.com> Message-ID: <1110394058.3276.12.camel@rousalka.dyndns.org> Le mercredi 09 mars 2005 ? 13:17 -0500, Thomas Fitzsimmons a ?crit : > On Wed, 2005-03-09 at 09:20 -0800, Anthony Green wrote: > >On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: > >> I've been seeing that message too. First of all, why does the urls > >> field of VMClassLoader not print *all* jars in the extensions directory? > >> Is this a libgcj bug? > > > >It certainly looks that way. > > > >> The other annoying thing is the difference > >> between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. > >> We either need to change the JPackage standard to point > >> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext > >> and /usr/lib/java-ext into libgcj as extensions directories. Defining > >> java.ext.dirs in all the wrapper scripts is turning out to be quite > >> fragile. In this case the mx4j jar probably installs > >> in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting > >> set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. > > > >I don't think that's really the problem, since mx4j doesn't install in > >any extensions directory. It probably should for gcj at least, since > >it's included in Sun's rt.jar. > > > >But it seems that gcj should have it's own extension directory. > > > > That's a good idea. Then we wouldn't have all these problems associated > with trying to match Sun's JAR layouts (e.g. classpathx-mail embedding > an inetlib implementation, ugh). We could just create jar file symlinks > (mostly to libgcj.jar) for programs that look for the actual jars. > Everything else they needed (e.g. providers) would transparently be > included on CLASSPATH by way of the gcj extensions directory. In fact, > we could just keep using /usr/share/java/ext for that purpose. What are > the ramifications of putting jars in the extension directories? Please don't use /usr/share/java/ext. You'll get into big problems the day two gcj versions are deployed in parallel (think gcc4) if they share the same extension dir. It's much easier to have separate dirs (possibly with symlinks pointing to a common pool) than to handle things like "I want to include all the jars in this dir except this one which is used by another version". This being said, the way JPackage does stuff is not fixed in stone, it can change for the next release if people think it could get better. (only please remember we have already a full repo built around the current rules, so don't ask for changes just for cosmetic value) Regards, -- Nicolas Mailhot -------------- 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 aph at redhat.com Wed Mar 9 19:10:00 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Mar 2005 19:10:00 +0000 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <1110370261.5528.29.camel@orion> References: <1110368089.5528.16.camel@orion> <16942.57769.529784.160252@cuddles.cambridge.redhat.com> <1110370261.5528.29.camel@orion> Message-ID: <16943.18952.421815.801158@cuddles.cambridge.redhat.com> Bob Deblier writes: > On Wed, 2005-03-09 at 11:44 +0000, Andrew Haley wrote: > > > at I'm looking for is advice on the best approach to integrate > > > building a CSP jar file, deriving native interface headers from > > > multiple classes, followed by compiling a C shared library with the > > > native code. > > > > Sounds good. This will be a once only job, will it? > > Actually, what you suggest makes sense: headers to be generated once by > me and included in the cvs and tarball - they shouldn't change. I was > doing the following: > - figure out which build system is available > - generate the jar file with Ant > - generate the header files from the jar file with Ant > - compile the shared library > > > > My tentative approach is using autoconf to figure out if either gcj/gcjh > > > or javac/javah is available, generate a build.xml file for Apache Ant. I > > > have this working for Sun's JDK. Support for gcj should be easier once > > > libgcj contains javax.crypto - is this planned for 4.0? > > > > It seems to be there. Is there anything specific that you think might > > be missing? > > It's not in version 3.4.3-2 and probably should have investigated > libgcj-4.0.0 before asking ;) Don't take my word for it! Please have a look to see if what you need is there. I am not an expert in this area. Andrew. From rmoseley at redhat.com Wed Mar 9 20:39:57 2005 From: rmoseley at redhat.com (Rick Moseley) Date: Wed, 09 Mar 2005 14:39:57 -0600 Subject: [fedora-java] Interesting articles on Java/Eclipse Message-ID: <422F5F1D.8040909@redhat.com> JAVA VS. MICROSOFT .NET DEBATE RAGES LAS VEGAS -- After describing Java as a stable technology with no great surprises likely to come, Java experts during a conference panel session fielded questions about the competitive power of Microsoft's rival .Net platform. http://newsletter.infoworld.com/t?ctl=C1872C:1F60395 ====================================================================== IBM: ECLIPSE FACES CHALLENGES AHEAD BURLINGAME, CALIF. - Eclipse will have to deal with its own success and the challenges that success presents, said Lee Nackman, a CTO and vice president at IBM Rational Software who was involved in founding the open source platform. http://newsletter.infoworld.com/t?ctl=C18729:1F60395 ====================================================================== JAVA STAVING OFF .NET, SPRING FOUNDER SAYS LAS VEGAS -- J2EE technology is in a very healthy state, staving off the rival .Net platform and fostering innovation, said Rod Johnson, founder of the open source Spring Framework for Java development, in a presentation on Friday. http://newsletter.infoworld.com/t?ctl=C1872A:1F60395 ====================================================================== ECLIPSE CHIEF TALKS UP PROJECTS, AWAITS SUN AND MICROSOFT The Eclipse Foundation for open source tools held its technical conference, EclipseCon 2005, in Burlingame, Calif., the week of Feb. 28. Stressing its momentum, the organization touted participation frrm vendors such as BEA Systems, Borland Socqftware, Computer Associates International, and Sybase. Mike Milinkovich, a former Oracle vice president of technical services, became the first executive director of the independent foundation when Eclipse was spun out of IBM last year. InfoWorld Editor at Large Paul Krill discussed Eclipse goings-on and impacts with Milinkovich. http://newsletter.infoworld.com/t?ctl=C1872D:1F60395 ====================================================================== From green at redhat.com Wed Mar 9 21:01:37 2005 From: green at redhat.com (Anthony Green) Date: Wed, 09 Mar 2005 13:01:37 -0800 Subject: mx4j (Was: [fedora-java] tomcat5) In-Reply-To: <1110381905.5536.19.camel@localhost.localdomain> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> Message-ID: <1110402097.5536.40.camel@localhost.localdomain> I looked at this a little further... On Wed, 2005-03-09 at 07:25 -0800, Anthony Green wrote: > Now tomcat5 gets a lot further, and we hit something new.... > > # cat /var/log/tomcat5/catalina.out > Bootstrap: Class loader creation threw exception > java.lang.NoClassDefFoundError: while resolving class: javax.management.MBeanServerFactory > 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.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source) > at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source) > at org.apache.catalina.startup.Bootstrap.init() (Unknown Source) > at org.apache.catalina.startup.Bootstrap.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.ClassNotFoundException: mx4j.log.Logger not found in gnu.gcj.runtime.SystemClassLoader{urls=[], parent=gnu.gcj.runtime.VMClassLoader{urls=[file:/usr/share/java/ext/com-sun-tools-doclets-Taglet-0.7.1.jar], 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.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.6.0.0) > ...8 more The tomcat5 startup script uses JPackage's rebuild-jar-repository script to construct a directory of jar files for the server to use. One of these is [jmxri].jar. So it symlinks to /usr/share/java/jmxri.jar, which is itself a symlink since jmx appears to be managed by alternatives. We eventually get to /usr/share/java/mx4j/mx4j-jmx.jar. Unfortunately, this jar has external dependencies on other jar files in /usr/share/java/mx4j. How is rebuild-jar-repository or tomcat5 supposed to know this? We end up with an incomplete jar repository, which is causing this problem. Is there a good and simple solution to this problem? AG From tromey at redhat.com Wed Mar 9 21:06:50 2005 From: tromey at redhat.com (Tom Tromey) Date: 09 Mar 2005 14:06:50 -0700 Subject: [fedora-java] tomcat5 In-Reply-To: <16943.17595.907330.871405@cuddles.cambridge.redhat.com> References: <1110292630.5352.8.camel@localhost.localdomain> <200503080948.11924@vadim.nasardinov> <1110294932.10073.2.camel@localhost.localdomain> <1110307762.23370.121.camel@tortoise.toronto.redhat.com> <1110358573.5536.0.camel@localhost.localdomain> <37142.192.54.193.137.1110363141.squirrel@rousalka.dyndns.org> <1110381905.5536.19.camel@localhost.localdomain> <1110385447.23370.149.camel@tortoise.toronto.redhat.com> <16943.17595.907330.871405@cuddles.cambridge.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: >> I looked into this. The problem is, URLClassLoader caches the >> toString() result but does not reset it when a new URL is added. >> Whoops. Andrew> Where's this? We talked about this on irc but I thought I'd follow-up for the record. It is just a small bug in URLClassLoader; addURL has to clear the cached toString() result. This is now fixed in libgcj and classpath. Tom From ziga.mahkovec at klika.si Wed Mar 9 21:24:15 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 22:24:15 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110386322.23370.159.camel@tortoise.toronto.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> Message-ID: <1110403455.5553.11.camel@localhost> On Wed, 2005-03-09 at 11:38 -0500, Thomas Fitzsimmons wrote: > On Wed, 2005-03-09 at 15:04 +0000, Andrew Haley wrote: > >I see. Of course, I have no idea why tools.jar is attempting to use > >the gcjlib:// class loader, or why it is so slow when it does. It > >really should not explicitly use this class loader. > > I doesn't any more. We were doing that to avoid having to always add > jdtcore.jar to the classpath. I also have no idea why it's so slow but > I did notice a significant performance hit when compared to interpreted > mode. > > Ziga, you can get the sources for java-gcj-compat from > sources.redhat.com: Ah, much better, thanks. Here are the revised times (BTW, that's a 1.5GHz Pentium M): HelloWorld ecj | ecj-native | jikes ------------------------------------------------------------- real 0m1.863s | real 0m1.614s | real 0m0.067s user 0m1.758s | user 0m1.536s | user 0m0.050s sys 0m0.103s | sys 0m0.076s | sys 0m0.012s GNU Classpath (cd lib; make) ecj | ecj-native | jikes ------------------------------------------------------------- real 1m24.539s | real 0m24.552s | real 0m9.439s user 1m23.157s | user 0m23.047s | user 0m7.486s sys 0m1.142s | sys 0m1.139s | sys 0m0.771s Note that classpath sources need a tiny hack to keep ecj from crashing. But that looks like an upstream Eclipse bug, since I could reproduce it running ecj with java-1.5.0-sun. Andrew, I don't suppose you still need oprofile data (or are there other places where gcjlib:// loading might be a problem)? -- Ziga From tromey at redhat.com Wed Mar 9 21:22:49 2005 From: tromey at redhat.com (Tom Tromey) Date: 09 Mar 2005 14:22:49 -0700 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: <1110368089.5528.16.camel@orion> References: <1110368089.5528.16.camel@orion> Message-ID: >>>>> "Bob" == Bob Deblier writes: Bob> Support for gcj should be easier once Bob> libgcj contains javax.crypto - is this planned for 4.0? Yes, it is in there. If your native library uses jni, and you have java-gcj-compat installed, you can build your code against gcj using the same build.xml that you would use for the jdk. This is the simplest way to go. (Well, aside from building a .so and registering it... that needs gcj-specific code of course) If you want to use CNI, to avoid the JNI performance penalty, then you have to do more work. Tom From mckinlay at redhat.com Wed Mar 9 21:31:38 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Wed, 09 Mar 2005 16:31:38 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110403455.5553.11.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> Message-ID: <422F6B3A.5080402@redhat.com> Ziga Mahkovec wrote: >Ah, much better, thanks. Here are the revised times (BTW, that's a >1.5GHz Pentium M): > >HelloWorld > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 0m1.863s | real 0m1.614s | real 0m0.067s >user 0m1.758s | user 0m1.536s | user 0m0.050s >sys 0m0.103s | sys 0m0.076s | sys 0m0.012s > > >GNU Classpath (cd lib; make) > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 1m24.539s | real 0m24.552s | real 0m9.439s >user 1m23.157s | user 0m23.047s | user 0m7.486s >sys 0m1.142s | sys 0m1.139s | sys 0m0.771s > > >Note that classpath sources need a tiny hack to keep ecj from crashing. >But that looks like an upstream Eclipse bug, since I could reproduce it >running ecj with java-1.5.0-sun. > >Andrew, I don't suppose you still need oprofile data (or are there other >places where gcjlib:// loading might be a problem)? > > The ecj-native times still look somewhat slow. Back in the RHUG days, a gcj-compiled ecj was faster than jikes at building classpath. Perhaps the BC-ABI stuff is slowing us down a bit. Bryce From fitzsim at redhat.com Wed Mar 9 21:32:11 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 16:32:11 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110403455.5553.11.camel@localhost> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> Message-ID: <1110403931.23370.178.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 22:24 +0100, Ziga Mahkovec wrote: >On Wed, 2005-03-09 at 11:38 -0500, Thomas Fitzsimmons wrote: >> On Wed, 2005-03-09 at 15:04 +0000, Andrew Haley wrote: >> >I see. Of course, I have no idea why tools.jar is attempting to use >> >the gcjlib:// class loader, or why it is so slow when it does. It >> >really should not explicitly use this class loader. >> >> I doesn't any more. We were doing that to avoid having to always add >> jdtcore.jar to the classpath. I also have no idea why it's so slow but >> I did notice a significant performance hit when compared to interpreted >> mode. >> >> Ziga, you can get the sources for java-gcj-compat from >> sources.redhat.com: > >Ah, much better, thanks. Here are the revised times (BTW, that's a >1.5GHz Pentium M): > >HelloWorld > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 0m1.863s | real 0m1.614s | real 0m0.067s >user 0m1.758s | user 0m1.536s | user 0m0.050s >sys 0m0.103s | sys 0m0.076s | sys 0m0.012s > > >GNU Classpath (cd lib; make) > >ecj | ecj-native | jikes >------------------------------------------------------------- >real 1m24.539s | real 0m24.552s | real 0m9.439s >user 1m23.157s | user 0m23.047s | user 0m7.486s >sys 0m1.142s | sys 0m1.139s | sys 0m0.771s > > What release of eclipse-ecj are you using? Just recently we were able to build Eclipse with -O2 on x86. I'm not sure if the new packages have hit rawhide yet. Tom From ziga.mahkovec at klika.si Wed Mar 9 21:46:43 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Wed, 09 Mar 2005 22:46:43 +0100 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110403931.23370.178.camel@tortoise.toronto.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> <1110403931.23370.178.camel@tortoise.toronto.redhat.com> Message-ID: <1110404803.5553.17.camel@localhost> On Wed, 2005-03-09 at 16:32 -0500, Thomas Fitzsimmons wrote: > On Wed, 2005-03-09 at 22:24 +0100, Ziga Mahkovec wrote: > >GNU Classpath (cd lib; make) > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 1m24.539s | real 0m24.552s | real 0m9.439s > >user 1m23.157s | user 0m23.047s | user 0m7.486s > >sys 0m1.142s | sys 0m1.139s | sys 0m0.771s > > What release of eclipse-ecj are you using? Just recently we were able > to build Eclipse with -O2 on x86. I'm not sure if the new packages have > hit rawhide yet. eclipse-ecj-3.1.0_fc-0.M5.10, which is currently in rawhide. I'll give the new packages a try once they land there; I'm not building the beast myself though, no way :) -- Ziga From fitzsim at redhat.com Wed Mar 9 22:01:45 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Mar 2005 17:01:45 -0500 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <1110403931.23370.178.camel@tortoise.toronto.redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> <1110403931.23370.178.camel@tortoise.toronto.redhat.com> Message-ID: <1110405705.23370.182.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-09 at 16:32 -0500, Thomas Fitzsimmons wrote: >On Wed, 2005-03-09 at 22:24 +0100, Ziga Mahkovec wrote: >>On Wed, 2005-03-09 at 11:38 -0500, Thomas Fitzsimmons wrote: >>> On Wed, 2005-03-09 at 15:04 +0000, Andrew Haley wrote: >>> >I see. Of course, I have no idea why tools.jar is attempting to use >>> >the gcjlib:// class loader, or why it is so slow when it does. It >>> >really should not explicitly use this class loader. >>> >>> I doesn't any more. We were doing that to avoid having to always add >>> jdtcore.jar to the classpath. I also have no idea why it's so slow but >>> I did notice a significant performance hit when compared to interpreted >>> mode. >>> >>> Ziga, you can get the sources for java-gcj-compat from >>> sources.redhat.com: >> >>Ah, much better, thanks. Here are the revised times (BTW, that's a >>1.5GHz Pentium M): >> >>HelloWorld >> >>ecj | ecj-native | jikes >>------------------------------------------------------------- >>real 0m1.863s | real 0m1.614s | real 0m0.067s >>user 0m1.758s | user 0m1.536s | user 0m0.050s >>sys 0m0.103s | sys 0m0.076s | sys 0m0.012s >> >> >>GNU Classpath (cd lib; make) >> >>ecj | ecj-native | jikes >>------------------------------------------------------------- >>real 1m24.539s | real 0m24.552s | real 0m9.439s >>user 1m23.157s | user 0m23.047s | user 0m7.486s >>sys 0m1.142s | sys 0m1.139s | sys 0m0.771s >> >> > >What release of eclipse-ecj are you using? Just recently we were able >to build Eclipse with -O2 on x86. I'm not sure if the new packages have >hit rawhide yet. > They'll be in rawhide tomorrow. Release 3.1.0_fc-0.M5.12 or 3.1.0_fc-0.M5.13. Tom From bob.deblier at telenet.be Thu Mar 10 06:08:19 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Thu, 10 Mar 2005 07:08:19 +0100 Subject: [fedora-java] Self Introduction - Bob Deblier In-Reply-To: References: <1110368089.5528.16.camel@orion> Message-ID: <1110434900.5521.1.camel@orion> On Wed, 2005-03-09 at 14:22 -0700, Tom Tromey wrote: > >>>>> "Bob" == Bob Deblier writes: > > Bob> Support for gcj should be easier once > Bob> libgcj contains javax.crypto - is this planned for 4.0? > > Yes, it is in there. > If your native library uses jni, and you have java-gcj-compat > installed, you can build your code against gcj using the same > build.xml that you would use for the jdk. This is the simplest way > to go. (Well, aside from building a .so and registering it... that > needs gcj-specific code of course) > > If you want to use CNI, to avoid the JNI performance penalty, then > you have to do more work. > > Tom Tom, Thanks for the tips. Right now I'm using JNI but will investigate CNI. Sincerely, Bob From aph at redhat.com Thu Mar 10 12:05:07 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Mar 2005 12:05:07 +0000 Subject: [fedora-java] Using the natively-built Eclipse compiler In-Reply-To: <422F6B3A.5080402@redhat.com> References: <1110105522.15251.49.camel@localhost.localdomain> <1110317537.10580.7.camel@localhost> <422E2EC5.6060907@redhat.com> <1110325286.10580.11.camel@localhost> <16942.57589.638526.568285@cuddles.cambridge.redhat.com> <1110375539.5587.31.camel@localhost> <16943.888.428446.685556@cuddles.cambridge.redhat.com> <1110379143.5587.41.camel@localhost> <16943.3031.961762.318989@cuddles.cambridge.redhat.com> <1110380363.5587.49.camel@localhost> <16943.4204.355394.783901@cuddles.cambridge.redhat.com> <1110386322.23370.159.camel@tortoise.toronto.redhat.com> <1110403455.5553.11.camel@localhost> <422F6B3A.5080402@redhat.com> Message-ID: <16944.14323.685133.873228@cuddles.cambridge.redhat.com> Bryce McKinlay writes: > Ziga Mahkovec wrote: > > >Ah, much better, thanks. Here are the revised times (BTW, that's a > >1.5GHz Pentium M): > > > >HelloWorld > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 0m1.863s | real 0m1.614s | real 0m0.067s > >user 0m1.758s | user 0m1.536s | user 0m0.050s > >sys 0m0.103s | sys 0m0.076s | sys 0m0.012s > > > > > >GNU Classpath (cd lib; make) > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 1m24.539s | real 0m24.552s | real 0m9.439s > >user 1m23.157s | user 0m23.047s | user 0m7.486s > >sys 0m1.142s | sys 0m1.139s | sys 0m0.771s > > > > > >Note that classpath sources need a tiny hack to keep ecj from crashing. > >But that looks like an upstream Eclipse bug, since I could reproduce it > >running ecj with java-1.5.0-sun. > > > >Andrew, I don't suppose you still need oprofile data (or are there other > >places where gcjlib:// loading might be a problem)? It's not so very important now, but it is still interesting. By the way, if you're not used to oprofile: the docs make it look heinously difficult to use, but it's really very easy! The only hard part is reading the docs... I do sudo sh -c 'opcontrol --reset ; opcontrol --start'; ./a.out trash flibber poo; sudo sh -c 'opcontrol --stop' to measure a job, then sudo opreport -l to get the report. It's really that easy. The trouble with very short runtimes like this one is that you might not have enough samples. > The ecj-native times still look somewhat slow. Back in the RHUG days, a > gcj-compiled ecj was faster than jikes at building classpath. Perhaps > the BC-ABI stuff is slowing us down a bit. Yeah. Oprofile might still be interesting. Andrew. From caolanm at redhat.com Thu Mar 10 14:13:17 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 10 Mar 2005 14:13:17 +0000 Subject: [fedora-java] latest gcj (gcc4) and OOo 1.9.84 news Message-ID: <1110463997.9665.8.camel@sheol.homelinux.org> I did another round of testing to see what additionally works or doesn't in OOo2 with gcj from gcc4, and its big progress, which is most excellent. I've enabled the new stuff which is working in OOo workspace gcj3. There are a handful of remaining problems, various temporary workaround patches and testcases where applicable at http://people.redhat.com/caolanm/java/ 1. ooo patched rhino fails to build with gcj tar xvzf rhino15R4.tar.gz cd rhino1_5R4/ patch -p3 < ../rhino1_5R4.patch ant -Dbuild.compiler=gcj -f build.xml ERROR in rhino1_5R4/toolsrc/org/mozilla/javascript/tools/debugger/Main.java (at line 449) [javac] int pos = viewToModel(new Point(popup.x, popup.y)); the scripting module also depends on this rhino module submitted as rh#150772#. I bet this is trivial to fix. 2. complicated problem I don't understand in wizards component registration :-( submitted as rh#150650# temp ooo side wizards.workaround.patch to get past registration 3. canvas module fails to compile a missing "java.awt.Frame.createBufferStrategy" implementation ? 4. gcj's libjawt contains a reference to undefined LINK_ReallyLinkKnownClass Thomas Fitzsimmons is taking care of it. temp ooo side libjawt.workaround.patch to not checkdll bean for gcj, this is a relatively trivial thing as well. ---- unimportant stuff ---- 5. sandbox uses sun.applet.AppletAudioClip and other sun.foo classes, not important, its really a deprecated module 6. sj2 uses some sandbox things so some parts cannot be built, apparently this module is being cleaned up to remove some of this, again not important. From fitzsim at redhat.com Thu Mar 10 16:04:24 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Mar 2005 11:04:24 -0500 Subject: [fedora-java] latest gcj (gcc4) and OOo 1.9.84 news In-Reply-To: <1110463997.9665.8.camel@sheol.homelinux.org> References: <1110463997.9665.8.camel@sheol.homelinux.org> Message-ID: <1110470665.23370.232.camel@tortoise.toronto.redhat.com> On Thu, 2005-03-10 at 14:13 +0000, Caolan McNamara wrote: >I did another round of testing to see what additionally works or doesn't >in OOo2 with gcj from gcc4, and its big progress, which is most >excellent. I've enabled the new stuff which is working in OOo workspace >gcj3. There are a handful of remaining problems, various temporary >workaround patches and testcases where applicable at >http://people.redhat.com/caolanm/java/ > >1. ooo patched rhino fails to build with gcj > >tar xvzf rhino15R4.tar.gz >cd rhino1_5R4/ >patch -p3 < ../rhino1_5R4.patch >ant -Dbuild.compiler=gcj -f build.xml > >ERROR in >rhino1_5R4/toolsrc/org/mozilla/javascript/tools/debugger/Main.java (at >line 449) >[javac] int pos = viewToModel(new Point(popup.x, popup.y)); > >the scripting module also depends on this rhino module >submitted as rh#150772#. I bet this is trivial to fix. > OK, I'll look at this. >2. complicated problem I don't understand in wizards component >registration :-( > submitted as rh#150650# > temp ooo side wizards.workaround.patch to get past registration > >3. canvas module fails to compile > a missing "java.awt.Frame.createBufferStrategy" implementation ? > Can you file a bug for this in RH bugzilla and assign it to me? I'll work on it. >4. gcj's libjawt contains a reference to undefined >LINK_ReallyLinkKnownClass > Thomas Fitzsimmons is taking care of it. > temp ooo side libjawt.workaround.patch to not checkdll bean for >gcj, this is a relatively trivial thing as well. > I'll fix this on GCC HEAD today. >---- unimportant stuff ---- > >5. sandbox uses sun.applet.AppletAudioClip and other sun.foo classes, >not important, its really a deprecated module > I'll see if Tritonus implements this class. If so, I'll package it. I know this is less important but we need Tritonus anyway. Tom From robilad at kaffe.org Thu Mar 10 17:13:18 2005 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 10 Mar 2005 18:13:18 +0100 Subject: [tools-jdk] Re: [fedora-java] latest gcj (gcc4) and OOo 1.9.84 news In-Reply-To: <1110470665.23370.232.camel@tortoise.toronto.redhat.com> References: <1110463997.9665.8.camel@sheol.homelinux.org> <1110470665.23370.232.camel@tortoise.toronto.redhat.com> Message-ID: <4230802E.9090202@kaffe.org> Thomas Fitzsimmons wrote: >>5. sandbox uses sun.applet.AppletAudioClip and other sun.foo classes, >>not important, its really a deprecated module >> > > > I'll see if Tritonus implements this class. If so, I'll package it. I > know this is less important but we need Tritonus anyway. It doesn't afaik. The ooo code there should be really updated to use a sane API or kicked out of the default build. cheers, dalibor topic From tromey at redhat.com Thu Mar 10 18:24:41 2005 From: tromey at redhat.com (Tom Tromey) Date: 10 Mar 2005 11:24:41 -0700 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <20050308205618.GA19940@redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> <20050308154406.GC30854@redhat.com> <20050308205618.GA19940@redhat.com> Message-ID: >>>>> "Joe" == Joe Orton writes: >> gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 Joe> So do I need to file a bug on this issue in Red Hat bugzilla or are is Joe> this "in progress"? I can't enable the Subversion javahl bindings until Joe> this is fixed. Andrew Haley has a list of "gcc bugs we would like fixed in gcc 4.0". I forwarded this to him. He's going to try to get a gcc hacker at RH to fix these (though I don't actually know what criteria he's using to decide what to ask for...). Tom From aph at redhat.com Thu Mar 10 18:31:18 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Mar 2005 18:31:18 +0000 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> <20050308154406.GC30854@redhat.com> <20050308205618.GA19940@redhat.com> Message-ID: <16944.37494.605901.82584@cuddles.cambridge.redhat.com> Tom Tromey writes: > >>>>> "Joe" == Joe Orton writes: > > >> gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 > > Joe> So do I need to file a bug on this issue in Red Hat bugzilla or are is > Joe> this "in progress"? I can't enable the Subversion javahl bindings until > Joe> this is fixed. > > Andrew Haley has a list of "gcc bugs we would like fixed in gcc > 4.0". I forwarded this to him. He's going to try to get a gcc > hacker at RH to fix these (though I don't actually know what > criteria he's using to decide what to ask for...). At the moment, my criterion is "kills a significant number of gcj apps or renders some other feature, such as debugging, useless." Andrew. From fitzsim at redhat.com Thu Mar 10 19:34:54 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Mar 2005 14:34:54 -0500 Subject: [fedora-java] Re: subversion java bindings In-Reply-To: <16944.37494.605901.82584@cuddles.cambridge.redhat.com> References: <1109958617.7344.30.camel@localhost.localdomain> <20050304181454.GA999@redhat.com> <1109960982.7344.38.camel@localhost.localdomain> <20050308110012.GC2587@redhat.com> <1110284867.5352.4.camel@localhost.localdomain> <20050308154406.GC30854@redhat.com> <20050308205618.GA19940@redhat.com> <16944.37494.605901.82584@cuddles.cambridge.redhat.com> Message-ID: <1110483294.23370.238.camel@tortoise.toronto.redhat.com> On Thu, 2005-03-10 at 18:31 +0000, Andrew Haley wrote: >Tom Tromey writes: > > >>>>> "Joe" == Joe Orton writes: > > > > >> gcj bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 > > > > Joe> So do I need to file a bug on this issue in Red Hat bugzilla or are is > > Joe> this "in progress"? I can't enable the Subversion javahl bindings until > > Joe> this is fixed. > > > > Andrew Haley has a list of "gcc bugs we would like fixed in gcc > > 4.0". I forwarded this to him. He's going to try to get a gcc > > hacker at RH to fix these (though I don't actually know what > > criteria he's using to decide what to ask for...). > >At the moment, my criterion is "kills a significant number of gcj apps >or renders some other feature, such as debugging, useless." > You may want to add this one, since it prevents building eclipse on ia64: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294 Tom From ziga.mahkovec at klika.si Fri Mar 11 09:14:48 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 10:14:48 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance Message-ID: <1110532488.5506.1.camel@localhost> I noticed that installing the eclipse-* packages takes really long (around 10 minutes on my laptop). Most of time is spent running gcj- dbtool, doing lots of disk IO. This seemed a bit unusual and after inspecting the gcj-dbtool sources, I found out that in resizeMap(), a new PersistentByteMap is created for each jar package that is added -- amounting to almost 150 several-MB temporary files created. I don't think this was intentional. The attached patch cuts my installation time for eclipse-platform from 7m17s to 1m35s. I've verified that eclipse.db is identical to the old database, so hopefully the patch doesn't break anything. -- Ziga -------------- next part -------------- A non-text attachment was scrubbed... Name: gcj_dbtool.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: From aph at redhat.com Fri Mar 11 10:02:05 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 10:02:05 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <1110532488.5506.1.camel@localhost> References: <1110532488.5506.1.camel@localhost> Message-ID: <16945.27805.194200.716704@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > I noticed that installing the eclipse-* packages takes really long > (around 10 minutes on my laptop). Most of time is spent running gcj- > dbtool, doing lots of disk IO. > > This seemed a bit unusual and after inspecting the gcj-dbtool sources, I > found out that in resizeMap(), a new PersistentByteMap is created for > each jar package that is added -- amounting to almost 150 several-MB > temporary files created. I don't think this was intentional. > > The attached patch cuts my installation time for eclipse-platform from > 7m17s to 1m35s. I've verified that eclipse.db is identical to the old > database, so hopefully the patch doesn't break anything. This is wrong. Other running applications may be accessing a .db file while it is in place, and it is not safe to modify it. The right technique is to copy the old file to a new one, add to the new one, and then rename it. Any processes that have the old one mapped will continue to use it. The problem is that the Eclipse installer is doing things in a very inefficient way. The most efficient way is to generate a separate map for each jar file, and then merge them all at the end. This is very fast. It also has the advantage that the resulting file is more compact. Andrew. From ziga.mahkovec at klika.si Fri Mar 11 10:25:03 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 11:25:03 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.27805.194200.716704@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> Message-ID: <1110536703.5506.34.camel@localhost> On Fri, 2005-03-11 at 10:02 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > This seemed a bit unusual and after inspecting the gcj-dbtool sources, I > > found out that in resizeMap(), a new PersistentByteMap is created for > > each jar package that is added -- amounting to almost 150 several-MB > > temporary files created. I don't think this was intentional. > > This is wrong. > > Other running applications may be accessing a .db file while it is in > place, and it is not safe to modify it. The right technique is to > copy the old file to a new one, add to the new one, and then rename > it. Any processes that have the old one mapped will continue to use > it. Ah, I hadn't thought about that. Probably because this happens during installation, where the database was just created, so I wouldn't expect any consumers yet. But I see your point; this could be a problem for deferred installations of certain eclipse packages. > The problem is that the Eclipse installer is doing things in a very > inefficient way. The most efficient way is to generate a separate map > for each jar file, and then merge them all at the end. This is very > fast. It also has the advantage that the resulting file is more > compact. Maybe this could be further improved by creating a single separate map for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch which triggers the behavior in the patch). Then, only two maps would have to be merged, avoiding the need to create 150 separate maps. -- Ziga From aph at redhat.com Fri Mar 11 10:29:12 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 10:29:12 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <1110536703.5506.34.camel@localhost> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> Message-ID: <16945.29432.336537.26255@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Fri, 2005-03-11 at 10:02 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > This seemed a bit unusual and after inspecting the gcj-dbtool sources, I > > > found out that in resizeMap(), a new PersistentByteMap is created for > > > each jar package that is added -- amounting to almost 150 several-MB > > > temporary files created. I don't think this was intentional. > > > > This is wrong. > > > > Other running applications may be accessing a .db file while it is in > > place, and it is not safe to modify it. The right technique is to > > copy the old file to a new one, add to the new one, and then rename > > it. Any processes that have the old one mapped will continue to use > > it. > > Ah, I hadn't thought about that. Probably because this happens during > installation, where the database was just created, so I wouldn't expect > any consumers yet. But I see your point; this could be a problem for > deferred installations of certain eclipse packages. The gcj-dbtool isn't just used by Eclipse. It has to be safe when adding a jar in a live system. > > The problem is that the Eclipse installer is doing things in a very > > inefficient way. The most efficient way is to generate a separate map > > for each jar file, and then merge them all at the end. This is very > > fast. It also has the advantage that the resulting file is more > > compact. > > Maybe this could be further improved by creating a single separate map > for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch > which triggers the behavior in the patch). Then, only two maps would > have to be merged, avoiding the need to create 150 separate maps. What's the problem with creating 150 separate maps? I don't get it. Andrew. From ziga.mahkovec at klika.si Fri Mar 11 10:37:35 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 11:37:35 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.29432.336537.26255@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> Message-ID: <1110537455.5506.40.camel@localhost> On Fri, 2005-03-11 at 10:29 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > Maybe this could be further improved by creating a single separate map > > for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch > > which triggers the behavior in the patch). Then, only two maps would > > have to be merged, avoiding the need to create 150 separate maps. > > What's the problem with creating 150 separate maps? I don't get it. Fragmentation I guess. Each new map would have to over-allocate enough space for a jar file to avoid resizing. And somehow a single map seems like a cleaner solution. But those are minor issues. Any improvement over the current situation would help. -- Ziga From aph at redhat.com Fri Mar 11 11:30:50 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 11:30:50 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <1110537455.5506.40.camel@localhost> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> <1110537455.5506.40.camel@localhost> Message-ID: <16945.33130.208463.355228@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > On Fri, 2005-03-11 at 10:29 +0000, Andrew Haley wrote: > > Ziga Mahkovec writes: > > > Maybe this could be further improved by creating a single separate map > > > for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch > > > which triggers the behavior in the patch). Then, only two maps would > > > have to be merged, avoiding the need to create 150 separate maps. > > > > What's the problem with creating 150 separate maps? I don't get it. > > Fragmentation I guess. Each new map would have to over-allocate enough > space for a jar file to avoid resizing. No, I don't think that would be a problem. Each file will be sized to be just big enough, and the resulting merged map will also be just big enough. (The existing code could be made more efficient, I grant you: it's silly to create a small map that instantly gets resized.) > And somehow a single map seems like a cleaner solution. But those > are minor issues. Any improvement over the current situation would > help. It should be just fine. Try it. When used as I describe, almost all of the time is spent reading the jar files, not creating the maps. There's nothing you can do about the maps that will make the process any faster. When building jonas, which has 28871 classes in 239 jar files, the whole process takes 1m1.140s on my box. I am very loath to add "unsafe" flags to any program, particularly when there's a simple alternative. Andrew. From overholt at redhat.com Fri Mar 11 13:31:45 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 11 Mar 2005 08:31:45 -0500 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.27805.194200.716704@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> Message-ID: <20050311133145.GB31511@redhat.com> * Andrew Haley [2005-03-11 05:03]: > The problem is that the Eclipse installer is doing things in a very > inefficient way. It would have been nice to hear this before :) > The most efficient way is to generate a separate map for each jar file, > and then merge them all at the end. This is very fast. It also has the > advantage that the resulting file is more compact. The other problem here is that Tom Tromey's -f flag has yet to land in our gcj RPMs. That will allow us to create the dbs in %install and then just merge them in %post so the end user will only see the merging and not the actual creation. Andrew From aph at redhat.com Fri Mar 11 13:34:49 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 13:34:49 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <20050311133145.GB31511@redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <20050311133145.GB31511@redhat.com> Message-ID: <16945.40569.120786.533480@cuddles.cambridge.redhat.com> Andrew Overholt writes: > * Andrew Haley [2005-03-11 05:03]: > > The problem is that the Eclipse installer is doing things in a very > > inefficient way. > > It would have been nice to hear this before :) We're in the development phase. Things change... > > The most efficient way is to generate a separate map for each jar file, > > and then merge them all at the end. This is very fast. It also has the > > advantage that the resulting file is more compact. > > The other problem here is that Tom Tromey's -f flag has yet to land in our > gcj RPMs. That will allow us to create the dbs in %install and then just > merge them in %post so the end user will only see the merging and not the > actual creation. OK. Andrew. From ziga.mahkovec at klika.si Fri Mar 11 13:37:20 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 14:37:20 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.33130.208463.355228@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> <1110537455.5506.40.camel@localhost> <16945.33130.208463.355228@cuddles.cambridge.redhat.com> Message-ID: <1110548240.5506.61.camel@localhost> On Fri, 2005-03-11 at 11:30 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > And somehow a single map seems like a cleaner solution. But those > > are minor issues. Any improvement over the current situation would > > help. > > It should be just fine. Try it. > > When used as I describe, almost all of the time is spent reading the > jar files, not creating the maps. There's nothing you can do about > the maps that will make the process any faster. When building jonas, > which has 28871 classes in 239 jar files, the whole process takes > 1m1.140s on my box. Sounds great, thanks for all the clarifications! Just one final question (I promise (-:). Would it be possible (and make sense) to move the "gcj-dbtool -a" stage from %post to %install? I'm thinking the build system has enough information to compile the map -- when installing the package, only merging would then take place. This would offload most of the disk IO to the build system. -- Ziga From ziga.mahkovec at klika.si Fri Mar 11 13:40:20 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 14:40:20 +0100 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <1110548240.5506.61.camel@localhost> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> <1110537455.5506.40.camel@localhost> <16945.33130.208463.355228@cuddles.cambridge.redhat.com> <1110548240.5506.61.camel@localhost> Message-ID: <1110548420.5506.63.camel@localhost> On Fri, 2005-03-11 at 14:37 +0100, Ziga Mahkovec wrote: > Would it be possible (and make sense) to move the "gcj-dbtool -a" > stage from %post to %install? Oops, must read all mail before replying, never mind :) -- Ziga From vadimn at redhat.com Fri Mar 11 13:52:36 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 11 Mar 2005 08:52:36 -0500 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.27805.194200.716704@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> Message-ID: <200503110852.36433@vadim.nasardinov> On Friday 11 March 2005 05:02, Andrew Haley wrote: > The right technique is to copy the old file to a new one, add to the > new one, and then rename it. Do we have a mechanism in place to enforce serialization of two or more concurrent attempts to apply this technique? From aph at redhat.com Fri Mar 11 13:56:49 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 13:56:49 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <200503110852.36433@vadim.nasardinov> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <200503110852.36433@vadim.nasardinov> Message-ID: <16945.41889.361626.167343@cuddles.cambridge.redhat.com> Vadim Nasardinov writes: > On Friday 11 March 2005 05:02, Andrew Haley wrote: > > The right technique is to copy the old file to a new one, add to the > > new one, and then rename it. > > Do we have a mechanism in place to enforce serialization of two or > more concurrent attempts to apply this technique? No. You'd have to be trying to install two packages simultaneously for this to happen. Don't Do That. Andrew. From vadimn at redhat.com Fri Mar 11 14:06:57 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 11 Mar 2005 09:06:57 -0500 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.41889.361626.167343@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <200503110852.36433@vadim.nasardinov> <16945.41889.361626.167343@cuddles.cambridge.redhat.com> Message-ID: <200503110906.57764@vadim.nasardinov> On Friday 11 March 2005 08:56, Andrew Haley wrote: > > Do we have a mechanism in place to enforce serialization of two > > or more concurrent attempts to apply this technique? > > No. You'd have to be trying to install two packages simultaneously > for this to happen. Don't Do That. I wasn't going to, but someone else might. I'm fine with that. Someone else might not be. So, the assumption is that the only way to modify the db is by installing/uninstalling RPMs. Is that correct? From aph at redhat.com Fri Mar 11 14:10:28 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 14:10:28 +0000 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <200503110906.57764@vadim.nasardinov> References: <1110532488.5506.1.camel@localhost> <200503110852.36433@vadim.nasardinov> <16945.41889.361626.167343@cuddles.cambridge.redhat.com> <200503110906.57764@vadim.nasardinov> Message-ID: <16945.42708.714025.343393@cuddles.cambridge.redhat.com> Vadim Nasardinov writes: > On Friday 11 March 2005 08:56, Andrew Haley wrote: > > > Do we have a mechanism in place to enforce serialization of two > > > or more concurrent attempts to apply this technique? > > > > No. You'd have to be trying to install two packages simultaneously > > for this to happen. Don't Do That. > > I wasn't going to, but someone else might. I'm fine with that. > Someone else might not be. > > So, the assumption is that the only way to modify the db is by > installing/uninstalling RPMs. Is that correct? No, not at all. The assumption is that if you're adding a package to the common shared region, or indeed removing one, it's not a good idea to try doing several at the same time. I'm sure it's possible to do filesystem locking if anyone thing this is necessary. The problem is, of course, that someone might want to do more than one update. Andrew. From tromey at redhat.com Fri Mar 11 17:49:18 2005 From: tromey at redhat.com (Tom Tromey) Date: 11 Mar 2005 10:49:18 -0700 Subject: [fedora-java] default .db for gij Message-ID: FYI, I checked in a patch to gcc that sets the default database for gij. Once this is put in the gcc RPM, you won't need to set the .db on the gij command line. You can use "gcj-dbtool -p" in your spec file to get the name of the default .db. Jakub, libgcj will build and install a default .db. However, I'm not sure we really want to have this file owned by the gcc RPM. It is going to be modified by other RPMs as they are installed... what is the usual thing to do in this situation? Tom From walters at redhat.com Fri Mar 11 18:04:19 2005 From: walters at redhat.com (Colin Walters) Date: Fri, 11 Mar 2005 13:04:19 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: References: Message-ID: <1110564260.4138.1.camel@nexus.verbum.private> On Fri, 2005-03-11 at 10:49 -0700, Tom Tromey wrote: > Jakub, libgcj will build and install a default .db. However, I'm not > sure we really want to have this file owned by the gcc RPM. It is > going to be modified by other RPMs as they are installed... what is > the usual thing to do in this situation? Conceptually it's just a cache right? Why not put it in /var/cache/ somewhere? From pmuldoon at redhat.com Fri Mar 11 18:06:50 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Fri, 11 Mar 2005 12:06:50 -0600 Subject: [fedora-java] default .db for gij In-Reply-To: References: Message-ID: <1110564410.5956.10.camel@localhost.localdomain> On the central db idea (as opposed to having each application having their own db), what happens on a partial disk failure, and e2fsck can't recover inodes that belong to the db? Reinstall all gcj built rpms? How would the user know what to do in that scenario? Do we keep a gzipped backup tucked away somewhere? Also, where would you put it? I imagine it would have to go somewhere on root say /usr/lib? If you put it, I dunno, in /var or somewhere like that, a mount failure would render all gcj apps back to fall back to interpretated. Just two questions that quickly occurred to me. The db almost sounds like it is going to become something akin to a registry like Windows has; I'm not saying that is a bad thing, but a single bad inode can spoil the party. ;) Regards Phil On Fri, 2005-03-11 at 10:49 -0700, Tom Tromey wrote: > FYI, I checked in a patch to gcc that sets the default database for > gij. Once this is put in the gcc RPM, you won't need to set the .db > on the gij command line. > > You can use "gcj-dbtool -p" in your spec file to get the name of the > default .db. > > > Jakub, libgcj will build and install a default .db. However, I'm not > sure we really want to have this file owned by the gcc RPM. It is > going to be modified by other RPMs as they are installed... what is > the usual thing to do in this situation? > > Tom > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From jakub at redhat.com Fri Mar 11 18:11:51 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 11 Mar 2005 13:11:51 -0500 Subject: [fedora-java] Re: default .db for gij In-Reply-To: References: Message-ID: <20050311181151.GB853@devserv.devel.redhat.com> On Fri, Mar 11, 2005 at 10:49:18AM -0700, Tom Tromey wrote: > FYI, I checked in a patch to gcc that sets the default database for > gij. Once this is put in the gcc RPM, you won't need to set the .db > on the gij command line. > > You can use "gcj-dbtool -p" in your spec file to get the name of the > default .db. > > Jakub, libgcj will build and install a default .db. However, I'm not > sure we really want to have this file owned by the gcc RPM. It is > going to be modified by other RPMs as they are installed... what is > the usual thing to do in this situation? It can be say %ghost %config file, populated at libgcj's %post time (as well as %post of other packages). Now, if you are storing full paths of shared libraries, I guess it needs to live in /usr/$LIB/java/ somewhere (so that there are separate 32-bit and 64-bit .db's on say x86-64, ppc*, s390* etc.). Or do you have one .db instead with flags for which ABI a particular library is (like say /etc/ld.so.cache has)? Jakub From aph at redhat.com Fri Mar 11 18:14:04 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 18:14:04 +0000 Subject: [fedora-java] default .db for gij In-Reply-To: <1110564410.5956.10.camel@localhost.localdomain> References: <1110564410.5956.10.camel@localhost.localdomain> Message-ID: <16945.57324.907497.479934@cuddles.cambridge.redhat.com> Phil Muldoon writes: > On the central db idea (as opposed to having each application having > their own db), what happens on a partial disk failure, and e2fsck can't > recover inodes that belong to the db? Reinstall all gcj built rpms? No. Whenever an rpm is installed, the %post should *rebuild* the db from each application's db. It's just a cache. > Also, where would you put it? I imagine it would have to go somewhere > on root say /usr/lib? If you put it, I dunno, in /var or somewhere like > that, a mount failure would render all gcj apps back to fall back to > interpretated. /var/cache/somewhere sounds like a good idea for the central db. Andrew. From tromey at redhat.com Fri Mar 11 18:46:41 2005 From: tromey at redhat.com (Tom Tromey) Date: 11 Mar 2005 11:46:41 -0700 Subject: [fedora-java] Re: default .db for gij In-Reply-To: <20050311181151.GB853@devserv.devel.redhat.com> References: <20050311181151.GB853@devserv.devel.redhat.com> Message-ID: Jakub> Now, if you are storing full paths of shared libraries, I guess Jakub> it needs to live in /usr/$LIB/java/ somewhere (so that there are Jakub> separate 32-bit and 64-bit .db's on say x86-64, ppc*, s390* etc.). Yes, it stores full paths. Right now the default is: ## Where the standard .db file is found. dbexecdir = $(libdir)/gcj- at gcc_version@ ## Name of the default .db. db_name = classmap.db Colin> Conceptually it's just a cache right? Why not put it in Colin> /var/cache/ somewhere? That is fine by me. I think I'd have to resurrect the patch to add a gcc configure option for this, since it seems weird to look in /var/cache in a typical gcc build... ordinarily we're constrained to $prefix. Whatever the gcc and java project packaging folks want here, I will implement. Just let me know. Tom From dmalcolm at redhat.com Fri Mar 11 19:03:10 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 11 Mar 2005 14:03:10 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: <16945.57324.907497.479934@cuddles.cambridge.redhat.com> References: <1110564410.5956.10.camel@localhost.localdomain> <16945.57324.907497.479934@cuddles.cambridge.redhat.com> Message-ID: <1110567790.30553.22.camel@cassandra.boston.redhat.com> On Fri, 2005-03-11 at 18:14 +0000, Andrew Haley wrote: >Phil Muldoon writes: > > On the central db idea (as opposed to having each application having > > their own db), what happens on a partial disk failure, and e2fsck can't > > recover inodes that belong to the db? Reinstall all gcj built rpms? > >No. Whenever an rpm is installed, the %post should *rebuild* the db >from each application's db. It's just a cache. Does this get amortized so that you don't regenerate it for each package in a transaction? Otherwise are we getting O(n^2) work? Dave Malcolm From aph at redhat.com Fri Mar 11 19:04:53 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 19:04:53 +0000 Subject: [fedora-java] default .db for gij In-Reply-To: <1110567790.30553.22.camel@cassandra.boston.redhat.com> References: <1110564410.5956.10.camel@localhost.localdomain> <16945.57324.907497.479934@cuddles.cambridge.redhat.com> <1110567790.30553.22.camel@cassandra.boston.redhat.com> Message-ID: <16945.60373.560272.506562@cuddles.cambridge.redhat.com> David Malcolm writes: > On Fri, 2005-03-11 at 18:14 +0000, Andrew Haley wrote: > >Phil Muldoon writes: > > > On the central db idea (as opposed to having each application having > > > their own db), what happens on a partial disk failure, and e2fsck can't > > > recover inodes that belong to the db? Reinstall all gcj built rpms? > > > >No. Whenever an rpm is installed, the %post should *rebuild* the db > >from each application's db. It's just a cache. > Does this get amortized so that you don't regenerate it for each package > in a transaction? Otherwise are we getting O(n^2) work? It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles and 40,000 classes. Andrew. From vadimn at redhat.com Fri Mar 11 19:46:00 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 11 Mar 2005 14:46:00 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: <16945.60373.560272.506562@cuddles.cambridge.redhat.com> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> Message-ID: <200503111446.00980@vadim.nasardinov> On Friday 11 March 2005 14:04, Andrew Haley wrote: > > Does this get amortized so that you don't regenerate it for each package > > in a transaction? Otherwise are we getting O(n^2) work? > > It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles > and 40,000 classes. That doesn't answer his question though, does it? From tromey at redhat.com Fri Mar 11 20:02:49 2005 From: tromey at redhat.com (Tom Tromey) Date: 11 Mar 2005 13:02:49 -0700 Subject: [fedora-java] default .db for gij In-Reply-To: <16945.57324.907497.479934@cuddles.cambridge.redhat.com> References: <1110564410.5956.10.camel@localhost.localdomain> <16945.57324.907497.479934@cuddles.cambridge.redhat.com> Message-ID: Phil> On the central db idea (as opposed to having each application having Phil> their own db), what happens on a partial disk failure, and e2fsck can't Phil> recover inodes that belong to the db? Reinstall all gcj built rpms? Andrew> No. Whenever an rpm is installed, the %post should *rebuild* the db Andrew> from each application's db. It's just a cache. One thing we've discussed on irc is having either rpm macro support or a script somewhere to do this. The latter is nice if your .db does get hosed -- you could just run the script to fix it. AFAIK this isn't definitively assigned to someone to do yet. And, we would have to decide where to install this thing and what package ought to own it. Tom From tromey at redhat.com Fri Mar 11 20:04:42 2005 From: tromey at redhat.com (Tom Tromey) Date: 11 Mar 2005 13:04:42 -0700 Subject: [fedora-java] default .db for gij In-Reply-To: <200503111446.00980@vadim.nasardinov> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> Message-ID: >> > Does this get amortized so that you don't regenerate it for each package >> > in a transaction? Otherwise are we getting O(n^2) work? >> >> It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles >> and 40,000 classes. Vadim> That doesn't answer his question though, does it? Yeah, the answer right now is "no, we are doing O(n^2) work". At install time we could just merge new .db files into the master .db. Doing this at uninstall time would require more hacks to gcj-dbtool, I think. Maybe it doesn't matter though. Tom From aph at redhat.com Fri Mar 11 20:11:51 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 20:11:51 +0000 Subject: [fedora-java] default .db for gij In-Reply-To: <200503111446.00980@vadim.nasardinov> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> Message-ID: <16945.64391.971735.79620@cuddles.cambridge.redhat.com> Vadim Nasardinov writes: > On Friday 11 March 2005 14:04, Andrew Haley wrote: > > > Does this get amortized so that you don't regenerate it for each package > > > in a transaction? Otherwise are we getting O(n^2) work? > > > > It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles > > and 40,000 classes. > > That doesn't answer his question though, does it? No, it doesn't, but it does suggest that it's a second order effect and so probably not worth worrying about for the time being. There is an N^2 effect, yes. But if we're to do anything more sophisticated maybe RPM will have to have some sort of new functionality. Andrew. From aph at redhat.com Fri Mar 11 20:13:57 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Mar 2005 20:13:57 +0000 Subject: [fedora-java] default .db for gij In-Reply-To: References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> Message-ID: <16945.64517.617603.20926@cuddles.cambridge.redhat.com> Tom Tromey writes: > >> > Does this get amortized so that you don't regenerate it for each package > >> > in a transaction? Otherwise are we getting O(n^2) work? > >> > >> It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles > >> and 40,000 classes. > > Vadim> That doesn't answer his question though, does it? > > Yeah, the answer right now is "no, we are doing O(n^2) work". > > At install time we could just merge new .db files into the master .db. We could, but that requires locking for concurrent access. Probably not a good idea. Andrew. From dmalcolm at redhat.com Fri Mar 11 21:11:02 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 11 Mar 2005 16:11:02 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: <16945.64391.971735.79620@cuddles.cambridge.redhat.com> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> <16945.64391.971735.79620@cuddles.cambridge.redhat.com> Message-ID: <1110575462.30553.35.camel@cassandra.boston.redhat.com> On Fri, 2005-03-11 at 20:11 +0000, Andrew Haley wrote: >Vadim Nasardinov writes: > > On Friday 11 March 2005 14:04, Andrew Haley wrote: > > > > Does this get amortized so that you don't regenerate it for each package > > > > in a transaction? Otherwise are we getting O(n^2) work? > > > > > > It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles > > > and 40,000 classes. > > > > That doesn't answer his question though, does it? > >No, it doesn't, but it does suggest that it's a second order effect >and so probably not worth worrying about for the time being. > >There is an N^2 effect, yes. But if we're to do anything more >sophisticated maybe RPM will have to have some sort of new >functionality. Yeah, I was just being paranoid. IIRC we had some problems on the desktop when regenerating mimetype databases, and scrollkeeper for documentation. I think scrollkeeper was the big offender here, since it wasn't fast, and its database regeneration hook used to bring RPM to its knees (successively regenerating the database for package 1, then for package 2, etc all the way through a transaction) From mckinlay at redhat.com Fri Mar 11 21:24:02 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Fri, 11 Mar 2005 16:24:02 -0500 Subject: [fedora-java] [Patch] Improving gcj-dbtool performance In-Reply-To: <16945.33130.208463.355228@cuddles.cambridge.redhat.com> References: <1110532488.5506.1.camel@localhost> <16945.27805.194200.716704@cuddles.cambridge.redhat.com> <1110536703.5506.34.camel@localhost> <16945.29432.336537.26255@cuddles.cambridge.redhat.com> <1110537455.5506.40.camel@localhost> <16945.33130.208463.355228@cuddles.cambridge.redhat.com> Message-ID: <42320C72.5060705@redhat.com> Andrew Haley wrote: >It should be just fine. Try it. > >When used as I describe, almost all of the time is spent reading the >jar files, not creating the maps. There's nothing you can do about >the maps that will make the process any faster. > > We can have gcj generate the signature for each bytecode class and put it into class metadata at compilation time. That way gcj-dbtool won't need the .jar's. Bryce From dmalcolm at redhat.com Fri Mar 11 21:27:25 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 11 Mar 2005 16:27:25 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: <1110575462.30553.35.camel@cassandra.boston.redhat.com> References: <1110567790.30553.22.camel@cassandra.boston.redhat.com> <16945.60373.560272.506562@cuddles.cambridge.redhat.com> <200503111446.00980@vadim.nasardinov> <16945.64391.971735.79620@cuddles.cambridge.redhat.com> <1110575462.30553.35.camel@cassandra.boston.redhat.com> Message-ID: <1110576445.30553.38.camel@cassandra.boston.redhat.com> On Fri, 2005-03-11 at 16:11 -0500, David Malcolm wrote: >On Fri, 2005-03-11 at 20:11 +0000, Andrew Haley wrote: >>Vadim Nasardinov writes: >> > On Friday 11 March 2005 14:04, Andrew Haley wrote: >> > > > Does this get amortized so that you don't regenerate it for each package >> > > > in a transaction? Otherwise are we getting O(n^2) work? >> > > >> > > It's very fast. 0.7 seconds for all of jonas, and that's 300 jarfiles >> > > and 40,000 classes. >> > >> > That doesn't answer his question though, does it? >> >>No, it doesn't, but it does suggest that it's a second order effect >>and so probably not worth worrying about for the time being. >> >>There is an N^2 effect, yes. But if we're to do anything more >>sophisticated maybe RPM will have to have some sort of new >>functionality. > >Yeah, I was just being paranoid. IIRC we had some problems on the >desktop when regenerating mimetype databases, and scrollkeeper for >documentation. I think scrollkeeper was the big offender here, since it >wasn't fast, and its database regeneration hook used to bring RPM to its >knees (successively regenerating the database for package 1, then for >package 2, etc all the way through a transaction) /me fears he has started something bad here; premature optimization is the root of all evil. From ziga.mahkovec at klika.si Fri Mar 11 22:30:43 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 11 Mar 2005 23:30:43 +0100 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) Message-ID: <1110580244.2342.18.camel@localhost> I upgraded to libgcj-4.0.0-0.32 and eclipse-ecj-3.1.0_fc-0.M5.12. The results for compiling classpath: ecj | ecj-native | jikes ------------------------------------------------------------- real 1m31.786s | real 0m16.207s | real 0m8.423s user 1m22.796s | user 0m14.925s | user 0m7.052s sys 0m1.369s | sys 0m1.020s | sys 0m0.755s (ecj-native went from 24.5s to 16.2s as a result of -O2) I also uploaded oprofiles for ecj[1], ecj-native[2] and ecj-native-with- the-old-gcjlib-tools-jar[3]. Note that I'm running a Centrino so the oprofile driver falls back to timer interrupt mode. [1] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj.log [2] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native.log [3] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native-gcjlib.log -- Ziga From dpaun at rogers.com Fri Mar 11 23:00:40 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Fri, 11 Mar 2005 18:00:40 -0500 Subject: [fedora-java] default .db for gij In-Reply-To: References: Message-ID: <20050311230040.GD5762@rogers.com> On Fri, Mar 11, 2005 at 10:49:18AM -0700, Tom Tromey wrote: > Jakub, libgcj will build and install a default .db. However, I'm not > sure we really want to have this file owned by the gcc RPM. It is > going to be modified by other RPMs as they are installed... what is > the usual thing to do in this situation? Why not install the different .db's into a database.d/ directory like we do for a bunch of things now (like /etc/profile.d). This would make adding/deleting from it much simpler, and it would also help a lot to avoid the O(n^2) recompilation step since we can recompile just based on file timestamps. The dir.d/ stuff works very well in practice, let's be consistent and use it everywhere it applies. -- Dimi. From green at redhat.com Sat Mar 12 00:23:03 2005 From: green at redhat.com (Anthony Green) Date: Fri, 11 Mar 2005 16:23:03 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 Message-ID: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> Here's a solution to jmx problem in rawhide. I hope somebody (gbenson?) can apply it and rebuild the RPMs. Thanks! AG -------- Forwarded Message -------- From: Anthony Green To: Discussion about JPackage project Subject: Re: [JPackage-discuss] [Fwd: mx4j (Was: [fedora-java] tomcat5)] Date: Fri, 11 Mar 2005 16:13:28 -0800 On Fri, 2005-03-11 at 10:43 -0500, Fernando Nasser wrote: > The javamail package already has a 'javamail-monolithic' subpackage with > such a jar file and we are about to do the same for classpathx-mail. > > Following the trend we should have a 'mx4j-monolithic' subpackage. Actually, it turns out that this jar (or something close to it) already exists. The only problem is that the spec file is using "mx4j-jmx.jar" for the alternative instead of just "mx4j.jar". Somebody just needs to apply this patch and rebuild. tomcat5 also needs to be rebuilt, since it actually copies the jmxri alternative jar file into itself as part of the build procedure. AG *** mx4j.spec~ 2005-03-07 01:56:29.000000000 -0800 --- mx4j.spec 2005-03-11 15:36:58.000000000 -0800 *************** *** 209,219 **** rm -f %{_javadir}/%{name}.jar %post ! /usr/sbin/update-alternatives --install %{_javadir}/jmxri.jar jmxri %{_javadir}/%{name}/%{name}-jmx.jar 0 %postun if [ "$1" = "0" ]; then ! /usr/sbin/update-alternatives --remove jmxri %{_javadir}/%{name}/%{name}-jmx.jar fi --- 209,219 ---- rm -f %{_javadir}/%{name}.jar %post ! /usr/sbin/update-alternatives --install %{_javadir}/jmxri.jar jmxri %{_javadir}/%{name}/%{name}.jar 0 %postun if [ "$1" = "0" ]; then ! /usr/sbin/update-alternatives --remove jmxri %{_javadir}/%{name}/%{name}.jar fi AG From aph at redhat.com Sat Mar 12 11:55:05 2005 From: aph at redhat.com (Andrew Haley) Date: Sat, 12 Mar 2005 11:55:05 +0000 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <1110580244.2342.18.camel@localhost> References: <1110580244.2342.18.camel@localhost> Message-ID: <16946.55449.39039.200659@cuddles.cambridge.redhat.com> Ziga Mahkovec writes: > I upgraded to libgcj-4.0.0-0.32 and eclipse-ecj-3.1.0_fc-0.M5.12. > The results for compiling classpath: > > ecj | ecj-native | jikes > ------------------------------------------------------------- > real 1m31.786s | real 0m16.207s | real 0m8.423s > user 1m22.796s | user 0m14.925s | user 0m7.052s > sys 0m1.369s | sys 0m1.020s | sys 0m0.755s > > (ecj-native went from 24.5s to 16.2s as a result of -O2) > > I also uploaded oprofiles for ecj[1], ecj-native[2] and ecj-native-with- > the-old-gcjlib-tools-jar[3]. > > Note that I'm running a Centrino so the oprofile driver falls back to > timer interrupt mode. > > [1] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj.log > [2] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native.log > [3] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native-gcjlib.log Thank you very much for doing this. It's very useful. Jikes is famously fast, so I'm fairly pleased to see we're close. It says here: "[Jikes] is astoundingly fast -- hundreds of thousands of lines of code per minute (about ten times faster than other compilers)" There are some surprises here. Is ecj fully interpreted code? _Jv_InterpMethod::run seems only to take 0.0036% of the time. I'm going to investigate some more. I'm sure that ecj-native isn't purely native code, because of this line: 399 2.2024 libgcj.so.6.0.0 _Jv_BytecodeVerifier::verify_instructions_0() which is weird. Thanks again, Andrew. From gbenson at redhat.com Mon Mar 14 14:12:33 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Mar 2005 14:12:33 +0000 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050314141232.GC14998@redhat.com> I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make JPackage patches. Cheers, Gary Anthony Green wrote: > Here's a solution to jmx problem in rawhide. I hope somebody > (gbenson?) can apply it and rebuild the RPMs. > > Thanks! > > AG > > -------- Forwarded Message -------- > From: Anthony Green > To: Discussion about JPackage project > Subject: Re: [JPackage-discuss] [Fwd: mx4j (Was: [fedora-java] tomcat5)] > Date: Fri, 11 Mar 2005 16:13:28 -0800 > On Fri, 2005-03-11 at 10:43 -0500, Fernando Nasser wrote: > > The javamail package already has a 'javamail-monolithic' subpackage with > > such a jar file and we are about to do the same for classpathx-mail. > > > > Following the trend we should have a 'mx4j-monolithic' subpackage. > > Actually, it turns out that this jar (or something close to it) already > exists. The only problem is that the spec file is using "mx4j-jmx.jar" > for the alternative instead of just "mx4j.jar". > > Somebody just needs to apply this patch and rebuild. tomcat5 also needs > to be rebuilt, since it actually copies the jmxri alternative jar file > into itself as part of the build procedure. > > AG > > > *** mx4j.spec~ 2005-03-07 01:56:29.000000000 -0800 > --- mx4j.spec 2005-03-11 15:36:58.000000000 -0800 > *************** > *** 209,219 **** > rm -f %{_javadir}/%{name}.jar > > %post > ! /usr/sbin/update-alternatives --install %{_javadir}/jmxri.jar jmxri %{_javadir}/%{name}/%{name}-jmx.jar 0 > > %postun > if [ "$1" = "0" ]; then > ! /usr/sbin/update-alternatives --remove jmxri %{_javadir}/%{name}/%{name}-jmx.jar > fi > > > --- 209,219 ---- > rm -f %{_javadir}/%{name}.jar > > %post > ! /usr/sbin/update-alternatives --install %{_javadir}/jmxri.jar jmxri %{_javadir}/%{name}/%{name}.jar 0 > > %postun > if [ "$1" = "0" ]; then > ! /usr/sbin/update-alternatives --remove jmxri %{_javadir}/%{name}/%{name}.jar > fi > > > > > AG From green at redhat.com Mon Mar 14 15:40:08 2005 From: green at redhat.com (Anthony Green) Date: Mon, 14 Mar 2005 07:40:08 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <20050314141232.GC14998@redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> Message-ID: <1110814808.5273.5.camel@localhost.localdomain> On Mon, 2005-03-14 at 14:12 +0000, Gary Benson wrote: > I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and > tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make > JPackage patches. OK, thanks. I don't see it in rawhide yet. Do you know how long this takes? AG From overholt at redhat.com Mon Mar 14 15:50:36 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 14 Mar 2005 10:50:36 -0500 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110814808.5273.5.camel@localhost.localdomain> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110814808.5273.5.camel@localhost.localdomain> Message-ID: <20050314155036.GA27584@redhat.com> * Anthony Green [2005-03-14 10:47]: > On Mon, 2005-03-14 at 14:12 +0000, Gary Benson wrote: > > I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and > > tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make > > JPackage patches. > > OK, thanks. I don't see it in rawhide yet. Do you know how long this > takes? I think the push happens at 5:30 AM EST each day and it takes a few hours. I could be wrong, though. Andrew From Nicolas.Mailhot at laPoste.net Mon Mar 14 19:13:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 14 Mar 2005 20:13:07 +0100 Subject: [fedora-java] Re: [JPackage-discuss] XSLT limitations (was: Re: Recursive Classpath Thing) In-Reply-To: <20050314160948.GF14998@redhat.com> References: <1110404694.5536.42.camel@localhost.localdomain> <20050314111515.GB14998@redhat.com> <6013.192.54.193.137.1110799386.squirrel@rousalka.dyndns.org> <200503140841.38596@vadim.nasardinov> <11685.192.54.193.137.1110808665.squirrel@rousalka.dyndns.org> <20050314141450.GD14998@redhat.com> <10539.192.54.193.137.1110810361.squirrel@rousalka.dyndns.org> <20050314144424.GE14998@redhat.com> <12365.192.54.193.137.1110812247.squirrel@rousalka.dyndns.org> <20050314160948.GF14998@redhat.com> Message-ID: <1110827589.2046.52.camel@rousalka.dyndns.org> Le lundi 14 mars 2005 ? 16:09 +0000, Gary Benson a ?crit : > Before I jump in feet first, can I clarify what the ultimate goal is. > As far as I see it, currently the command "build-classpath bcel" will > print out "/usr/share/java/bcel.jar". You would like it to print out > "/usr/share/java/regexp.jar:/usr/share/java/bcel.jar". Am I correct? Ok, you asked it you'll get it;) CC-ing fedora-devel-java, Steve Cohen (who also expressed some interest lately) and the common java packaging list (since I do believe this is larger than JPackage alone and is cojapas material at least). The ultimate goal as you write is to generate a classic /usr/share/java/regexp.jar:/usr/share/java/bcel.jar classpath (or populate a directory with jar symlinks, those being the two main ways an application creates its own classpath). A lot of people me included feel you can't create classpathes like this from the jar files alone, and you need additional metadata, probably in standalone files like is already the case for various Unix systems. There is broad agreement on what those files should contain. A lesser number of people want these standalone files to be in XML. I'm among this group, mainly because we will have to deal with windows users at some point and I don't even want to deal with problems like CRLF in 2005. I'll describe now broadly what I personally think these XML files contents should be. The thing that converts these files to the aforementioned path is left to your discretion. Like you rightly wrote, once such an engine is written and proves the validity of the approach it can be rewritten in other langages. The main thing is not to have to rewrite all the description files all the times, and keep the output stable so startup scripts do not need rewriting either. 1. a single XML file should describe one classpath unit provided by a given project. 2. a classpath unit is most of the times a jar file or a set of jar files. But it is not always the case : it can also contain stuff like property files, xml files, even sometimes resources like sound files, icons, etc 3. on some platforms all those files are lumped in a single per-app dir. On others like Linux common conventions like the FHS mandate separation of configuration and data parts 4. likewise on multi-user systems separate users must be able to overload the configuration parts transparently 5. lastly while the configuration of an infrastructure is often system-wide in scope, sometimes it's very useful to be able to overload it on a per-app basis (a common example would be log4j - you don't want all the apps in the system share the same log files, even if you want them to share the log4j code) 6. therefore while a classpath unit descriptor should list the files that compose it, exact file location should be left to separate policy files (for example given a set of files search the jars in /usr/share/java, the .properties in the same dir then ~/.java then /etc/java, etc) 7. when a classpath unit is an implementation of a common java infrastructure like jmx it should declare it 8. this means the possibility of simultaneous installations of several implementations of the same thing on a given system exists. While some objective factors like jvm compatibility (I'll get to this point later) can be used to choose a particular implementations, sometimes you'll just have several valid choices. It is probably very dangerous to let classpath units self-declare their relative priorities (everyone would want to be king). Therefore we need separate policy files that list implementation priorities (probably distro specific, maybe overloadable by the user, should list all known implementations to be effective and the system then should choose between the implementations actually present) 9. a particular classpath unit must list all the other classpath units it depends on. Some of them might be mandatory (won't work without them) others might be opportunistic (use them if they're here, if not the app will still work without them) 10. a particular classpath unit might use jni and require a particular library to be in the app library path (now since we've already decided to output a java classpath, I don't know if it's better to do such resolution in a separate utility that takes a classpath in input and outputs a LD_LIBRARY_PATH, if you use the same command to output one of them depending on a CLI parameter or if you always output two lines, one with the classpath the other with the LD_LIBRARY_PATH. And apps like tomcat that want directories of jars are yet another problem) 11. a particular classpath unit might use some features of the java langage only found on some java language versions and require the jvm to support them 12. a particular classpath unit might work with some jvms only - the extreme case being in-jvm implementations that only work with a single jvm (yes I think in-jvm libraries need to be covered by the xml descriptors too) 13 sometimes you may need to generate your classpath in separate bits (for example an ant build.xml where some targets require additional jars like junit - they'll need their path in pieces but the pieces must be compatible with each other) 14 sometimes a classpath unit has a direct influence on some othe jvm parameters like memory sizing 15 you need to handle classpath unit versionning- given the problem scope managing version ranges is probably best. 16 lots of other considerations that are eluding me right now but will come to light later. The main point is classpath building is _hard_, this is largely hidden by the fact classpathes are by and large manually written right now, but if we want to automate this we must remember it. When writing a classpath builder you have to remember you may need to add some rules later, so under-specifying is probably a bad idea. Given all this the xml files I started working on looked like this : And this : The exact element hierarchy can be probably hammered on while writing the actual implementation. As long as all the elements are present in the files mass syntax changing can be handled by xslt later. I hope I haven't disgusted you and you still want to work on the problem. If you still have questions don't hesitate to ask. For now I'm closing this post before writing a novel. Regards, -- Nicolas Mailhot -------------- 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 green at redhat.com Tue Mar 15 15:40:38 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 07:40:38 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <20050314141232.GC14998@redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> Message-ID: <1110901238.7168.21.camel@localhost.localdomain> On Mon, 2005-03-14 at 14:12 +0000, Gary Benson wrote: > I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and > tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make > JPackage patches. Ok, thanks - that fixed the jmxri problem. tomcat5 still doesn't run out of the box. You need to do this first: $ cd /usr/lib/jvm-exports/java-1.4.2-gcj $ ln -s /usr/share/java/libgcj-4.0.0.jar jaas.jar $ ln -s /usr/share/java/libgcj-4.0.0.jar jdbc-stdext.jar $ ln -s /usr/share/java/libgcj-4.0.0.jar jndi.jar $ ln -s /usr/share/java/libgcj-4.0.0.jar jta.jar fitzsim has gcj-java-compat patches for this (except for the jta line), but it sounded like he wanted to wait until after FC4test1 was branched before putting them in. Tom: why? But now I'm seeing JSP related problems. Our java compiler doesn't recognize the -extdirs option it's being passed. I had no problem when I tried JSP sample programs before this (on a different machine). Did you tweak anything else? AG From overholt at redhat.com Tue Mar 15 17:36:27 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 12:36:27 -0500 Subject: [fedora-java] failing jar compilation Message-ID: <20050315173627.GB29844@redhat.com> Hi, Eclipse has now changed their build procedures to bootstrap like so: A. build ecj itself with a pre-existing java compiler B. build ecj with output 1. C. use output of 2. to build rest of Eclipse We've modified like this: 1. a. build "franken-ecj" with gcj -C b. natively-compile 1a. 2. a. use output of 1. to build ecj a la A. above b. natively-compile 2a. 3. a. use output of 2. to build ecj a la B. above b. natively-compile 3b. 4. use output of 3. to build rest of Eclipse However, with both gcc head and our latest gcc-java RPMs (gcc-java-4.0.0-0.33), 3b. is failing for me: $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o ecj.withecj.jar.so ecj.withecj.jar org/eclipse/jdt/core/CheckDebugAttributes.java: In class 'org.eclipse.jdt.core.CheckDebugAttributes': org/eclipse/jdt/core/CheckDebugAttributes.java: In constructor '()': org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=5: premature end of bytecode org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: premature end of bytecode org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: branch to middle of instruction org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=5: premature end of bytecode org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: premature end of bytecode org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=7: stack sizes differ org/eclipse/jdt/core/CheckDebugAttributes.java:0: internal compiler error: Segmentation fault As opposed to: $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o ecj.withjavac.jar.so ecj.withjavac.jar $ Anyone have any ideas? I've put the two jars at [1] until I can narrow it down for a proper bug report. Andrew [1] http://people.redhat.com/overholt/ecj.withecj.jar http://people.redhat.com/overholt/ecj.withjavac.jar From green at redhat.com Tue Mar 15 18:38:05 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 10:38:05 -0800 Subject: [fedora-java] failing jar compilation In-Reply-To: <20050315173627.GB29844@redhat.com> References: <20050315173627.GB29844@redhat.com> Message-ID: <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-15 at 12:36 -0500, Andrew Overholt wrote: > Hi, > > Eclipse has now changed their build procedures to bootstrap like so: > > A. build ecj itself with a pre-existing java compiler > B. build ecj with output 1. > C. use output of 2. to build rest of Eclipse > > We've modified like this: > > 1. a. build "franken-ecj" with gcj -C > b. natively-compile 1a. > 2. a. use output of 1. to build ecj a la A. above > b. natively-compile 2a. > 3. a. use output of 2. to build ecj a la B. above > b. natively-compile 3b. > 4. use output of 3. to build rest of Eclipse > > However, with both gcc head and our latest gcc-java RPMs > (gcc-java-4.0.0-0.33), 3b. is failing for me: Why bother compiling to bytecode in the stage 1? We can avoid this bug by simply compiling straight to native code from the java source. AG From overholt at redhat.com Tue Mar 15 18:46:30 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 13:46:30 -0500 Subject: [fedora-java] failing jar compilation In-Reply-To: <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050315184630.GD29844@redhat.com> * Anthony Green [2005-03-15 13:43]: > On Tue, 2005-03-15 at 12:36 -0500, Andrew Overholt wrote: > > 1. a. build "franken-ecj" with gcj -C > > b. natively-compile 1a. > Why bother compiling to bytecode in the stage 1? We can avoid this bug > by simply compiling straight to native code from the java source. Yeah, good one. I'll do that. Andrew From overholt at redhat.com Tue Mar 15 18:50:08 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 13:50:08 -0500 Subject: [fedora-java] failing jar compilation In-Reply-To: <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050315185008.GE29844@redhat.com> * Anthony Green [2005-03-15 13:43]: > > Why bother compiling to bytecode in the stage 1? We can avoid this bug > by simply compiling straight to native code from the java source. Actually, on second thought, I don't know if this will work. We need the system's java-gcj-compat to use the ecj we've just built (with gcj) and the only way I can think of doing this is by setting GCJ_PROPERTIES. I guess I could compile the stuff to a binary called "javac" and set PATH=.:$PATH, but I'm not sure some of the stuff provided by java-gcj-compat won't fail. Andrew From fitzsim at redhat.com Tue Mar 15 18:55:34 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 15 Mar 2005 13:55:34 -0500 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110901238.7168.21.camel@localhost.localdomain> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110901238.7168.21.camel@localhost.localdomain> Message-ID: <1110912934.3852.5.camel@tortoise.toronto.redhat.com> On Tue, 2005-03-15 at 07:40 -0800, Anthony Green wrote: > On Mon, 2005-03-14 at 14:12 +0000, Gary Benson wrote: > > I've built this into dist-fc4 (mx4j-2.1.0-1jpp_2fc and > > tomcat5-5.0.30-1jpp_2fc). Let me know if it works, and I'll make > > JPackage patches. > > Ok, thanks - that fixed the jmxri problem. > > tomcat5 still doesn't run out of the box. You need to do this first: > > $ cd /usr/lib/jvm-exports/java-1.4.2-gcj > $ ln -s /usr/share/java/libgcj-4.0.0.jar jaas.jar > $ ln -s /usr/share/java/libgcj-4.0.0.jar jdbc-stdext.jar > $ ln -s /usr/share/java/libgcj-4.0.0.jar jndi.jar > $ ln -s /usr/share/java/libgcj-4.0.0.jar jta.jar > > fitzsim has gcj-java-compat patches for this (except for the jta line), > but it sounded like he wanted to wait until after FC4test1 was branched > before putting them in. Tom: why? > I didn't want to destabilize things right before FC4test1, since I made a bunch of changes to support adding security providers. I'll commit them today. > But now I'm seeing JSP related problems. Our java compiler doesn't > recognize the -extdirs option it's being passed. I had no problem when > I tried JSP sample programs before this (on a different machine). Did > you tweak anything else? > I committed your -extdirs patches to java-gcj-compat -- I'm not sure if they would cause JSP failures though. Tom > AG > > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From overholt at redhat.com Tue Mar 15 19:35:21 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 14:35:21 -0500 Subject: [fedora-java] Re: Eclipse on s390{,x} In-Reply-To: <1109805346.5081.6.camel@localhost.localdomain> References: <20050302211247.GD29000@redhat.com> <1109805346.5081.6.camel@localhost.localdomain> Message-ID: <20050315193521.GF29844@redhat.com> * Ben Konrath [2005-03-02 18:15]: > > On Wed, 2005-02-03 at 16:12 -0500, Andrew Overholt wrote: > > > Ideally we'd contribute this work back upstream to the Eclipse Foundation, > > but I think Ben Konrath mentioned something about doing that requiring > > machines or builds or something? Ben, any comments on that? > > Here are the upstream instructions: > > http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-releng-home/contributingEclipsePorts.html?rev=HEAD&content-type=text/html > > I'm not sure if anybody is doing this right now, but I have seen > references indicating that contributed builds will be available in the > near future. I did the work to patch for building on s390 and s390x. I don't know oif we'll be able to contribute the builds back, though, 'cause we don't have any machines (outside of the build ones) on which we can run tests. Andrew From overholt at redhat.com Tue Mar 15 19:39:17 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 14:39:17 -0500 Subject: [fedora-java] Automated Eclipse tests In-Reply-To: References: <1110055451.15721.13.camel@localhost> <1110181236.28220.4.camel@localhost.localdomain> <1110208669.10581.11.camel@localhost> <1110234039.5456.7.camel@localhost.localdomain> <20050308031504.GJ29253@rogers.com> <20050308154055.GB30854@redhat.com> <422DC9D1.5090702@redhat.com> Message-ID: <20050315193916.GH29844@redhat.com> * Tom Tromey [2005-03-08 13:25]: > Bryce> Is resources.jar still used entirely uncompiled? We > Bryce> should perhaps concentrate on that bug first. > > I think this bug is still undiagnosed. Actually, it seems to work now (on i386 and ppc, at least)! Andrew From green at redhat.com Tue Mar 15 20:08:06 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 12:08:06 -0800 Subject: [fedora-java] failing jar compilation In-Reply-To: <20050315185008.GE29844@redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050315185008.GE29844@redhat.com> Message-ID: <1110917286.5879.2.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-15 at 13:50 -0500, Andrew Overholt wrote: > * Anthony Green [2005-03-15 13:43]: > > > > Why bother compiling to bytecode in the stage 1? We can avoid this bug > > by simply compiling straight to native code from the java source. > > Actually, on second thought, I don't know if this will work. We need the > system's java-gcj-compat to use the ecj we've just built (with gcj) and the > only way I can think of doing this is by setting GCJ_PROPERTIES. > > I guess I could compile the stuff to a binary called "javac" and set > PATH=.:$PATH, but I'm not sure some of the stuff provided by > java-gcj-compat won't fail. I'm not sure I understand. For the stage2 build, were you expecting to use java-gcj-compat and a classmap database to get the stage1 built compiler? In that case you could simple compile the stage1 bytecode _after_ you build the native code. AG From green at redhat.com Tue Mar 15 20:14:32 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 12:14:32 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110912934.3852.5.camel@tortoise.toronto.redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110901238.7168.21.camel@localhost.localdomain> <1110912934.3852.5.camel@tortoise.toronto.redhat.com> Message-ID: <1110917673.5879.6.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-15 at 13:55 -0500, Thomas Fitzsimmons wrote: > > tomcat5 still doesn't run out of the box. You need to do this first: > > > > $ cd /usr/lib/jvm-exports/java-1.4.2-gcj > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jaas.jar > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jdbc-stdext.jar > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jndi.jar > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jta.jar [snip] > I didn't want to destabilize things right before FC4test1, since I made > a bunch of changes to support adding security providers. I'll commit > them today. Could also please add the jta.jar symlink, and make java-gcj-compat Provide jta? [snip] > > I committed your -extdirs patches to java-gcj-compat -- I'm not sure if > they would cause JSP failures though. I don't know either. I may have time to look into this tomorrow. AG From fitzsim at redhat.com Tue Mar 15 21:16:42 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 15 Mar 2005 16:16:42 -0500 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110917673.5879.6.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110901238.7168.21.camel@localhost.localdomain> <1110912934.3852.5.camel@tortoise.toronto.redhat.com> <1110917673.5879.6.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1110921402.3852.9.camel@tortoise.toronto.redhat.com> On Tue, 2005-03-15 at 12:14 -0800, Anthony Green wrote: > On Tue, 2005-03-15 at 13:55 -0500, Thomas Fitzsimmons wrote: > > > tomcat5 still doesn't run out of the box. You need to do this first: > > > > > > $ cd /usr/lib/jvm-exports/java-1.4.2-gcj > > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jaas.jar > > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jdbc-stdext.jar > > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jndi.jar > > > $ ln -s /usr/share/java/libgcj-4.0.0.jar jta.jar > [snip] > > I didn't want to destabilize things right before FC4test1, since I made > > a bunch of changes to support adding security providers. I'll commit > > them today. > > Could also please add the jta.jar symlink, and make java-gcj-compat > Provide jta? > Done. Try java-1.4.2-gcj-compat-1.4.2.0-40jpp_11rh. Tom From overholt at redhat.com Tue Mar 15 21:58:34 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 16:58:34 -0500 Subject: [fedora-java] failing jar compilation In-Reply-To: <1110917286.5879.2.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050315185008.GE29844@redhat.com> <1110917286.5879.2.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050315215834.GK29844@redhat.com> * Anthony Green [2005-03-15 15:16]: > On Tue, 2005-03-15 at 13:50 -0500, Andrew Overholt wrote: > > * Anthony Green [2005-03-15 13:43]: > > > > > > Why bother compiling to bytecode in the stage 1? We can avoid this bug > > > by simply compiling straight to native code from the java source. > > > > Actually, on second thought, I don't know if this will work. We need the > > system's java-gcj-compat to use the ecj we've just built (with gcj) and the > > only way I can think of doing this is by setting GCJ_PROPERTIES. > > > > I guess I could compile the stuff to a binary called "javac" and set > > PATH=.:$PATH, but I'm not sure some of the stuff provided by > > java-gcj-compat won't fail. > > I'm not sure I understand. For the stage2 build, were you expecting to > use java-gcj-compat and a classmap database to get the stage1 built > compiler? Yes. > In that case you could simple compile the stage1 bytecode _after_ you > build the native code. :) Good point. I will try that. Does anyone have any comments about my original problem? That's stopping me from progressing with this since and it means that I can't build eclipse right now. Andrew From green at redhat.com Tue Mar 15 22:08:16 2005 From: green at redhat.com (Anthony Green) Date: Tue, 15 Mar 2005 14:08:16 -0800 Subject: [fedora-java] failing jar compilation In-Reply-To: <20050315215834.GK29844@redhat.com> References: <20050315173627.GB29844@redhat.com> <1110911885.5201.1.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050315185008.GE29844@redhat.com> <1110917286.5879.2.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050315215834.GK29844@redhat.com> Message-ID: <1110924496.5879.32.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-15 at 16:58 -0500, Andrew Overholt wrote: > Does anyone have any comments about my original problem? That's stopping > me from progressing with this since and it means that I can't build eclipse > right now. Oh man - I'm sorry. I totally misread your mail. I thought it was 1b that was failing, not 3b. Ignore everything I wrote in this thread :-) I have no idea what the problem is. It might be worth running that bytecode through another verifier to see if the bytecode really is wrong. AG From overholt at redhat.com Wed Mar 16 00:55:54 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 19:55:54 -0500 Subject: [fedora-java] Eclipse launcher icon.xpm Message-ID: <20050316005554.GB27876@redhat.com> Hi, I encountered a problem with the Eclipse build procedure a while back where it was getting confused on non-x86{,_64} platforms with icon.xpm. One of the Eclipse developers is asking for input on the situation since apparently icon.xpm doesn't do anything on linux. Does anyone know anything about this? https://bugs.eclipse.org/bugs/show_bug.cgi?id=86848 Thanks, Andrew From overholt at redhat.com Wed Mar 16 01:01:07 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Mar 2005 20:01:07 -0500 Subject: [fedora-java] "Notable features of FC4test1 include:" Message-ID: <20050316010107.GC27876@redhat.com> At [1]: "Notable features of FC4test1 include: [...] . The Eclipse IDE included along with some featured plugins . A solid foundation of Java packages for developers (ant, gcj, tomcat, struts, more classpath stuff) and the ability to possibly run Java apps through gij. [...]" :) Andrew [1] http://www.linuxcompatible.org/story43567.html From mark at klomp.org Wed Mar 16 09:57:47 2005 From: mark at klomp.org (Mark Wielaard) Date: Wed, 16 Mar 2005 10:57:47 +0100 Subject: [fedora-java] "Notable features of FC4test1 include:" In-Reply-To: <20050316010107.GC27876@redhat.com> References: <20050316010107.GC27876@redhat.com> Message-ID: <1110967067.4612.6.camel@localhost.localdomain> Hi, On Tue, 2005-03-15 at 20:01 -0500, Andrew Overholt wrote: > At [1]: > > "Notable features of FC4test1 include: > [...] > . The Eclipse IDE included along with some featured plugins > . A solid foundation of Java packages for developers (ant, gcj, tomcat, > struts, more classpath stuff) and the ability to possibly run Java apps > through gij. > [...]" > > :) And at [2] one of the comments is just: "Well, I'm going to try just for the super cool GCJ support" What I found interesting and encouraging was: . gcc 4.0 as the primary system compiler If that works well and all packages in the system have already been compiled with 4.0 then we are a lot closer to the new gcc release then I had realised. Awesome! Keep up the good work, Mark [2] http://lwn.net/Articles/127694/ -------------- 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 aph at redhat.com Wed Mar 16 11:17:01 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Mar 2005 11:17:01 +0000 Subject: [fedora-java] failing jar compilation In-Reply-To: <20050315173627.GB29844@redhat.com> References: <20050315173627.GB29844@redhat.com> Message-ID: <16952.5549.112273.756948@cuddles.cambridge.redhat.com> Andrew Overholt writes: > > However, with both gcc head and our latest gcc-java RPMs > (gcc-java-4.0.0-0.33), 3b. is failing for me: > > $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o ecj.withecj.jar.so ecj.withecj.jar > org/eclipse/jdt/core/CheckDebugAttributes.java: In class 'org.eclipse.jdt.core.CheckDebugAttributes': > org/eclipse/jdt/core/CheckDebugAttributes.java: In constructor '()': > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=5: premature end of bytecode > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: premature end of bytecode > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: branch to middle of instruction > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=5: premature end of bytecode > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=6: premature end of bytecode > org/eclipse/jdt/core/CheckDebugAttributes.java:0: error: verification failed at PC=7: stack sizes differ > org/eclipse/jdt/core/CheckDebugAttributes.java:0: internal compiler error: Segmentation fault > > As opposed to: > > $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o ecj.withjavac.jar.so ecj.withjavac.jar > $ > > Anyone have any ideas? I've put the two jars at [1] until I can narrow it > down for a proper bug report. > > Andrew > > [1] > http://people.redhat.com/overholt/ecj.withecj.jar > http://people.redhat.com/overholt/ecj.withjavac.jar $ fastjar tf ~/ecj.withecj.jar | sort META-INF/ META-INF/MANIFEST.MF org/ org/eclipse/ org/eclipse/jdt/ org/eclipse/jdt/core/ org/eclipse/jdt/core/CheckDebugAttributes.class org/eclipse/jdt/core/CheckDebugAttributes.class Yeah. I know gcj should give a better error message. Nonetheless, the cause of the problem is pretty obvious. Andrew. From rmoseley at redhat.com Wed Mar 16 13:26:12 2005 From: rmoseley at redhat.com (Rick Moseley) Date: Wed, 16 Mar 2005 07:26:12 -0600 Subject: [fedora-java] Eclipse launcher icon.xpm In-Reply-To: <20050316005554.GB27876@redhat.com> References: <20050316005554.GB27876@redhat.com> Message-ID: <423833F4.6070502@redhat.com> Andrew Overholt wrote: >Hi, > >I encountered a problem with the Eclipse build procedure a while back where >it was getting confused on non-x86{,_64} platforms with icon.xpm. One of >the Eclipse developers is asking for input on the situation since >apparently icon.xpm doesn't do anything on linux. Does anyone know >anything about this? > > During my recent travels through the wondrous world of Eclipse icons trying to figure out how to make our own icon appearance more consistent in response to https://bugzilla.redhat.com/beta/show_bug.cgi?id=146484 I could not find where this icon.xpm was used. It is a 48x48 pixel icon, so it is fairly large and there are not many of that size used in Eclipse. Most of the icons used are of the 16x16 pixel variety and it seems each plugin has its own icon set. *Most* of the time the Eclipse icon is named "eclipse16.gif" or just "eclipse.gif" inside these plugins, so it is basically a nightmare if someone wants to replace with their own set. Rick >https://bugs.eclipse.org/bugs/show_bug.cgi?id=86848 > >Thanks, > >Andrew > >-- >fedora-devel-java-list mailing list >fedora-devel-java-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > > From green at redhat.com Wed Mar 16 16:21:12 2005 From: green at redhat.com (Anthony Green) Date: Wed, 16 Mar 2005 08:21:12 -0800 Subject: [fedora-java] Solution to the jmxri/mx4j problem in tomcat5 In-Reply-To: <1110921402.3852.9.camel@tortoise.toronto.redhat.com> References: <1110586983.5157.37.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050314141232.GC14998@redhat.com> <1110901238.7168.21.camel@localhost.localdomain> <1110912934.3852.5.camel@tortoise.toronto.redhat.com> <1110917673.5879.6.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1110921402.3852.9.camel@tortoise.toronto.redhat.com> Message-ID: <1110990072.7229.10.camel@localhost.localdomain> On Tue, 2005-03-15 at 16:16 -0500, Thomas Fitzsimmons wrote: > Done. Try java-1.4.2-gcj-compat-1.4.2.0-40jpp_11rh. I just updated and it appears to work now without manual intervention. Just run... $ service tomcat5 start and, after a few seconds, point your browser at http://localhost:8080/ Thanks! AG From sopwith at redhat.com Wed Mar 16 17:28:00 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 16 Mar 2005 12:28:00 -0500 Subject: [fedora-java] Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-extras-list - For users and developers of Fedora Extras fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-tools-list - For discussions about the toolchain (gcc, gdb, etc...) within Fedora fedora-devel-java-list - For discussions about Java-related Fedora development fedora-patches-list - For submitting patches to Fedora maintainers, and used in line with BugWeek fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-marketing-list - For discussions about marketing and expanding the Fedora user base fedora-de-list - For discussions about Fedora in the German language fedora-es-list - For discussions about Fedora in the Spanish language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From tromey at redhat.com Wed Mar 16 18:52:16 2005 From: tromey at redhat.com (Tom Tromey) Date: 16 Mar 2005 11:52:16 -0700 Subject: [fedora-java] failing jar compilation In-Reply-To: <16952.5549.112273.756948@cuddles.cambridge.redhat.com> References: <20050315173627.GB29844@redhat.com> <16952.5549.112273.756948@cuddles.cambridge.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: Andrew> org/eclipse/jdt/core/CheckDebugAttributes.class Andrew> org/eclipse/jdt/core/CheckDebugAttributes.class Andrew> Yeah. I know gcj should give a better error message. Nonetheless, the Andrew> cause of the problem is pretty obvious. I filed this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20502 Tom From green at redhat.com Thu Mar 17 04:34:35 2005 From: green at redhat.com (Anthony Green) Date: Wed, 16 Mar 2005 20:34:35 -0800 Subject: [fedora-java] mod_jk Message-ID: <1111034075.5269.3.camel@localhost.localdomain> I just noticed that we don't build jk (from tomcat5) or package mod_jk (or should that be jk2/mod_jk2?). It seems weird to package tomcat5, but not the Apache httpd connector. Is it too late to squeeze into FC4? AG From shiva at sewingwitch.com Thu Mar 17 05:43:23 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 16 Mar 2005 21:43:23 -0800 Subject: [fedora-java] mod_jk In-Reply-To: <1111034075.5269.3.camel@localhost.localdomain> References: <1111034075.5269.3.camel@localhost.localdomain> Message-ID: --On Wednesday, March 16, 2005 8:34 PM -0800 Anthony Green wrote: > I just noticed that we don't build jk (from tomcat5) or package mod_jk > (or should that be jk2/mod_jk2?). It seems weird to package tomcat5, > but not the Apache httpd connector. Is it too late to squeeze into FC4? FC2 included mod_jk2, which is now deprecated. >From : ># jk2 is a refactoring of mod_jk and uses the Apache Portable Runtime ># (apr). But due to lack of developer interest, it is unsupported. The ># alternative is mod_jk or mod_proxy_ajp. mod_jk is great and should be ># used for production. It is getting fixes as needed (which is now rare). >From : > JK2 has been put in maintainer mode and no further development will take > place. The reason for shutting down JK2 development was the lack of > developers interest. Other reason was lack of users interest in adopting > JK2, caused by configuration complexity when compared to JK. > > JK2 will have it's successor within core Apache2.1/2.2 distribution. We > have developed new proxy_ajp that is an addition to the mod_proxy and > uses Tomcat's AJP protocol stack. It is developped in httpd-2.1 and > integrated in it. We have also developed a new proxy_balancer module for > load balancing http and ajp protocol stacks. > > JK will be fully supported for all other web servers. The next JK release > is planned for the end of November. Lots of code from JK2 has been ported > to JK From Nicolas.Mailhot at laPoste.net Thu Mar 17 07:00:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 17 Mar 2005 08:00:07 +0100 Subject: [fedora-java] mod_jk In-Reply-To: References: <1111034075.5269.3.camel@localhost.localdomain> Message-ID: <1111042807.439.2.camel@rousalka.dyndns.org> Le mercredi 16 mars 2005 ? 21:43 -0800, Kenneth Porter a ?crit : > --On Wednesday, March 16, 2005 8:34 PM -0800 Anthony Green > wrote: > > > I just noticed that we don't build jk (from tomcat5) or package mod_jk > > (or should that be jk2/mod_jk2?). It seems weird to package tomcat5, > > but not the Apache httpd connector. Is it too late to squeeze into FC4? > > FC2 included mod_jk2, which is now deprecated. But jk1 should be fine - it survived several rewrite attempts, the latest being jk2. jk1 is still actively developed and maintained, with regular releases. Never understood why FC went for jk2 myself. Regards, -- Nicolas Mailhot -------------- 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 fernando at lozano.eti.br Thu Mar 17 14:01:00 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Thu, 17 Mar 2005 11:01:00 -0300 Subject: [fedora-java] mod_jk In-Reply-To: <1111034075.5269.3.camel@localhost.localdomain> References: <1111034075.5269.3.camel@localhost.localdomain> Message-ID: <42398D9C.2000504@lozano.eti.br> Hi Anthony, >I just noticed that we don't build jk (from tomcat5) or package mod_jk >(or should that be jk2/mod_jk2?). It seems weird to package tomcat5, >but not the Apache httpd connector. Is it too late to squeeze into FC4? > > This is not the http connector, it is the ajp connector. It is necessary only if you want apache to serve as a front-end for tomcat, say when a site needs to run both jsp and php, or you want apache to load balance many tomcat instances. I would like to have it, but it is not strictly necessary to run java web apps using tomcat. []s, Fernando Lozano From shiva at sewingwitch.com Thu Mar 17 14:46:15 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 17 Mar 2005 06:46:15 -0800 Subject: [fedora-java] mod_jk In-Reply-To: <42398D9C.2000504@lozano.eti.br> References: <1111034075.5269.3.camel@localhost.localdomain> <42398D9C.2000504@lozano.eti.br> Message-ID: --On Thursday, March 17, 2005 11:01 AM -0300 Fernando Lozano wrote: > This is not the http connector, it is the ajp connector. It is necessary > only if you want apache to serve as a front-end for tomcat, say when a > site needs to run both jsp and php, or you want apache to load balance > many tomcat instances. I would like to have it, but it is not strictly > necessary to run java web apps using tomcat. But it is necessary if, like me, you're serving a "regular" web site and need to integrate somebody's Java app. I've been running Apache/PHP for some time and now want to run DataVision and the cookbook for web integration calls for Tomcat. (Right now I'm stuck trying to figure out how to map a URI to the dvwebapp example application.) From nicolas.mailhot at laposte.net Thu Mar 17 15:09:59 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 17 Mar 2005 16:09:59 +0100 (CET) Subject: [fedora-java] mod_jk In-Reply-To: References: <1111034075.5269.3.camel@localhost.localdomain> <42398D9C.2000504@lozano.eti.br> Message-ID: <60566.192.54.193.35.1111072199.squirrel@rousalka.dyndns.org> On Jeu 17 mars 2005 15:46, Kenneth Porter a ?crit : > But it is necessary if, like me, you're serving a "regular" web site and > need to integrate somebody's Java app. I've been running Apache/PHP for > some time and now want to run DataVision > and the cookbook for web integration > calls for Tomcat. (Right now I'm > stuck trying to figure out how to map a URI to the dvwebapp example > application.) You have good mod_jk packages at JPackage. Probably nothing built for FC4T1, but the srpms should rebuild just fine. They should be pretty up-to-date, latest jk1 version or the previous one. Regards, -- Nicolas Mailhot From shiva at sewingwitch.com Thu Mar 17 15:18:30 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 17 Mar 2005 07:18:30 -0800 Subject: [fedora-java] mod_jk In-Reply-To: <60566.192.54.193.35.1111072199.squirrel@rousalka.dyndns.org> References: <1111034075.5269.3.camel@localhost.localdomain> <42398D9C.2000504@lozano.eti.br> <60566.192.54.193.35.1111072199.squirrel@rousalka.dyndns.org> Message-ID: <213B60E1D37FC37938A0C494@[10.169.6.246]> --On Thursday, March 17, 2005 4:09 PM +0100 Nicolas Mailhot wrote: > You have good mod_jk packages at JPackage. Probably nothing built for > FC4T1, but the srpms should rebuild just fine. > > They should be pretty up-to-date, latest jk1 version or the previous one. As I said, I'm just getting my feet wet with Java. (I've been able to read it for some time, to follow magazine articles, but never deployed anything.) (I'm using FC2, but do pull SRPMs from Rawhide and other repositories.) I hadn't seen before. Thanks for the pointer. From fernando at lozano.eti.br Thu Mar 17 15:42:13 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Thu, 17 Mar 2005 12:42:13 -0300 Subject: [fedora-java] mod_jk In-Reply-To: References: <1111034075.5269.3.camel@localhost.localdomain> <42398D9C.2000504@lozano.eti.br> Message-ID: <4239A555.9040001@lozano.eti.br> Hi Kenneth, >> This is not the http connector, it is the ajp connector. It is necessary >> only if you want apache to serve as a front-end for tomcat, say when a >> site needs to run both jsp and php, or you want apache to load balance >> many tomcat instances. I would like to have it, but it is not strictly >> necessary to run java web apps using tomcat. > > > But it is necessary if, like me, you're serving a "regular" web site > and need to integrate somebody's Java app. That's what I told. :-) []s, Fernando Lozano From overholt at redhat.com Thu Mar 17 21:08:34 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 17 Mar 2005 16:08:34 -0500 Subject: [fedora-java] Fedora "Project"? Message-ID: <20050317210834.GC31481@redhat.com> What do people think about having all the java stuff as a "project" like, for example, Stateless Linux or Anaconda Installer at http://fedora.redhat.com/projects/ ? Andrew From green at redhat.com Thu Mar 17 21:18:56 2005 From: green at redhat.com (Anthony Green) Date: Thu, 17 Mar 2005 13:18:56 -0800 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <20050317210834.GC31481@redhat.com> References: <20050317210834.GC31481@redhat.com> Message-ID: <1111094336.5269.33.camel@localhost.localdomain> On Thu, 2005-03-17 at 16:08 -0500, Andrew Overholt wrote: > What do people think about having all the java stuff as a "project" like, > for example, Stateless Linux or Anaconda Installer at > http://fedora.redhat.com/projects/ > ? Yes, this is a good idea - although I'm not sure it mean anything more than having a web site. But that's definitely valuable for publicizing our efforts. AG From dmalcolm at redhat.com Thu Mar 17 22:37:03 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 17 Mar 2005 17:37:03 -0500 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <20050317210834.GC31481@redhat.com> References: <20050317210834.GC31481@redhat.com> Message-ID: <1111099024.5361.128.camel@cassandra.boston.redhat.com> On Thu, 2005-03-17 at 16:08 -0500, Andrew Overholt wrote: > What do people think about having all the java stuff as a "project" like, > for example, Stateless Linux or Anaconda Installer at > http://fedora.redhat.com/projects/ > ? > Maybe have a wiki page (as well or instead? not sure) since it's so much easier for outside contributors? http://fedoraproject.org/wiki/ From talios at gmail.com Thu Mar 17 22:41:34 2005 From: talios at gmail.com (Mark Derricutt) Date: Fri, 18 Mar 2005 11:41:34 +1300 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <1111099024.5361.128.camel@cassandra.boston.redhat.com> References: <20050317210834.GC31481@redhat.com> <1111099024.5361.128.camel@cassandra.boston.redhat.com> Message-ID: <5184347f05031714411aa3f7af@mail.gmail.com> How would this "project" differ than whats going on the JPackae project. I've not really followed too closely "Fedora java" as opposed to "Fedoras use of JPackage" ( I'm really beginning to dislike GMail actually ). From fernando at lozano.eti.br Thu Mar 17 23:48:02 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Thu, 17 Mar 2005 20:48:02 -0300 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <5184347f05031714411aa3f7af@mail.gmail.com> References: <20050317210834.GC31481@redhat.com> <1111099024.5361.128.camel@cassandra.boston.redhat.com> <5184347f05031714411aa3f7af@mail.gmail.com> Message-ID: <423A1732.6040501@lozano.eti.br> Hi, I think a fedora-java project visible on the fedora main page (and including a wiki) would be very nice. It involves a lot of packages and high-visibility applications like Eclipse and Tomcat. But as I understand fedora-java is very different from JPackage. Most packages there need Sun Java, but fedora-java is built around gcj and native compilation. Please enlightem me if I am wrong. []s, Fernando Lozano From tromey at redhat.com Fri Mar 18 00:26:25 2005 From: tromey at redhat.com (Tom Tromey) Date: 17 Mar 2005 17:26:25 -0700 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1109465599.8854.32.camel@localhost> References: <20050225164858.GH19850@redhat.com> <1109465599.8854.32.camel@localhost> Message-ID: >>>>> "Ziga" == Ziga Mahkovec writes: Ziga> I gave these a spin and they work great. The only problem I had so far Ziga> was with opening XML files. I attached a sample file (a web application Ziga> descriptor) which, when opened in Eclipse, produces the attached Ziga> exception. Any XML file with a DOCTYPE seems to trigger this. Ziga> !MESSAGE Unable to initialize editor: org.eclipse.ui.DefaultTextEditor java.net.MalformedURLException: Absolute URL required with null context I forwarded this to Chris Burdess and he wrote a fix that is in GNU Classpath. I could send the patch if someone wants to test it. Otherwise it will have to wait until I get my tree back in a sane state so I can try it out. Tom From pmuldoon at redhat.com Fri Mar 18 04:36:17 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 17 Mar 2005 22:36:17 -0600 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <20050317210834.GC31481@redhat.com> References: <20050317210834.GC31481@redhat.com> Message-ID: <1111120578.5779.13.camel@localhost.localdomain> I think it is good idea, especially as it will lend a focus to specific aims of Java on Fedora. Regards Phil On Thu, 2005-03-17 at 16:08 -0500, Andrew Overholt wrote: > What do people think about having all the java stuff as a "project" like, > for example, Stateless Linux or Anaconda Installer at > http://fedora.redhat.com/projects/ > ? > > Andrew > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From bkonrath at redhat.com Fri Mar 18 04:59:43 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 17 Mar 2005 23:59:43 -0500 Subject: [fedora-java] generating a cdt 3.0 tarball Message-ID: <1111121983.30148.6.camel@town.toronto.redhat.com> Hey Phil/Rick, Here are some updated instructions for generating the CDT 3.0M5 tarball. I couldn't actually find the 3.0 tag so I just put "**3.0TAG**" in the sed line so you'll have to track it down (if it exists). If the repo hasn't been tagged, then we're stuck with HEAD I suppose. % mkdir temp && cd temp % /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse % mkdir home % cvs -d :pserver:anonymous dev eclipse org:/home/tools co \ org.eclipse.cdt-releng/org.eclipse.cdt.releng % cd org.eclipse.cdt-releng/org.eclipse.cdt.releng % sed --in-place 's/HEAD/**3.0TAG**/' maps/cdt.map % java -cp ../../SDK/startup.jar \ -Duser.home=../../home \ org.eclipse.core.launcher.Main \ -application org.eclipse.ant.core.antRunner \ -buildfile build.xml \ -DbaseLocation=/user/share/eclipse \ -DdontUnzip=true fetch % cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz org.eclipse.cdt.releng I just tried this from HEAD and it seems to be be working with gij now! If you have any problems, feel free to ping me. Cheers, Ben From pmuldoon at redhat.com Fri Mar 18 05:16:02 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 17 Mar 2005 23:16:02 -0600 Subject: [fedora-java] Re: generating a cdt 3.0 tarball In-Reply-To: <1111121983.30148.6.camel@town.toronto.redhat.com> References: <1111121983.30148.6.camel@town.toronto.redhat.com> Message-ID: <1111122963.5779.33.camel@localhost.localdomain> Ben Thanks for the changes to the existing procedure. CDT 3.0M5 does not seem be out just yet. But we'll roll a new rpm as soon as it is. Regards Phil On Thu, 2005-03-17 at 23:59 -0500, Ben Konrath wrote: > Hey Phil/Rick, > > Here are some updated instructions for generating the CDT 3.0M5 tarball. > I couldn't actually find the 3.0 tag so I just put "**3.0TAG**" in the > sed line so you'll have to track it down (if it exists). If the repo > hasn't been tagged, then we're stuck with HEAD I suppose. > > % mkdir temp && cd temp > % /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse > % mkdir home > % cvs -d :pserver:anonymous dev eclipse org:/home/tools co \ > org.eclipse.cdt-releng/org.eclipse.cdt.releng > % cd org.eclipse.cdt-releng/org.eclipse.cdt.releng > % sed --in-place 's/HEAD/**3.0TAG**/' maps/cdt.map > % java -cp ../../SDK/startup.jar \ > -Duser.home=../../home \ > org.eclipse.core.launcher.Main \ > -application org.eclipse.ant.core.antRunner \ > -buildfile build.xml \ > -DbaseLocation=/user/share/eclipse \ > -DdontUnzip=true fetch > % cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz org.eclipse.cdt.releng > > I just tried this from HEAD and it seems to be be working with gij now! > If you have any problems, feel free to ping me. > > Cheers, Ben > From ziga.mahkovec at klika.si Fri Mar 18 10:06:25 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 18 Mar 2005 11:06:25 +0100 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: References: <20050225164858.GH19850@redhat.com> <1109465599.8854.32.camel@localhost> Message-ID: <1111140385.5383.8.camel@localhost> On Thu, 2005-03-17 at 17:26 -0700, Tom Tromey wrote: > >>>>> "Ziga" == Ziga Mahkovec writes: > > Ziga> I gave these a spin and they work great. The only problem I had so far > Ziga> was with opening XML files. I attached a sample file (a web application > Ziga> descriptor) which, when opened in Eclipse, produces the attached > Ziga> exception. Any XML file with a DOCTYPE seems to trigger this. > > Ziga> !MESSAGE Unable to initialize editor: org.eclipse.ui.DefaultTextEditor java.net.MalformedURLException: Absolute URL required with null context > > I forwarded this to Chris Burdess and he wrote a fix that is in GNU > Classpath. > > I could send the patch if someone wants to test it. Otherwise it will > have to wait until I get my tree back in a sane state so I can try it > out. I'd be willing to test the patch. Given that this was actually a native compilation issue[1] (it works fine in interpreted mode), does this patch work around a compiler issue? [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149915 -- Ziga From bennet at redhat.com Fri Mar 18 12:40:07 2005 From: bennet at redhat.com (Karen Bennet) Date: Fri, 18 Mar 2005 07:40:07 -0500 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <20050317210834.GC31481@redhat.com> References: <20050317210834.GC31481@redhat.com> Message-ID: <423ACC27.1080901@redhat.com> We are restructuring and documenting what a fedora project means, this will be posted shortly to the fedora community, However, having fedora-java launched as a first 'created' project under these guidelines is a great idea. We might need to call it something other then java though, so welcome suggestions. Andrew Overholt wrote: >What do people think about having all the java stuff as a "project" like, >for example, Stateless Linux or Anaconda Installer at >http://fedora.redhat.com/projects/ >? > >Andrew > >-- >fedora-devel-java-list mailing list >fedora-devel-java-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > > From rmoseley at redhat.com Fri Mar 18 14:10:07 2005 From: rmoseley at redhat.com (Rick Moseley) Date: Fri, 18 Mar 2005 08:10:07 -0600 Subject: [fedora-java] Re: generating a cdt 3.0 tarball In-Reply-To: <1111122963.5779.33.camel@localhost.localdomain> References: <1111121983.30148.6.camel@town.toronto.redhat.com> <1111122963.5779.33.camel@localhost.localdomain> Message-ID: <423AE13F.9020707@redhat.com> Phil Muldoon wrote: >Ben > >Thanks for the changes to the existing procedure. CDT 3.0M5 does not >seem be out just yet. But we'll roll a new rpm as soon as it is. > > They released these tarballs: http://download.eclipse.org/tools/cdt/builds/3.0.0/I.I200503160300 which they claim on the mailing list to be 3.0M5 tarballs. See this thread on cdt-dev: cdt-dev] CDT3.0 M5 candidate (build I200503150300) sanity test : Red Flag >Regards > >Phil > >On Thu, 2005-03-17 at 23:59 -0500, Ben Konrath wrote: > > >>Hey Phil/Rick, >> >>Here are some updated instructions for generating the CDT 3.0M5 tarball. >>I couldn't actually find the 3.0 tag so I just put "**3.0TAG**" in the >>sed line so you'll have to track it down (if it exists). If the repo >>hasn't been tagged, then we're stuck with HEAD I suppose. >> >>% mkdir temp && cd temp >>% /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse >>% mkdir home >>% cvs -d :pserver:anonymous dev eclipse org:/home/tools co \ >> org.eclipse.cdt-releng/org.eclipse.cdt.releng >>% cd org.eclipse.cdt-releng/org.eclipse.cdt.releng >>% sed --in-place 's/HEAD/**3.0TAG**/' maps/cdt.map >>% java -cp ../../SDK/startup.jar \ >> -Duser.home=../../home \ >> org.eclipse.core.launcher.Main \ >> -application org.eclipse.ant.core.antRunner \ >> -buildfile build.xml \ >> -DbaseLocation=/user/share/eclipse \ >> -DdontUnzip=true fetch >>% cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz org.eclipse.cdt.releng >> >>I just tried this from HEAD and it seems to be be working with gij now! >>If you have any problems, feel free to ping me. >> >>Cheers, Ben >> >> Thanks for the write-up Ben, good work there. Rick >> >> > > > From rmoseley at redhat.com Fri Mar 18 15:47:24 2005 From: rmoseley at redhat.com (Rick Moseley) Date: Fri, 18 Mar 2005 09:47:24 -0600 Subject: [fedora-java] Re: generating a cdt 3.0 tarball In-Reply-To: <423AE13F.9020707@redhat.com> References: <1111121983.30148.6.camel@town.toronto.redhat.com> <1111122963.5779.33.camel@localhost.localdomain> <423AE13F.9020707@redhat.com> Message-ID: <423AF80C.8040605@redhat.com> Rick Moseley wrote: > Phil Muldoon wrote: > >> Ben >> >> Thanks for the changes to the existing procedure. CDT 3.0M5 does not >> seem be out just yet. But we'll roll a new rpm as soon as it is. >> >> > They released these tarballs: > > http://download.eclipse.org/tools/cdt/builds/3.0.0/I.I200503160300 > > which they claim on the mailing list to be 3.0M5 tarballs. See this > thread on > cdt-dev: > > cdt-dev] CDT3.0 M5 candidate (build I200503150300) sanity test : Red > Flag > >> Regards >> >> Phil >> >> On Thu, 2005-03-17 at 23:59 -0500, Ben Konrath wrote: >> >> >>> Hey Phil/Rick, >>> Here are some updated instructions for generating the CDT 3.0M5 >>> tarball. >>> I couldn't actually find the 3.0 tag so I just put "**3.0TAG**" in the >> I see from an e-mail from Doug Schaefer today on cdt-dev that he will be labeling the repository M5 sometime today. >>> >>> sed line so you'll have to track it down (if it exists). If the repo >>> hasn't been tagged, then we're stuck with HEAD I suppose. >>> >>> % mkdir temp && cd temp % >>> /usr/share/eclipse/buildscripts/copy-platform SDK /usr/share/eclipse >>> % mkdir home >>> % cvs -d :pserver:anonymous dev eclipse org:/home/tools co \ >>> org.eclipse.cdt-releng/org.eclipse.cdt.releng >>> % cd org.eclipse.cdt-releng/org.eclipse.cdt.releng >>> % sed --in-place 's/HEAD/**3.0TAG**/' maps/cdt.map >>> % java -cp ../../SDK/startup.jar \ >>> -Duser.home=../../home \ org.eclipse.core.launcher.Main \ >>> -application org.eclipse.ant.core.antRunner \ >>> -buildfile build.xml \ >>> -DbaseLocation=/user/share/eclipse \ >>> -DdontUnzip=true fetch >>> % cd .. && tar zcf eclipse-cdt-fetched-src-2.1.tar.gz >>> org.eclipse.cdt.releng >>> >>> I just tried this from HEAD and it seems to be be working with gij now! >>> If you have any problems, feel free to ping me. >>> Cheers, Ben >>> >> > Thanks for the write-up Ben, good work there. > > Rick > >>> >> >> >> >> > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From mark at klomp.org Sun Mar 20 21:12:07 2005 From: mark at klomp.org (Mark Wielaard) Date: Sun, 20 Mar 2005 22:12:07 +0100 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <423ACC27.1080901@redhat.com> References: <20050317210834.GC31481@redhat.com> <423ACC27.1080901@redhat.com> Message-ID: <1111353127.22259.346.camel@localhost.localdomain> Hi, On Fri, 2005-03-18 at 07:40 -0500, Karen Bennet wrote: > We might need to call it something other then java though, > so welcome suggestions. FYI attached is an email exchange from the debian-java mailinglist on this same subject. Michael Koch is a gcj and GNU Classpath hacker and Dalibor Topic is a Kaffe hacker. Obviously as GNU Classpath maintainer I am also biased and would call it after the classpath project. Please feel free to call it the "Fedora Classpath Community Project" if you like. But maybe "fedora-gcj" is more appropriate since you are currently building everything to native with gcj anyway. If you need some infrastructure to collaborate on any fedora packaging initiatives around gcj/classpath, like a wiki setup, quicker then the restructuring of the fedora project guidelines takes then we are happy to offer you space on our http://developer.classpath.org/ machine (in the understanding that it will migrate back to the official fedora mothership when it is ready of course). 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 -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 5679 URL: -------------- 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 Nicolas.Mailhot at laPoste.net Sun Mar 20 21:56:33 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 20 Mar 2005 22:56:33 +0100 Subject: [fedora-java] Fedora "Project"? In-Reply-To: <1111353127.22259.346.camel@localhost.localdomain> References: <20050317210834.GC31481@redhat.com> <423ACC27.1080901@redhat.com> <1111353127.22259.346.camel@localhost.localdomain> Message-ID: <1111355793.26693.6.camel@rousalka.dyndns.org> Le dimanche 20 mars 2005 ? 22:12 +0100, Mark Wielaard a ?crit : > Hi, > > On Fri, 2005-03-18 at 07:40 -0500, Karen Bennet wrote: > > We might need to call it something other then java though, > > so welcome suggestions. > > FYI attached is an email exchange from the debian-java mailinglist on > this same subject. Michael Koch is a gcj and GNU Classpath hacker and > Dalibor Topic is a Kaffe hacker. Obviously as GNU Classpath maintainer I > am also biased and would call it after the classpath project. Please > feel free to call it the "Fedora Classpath Community Project" if you > like. But maybe "fedora-gcj" is more appropriate since you are currently > building everything to native with gcj anyway. And if someone wants a sexy name instead please do not make a stupid pun like eclipse. Some people are too smart for their own good by far. -- Nicolas Mailhot -------------- 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 Mon Mar 21 17:43:03 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Mar 2005 12:43:03 -0500 Subject: [fedora-java] ant + ecj Message-ID: <20050321174303.GG25886@redhat.com> Hi, Robin Green was asking on IRC about this: http://sources.redhat.com/ml/rhug-rhats/2004-05/msg00002.html Is this in our latest ant? If not, can we put it there? Is this affected by us not having a "ecj" executable? Should I make one? Andrew "so many questions" Overholt From gbenson at redhat.com Mon Mar 21 18:02:57 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 21 Mar 2005 18:02:57 +0000 Subject: [fedora-java] ant + ecj In-Reply-To: <20050321174303.GG25886@redhat.com> References: <20050321174303.GG25886@redhat.com> Message-ID: <20050321180256.GG14935@redhat.com> Andrew Overholt wrote: > Robin Green was asking on IRC about this: > > http://sources.redhat.com/ml/rhug-rhats/2004-05/msg00002.html > > Is this in our latest ant? If not, can we put it there? Is this > affected by us not having a "ecj" executable? Should I make one? I think this happens by dint of java-gcj-compat. Gary From ziga.mahkovec at klika.si Mon Mar 21 18:10:25 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Mon, 21 Mar 2005 19:10:25 +0100 Subject: [fedora-java] ant + ecj In-Reply-To: <20050321174303.GG25886@redhat.com> References: <20050321174303.GG25886@redhat.com> Message-ID: <1111428625.5960.11.camel@localhost> On Mon, 2005-03-21 at 12:43 -0500, Andrew Overholt wrote: > Robin Green was asking on IRC about this: > > http://sources.redhat.com/ml/rhug-rhats/2004-05/msg00002.html > > Is this in our latest ant? If not, can we put it there? Is this affected > by us not having a "ecj" executable? Should I make one? This doesn't look like it requires an ecj executable, but having one would still be useful. GNU Classpath for example expects to find /usr/bin/ecj when configured --with-ecj. Right now I just create a link: /usr/bin/ecj -> /usr/lib/jvm/java-gcj/bin/javac -- Ziga From pmuldoon at redhat.com Mon Mar 21 19:07:40 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 21 Mar 2005 13:07:40 -0600 Subject: [fedora-java] gcj-db directory and merge/update scripts Message-ID: <1111432060.5777.13.camel@localhost.localdomain> Lets pin down where we want to put the application .db's that will be merged into the main gcj db. We are about the make changes to the Eclipse spec files to take advantage of the new central .db idea. How about something like: /var/cache/gcj-db-{gcj-version-no} or something to that effect? Will them main db go in there, and how should we structure the directory structure in here to avoid name collisions? I'm presuming we would want all application db's in there too. Also we need a script that does the merge in a generic way, that all spec files can call in %post (to merge their db in with the main db). How should we write this, and also, where should it be put. Should GCC own this too? Just a few things to get the discussion moving, and make some decisions on these few things. Regards Phil From greenrd at presidium.org Mon Mar 21 20:18:23 2005 From: greenrd at presidium.org (Robin Green) Date: Mon, 21 Mar 2005 20:18:23 +0000 Subject: [fedora-java] Re: ant + ecj References: <20050321174303.GG25886@redhat.com> Message-ID: On Mon, 21 Mar 2005 12:43:03 -0500, Andrew Overholt wrote: > Robin Green was asking on IRC about this: > > http://sources.redhat.com/ml/rhug-rhats/2004-05/msg00002.html > > Is this in our latest ant? I've now discovered that this isn't necessary. Eclipse have already provided jdtCompilerAdapter.jar which does precisely the same thing. To use it, simply put jdtCompilerAdapter.jar and jdtcore.jar (both located in /usr/share/eclipse/plugins/org.eclipse.jdt.core_*) on the classpath and tell ant to use it, e.g. by ant -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter From green at redhat.com Tue Mar 22 00:07:06 2005 From: green at redhat.com (Anthony Green) Date: Mon, 21 Mar 2005 16:07:06 -0800 Subject: [fedora-java] gcj-db directory and merge/update scripts In-Reply-To: <1111432060.5777.13.camel@localhost.localdomain> References: <1111432060.5777.13.camel@localhost.localdomain> Message-ID: <1111450027.5177.23.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Mon, 2005-03-21 at 13:07 -0600, Phil Muldoon wrote: > Lets pin down where we want to put the application .db's that will be > merged into the main gcj db. We are about the make changes to the > Eclipse spec files to take advantage of the new central .db idea. > > How about something like: > > /var/cache/gcj-db-{gcj-version-no} or something to that effect? I think Jakub pointed out that this was a bad idea since it doesn't work for multi-ABI systems. I believe that he proposed placing this in /usr/$LIB, where $LIB is ABI dependent, or adding an ABI key to the database. The first option is certainly less work. AG From pmuldoon at redhat.com Tue Mar 22 06:18:12 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 22 Mar 2005 00:18:12 -0600 Subject: [fedora-java] gcj-db directory and merge/update scripts In-Reply-To: <1111450027.5177.23.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <1111432060.5777.13.camel@localhost.localdomain> <1111450027.5177.23.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111472292.5782.14.camel@localhost.localdomain> On Mon, 2005-03-21 at 16:07 -0800, Anthony Green wrote: > On Mon, 2005-03-21 at 13:07 -0600, Phil Muldoon wrote: > > Lets pin down where we want to put the application .db's that will be > > merged into the main gcj db. We are about the make changes to the > > Eclipse spec files to take advantage of the new central .db idea. > > > > How about something like: > > > > /var/cache/gcj-db-{gcj-version-no} or something to that effect? > > I think Jakub pointed out that this was a bad idea since it doesn't work > for multi-ABI systems. I believe that he proposed placing this > in /usr/$LIB, where $LIB is ABI dependent, or adding an ABI key to the > database. The first option is certainly less work. That will work for me. I'm ambivalent to the actual location, as long as we can agree on somewhere. ;) Something like /usr/$LIB/gcj-db-{version}? I think the reason behind the version (I'm guessing from previous talks) is to avoid issues if the db changes format. As Tom mentioned, all the applications .dbs have to reside in some standard location to deal with %uninstall of any rpm that previously merged in a db to the master db. As Eclipse seems to be the only consumer of the db's in Core at the moment (maybe Jonas in the future?), maybe this sort of thing should be talked about on Extras too, based on a the presumption that eventually we shall see many consumers popping up there? Well, hopefully. Regards Phil From overholt at redhat.com Tue Mar 22 17:13:50 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 22 Mar 2005 12:13:50 -0500 Subject: [fedora-java] db merging script Message-ID: <20050322171350.GC10152@redhat.com> This is a crude example of what we could have, but it's what I've got so far: %post -n %{libname}-gtk2 if ![ -e `gcj-dbtool -p` ]; then dirname `gcj-dbtool -p` | xargs mkdir -p; gcj-dbtool -n `gcj-dbtool -p`; fi if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` fi %postun %{libname}-gtk2 if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` fi I'm not even sure if what I have will work. I'd just like to start the discussion about how best to do it. Anthony Green has raised valid concerns about multilib systems. Andrew From tromey at redhat.com Tue Mar 22 18:48:19 2005 From: tromey at redhat.com (Tom Tromey) Date: 22 Mar 2005 11:48:19 -0700 Subject: [fedora-java] db merging script In-Reply-To: <20050322171350.GC10152@redhat.com> References: <20050322171350.GC10152@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: Andrew> This is a crude example of what we could have, but it's what Andrew> I've got so far: Looks ok overall. I would probably put the result of `gcj-dbtool -p` into a shell variable. Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` Andrew> fi Is %{name} the name of the current RPM? If so then I think this is incorrect. We need to merge everything into the master .db. Andrew> I'm not even sure if what I have will work. I'd just like to start the Andrew> discussion about how best to do it. Can we get this in somewhere as an RPM macro? And, if so, where? jpackage-utils? java-gcj-compat? Andrew> Anthony Green has raised valid concerns Andrew> about multilib systems. I looked at the current gcc4.spec a little. It seems to me that we will have to just put the host architecture name into the path to the .db file. Assuming that would work, I don't really know about RPM multilibs. I CC'd Jakub for advice. Jakub, what should we do to make the built-in .db file work with multilibs? I will implement whatever it is we need. Tom From overholt at redhat.com Tue Mar 22 18:58:26 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 22 Mar 2005 13:58:26 -0500 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> Message-ID: <20050322185826.GF10152@redhat.com> * Tom Tromey [2005-03-22 13:55]: > > Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then > Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` > Andrew> fi > > Is %{name} the name of the current RPM? > If so then I think this is incorrect. We need to merge everything > into the master .db. We're merging into the master .db but until we sort out where to put the other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings. Andrew From green at redhat.com Tue Mar 22 19:01:48 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 11:01:48 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050322185826.GF10152@redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322185826.GF10152@redhat.com> Message-ID: <1111518108.5163.3.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 13:58 -0500, Andrew Overholt wrote: > We're merging into the master .db but until we sort out where to put the > other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings. How about in a directory called `gcj-dbtool -p`.d ? AG From pmuldoon at redhat.com Tue Mar 22 19:06:29 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 22 Mar 2005 13:06:29 -0600 Subject: [fedora-java] db merging script In-Reply-To: <20050322185826.GF10152@redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322185826.GF10152@redhat.com> Message-ID: <1111518390.5670.19.camel@dhcp-12.hsv.redhat.com> On Tue, 2005-03-22 at 13:58 -0500, Andrew Overholt wrote: > * Tom Tromey [2005-03-22 13:55]: > > > > Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then > > Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db` `gcj-dbtool -p` > > Andrew> fi > > > > Is %{name} the name of the current RPM? > > If so then I think this is incorrect. We need to merge everything > > into the master .db. > > We're merging into the master .db but until we sort out where to put the > other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings. Other than Anthony Green's response, there's not much opinion on that yet it seems. Maybe asking the question was premature; it's something I'd like to figure out sooner rather than later, though. The only other thing was the `find %{_libdir}/%{name}/mappings -name \*.db` potentially producing a list of db's that is to big to fit in the argument buffer, and that may make an incorrect merge. What are the advantages of an rpmacro over just placing a merge shell script in /usr/bin? Regards Phil From jakub at redhat.com Tue Mar 22 19:20:49 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 22 Mar 2005 14:20:49 -0500 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> Message-ID: <20050322192048.GU32746@devserv.devel.redhat.com> On Tue, Mar 22, 2005 at 11:48:19AM -0700, Tom Tromey wrote: > Andrew> Anthony Green has raised valid concerns > Andrew> about multilib systems. > > I looked at the current gcc4.spec a little. It seems to me that we > will have to just put the host architecture name into the path to the > .db file. Assuming that would work, I don't really know about RPM > multilibs. > > I CC'd Jakub for advice. Jakub, what should we do to make the > built-in .db file work with multilibs? I will implement whatever it > is we need. Well, first you want to decide whether you want one master .db file or one .db file per architecture. One master .db file might be a tiny bit slower (since the .db file will be bigger), but might be easier for users (e.g. gcj-dbtool -p would be usable). You just need to pick up some magic values for the architectures (say for ELF architectures you can e.g. use the EM_* constants ored with ELFCLASS{32,64} shifted up or something), add code that at configure or compile time stores the current arch magic number into libgcj.so (or wherever the code that will parse the .db file lives) and code into gcj-dbtool to compute the magic value for a given shared library. With per-arch .db you could e.g. store the file into /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be gcc $CFLAGS -print-multi-os-directory (well, even better the path would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with gcj-dbtool -p . The first approach is what e.g. ldconfig/ld.so use. Jakub From green at redhat.com Tue Mar 22 19:39:14 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 11:39:14 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050322192048.GU32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> Message-ID: <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote: > With per-arch .db you could e.g. store the file into > /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be > gcc $CFLAGS -print-multi-os-directory (well, even better the path > would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` > string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with > gcj-dbtool -p . I'm not sure I understand this second part. What's wrong with... /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db ? "gcj-dbtool -p " sounds hard to implement. AG From jakub at redhat.com Tue Mar 22 19:50:43 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 22 Mar 2005 14:50:43 -0500 Subject: [fedora-java] db merging script In-Reply-To: <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050322195043.GV32746@devserv.devel.redhat.com> On Tue, Mar 22, 2005 at 11:39:14AM -0800, Anthony Green wrote: > On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote: > > With per-arch .db you could e.g. store the file into > > /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be > > gcc $CFLAGS -print-multi-os-directory (well, even better the path > > would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` > > string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with > > gcj-dbtool -p . > > I'm not sure I understand this second part. > > What's wrong with... > > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db > > ? > > "gcj-dbtool -p " sounds hard to implement. You mean that gcj-dbtool -p would print /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db and you'd need to pass that through shell after making sure $CC and $CFLAGS are properly defined? Then you'd put the burden on rpm packagers, because in rpm %post $RPM_OPT_FLAGS certainly aren't set (and, you shouldn't require gcc to be installed just to install Java packages). Reminds me, gcj-dbtool should be probably moved from gcc-java subpackage to libgcj now that it is used not only during compile time. Jakub From aph at redhat.com Tue Mar 22 19:58:53 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Mar 2005 19:58:53 +0000 Subject: [fedora-java] db merging script In-Reply-To: <20050322195043.GV32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> Message-ID: <16960.30973.362032.296471@cuddles.cambridge.redhat.com> Jakub Jelinek writes: > On Tue, Mar 22, 2005 at 11:39:14AM -0800, Anthony Green wrote: > > On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote: > > > With per-arch .db you could e.g. store the file into > > > /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be > > > gcc $CFLAGS -print-multi-os-directory (well, even better the path > > > would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` > > > string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with > > > gcj-dbtool -p . > > > > I'm not sure I understand this second part. > > > > What's wrong with... > > > > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db > > > > ? > > > > "gcj-dbtool -p " sounds hard to implement. > > You mean that gcj-dbtool -p would print > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db > and you'd need to pass that through shell after making sure $CC and $CFLAGS > are properly defined? gcj-dbtool is a target program, part of libgcj. So, on a multi-arch system, would there not be two gcj-dbtools, linked against different libgcjs? And, each one would print its *own* directory. Andrew. From jakub at redhat.com Tue Mar 22 20:06:00 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 22 Mar 2005 15:06:00 -0500 Subject: [fedora-java] db merging script In-Reply-To: <16960.30973.362032.296471@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> Message-ID: <20050322200600.GW32746@devserv.devel.redhat.com> On Tue, Mar 22, 2005 at 07:58:53PM +0000, Andrew Haley wrote: > > You mean that gcj-dbtool -p would print > > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db > > and you'd need to pass that through shell after making sure $CC and $CFLAGS > > are properly defined? > > gcj-dbtool is a target program, part of libgcj. So, on a multi-arch > system, would there not be two gcj-dbtools, linked against different > libgcjs? And, each one would print its *own* directory. On multi-arch systems, there is usually just one set of binaries and one or two sets of libraries. If you want 2 gcj-dbtool programs, that's of course possible, but you need to decide where to install them (e.g. /usr/libexec/gcj/$LIB/gcj-dbtool ), but then all the programs that want to use gcj-dbtool need to figure out which one they want to call. For %post this location wouldn't be that hard, rpm %post would just call /usr/libexec/gcj/%{_lib}/gcj-dbtool -p ... But, will you require all Makefiles that deal with gcj-dbtool to call /usr/libexec/gcj/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-dbtool ? Certainly, one master .db file, although it will need some work inside gcj-dbtool and libgcj.so, will make things far easier for the users and developers. Jakub From aph at redhat.com Tue Mar 22 20:11:10 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Mar 2005 20:11:10 +0000 Subject: [fedora-java] db merging script In-Reply-To: <20050322200600.GW32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> Message-ID: <16960.31710.508597.276038@cuddles.cambridge.redhat.com> Jakub Jelinek writes: > > Certainly, one master .db file, although it will need some work inside > gcj-dbtool and libgcj.so, will make things far easier for the users and > developers. That's impossible. The .db is a mapping from bytecode to shared objects, and there is no guarantee that if a class exists in lib/foo.so it will also exist in lib64/foo.so. However, that class might well exist in lib64/bar.so. Andrew. From green at redhat.com Tue Mar 22 20:10:57 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 12:10:57 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050322195043.GV32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> Message-ID: <1111522257.5163.32.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 14:50 -0500, Jakub Jelinek wrote: > You mean that gcj-dbtool -p would print > /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db > and you'd need to pass that through shell after making sure $CC and $CFLAGS > are properly defined? > Then you'd put the burden on rpm packagers, because in rpm %post > $RPM_OPT_FLAGS certainly aren't set (and, you shouldn't require > gcc to be installed just to install Java packages). This shouldn't require gcc at install time. We can create the application specific classmaps at build time, and simply merge them at install time. AG From jakub at redhat.com Tue Mar 22 20:22:22 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 22 Mar 2005 15:22:22 -0500 Subject: [fedora-java] db merging script In-Reply-To: <16960.31710.508597.276038@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> <16960.31710.508597.276038@cuddles.cambridge.redhat.com> Message-ID: <20050322202221.GX32746@devserv.devel.redhat.com> On Tue, Mar 22, 2005 at 08:11:10PM +0000, Andrew Haley wrote: > Jakub Jelinek writes: > > > > Certainly, one master .db file, although it will need some work inside > > gcj-dbtool and libgcj.so, will make things far easier for the users and > > developers. > > That's impossible. > > The .db is a mapping from bytecode to shared objects, and there is no > guarantee that if a class exists in lib/foo.so it will also exist in > lib64/foo.so. However, that class might well exist in lib64/bar.so. Why impossible? If can be a mapping from pair to shared objects... Jakub From aph at redhat.com Tue Mar 22 20:44:26 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Mar 2005 20:44:26 +0000 Subject: [fedora-java] db merging script In-Reply-To: <20050322202221.GX32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> <16960.31710.508597.276038@cuddles.cambridge.redhat.com> <20050322202221.GX32746@devserv.devel.redhat.com> Message-ID: <16960.33706.680838.813211@cuddles.cambridge.redhat.com> Jakub Jelinek writes: > On Tue, Mar 22, 2005 at 08:11:10PM +0000, Andrew Haley wrote: > > Jakub Jelinek writes: > > > > > > Certainly, one master .db file, although it will need some work inside > > > gcj-dbtool and libgcj.so, will make things far easier for the users and > > > developers. > > > > That's impossible. > > > > The .db is a mapping from bytecode to shared objects, and there is no > > guarantee that if a class exists in lib/foo.so it will also exist in > > lib64/foo.so. However, that class might well exist in lib64/bar.so. > > Why impossible? If can be a mapping from pair to > shared objects... Oh, what a horrible idea. Yes, that would work, I suppose. It doesn't scale well, though. I would have thought it easier just to give the db an appropriate name for the arch. We don't use fat libraries, so why create fat databases? The reasoning is exactly the same. Andrew. From green at redhat.com Tue Mar 22 22:26:45 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 14:26:45 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050322171350.GC10152@redhat.com> References: <20050322171350.GC10152@redhat.com> Message-ID: <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Here's a real-world example from the servletapi5 spec file. It currently assumes that we should be using `gcj-dbtool -p`. Comments/suggestions welcome. *** servletapi5.spec 2004-11-04 06:41:06.000000000 -0800 --- servletapi5.spec.new 2005-03-22 14:23:54.964489184 -0800 *************** *** 3,9 **** %define name %{base_name}%{major_version} %define full_name jakarta-%{base_name} %define version 5.0.18 ! %define release 1jpp_3fc %define section free Name: %{name} --- 3,9 ---- %define name %{base_name}%{major_version} %define full_name jakarta-%{base_name} %define version 5.0.18 ! %define release 1jpp_4fc %define section free Name: %{name} *************** *** 23,29 **** BuildRequires: xerces-j2, xml-commons-apis BuildRequires: jpackage-utils >= 1.5.30 BuildRequires: java-javadoc - BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot #Obsoletes: servlet4 #Obsoletes: servlet23 --- 23,28 ---- *************** *** 66,79 **** --- 65,91 ---- ant dist -Dservletapi.build=build -Dservletapi.dist=dist popd + # Generate native code. + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar + gcj-dbtool -n jspapi-%{version}.db + gcj-dbtool -f jspapi-%{version}.db jsr152/dist/lib/jsp-api.jar %{_libdir}/libjspapi-%{version}.jar.so + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o lib%{name}-%{version}.jar.so jsr154/dist/lib/servlet-api.jar + gcj-dbtool -n %{name}-%{version}.db + gcj-dbtool -f %{name}-%{version}.db jsr154/dist/lib/servlet-api.jar %{_libdir}/lib%{name}-%{version}.jar.so %install cd jakarta-tomcat-%{version}-src/jakarta-servletapi-5 # jars install -d -m 755 $RPM_BUILD_ROOT%{_javadir} + install -d -m 755 $RPM_BUILD_ROOT%{_libdir} + install -d -m 755 $RPM_BUILD_ROOT`gcj-dbtool -p`.d install -m 644 jsr152/dist/lib/jsp-api.jar $RPM_BUILD_ROOT%{_javadir}/jspapi-%{version}.jar install -m 644 jsr154/dist/lib/servlet-api.jar $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar + install -m 644 libjspapi-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/libjspapi-%{version}.jar.so + install -m 644 lib%{name}-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/lib%{name}-%{version}.jar.so + install -m 644 jspapi-%{version}.db $RPM_BUILD_ROOT`gcj-dbtool -p`.d/jspapi-%{version}.db + install -m 644 %{name}-%{version}.db $RPM_BUILD_ROOT`gcj-dbtool -p`.d/%{name}-%{version}.db (cd $RPM_BUILD_ROOT%{_javadir} && for jar in *-%{version}*; do ln -sf ${jar} `echo $jar| sed "s|-%{version}||g"`; done) *************** *** 94,105 **** --- 106,125 ---- %post update-alternatives --install %{_javadir}/servlet.jar servlet %{_javadir}/%{name}-%{version}.jar 50 #update-alternatives --install %{_javadir}/jsp.jar jsp %{_javadir}/jsp-api-%{version}.jar 50 + DB=`gcj-dbtool -p` + rm -f $DB + gcj-dbtool -n $DB + (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) %postun if [ "$1" = "0" ]; then update-alternatives --remove servlet %{_javadir}/%{name}-%{version}.jar # update-alternatives --remove jsp %{_javadir}/jsp-api-%{version}.jar fi + DB=`gcj-dbtool -p` + rm -f $DB + gcj-dbtool -n $DB + (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) %post javadoc rm -f %{_javadocdir}/%{name} *************** *** 110,115 **** --- 130,136 ---- %files %defattr(-,root,root) %doc LICENSE + %{_libdir}/* %{_javadir}/* %files javadoc *************** *** 121,126 **** --- 142,150 ---- %changelog + * Tue Mar 22 2005 Anthony Green 0:5.0.18-1jpp_4fc + - Generate native libraries. + * Thu Nov 4 2004 Gary Benson 0:5.0.18-1jpp_3fc - Build into Fedora. From pmuldoon at redhat.com Tue Mar 22 22:41:19 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 22 Mar 2005 16:41:19 -0600 Subject: [fedora-java] db merging script In-Reply-To: <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> > %post > update-alternatives --install %{_javadir}/servlet.jar servlet %{_javadir}/%{name}-%{version}.jar 50 > #update-alternatives --install %{_javadir}/jsp.jar jsp %{_javadir}/jsp-api-%{version}.jar 50 > + DB=`gcj-dbtool -p` > + rm -f $DB > + gcj-dbtool -n $DB > + (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) I think it was Tom who suggested we should have some structure below the location of the db location to allow for name collisions. Will the: (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) account for $DB.d/foo/foo.jar.so and $DB.d/bar/bar.jar.so and so on? Regards Phil From green at redhat.com Tue Mar 22 22:46:20 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 14:46:20 -0800 Subject: [fedora-java] db merging script In-Reply-To: <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> Message-ID: <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 16:41 -0600, Phil Muldoon wrote: > I think it was Tom who suggested we should have some structure below the > location of the db location to allow for name collisions. Will the: > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) > > account for > > $DB.d/foo/foo.jar.so > > and > > $DB.d/bar/bar.jar.so > > and so on? No, but I think we should be using versioned names so, in theory, there should be no collisions. # ls -l /usr/lib/gcj-4.0.0/classmap.db.d/ total 2832 -rw-r--r-- 1 root root 1441792 Mar 22 14:19 jspapi-5.0.18.db -rw-r--r-- 1 root root 1441792 Mar 22 14:19 servletapi5-5.0.18.db BTW, I also think we should prefix the libs with "lib" and make them versioned. # ls -l /usr/lib/libjspapi-5.0.18.jar.so -rw-r--r-- 1 root root 300642 Mar 22 14:19 /usr/lib/libjspapi-5.0.18.jar.so This will make them usable for explicit linking, and make up a little bit for the fact that we don't have real so name versioning. AG From pmuldoon at redhat.com Tue Mar 22 23:13:16 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 22 Mar 2005 17:13:16 -0600 Subject: [fedora-java] db merging script In-Reply-To: <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111533196.5670.74.camel@dhcp-12.hsv.redhat.com> On Tue, 2005-03-22 at 14:46 -0800, Anthony Green wrote: > On Tue, 2005-03-22 at 16:41 -0600, Phil Muldoon wrote: > > I think it was Tom who suggested we should have some structure below the > > location of the db location to allow for name collisions. Will the: > > > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) > > > > account for > > > > $DB.d/foo/foo.jar.so > > > > and > > > > $DB.d/bar/bar.jar.so > > > > and so on? > > No, but I think we should be using versioned names so, in theory, there > should be no collisions. Okay, my example was wrong (s/jar.so/db), but I take your point. Right now appending version is something we don't do (because we can safely assume with our db and our location we won't have collision). Something to keep in mind. As long as it is tied with the version of the rpm then it should be cool. Maybe there are other issues here, but I can't think of any. I can't be sure but I think the merge automatically deletes the destination "merge to" database, so there theoretically could be an issue with the size of the argument list provided from the ls . to xargs there. Not sure if this is something we should worry about in reality or not Regards Phil From green at redhat.com Tue Mar 22 23:42:22 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 15:42:22 -0800 Subject: [fedora-java] db merging script In-Reply-To: <1111533196.5670.74.camel@dhcp-12.hsv.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111533196.5670.74.camel@dhcp-12.hsv.redhat.com> Message-ID: <1111534943.5163.79.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Tue, 2005-03-22 at 17:13 -0600, Phil Muldoon wrote: > I can't be sure but I think the merge automatically deletes the > destination "merge to" database, so there theoretically could be an > issue with the size of the argument list provided from the ls . to xargs > there. Not sure if this is something we should worry about in reality or > not Oh, yes, you're right. gcj-dbtool seems to create a temporary db and then copies it on top of the real one once complete. Given that, I think this would work: DB=`gcj-dbtool -p` rm -f $DB gcj-dbtool -n $DB (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) [note the extra $DB on that last line] AG From green at redhat.com Wed Mar 23 03:27:11 2005 From: green at redhat.com (Anthony Green) Date: Tue, 22 Mar 2005 19:27:11 -0800 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> Message-ID: <1111548431.5248.30.camel@localhost.localdomain> On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote: > I CC'd Jakub for advice. Jakub, what should we do to make the > built-in .db file work with multilibs? I will implement whatever it > is we need. After looking at this for a bit, I recommend the following: "gcj-dbtool -p" operates as usual (for no special reason) "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db This is convenient because it is easy to implement and easy to use. The %post and %postun spec file sections can simply do: DB=`gcj-dbtool -p %{_libdir}` and use DB for the database name. Presumably rpm will make sure that _libdir refers to the correct lib directory for the target ABI. AG From bryan at about.com Wed Mar 23 13:08:03 2005 From: bryan at about.com (Susan M. Taylor) Date: Wed, 23 Mar 2005 13:08:03 +0000 Subject: [fedora-java] Rolex for $249.99 Message-ID: <006b01c52fa9$251d1485$dbe6a75b@about.com> REPLICA WATCH MODELS Rolex, Patek Philippe, Bvlgari Cartier, Gucci, Franck Muller .. and 25 other most famous manufacturers. http://www.coolwatches.biz All for only $249.99! _________________________________________________________________________ To change your mail preferences, go here: http://www.signoffcorp.biz/uns.htm _________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From overholt at redhat.com Wed Mar 23 15:59:07 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 23 Mar 2005 10:59:07 -0500 Subject: [fedora-java] Eclipse plugins and .dbs Message-ID: <20050323155907.GA10099@redhat.com> I've attached a patch for the changelog plugin. This will fix up the native-compilation situation until everything's sorted out. Andrew -------------- next part -------------- Index: eclipse-changelog.spec =================================================================== RCS file: /cvs/dist/rpms/eclipse-changelog/devel/eclipse-changelog.spec,v retrieving revision 1.22 diff -u -p -r1.22 eclipse-changelog.spec --- eclipse-changelog.spec 10 Mar 2005 21:55:06 -0000 1.22 +++ eclipse-changelog.spec 23 Mar 2005 15:58:25 -0000 @@ -20,11 +20,12 @@ ExclusiveArch: i386 ppc x86_64 Summary: %{pkg_summary} Name: %{eclipse_name}-changelog Version: %{changelog_majmin}.%{changelog_micro}_fc -Release: 17 +Release: 18 License: EPL (Eclipse Public License) Group: Text Editors/Integrated Development Environments (IDE) URL: http://www.redhat.com -Requires: eclipse-ui +Requires: eclipse-platform +Requires: gcc-java # Note that following the Eclipse Releng process we do not distribute a # real .tar.gz file. Instead, you must build it by hand. The way to do @@ -107,9 +108,6 @@ for file in $(pwd)/com.redhat.eclipse.ch # Once compiled, we don't care about the jar (it's still in the original tar) rm $jarname - - # Create a text mapping of the jar <-->so mapping for later use. - echo %{eclipse_base}/plugins/$jarname::%{eclipse_lib_base}/plugins/$jarname.so >> %{name}.jarswithnativelibs done ;; esac @@ -141,10 +139,13 @@ gcj-dbtool -n $RPM_BUILD_ROOT/%{eclipse_ # Create plugins directory in eclipse lib base install -d -m755 $RPM_BUILD_ROOT/%{eclipse_lib_base}/plugins/ -cd $nativehome/eclipse/plugins +# Populate db with mappings +for j in `find $RPM_BUILD_ROOT/%{eclipse_base} -name \*.jar`; do + gcj-dbtool -f $RPM_BUILD_ROOT%{eclipse_lib_base}/mappings/changelog.db \ + $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; +done; -# Install the text jar <--> so mapping we created when we compiled -install -m644 %{name}.jarswithnativelibs $RPM_BUILD_ROOT/%{eclipse_lib_base} +cd $nativehome/eclipse/plugins # Copy the .so(s) we created earlier into the build root for file in `find . -type f -name *.so`; do @@ -153,23 +154,24 @@ for file in `find . -type f -name *.so`; done %post - -# Populate db with mappings -for j in `cat %{eclipse_lib_base}/%{name}.jarswithnativelibs`; do - gcj-dbtool -a %{eclipse_lib_base}/mappings/changelog.db `echo $j | sed "s/::/ /"` -done - # Merge all dbs together after install +dbLocation=`gcj-dbtool -p` +if ! [ -e $dbLocation ]; then + dirname $dbLocation | xargs mkdir -p + gcj-dbtool -n $dbLocation +fi + if [ -n "`find %{eclipse_lib_base}/mappings -name \*.db`" ]; then - gcj-dbtool -m %{eclipse_lib_base}/eclipse.db `find %{eclipse_lib_base}/mappings -name \*.db` + gcj-dbtool -m $dbLocation `find %{eclipse_lib_base}/mappings -name \*.db` $dbLocation fi %postun # After uninstall has removed our db, again merge the dbs # to remove our entries +dbLocation=`gcj-dbtool -p` if [ -n "`find %{eclipse_lib_base}/mappings -name \*.db`" ]; then - gcj-dbtool -m %{eclipse_lib_base}/eclipse.db `find %{eclipse_lib_base}/mappings -name \*.db` + gcj-dbtool -m $dbLocation `find %{eclipse_lib_base}/mappings -name \*.db` $dbLocation fi %clean @@ -181,9 +183,13 @@ rm -rf ${RPM_BUILD_ROOT} %{eclipse_base}/plugins/com.redhat.eclipse.changelog* %{eclipse_lib_base}/plugins/com.redhat.eclipse.changelog* %{eclipse_lib_base}/mappings/changelog.db -%{eclipse_lib_base}/%{name}.jarswithnativelibs %changelog +* Wed Mar 23 2005 Andrew Overholt 2.0.1_fc-18 +- Update with new gcj-dbtool stuff. +- Fix Requires. +- Remove *.jarswithnativelibs. + * Thu Mar 10 2005 Phil Muldoon 2.0.1-17 - Redo arches - Clean up BuildRequires From pmuldoon at redhat.com Wed Mar 23 16:04:48 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Wed, 23 Mar 2005 10:04:48 -0600 Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: <20050323155907.GA10099@redhat.com> References: <20050323155907.GA10099@redhat.com> Message-ID: <1111593888.5797.2.camel@localhost.localdomain> Andrew Cool. I'll merge and test build the plugin, and see how it does. Looks fine from an Eclipse point of view. Regards Phil On Wed, 2005-03-23 at 10:59 -0500, Andrew Overholt wrote: > I've attached a patch for the changelog plugin. This will fix up the > native-compilation situation until everything's sorted out. > > Andrew > -- > 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 Wed Mar 23 18:42:38 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Mar 2005 18:42:38 +0000 Subject: [fedora-java] db merging script In-Reply-To: <1111548431.5248.30.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111548431.5248.30.camel@localhost.localdomain> Message-ID: <16961.47262.192111.759933@cuddles.cambridge.redhat.com> Anthony Green writes: > On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote: > > I CC'd Jakub for advice. Jakub, what should we do to make the > > built-in .db file work with multilibs? I will implement whatever it > > is we need. > > After looking at this for a bit, I recommend the following: > > "gcj-dbtool -p" operates as usual (for no special reason) > "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db > > This is convenient because it is easy to implement and easy to use. > > The %post and %postun spec file sections can simply do: > > DB=`gcj-dbtool -p %{_libdir}` > > and use DB for the database name. Presumably rpm will make sure that > _libdir refers to the correct lib directory for the target ABI. That sounds pleasingly simple. Andrew. From overholt at redhat.com Wed Mar 23 18:53:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 23 Mar 2005 13:53:14 -0500 Subject: [fedora-java] db merging script In-Reply-To: <1111548431.5248.30.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111548431.5248.30.camel@localhost.localdomain> Message-ID: <20050323185314.GA10509@redhat.com> * Anthony Green [2005-03-22 22:32]: > On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote: > > I CC'd Jakub for advice. Jakub, what should we do to make the > > built-in .db file work with multilibs? I will implement whatever it > > is we need. > > After looking at this for a bit, I recommend the following: > > "gcj-dbtool -p" operates as usual (for no special reason) > "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db > > This is convenient because it is easy to implement and easy to use. > > The %post and %postun spec file sections can simply do: > > DB=`gcj-dbtool -p %{_libdir}` > > and use DB for the database name. Presumably rpm will make sure that > _libdir refers to the correct lib directory for the target ABI. This sounds good. Can we put a database subdirectory at the same location? LIBDIR/gcj-VERSION/classmap.d Andrew From green at redhat.com Wed Mar 23 19:22:52 2005 From: green at redhat.com (Anthony Green) Date: Wed, 23 Mar 2005 11:22:52 -0800 Subject: [fedora-java] db merging script In-Reply-To: <20050323185314.GA10509@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111548431.5248.30.camel@localhost.localdomain> <20050323185314.GA10509@redhat.com> Message-ID: <1111605772.5432.1.camel@localhost.localdomain> On Wed, 2005-03-23 at 13:53 -0500, Andrew Overholt wrote: > > The %post and %postun spec file sections can simply do: > > > > DB=`gcj-dbtool -p %{_libdir}` > > > > and use DB for the database name. Presumably rpm will make sure that > > _libdir refers to the correct lib directory for the target ABI. > > This sounds good. Can we put a database subdirectory at the same location? > > LIBDIR/gcj-VERSION/classmap.d Yes - in my spec file proposal I used $DB.d. AG From tromey at redhat.com Thu Mar 24 00:25:46 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:25:46 -0700 Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: <20050323155907.GA10099@redhat.com> References: <20050323155907.GA10099@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: Andrew> -Requires: eclipse-ui Andrew> +Requires: eclipse-platform Andrew> +Requires: gcc-java You probably just want to BuildRequires this, and then Require whatever tag all the JREs provide. That way people could still install eclipse and a proprietary JRE. (Perhaps jusst requiring eclipse-platform is enough, and that in turn ought to require the JRE... I dunno.) Tom From tromey at redhat.com Thu Mar 24 00:33:13 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:33:13 -0700 Subject: [fedora-java] db merging script In-Reply-To: <20050322200600.GW32746@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> Message-ID: >>>>> "Jakub" == Jakub Jelinek writes: Jakub> On multi-arch systems, there is usually just one set of binaries and one Jakub> or two sets of libraries. Programs like 'gcj-dbtool' and 'gij' are linked against a specific libgcj.so. If there is only one set of binaries, then it seems like we don't need to bother with multilib at all, since it will only ever be possible to use one particular libgcj.so -- the one 'gij' is linked to. At least, that is true in the common case... e.g., eclipse, which in the end invokes 'gij' at startup. Or am I missing some magic that lets us pick libraries at runtime? I don't know how this could work, but I'm ready to be enlightened :-) Tom From pmuldoon at redhat.com Thu Mar 24 00:40:30 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Wed, 23 Mar 2005 18:40:30 -0600 Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: References: <20050323155907.GA10099@redhat.com> Message-ID: <1111624830.12175.25.camel@localhost.localdomain> This was in response to bz 151866 (I think. I added Requires: gcc-java to the new cdt rpm). It's because in %post/%postun we need gcj-dbtool to merge. Regards Phil On Wed, 2005-03-23 at 17:25 -0700, Tom Tromey wrote: > >>>>> "Andrew" == Andrew Overholt writes: > > Andrew> -Requires: eclipse-ui > Andrew> +Requires: eclipse-platform > Andrew> +Requires: gcc-java > > You probably just want to BuildRequires this, and then Require > whatever tag all the JREs provide. That way people could still > install eclipse and a proprietary JRE. (Perhaps jusst requiring > eclipse-platform is enough, and that in turn ought to require the > JRE... I dunno.) > > Tom > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From tromey at redhat.com Thu Mar 24 00:37:35 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:37:35 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111518390.5670.19.camel@dhcp-12.hsv.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322185826.GF10152@redhat.com> <1111518390.5670.19.camel@dhcp-12.hsv.redhat.com> Message-ID: >>>>> "Phil" == Phil Muldoon writes: Phil> What are the advantages of an rpmacro over just placing a merge shell Phil> script in /usr/bin? Just that it doesn't show up in the user's $PATH. I don't know if that is a plus or a minus, honestly. Wherever it ends up, it needs a sensible name. Tom From tromey at redhat.com Thu Mar 24 00:41:30 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:41:30 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111531279.5670.59.camel@dhcp-12.hsv.redhat.com> <1111531581.5163.67.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> No, but I think we should be using versioned names so, in Anthony> theory, there should be no collisions. The name would have to include both the package name and the jar name in the package. It doesn't matter to me what particular naming convention we pick, as long as it is reasonably sensible and easy to automate... we can spell that with a '-' or a '/' :-) The reason I opted for subdirectories is just that programs like eclipse already use them. It presents an obvious mapping from the .jar structure to the .so cache, and we know it cannot clash as the original package has no clashes. Anthony> This will make them usable for explicit linking, and make up a little Anthony> bit for the fact that we don't have real so name versioning. Yeah, this is attractive, at least for some of the libraries. Tom From tromey at redhat.com Thu Mar 24 00:44:16 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 17:44:16 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> Here's a real-world example from the servletapi5 spec file. It Anthony> currently assumes that we should be using `gcj-dbtool -p`. Anthony> Comments/suggestions welcome. Anthony> + # Generate native code. Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar Anthony> + gcj-dbtool -n jspapi-%{version}.db [ ...] If it isn't too unwieldy, I would like to see this whole section replaced by a single call to some shell script to automate the find-compile-db loop. My goal is to make gcj-izing a jpackage RPM utterly trivial... Tom From pmuldoon at redhat.com Thu Mar 24 00:55:39 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Wed, 23 Mar 2005 18:55:39 -0600 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111625739.12175.31.camel@localhost.localdomain> > If it isn't too unwieldy, I would like to see this whole section > replaced by a single call to some shell script to automate the > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > utterly trivial... Andrew Overholt and I mused around with creating a wiki page somewhere along the lines of "How to build your Java project with GCJ and package it to rpm", and highlight some of the pitfalls, and strategies involved here (that our group encountered with Eclipse). I'm not sure if Fedora Core has a semi official wiki somewhere, but it is something I would like to do. Also another wiki on how to debug your natively built Java app. Hopefully that would help any Extra's project find the right path; and make things even easier. Regards Phil From fitzsim at redhat.com Thu Mar 24 00:58:41 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 23 Mar 2005 19:58:41 -0500 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111625921.11419.30.camel@tortoise.toronto.redhat.com> On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote: > >>>>> "Anthony" == Anthony Green writes: > > Anthony> Here's a real-world example from the servletapi5 spec file. It > Anthony> currently assumes that we should be using `gcj-dbtool -p`. > Anthony> Comments/suggestions welcome. > > Anthony> + # Generate native code. > Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar > Anthony> + gcj-dbtool -n jspapi-%{version}.db > [ ...] > > If it isn't too unwieldy, I would like to see this whole section > replaced by a single call to some shell script to automate the > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > utterly trivial... > If someone sends me the script I can add it to java-1.4.2-gcj-compat. Tom From tromey at redhat.com Thu Mar 24 01:45:42 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Mar 2005 18:45:42 -0700 Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: <1111624830.12175.25.camel@localhost.localdomain> References: <20050323155907.GA10099@redhat.com> <1111624830.12175.25.camel@localhost.localdomain> Message-ID: >>>>> "Phil" == Phil Muldoon writes: Phil> This was in response to bz 151866 (I think. I added Requires: gcc-java Phil> to the new cdt rpm). It's because in %post/%postun we need gcj-dbtool to Phil> merge. Ah, thanks... I didn't realize that. That does seem like a drawback of the current approach. Short of rewriting gcj-dbtool in plain old C, though, there's not much to be done about it. Tom From jakub at redhat.com Thu Mar 24 06:13:00 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 24 Mar 2005 01:13:00 -0500 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> Message-ID: <20050324061300.GB8801@devserv.devel.redhat.com> On Wed, Mar 23, 2005 at 05:33:13PM -0700, Tom Tromey wrote: > Programs like 'gcj-dbtool' and 'gij' are linked against a specific > libgcj.so. If there is only one set of binaries, then it seems like > we don't need to bother with multilib at all, since it will only ever > be possible to use one particular libgcj.so -- the one 'gij' is linked > to. At least, that is true in the common case... e.g., eclipse, which > in the end invokes 'gij' at startup. > > Or am I missing some magic that lets us pick libraries at runtime? > I don't know how this could work, but I'm ready to be enlightened :-) What prevents other programs to use libgcj.so (or now that there is libgij.so also libgij.so)? And when they do, you don't know if those programs will be 32-bit or 64-bit. Jakub From nicolas.mailhot at laposte.net Thu Mar 24 08:09:58 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Mar 2005 09:09:58 +0100 (CET) Subject: [fedora-java] Eclipse plugins and .dbs In-Reply-To: References: <20050323155907.GA10099@redhat.com> Message-ID: <48686.192.54.193.35.1111651798.squirrel@rousalka.dyndns.org> On Jeu 24 mars 2005 1:25, Tom Tromey a ?crit : >>>>>> "Andrew" == Andrew Overholt writes: > > Andrew> -Requires: eclipse-ui > Andrew> +Requires: eclipse-platform > Andrew> +Requires: gcc-java > > You probably just want to BuildRequires this, and then Require > whatever tag all the JREs provide. That way people could still > install eclipse and a proprietary JRE. (Perhaps jusst requiring > eclipse-platform is enough, and that in turn ought to require the > JRE... I dunno JPP jres should provide java, and jpp jvms should provide java-devel (and versionned virtuals too should you require a particular java level) -- Nicolas Mailhot From aph at redhat.com Thu Mar 24 11:50:21 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 24 Mar 2005 11:50:21 +0000 Subject: [fedora-java] db merging script In-Reply-To: <20050324061300.GB8801@devserv.devel.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> <20050324061300.GB8801@devserv.devel.redhat.com> Message-ID: <16962.43389.990081.17067@cuddles.cambridge.redhat.com> Jakub Jelinek writes: > On Wed, Mar 23, 2005 at 05:33:13PM -0700, Tom Tromey wrote: > > Programs like 'gcj-dbtool' and 'gij' are linked against a specific > > libgcj.so. If there is only one set of binaries, then it seems like > > we don't need to bother with multilib at all, since it will only ever > > be possible to use one particular libgcj.so -- the one 'gij' is linked > > to. At least, that is true in the common case... e.g., eclipse, which > > in the end invokes 'gij' at startup. > > > > Or am I missing some magic that lets us pick libraries at runtime? > > I don't know how this could work, but I'm ready to be enlightened :-) > > What prevents other programs to use libgcj.so (or now that there is > libgij.so also libgij.so)? Nothing. > And when they do, you don't know if those programs will be 32-bit or > 64-bit. I don't understand purpose of this comment. If there's a 32-bit multilib, the user will use -m32 at compile time, and that will link with the 32-bit library. Andrew. From phil at mkdoc.com Thu Mar 24 14:04:56 2005 From: phil at mkdoc.com (Phil Shaw) Date: Thu, 24 Mar 2005 14:04:56 -0000 Subject: [fedora-java] db merging script In-Reply-To: <1111625739.12175.31.camel@localhost.localdomain> References: Message-ID: <4242C908.23329.E1EE45A@localhost> On 23 Mar 2005, at 18:55, Phil Muldoon wrote: > Andrew Overholt and I mused around with creating a wiki page somewhere > along the lines of "How to build your Java project with GCJ and > package it to rpm", and highlight some of the pitfalls, and strategies > involved here (that our group encountered with Eclipse). I'm not sure > if Fedora Core has a semi official wiki somewhere, but it is something > I would like to do. Also another wiki on how to debug your natively > built Java app. Hopefully that would help any Extra's project find the > right path; and make things even easier. http://gcc.gnu.org/wiki/GCJ How about this? I would be interested in your notes. From overholt at redhat.com Thu Mar 24 15:46:42 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 24 Mar 2005 10:46:42 -0500 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <1110580244.2342.18.camel@localhost> References: <1110580244.2342.18.camel@localhost> Message-ID: <20050324154642.GA19233@redhat.com> Hi, I decided to do something similar to what Ziga had done. I took his HelloWorld.java [1] and compiled it with three incarnations of ecj: 1. java-gcj-compat's javac 2. an ecj made as in [2] 3. an ecj made as in [3] Quick and dirty results (see [4] for details): (average of 5 runs) | j-g-c's javac | ecj (from .java) | ecj (linked) ------------------------------------------------------------- real | 1.1724 s | 0.2812 s | 0.3804 s user | 1.0576 s | 0.217 s | 0.313 s sys | 0.1144 s | 0.0636 s | 0.0672 s I've attached the raw output of the time commands for all three tests. Andrew [1] http://www.bootchart.org/misc/ecj/HelloWorld.java [2] Note: this took a _long_ time ... maybe I did something wrong? (in an exploded Eclipse source tree (after rpmbuild --short-circuit -bp on our eclipse.spec) in plugins/org.eclipse.jdt.core/compiler: gcj -o ecj -I. --main=org.eclipse.jdt.internal.compiler.batch.Main -O2 \ `find -name \*.java -print0 | xargs -0` [3] gcj -O2 --main=org.eclipse.jdt.internal.compiler.batch.Main \ -Wl,-R,/usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0 \ /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so \ /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtCompilerAdapter.jar.so \ -o ecj.linked [4] export CLASSPATH=/usr/share/java/libgcj-4.0.0.jar time HelloWorld.java -------------- next part -------------- real 0m0.379s user 0m0.310s sys 0m0.068s real 0m0.381s user 0m0.317s sys 0m0.065s real 0m0.384s user 0m0.310s sys 0m0.073s real 0m0.383s user 0m0.316s sys 0m0.066s real 0m0.375s user 0m0.312s sys 0m0.064s -------------- next part -------------- real 0m0.277s user 0m0.210s sys 0m0.067s real 0m0.277s user 0m0.224s sys 0m0.052s real 0m0.279s user 0m0.198s sys 0m0.081s real 0m0.278s user 0m0.220s sys 0m0.057s real 0m0.295s user 0m0.233s sys 0m0.061s -------------- next part -------------- real 0m1.146s user 0m1.039s sys 0m0.107s real 0m1.170s user 0m1.051s sys 0m0.117s real 0m1.154s user 0m1.047s sys 0m0.107s real 0m1.159s user 0m1.044s sys 0m0.115s real 0m1.233s user 0m1.107s sys 0m0.126s From aph at redhat.com Thu Mar 24 15:51:14 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 24 Mar 2005 15:51:14 +0000 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <20050324154642.GA19233@redhat.com> References: <1110580244.2342.18.camel@localhost> <20050324154642.GA19233@redhat.com> Message-ID: <16962.57842.46886.603813@cuddles.cambridge.redhat.com> Andrew Overholt writes: > > I decided to do something similar to what Ziga had done. I took his > HelloWorld.java [1] and compiled it with three incarnations of ecj: Isn't this program to small to be a reasonable test? Andrew. From ziga.mahkovec at klika.si Thu Mar 24 16:18:04 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Thu, 24 Mar 2005 17:18:04 +0100 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <16962.57842.46886.603813@cuddles.cambridge.redhat.com> References: <1110580244.2342.18.camel@localhost> <20050324154642.GA19233@redhat.com> <16962.57842.46886.603813@cuddles.cambridge.redhat.com> Message-ID: <1111681084.5966.27.camel@localhost> On Thu, 2005-03-24 at 15:51 +0000, Andrew Haley wrote: > Andrew Overholt writes: > > > > I decided to do something similar to what Ziga had done. I took his > > HelloWorld.java [1] and compiled it with three incarnations of ecj: > > Isn't this program to small to be a reasonable test? Andrew, if you want to repeat the tests for GNU Classpath, here's what I did: 1. grab a classpath snapshot (or checkout from CVS) 2. ./configure --with-ecj 3. apply the attached patch to work around an ecj bug[1] 4. link /usr/bin/ecj to one of your incarnations 5. cd lib; time make 6. make clean, rinse, repeat If I understand correctly, any significant difference in these timings would indicate BC-ABI performance penalty? [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=88562 -- Ziga -------------- next part -------------- A non-text attachment was scrubbed... Name: ecj-crash.patch Type: text/x-patch Size: 857 bytes Desc: not available URL: From overholt at redhat.com Thu Mar 24 16:36:26 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 24 Mar 2005 11:36:26 -0500 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <1111681084.5966.27.camel@localhost> References: <1110580244.2342.18.camel@localhost> <20050324154642.GA19233@redhat.com> <16962.57842.46886.603813@cuddles.cambridge.redhat.com> <1111681084.5966.27.camel@localhost> Message-ID: <20050324163626.GA17909@redhat.com> * Ziga Mahkovec [2005-03-24 11:19]: > Andrew, if you want to repeat the tests for GNU Classpath, here's what I Cool, thanks. Here are two of the three results (the from-source ecj had some issues with relocation): ecj.linked: ---------- real 0m52.822s user 0m21.669s sys 0m2.018s java-gcj-compat's javac: ----------------------- real 1m5.062s user 0m24.139s sys 0m2.410s Andrew From green at redhat.com Thu Mar 24 23:14:35 2005 From: green at redhat.com (Anthony Green) Date: Thu, 24 Mar 2005 15:14:35 -0800 Subject: [fedora-java] db merging script In-Reply-To: <16961.47262.192111.759933@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111548431.5248.30.camel@localhost.localdomain> <16961.47262.192111.759933@cuddles.cambridge.redhat.com> Message-ID: <1111706076.17650.25.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Wed, 2005-03-23 at 18:42 +0000, Andrew Haley wrote: > Anthony Green writes: > > On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote: > > > I CC'd Jakub for advice. Jakub, what should we do to make the > > > built-in .db file work with multilibs? I will implement whatever it > > > is we need. > > > > After looking at this for a bit, I recommend the following: > > > > "gcj-dbtool -p" operates as usual (for no special reason) > > "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db [snip] > That sounds pleasingly simple. There's a patch waiting for approval now: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00886.html Hopefully it will find its way into rawhide update sometime soon. AG From green at redhat.com Fri Mar 25 01:25:51 2005 From: green at redhat.com (Anthony Green) Date: Thu, 24 Mar 2005 17:25:51 -0800 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote: > >>>>> "Anthony" == Anthony Green writes: > > Anthony> Here's a real-world example from the servletapi5 spec file. It > Anthony> currently assumes that we should be using `gcj-dbtool -p`. > Anthony> Comments/suggestions welcome. > > Anthony> + # Generate native code. > Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar > Anthony> + gcj-dbtool -n jspapi-%{version}.db > [ ...] > > If it isn't too unwieldy, I would like to see this whole section > replaced by a single call to some shell script to automate the > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > utterly trivial... hmmm.. what do you mean by "find" in find-compile-db? I don't think it's safe to simply compile and db-ify any .jar file in your build tree. The best we might hope for is probably something like... gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS SRC_JARFILE refers to the jar file we want to process. DEST_SO_NAME is the name we want to install it as. JPackages seem to use different build and install jar names in some cases, so we can't infer from SRC_JARFILE. And we should probably version the library name. BUILD_OPTIONS is needed because we want to pass in $RPM_OPT_FLAGS. I suppose the script can handle certain options, like -findirect- dispatch and -Wl,Bsymbolic. I'm not sure I'd call this utterly trivial. Is it enough of an improvement over what I suggested earlier? Then we could have another little script to replace: DB=`gcj-dbtool -p %{_libdir}` rm -f $DB gcj-dbtool -n $DB (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) Could these go in java-gcj-compat? Or maybe as RPM macros? AG From tromey at redhat.com Fri Mar 25 18:28:48 2005 From: tromey at redhat.com (Tom Tromey) Date: 25 Mar 2005 11:28:48 -0700 Subject: [fedora-java] db merging script In-Reply-To: <16962.43389.990081.17067@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <20050322192048.GU32746@devserv.devel.redhat.com> <1111520354.5163.24.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050322195043.GV32746@devserv.devel.redhat.com> <16960.30973.362032.296471@cuddles.cambridge.redhat.com> <20050322200600.GW32746@devserv.devel.redhat.com> <20050324061300.GB8801@devserv.devel.redhat.com> <16962.43389.990081.17067@cuddles.cambridge.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: >> And when they do, you don't know if those programs will be 32-bit or >> 64-bit. Andrew> I don't understand purpose of this comment. If there's a 32-bit Andrew> multilib, the user will use -m32 at compile time, and that will link Andrew> with the 32-bit library. Jakub was responding to me, since I didn't see how people would end up using the non-default libgcj.so. But his point is that some program may link against it explicitly, or dlopen and use the invocation API. And so, since we can't predict now which library might be used on a fully installed system, we have to handle this somehow. Anthony's gcj-dbtool patch went in, so we can start trying this soon. (FWIW I also didn't like the idea of having the ABI recorded in the .db.) Have we worked everything out now? We solved the multilib problem, and there seems to be a consensus on where to put the .so cache. Tom From tromey at redhat.com Fri Mar 25 18:33:43 2005 From: tromey at redhat.com (Tom Tromey) Date: 25 Mar 2005 11:33:43 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: >>>>> "Anthony" == Anthony Green writes: >> If it isn't too unwieldy, I would like to see this whole section >> replaced by a single call to some shell script to automate the >> find-compile-db loop. My goal is to make gcj-izing a jpackage RPM >> utterly trivial... Anthony> hmmm.. what do you mean by "find" in find-compile-db? I Anthony> don't think it's safe to simply compile and db-ify any .jar Anthony> file in your build tree. I was thinking we would do this in %install, by compiling every jar (or war or ...) we found in the install tree. But maybe it is ugly not to do in %build -- in which case, yeah, we need to do more manually. Anthony> The best we might hope for is probably something like... Anthony> gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS Anthony> I'm not sure I'd call this utterly trivial. Is it enough of an Anthony> improvement over what I suggested earlier? One thing that is nice about it is we can unpack and compile war files in the script. I suppose if we wanted we could also purge non-.class files from jars here as well, at least until gcj gets an option to do this. Anthony> Then we could have another little script to replace: Anthony> DB=`gcj-dbtool -p %{_libdir}` Anthony> rm -f $DB Anthony> gcj-dbtool -n $DB Anthony> (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) Anthony> Could these go in java-gcj-compat? Or maybe as RPM macros? Yeah, Tom F. offered to put them as scripts in java-gcj-compat. Let's do that for the time being. Tom From tromey at redhat.com Fri Mar 25 18:42:29 2005 From: tromey at redhat.com (Tom Tromey) Date: 25 Mar 2005 11:42:29 -0700 Subject: [fedora-java] Profiling ecj (was: Using the natively-built Eclipse compiler) In-Reply-To: <1111681084.5966.27.camel@localhost> References: <1110580244.2342.18.camel@localhost> <20050324154642.GA19233@redhat.com> <16962.57842.46886.603813@cuddles.cambridge.redhat.com> <1111681084.5966.27.camel@localhost> Message-ID: >>>>> "Ziga" == Ziga Mahkovec writes: Ziga> If I understand correctly, any significant difference in these timings Ziga> would indicate BC-ABI performance penalty? There are actually two variables hiding here: in case [3], not only is (e.g.) jdtcore.jar.so compiled with the BC-ABI, but it is also compiled from .class files and not .java source. The latter can sometimes have a performance impact. I would suggest adding another case, namely compiling the .jar files with the C++ ABI to see how that changes things (note that at the moment you can't compile .java source using the BC-ABI, as that part of the compiler is unfinished). It would also be interesting to see oprofile results for these runs. Tom From green at redhat.com Fri Mar 25 18:56:07 2005 From: green at redhat.com (Anthony Green) Date: Fri, 25 Mar 2005 10:56:07 -0800 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <1111776967.5243.9.camel@localhost.localdomain> On Fri, 2005-03-25 at 11:33 -0700, Tom Tromey wrote: > Anthony> hmmm.. what do you mean by "find" in find-compile-db? I > Anthony> don't think it's safe to simply compile and db-ify any .jar > Anthony> file in your build tree. > > I was thinking we would do this in %install, by compiling every jar > (or war or ...) we found in the install tree. But maybe it is ugly > not to do in %build -- in which case, yeah, we need to do more > manually. I don't think we'll get much support for compiling these at install time: (1) as Jakub recently pointed out, it would require gcj to be installed just to install java applications. (2) releng types have told us that slowing down the install by compiling things at install time is a non-starter. AG From tromey at redhat.com Fri Mar 25 19:13:37 2005 From: tromey at redhat.com (Tom Tromey) Date: 25 Mar 2005 12:13:37 -0700 Subject: [fedora-java] db merging script In-Reply-To: <1111776967.5243.9.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111776967.5243.9.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: >> I was thinking we would do this in %install, by compiling every jar >> (or war or ...) we found in the install tree. But maybe it is ugly >> not to do in %build -- in which case, yeah, we need to do more >> manually. Anthony> I don't think we'll get much support for compiling these at install Anthony> time: There's some terminology confusion here. As I understand RPM, which is not much, '%install' is a step that is run while building the RPM itself. %build does the "building", and %install puts the results into an install tree. Then RPM uses %files to figure out how to break down the install tree into different binary RPMs. There are other sections you can specify if you want some script to be run when the RPM itself is installed. Tom From kms at passback.co.uk Fri Mar 25 20:32:50 2005 From: kms at passback.co.uk (Keith Sharp) Date: Fri, 25 Mar 2005 20:32:50 +0000 Subject: [fedora-java] Eclipse Problems - Create a "Standard Make C Project" Message-ID: <1111782771.15096.16.camel@animal.passback.co.uk> Hello, When I try to create a new "Standard Make C Project" it fails at the last stage of the wizard, when I click finish, by displaying a dialog box that says "Project cannot be created Reason: Internal Error:". All the dialog has is an ok button! I can create a "Managed Make C Project" with no problems. Any thoughts on how to debug this further? I am running FC4T1 with Eclipse updated to latest Rawhide: $ rpm -qa eclipse\* eclipse-cdt-3.0.0_fc-0.M5.1 eclipse-changelog-2.0.1_fc-18 eclipse-ecj-3.1.0_fc-0.M5.13 eclipse-pde-devel-3.1.0_fc-0.M5.13 eclipse-pde-3.1.0_fc-0.M5.13 eclipse-platform-3.1.0_fc-0.M5.13 eclipse-jdt-3.1.0_fc-0.M5.13 eclipse-platform-devel-3.1.0_fc-0.M5.13 eclipse-pydev-0.9.0_fc-4 eclipse-jdt-devel-3.1.0_fc-0.M5.13 eclipse-bugzilla-0.1.0_fc-8 Thanks, keith. From bkonrath at redhat.com Fri Mar 25 21:01:13 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Fri, 25 Mar 2005 16:01:13 -0500 Subject: [fedora-java] Eclipse Problems - Create a "Standard Make C Project" In-Reply-To: <1111782771.15096.16.camel@animal.passback.co.uk> References: <1111782771.15096.16.camel@animal.passback.co.uk> Message-ID: <20050325210113.GD23490@town.toronto.redhat.com> Hi Keith, On Fri, Mar 25, 2005 at 08:32:50PM +0000, Keith Sharp wrote: > Hello, > > When I try to create a new "Standard Make C Project" it fails at the > last stage of the wizard, when I click finish, by displaying a dialog > box that says "Project cannot be created Reason: Internal Error:". All > the dialog has is an ok button! I can create a "Managed Make C Project" > with no problems. I'm actually in the middle of tracking this one down. We've come up with a hack that would allow you to create "standard make" project but you would not be able to change some (possibly all) of the project settings. I'll apply this hack if we can't sort out this stuff in a few days. If you have a minute, could file a bug in the Red Hat bugzilla about this? Thanks, Ben From zbalevsky at limepeer.com Fri Mar 25 21:12:39 2005 From: zbalevsky at limepeer.com (zbalevsky) Date: Fri, 25 Mar 2005 16:12:39 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 Message-ID: <42447EC7.4000109@limepeer.com> Greetings, I looked around bugzilla but there wasn't anything similar to this bug. Every time I start the native eclipse, the entire computer freezes as soon as it passes the splash screen. Hard reset is the only thing that works from that point on. I tried starting the regular eclipse 3.1M5 with gij and the result was the same; regular eclipse runs fine on the Sun jvm. This is an i386 fc4t1 system updated to the latest rawhide (from last night). Are there any options I can pass to either gij or the eclipse binary that will make it print some debugging info? From pmuldoon at redhat.com Fri Mar 25 21:12:47 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Fri, 25 Mar 2005 15:12:47 -0600 Subject: [fedora-java] Eclipse Problems - Create a "Standard Make C Project" In-Reply-To: <1111782771.15096.16.camel@animal.passback.co.uk> References: <1111782771.15096.16.camel@animal.passback.co.uk> Message-ID: <1111785167.5808.10.camel@localhost.localdomain> Keith As ben mentioned, we are tracking (and attempting to fix) this bug. You can still use managed make projects as normal. We should have a fix in a few days. Incidentally, this only happens when you attempt to create a brand new standard project. If you have existing projects (or pull in from CVS), the rest of the CDT appears to work fine. Anyway, file a bug, so we can start some tracking on it. Regards Phil On Fri, 2005-03-25 at 20:32 +0000, Keith Sharp wrote: > Hello, > > When I try to create a new "Standard Make C Project" it fails at the > last stage of the wizard, when I click finish, by displaying a dialog > box that says "Project cannot be created Reason: Internal Error:". All > the dialog has is an ok button! I can create a "Managed Make C Project" > with no problems. > > Any thoughts on how to debug this further? I am running FC4T1 with > Eclipse updated to latest Rawhide: > > $ rpm -qa eclipse\* > eclipse-cdt-3.0.0_fc-0.M5.1 > eclipse-changelog-2.0.1_fc-18 > eclipse-ecj-3.1.0_fc-0.M5.13 > eclipse-pde-devel-3.1.0_fc-0.M5.13 > eclipse-pde-3.1.0_fc-0.M5.13 > eclipse-platform-3.1.0_fc-0.M5.13 > eclipse-jdt-3.1.0_fc-0.M5.13 > eclipse-platform-devel-3.1.0_fc-0.M5.13 > eclipse-pydev-0.9.0_fc-4 > eclipse-jdt-devel-3.1.0_fc-0.M5.13 > eclipse-bugzilla-0.1.0_fc-8 > > Thanks, > > keith. > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From bkonrath at redhat.com Fri Mar 25 21:25:57 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Fri, 25 Mar 2005 16:25:57 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <42447EC7.4000109@limepeer.com> References: <42447EC7.4000109@limepeer.com> Message-ID: <20050325212556.GA3809@town.toronto.redhat.com> On Fri, Mar 25, 2005 at 04:12:39PM -0500, zbalevsky wrote: > Greetings, > > I looked around bugzilla but there wasn't anything similar to this bug. > Every time I start the native eclipse, the entire computer freezes as > soon as it passes the splash screen. Hard reset is the only thing that > works from that point on. I tried starting the regular eclipse 3.1M5 > with gij and the result was the same; regular eclipse runs fine on the > Sun jvm. > > This is an i386 fc4t1 system updated to the latest rawhide (from last > night). Are there any options I can pass to either gij or the eclipse > binary that will make it print some debugging info? Yes, on the eclipse side of things you can run: eclipse -consolelog -debug I'd be interested to see what this prints out. Cheers, Ben From zbalevsky at limepeer.com Fri Mar 25 21:49:40 2005 From: zbalevsky at limepeer.com (zbalevsky) Date: Fri, 25 Mar 2005 16:49:40 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <20050325212556.GA3809@town.toronto.redhat.com> References: <42447EC7.4000109@limepeer.com> <20050325212556.GA3809@town.toronto.redhat.com> Message-ID: <42448774.9040704@limepeer.com> Ben Konrath wrote: >On Fri, Mar 25, 2005 at 04:12:39PM -0500, zbalevsky wrote: > > >>Greetings, >> >>I looked around bugzilla but there wasn't anything similar to this bug. >>Every time I start the native eclipse, the entire computer freezes as >>soon as it passes the splash screen. Hard reset is the only thing that >>works from that point on. I tried starting the regular eclipse 3.1M5 >>with gij and the result was the same; regular eclipse runs fine on the >>Sun jvm. >> >>This is an i386 fc4t1 system updated to the latest rawhide (from last >>night). Are there any options I can pass to either gij or the eclipse >>binary that will make it print some debugging info? >> >> > >Yes, on the eclipse side of things you can run: > >eclipse -consolelog -debug > >I'd be interested to see what this prints out. > >Cheers, Ben > > I'm attaching the logfile. It is possible that some of the last messages did not make it to disk when the system froze. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.txt URL: From bkonrath at redhat.com Sat Mar 26 01:41:38 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Fri, 25 Mar 2005 20:41:38 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <42448774.9040704@limepeer.com> References: <42447EC7.4000109@limepeer.com> <20050325212556.GA3809@town.toronto.redhat.com> <42448774.9040704@limepeer.com> Message-ID: <20050326014138.GB3809@town.toronto.redhat.com> On Fri, Mar 25, 2005 at 04:49:40PM -0500, zbalevsky wrote: > I'm attaching the logfile. It is possible that some of the last > messages did not make it to disk when the system froze. Yeah, your right that doesn't show anything. I remember having the same problem a couple of weeks ago but I could not reproduce it reliably. Can you try running eclipse again with a clean workspace and a clean configuration directory? To do this you should first move the configuration files out of the way: mv ~/.eclipse{,.bak} Normally it's safe to just delete this directory, but it would be useful for us to see if this is causing problems. Now to run eclipse with a clean workspace, just do: eclipse -consolelog -debug -data path/to/workspace/ Note: the workspace shouldn't exist, eclipse will create a new directory if nothing is there. Cheers, Ben From zbalevsky at limepeer.com Sat Mar 26 04:56:55 2005 From: zbalevsky at limepeer.com (zbalevsky) Date: Fri, 25 Mar 2005 23:56:55 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <20050326014138.GB3809@town.toronto.redhat.com> References: <42447EC7.4000109@limepeer.com> <20050325212556.GA3809@town.toronto.redhat.com> <42448774.9040704@limepeer.com> <20050326014138.GB3809@town.toronto.redhat.com> Message-ID: <4244EB97.40209@limepeer.com> Ben Konrath wrote: >On Fri, Mar 25, 2005 at 04:49:40PM -0500, zbalevsky wrote: > > >>I'm attaching the logfile. It is possible that some of the last >>messages did not make it to disk when the system froze. >> >> > >Yeah, your right that doesn't show anything. I remember having the >same problem a couple of weeks ago but I could not reproduce it >reliably. Can you try running eclipse again with a clean workspace and a >clean configuration directory? > >To do this you should first move the configuration files out of the way: > >mv ~/.eclipse{,.bak} > >Normally it's safe to just delete this directory, but it would be useful >for us to see if this is causing problems. Now to run eclipse with a >clean workspace, just do: > >eclipse -consolelog -debug -data path/to/workspace/ > >Note: the workspace shouldn't exist, eclipse will create a new >directory if nothing is there. > >Cheers, Ben > >-- > Hi again, I'm attaching a log of a freeze when the workspace does not exist. I really don't think this is an eclipse problem since when I ran it under strace -ff everything went fine (albeit excruciatingly slow). Any idea where I can take this issue next? gcj / gij / kernel people? If I open a bugzilla will it end up being redirected here? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.eclipse2 URL: From tadej.janez at tadej.hicsalta.si Sat Mar 26 10:09:39 2005 From: tadej.janez at tadej.hicsalta.si (Tadej =?iso-8859-2?Q?Jane=BE?=) Date: Sat, 26 Mar 2005 11:09:39 +0100 Subject: [fedora-java] db merging script In-Reply-To: <1111625739.12175.31.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111625739.12175.31.camel@localhost.localdomain> Message-ID: <1111831779.5456.7.camel@localhost.localdomain> On Wed, 2005-03-23 at 18:55 -0600, Phil Muldoon wrote: > Andrew Overholt and I mused around with creating a wiki page somewhere > along the lines of "How to build your Java project with GCJ and package > it to rpm", and highlight some of the pitfalls, and strategies involved > here (that our group encountered with Eclipse). I'm not sure if Fedora > Core has a semi official wiki somewhere, but it is something I would > like to do. Also another wiki on how to debug your natively built Java > app. Hopefully that would help any Extra's project find the right path; > and make things even easier. I think that would be very useful. Maybe you could add it to http://fedoraproject.org/wiki/ ? Thanks, Tadej -- Tadej Jane? From kms at passback.co.uk Sat Mar 26 10:48:04 2005 From: kms at passback.co.uk (Keith Sharp) Date: Sat, 26 Mar 2005 10:48:04 +0000 Subject: [fedora-java] Eclipse Problems - Create a "Standard Make C Project" In-Reply-To: <1111785167.5808.10.camel@localhost.localdomain> References: <1111782771.15096.16.camel@animal.passback.co.uk> <1111785167.5808.10.camel@localhost.localdomain> Message-ID: <1111834085.27888.0.camel@animal.passback.co.uk> On Fri, 2005-03-25 at 15:12 -0600, Phil Muldoon wrote: > Keith > > As ben mentioned, we are tracking (and attempting to fix) this bug. You > can still use managed make projects as normal. We should have a fix in a > few days. Incidentally, this only happens when you attempt to create a > brand new standard project. If you have existing projects (or pull in > from CVS), the rest of the CDT appears to work fine. > > Anyway, file a bug, so we can start some tracking on it. Created #152206 Keith. From pmuldoon at redhat.com Sat Mar 26 20:29:55 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Sat, 26 Mar 2005 14:29:55 -0600 Subject: [fedora-java] db merging script In-Reply-To: <1111831779.5456.7.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111625739.12175.31.camel@localhost.localdomain> <1111831779.5456.7.camel@localhost.localdomain> Message-ID: <1111868995.5808.1.camel@localhost.localdomain> On Sat, 2005-03-26 at 11:09 +0100, Tadej Jane? wrote: > I think that would be very useful. > > Maybe you could add it to http://fedoraproject.org/wiki/ ? > > Thanks, > > Tadej > On Thu, 2005-03-24 at 14:04 +0000, Phil Shaw wrote: > http://gcc.gnu.org/wiki/GCJ > > How about this? I would be interested in your notes. Okay, when the current rush has died down, I'll write something up, and post it to both sites. Regards Phil From djo at coconut-palm-software.com Sun Mar 27 03:41:55 2005 From: djo at coconut-palm-software.com (David J. Orme) Date: Sat, 26 Mar 2005 21:41:55 -0600 Subject: [fedora-java] db merging script In-Reply-To: <1111868995.5808.1.camel@localhost.localdomain> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111625739.12175.31.camel@localhost.localdomain> <1111831779.5456.7.camel@localhost.localdomain> <1111868995.5808.1.camel@localhost.localdomain> Message-ID: <42462B83.4010509@coconut-palm-software.com> Phil, If you could post here when you've done that, I'd be most appreciative. Regards, Dave Orme Phil Muldoon wrote: >On Sat, 2005-03-26 at 11:09 +0100, Tadej Jane? wrote: > > >>I think that would be very useful. >> >>Maybe you could add it to http://fedoraproject.org/wiki/ ? >> >>Thanks, >> >>Tadej >> >> >> > >On Thu, 2005-03-24 at 14:04 +0000, Phil Shaw wrote: > > > >>http://gcc.gnu.org/wiki/GCJ >> >>How about this? I would be interested in your notes. >> >> > >Okay, when the current rush has died down, I'll write something up, and >post it to both sites. > > >Regards > >Phil > > >-- >fedora-devel-java-list mailing list >fedora-devel-java-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > > -- Got Java? Use db4objects! PGP Public Key (for confidential communications): http://www.coconut-palm-software.com/~djo/public_key.txt From jdesbonnet at gmail.com Sun Mar 27 12:45:30 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Sun, 27 Mar 2005 13:45:30 +0100 Subject: [fedora-java] DBus and Java Message-ID: <1cef3e9505032704453b2ff07d@mail.gmail.com> I understand that the long term plan with Fedora is to expose all system configuration information via DBus. Are there any Java bindings for this yet? Part of the reason I ask is I'm wondering what is (or will be) the correct way to query locally installed RPMs. Thanks, Joe. From greenrd at presidium.org Sun Mar 27 12:56:05 2005 From: greenrd at presidium.org (Robin Green) Date: Sun, 27 Mar 2005 07:56:05 -0500 (EST) Subject: [fedora-java] DBus and Java In-Reply-To: <1cef3e9505032704453b2ff07d@mail.gmail.com> References: <1cef3e9505032704453b2ff07d@mail.gmail.com> Message-ID: On Sun, 27 Mar 2005, Joe Desbonnet wrote: > I understand that the long term plan with Fedora is to expose all > system configuration information via DBus. Are there any Java bindings > for this yet? > > Part of the reason I ask is I'm wondering what is (or will be) the > correct way to query locally installed RPMs. Can't you just use Process p = Runtime.exec ("rpm -q " + packageName) InputStream in = p.getInputStream (); // Read query results from in ? -- Robin From walters at redhat.com Sun Mar 27 13:03:04 2005 From: walters at redhat.com (Colin Walters) Date: Sun, 27 Mar 2005 08:03:04 -0500 Subject: [fedora-java] DBus and Java In-Reply-To: <1cef3e9505032704453b2ff07d@mail.gmail.com> References: <1cef3e9505032704453b2ff07d@mail.gmail.com> Message-ID: <1111928584.16952.28.camel@nexus.verbum.private> On Sun, 2005-03-27 at 13:45 +0100, Joe Desbonnet wrote: > I understand that the long term plan with Fedora is to expose all > system configuration information via DBus. I wouldn't say that, really. I don't think anyone is going to make a D-BUS service for exposing Apache configuration, for example. That's not to say it wouldn't be neat if it just happened, but I think it would be of less value than some other things we could be spending time on. > Are there any Java bindings > for this yet? Not yet, no. The Java-GNOME people are working on it though: http://lists.freedesktop.org/archives/dbus/2005-February/002180.html > Part of the reason I ask is I'm wondering what is (or will be) the > correct way to query locally installed RPMs. I think Robin's correct; your best bet now is just to invoke rpm. Alternatively there might be Java bindings to the librpm. From phil at mkdoc.com Sun Mar 27 17:20:57 2005 From: phil at mkdoc.com (Phil Shaw) Date: Sun, 27 Mar 2005 18:20:57 +0100 Subject: [fedora-java] DBus and Java In-Reply-To: <1111928584.16952.28.camel@nexus.verbum.private> References: <1cef3e9505032704453b2ff07d@mail.gmail.com> Message-ID: <4246F989.6840.1E456C5A@localhost> On 27 Mar 2005, at 8:03, Colin Walters wrote: > > Part of the reason I ask is I'm wondering what is (or will be) the > > correct way to query locally installed RPMs. > > I think Robin's correct; your best bet now is just to invoke rpm. > Alternatively there might be Java bindings to the librpm. I haven't used this, but found it by accident some time ago and bookmarked it. It might give the start you're after. From greenrd at presidium.org Sun Mar 27 17:23:54 2005 From: greenrd at presidium.org (Robin Green) Date: Sun, 27 Mar 2005 12:23:54 -0500 (EST) Subject: [fedora-java] DBus and Java In-Reply-To: <4246F989.6840.1E456C5A@localhost> References: <1cef3e9505032704453b2ff07d@mail.gmail.com> <4246F989.6840.1E456C5A@localhost> Message-ID: On Sun, 27 Mar 2005, Phil Shaw wrote: > I haven't used this, but found it by accident some time ago and > bookmarked it. It might give the start you're after. > > Also, I have hacked jrpm to support the rpm headers that older versions of yum use (newer versions use XML). Email me if you want that code. From tromey at redhat.com Mon Mar 28 21:12:04 2005 From: tromey at redhat.com (Tom Tromey) Date: 28 Mar 2005 14:12:04 -0700 Subject: [fedora-java] New Eclipse RPMs In-Reply-To: <1111140385.5383.8.camel@localhost> References: <20050225164858.GH19850@redhat.com> <1109465599.8854.32.camel@localhost> <1111140385.5383.8.camel@localhost> Message-ID: >>>>> "Ziga" == Ziga Mahkovec writes: >> I could send the patch if someone wants to test it. Otherwise it will >> have to wait until I get my tree back in a sane state so I can try it >> out. Ziga> I'd be willing to test the patch. Given that this was actually a native Ziga> compilation issue[1] (it works fine in interpreted mode), does this Ziga> patch work around a compiler issue? Ziga> [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149915 Thanks for pointing this out. The reason I didn't send the patch is that it is purely on the runtime side, so probably wouldn't have helped. Tom From tjarvi at qbang.org Tue Mar 29 10:08:35 2005 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 29 Mar 2005 03:08:35 -0700 (MST) Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <42447EC7.4000109@limepeer.com> References: <42447EC7.4000109@limepeer.com> Message-ID: On Fri, 25 Mar 2005, zbalevsky wrote: > Greetings, > > I looked around bugzilla but there wasn't anything similar to this bug. > Every time I start the native eclipse, the entire computer freezes as soon as > it passes the splash screen. Hard reset is the only thing that works from > that point on. I tried starting the regular eclipse 3.1M5 with gij and the > result was the same; regular eclipse runs fine on the Sun jvm. > > This is an i386 fc4t1 system updated to the latest rawhide (from last night). > Are there any options I can pass to either gij or the eclipse binary that > will make it print some debugging info? > I found your post after filing a bug which sounds very similar. I had just been passivly following but have seen a bug like this for weeks. I finally decided to netdump and see if anyone had any ideas. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152386 -- Trent Jarvi From aph at redhat.com Tue Mar 29 20:54:34 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Mar 2005 21:54:34 +0100 Subject: [fedora-java] db merging script In-Reply-To: <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <16969.49290.344620.134371@cuddles.cambridge.redhat.com> Anthony Green writes: > On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote: > > >>>>> "Anthony" == Anthony Green writes: > > > > Anthony> Here's a real-world example from the servletapi5 spec file. It > > Anthony> currently assumes that we should be using `gcj-dbtool -p`. > > Anthony> Comments/suggestions welcome. > > > > Anthony> + # Generate native code. > > Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar > > Anthony> + gcj-dbtool -n jspapi-%{version}.db > > [ ...] > > > > If it isn't too unwieldy, I would like to see this whole section > > replaced by a single call to some shell script to automate the > > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > > utterly trivial... > > hmmm.. what do you mean by "find" in find-compile-db? I don't think > it's safe to simply compile and db-ify any .jar file in your build tree. > > The best we might hope for is probably something like... > > gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS > > SRC_JARFILE refers to the jar file we want to process. > > DEST_SO_NAME is the name we want to install it as. JPackages seem to > use different build and install jar names in some cases, so we can't > infer from SRC_JARFILE. And we should probably version the library > name. > > BUILD_OPTIONS is needed because we want to pass in $RPM_OPT_FLAGS. > I suppose the script can handle certain options, like -findirect- > dispatch and -Wl,Bsymbolic. > > I'm not sure I'd call this utterly trivial. Is it enough of an > improvement over what I suggested earlier? > > > Then we could have another little script to replace: > > DB=`gcj-dbtool -p %{_libdir}` > rm -f $DB I don't like this. Any process that starts during this time will fail because the .db is missing. The right way is to find everything and merge into the master. This is how it should work: DB=`gcj-dbtool -p %{_libdir}` (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) If we expect problems with command line lengths I'll fix gcj-dbtool to take the list from stdin. Andrew. From bkonrath at redhat.com Tue Mar 29 21:14:15 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 29 Mar 2005 16:14:15 -0500 Subject: [fedora-java] native and regular eclipse freezing in fc4t1 In-Reply-To: <4244EB97.40209@limepeer.com> References: <42447EC7.4000109@limepeer.com> <20050325212556.GA3809@town.toronto.redhat.com> <42448774.9040704@limepeer.com> <20050326014138.GB3809@town.toronto.redhat.com> <4244EB97.40209@limepeer.com> Message-ID: <1112130855.10339.26.camel@town.toronto.redhat.com> Hi, Sorry for the delay, I was offline for the latter part of the Easter holiday. On Fri, 2005-03-25 at 23:56 -0500, zbalevsky wrote: > I really don't think this is an eclipse problem since when I ran it > under strace -ff everything went fine (albeit excruciatingly slow). Any > idea where I can take this issue next? gcj / gij / kernel people? If I > open a bugzilla will it end up being redirected here? I agree, this probably isn't an Eclipse bug. Let's use the open bug to track this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152386 (Thanks for pointing this out Trent.) > !ENTRY org.eclipse.core.resources 4 567 2005-03-25 23:48:21.756 > !MESSAGE Conversion of persistent properties failed. > !SUBENTRY 1 org.eclipse.core.resources 4 271 2005-03-25 23:48:21.757 > !MESSAGE Could not create indexed cursor: /root/workspace/.metadata/.plugins/org.eclipse.core.resources/.root/.properties. > !STACK 0 > IndexedStoreException:Index not found. > at org.eclipse.core.internal.indexing.IndexedStore.getIndex(java.lang.String) (/usr/lib/eclipse/plugins/org.eclipse.core.resources.compatibility_3.1.0/compatibility.jar.so) > at org.eclipse.core.internal.properties.IndexedStoreWrapper.getIndex() (/usr/lib/eclipse/plugins/org.eclipse.core.resources.compatibility_3.1.0/compatibility.jar.so) This is a bug, but it is probably not the cause of your problem because I get the same exception but my machine but my machine doesn't crash. Cheers, Ben From overholt at redhat.com Tue Mar 29 22:48:16 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 29 Mar 2005 17:48:16 -0500 Subject: [fedora-java] db merging script In-Reply-To: <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <20050329224815.GB20638@redhat.com> * Anthony Green [2005-03-24 20:30]: > > If it isn't too unwieldy, I would like to see this whole section > > replaced by a single call to some shell script to automate the > > find-compile-db loop. My goal is to make gcj-izing a jpackage RPM > > utterly trivial... > The best we might hope for is probably something like... > > gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS > > Then we could have another little script to replace: > > DB=`gcj-dbtool -p %{_libdir}` > rm -f $DB > gcj-dbtool -n $DB > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) How about the attached three scripts? gcj-findandnativify.sh is kinda flaky, but it'll work well for us during the eclipse build procedure (I'm testing a build now). I've attached a patch to the current eclipse.spec and it simplifies things greatly. Comments welcome. > Could these go in java-gcj-compat? Or maybe as RPM macros? Tom Fitzsimmons has offered to put these in java-gcj-compat. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: gcj-findandnativify.sh Type: application/x-sh Size: 1019 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gcj-nativify.sh Type: application/x-sh Size: 435 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rebuildgcjdb.sh Type: application/x-sh Size: 298 bytes Desc: not available URL: -------------- next part -------------- --- eclipse.spec 2005-03-29 16:36:02.000000000 -0500 +++ eclipse.spec.new 2005-03-29 17:42:48.000000000 -0500 @@ -424,27 +424,12 @@ # Native build -- do -O2 on x86 and ppc only (for now) %ifarch %{ix86} ppc - mkdir -p $RPM_BUILD_ROOT%{_libdir}/%{name} - for j in `find -name \*.jar`; do - d=".%{_libdir}/%{name}/`dirname $j | sed 's:\./::'`"; - mkdir -p $d; - s=`echo $j | sed "s:\./::"`; - gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -O2 \ - -o $d/`basename $j`.so $j; - done + gcj-findandnativify.sh %{name} "$RPM_OPT_FLAGS -fPIC -fjni -O2" %else - mkdir -p $RPM_BUILD_ROOT%{_libdir}/%{name} - for j in `find -name \*.jar`; do - d=".%{_libdir}/%{name}/`dirname $j | sed 's:\./::'`"; - mkdir -p $d; - s=`echo $j | sed "s:\./::"`; - gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic \ - -o $d/`basename $j`.so $j; - done + gcj-findandnativify.sh %{name} "$RPM_OPT_FLAGS -fPIC -fjni" %endif -# Tar up the native libs -tar czvf ../%{name}-nativelycompiledjars.tar.gz .%{_libdir}/%{name} +mv %{name}.tar.gz .. popd @@ -466,12 +451,12 @@ install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/%{name} # Natively-compiled jars (shared libraries) -tar -C $RPM_BUILD_ROOT -zxf result/%{name}-nativelycompiledjars.tar.gz +tar -C $RPM_BUILD_ROOT -zxf result/%{name}.tar.gz install -d -m 755 $RPM_BUILD_ROOT%{_bindir} # Directory to hold all the .jar->.so mapping dbs -install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings +install -d -m 755 $RPM_BUILD_ROOT`gcj-dbtool -p %{_libdir}` # Eclipse binary mv $RPM_BUILD_ROOT%{_datadir}/%{name}/eclipse \ @@ -648,24 +633,25 @@ $RPM_BUILD_ROOT%{_datadir}/java/jdtcore.jar # Create the gcj dbs for libswt, ecj, platform, jdt, and pde -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/ecj.db 80000 -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/libswt3-gtk2.db 80000 -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/platform.db 80000 -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db 80000 -gcj-dbtool -n $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/pde.db 80000 +gcjdbdir=`gcj-dbtool -p %{_libdir}` +gcj-dbtool -n $gcjdbdir/ecj.db 80000 +gcj-dbtool -n $gcjdbdir/libswt3-gtk2.db 80000 +gcj-dbtool -n $gcjdbdir/platform.db 80000 +gcj-dbtool -n $gcjdbdir/jdt.db 80000 +gcj-dbtool -n $gcjdbdir/pde.db 80000 # ecj db -gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/ecj.db \ +gcj-dbtool -f $gcjdbdir/ecj.db \ $RPM_BUILD_ROOT%{_datadir}/%{name}/plugins/org.eclipse.jdt.core_%{eclipse_majmin}.%{eclipse_micro}/jdtcore.jar \ %{_libdir}/%{name}/plugins/org.eclipse.jdt.core_%{eclipse_majmin}.%{eclipse_micro}/jdtcore.jar.so -gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/ecj.db \ +gcj-dbtool -f $gcjdbdir/ecj.db \ $RPM_BUILD_ROOT%{_datadir}/%{name}/plugins/org.eclipse.jdt.core_%{eclipse_majmin}.%{eclipse_micro}/jdtCompilerAdapter.jar \ %{_libdir}/%{name}/plugins/org.eclipse.jdt.core_%{eclipse_majmin}.%{eclipse_micro}/jdtCompilerAdapter.jar.so # jdt db for dir in `cat %{SOURCE7}`; do for j in `find $RPM_BUILD_ROOT/$dir -name \*.jar`; do - gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db \ + gcj-dbtool -f $gcjdbdir/jdt.db \ $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; done; done @@ -673,7 +659,7 @@ # pde db for dir in `cat %{SOURCE8}`; do for j in `find $RPM_BUILD_ROOT/$dir -name \*.jar`; do - gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db \ + gcj-dbtool -f $gcjdbdir/pde.db \ $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; done; done @@ -681,7 +667,7 @@ # platform db for dir in `cat %{SOURCE9}`; do for j in `find $RPM_BUILD_ROOT/$dir -name \*.jar`; do - gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db \ + gcj-dbtool -f $gcjdbdir/platform.db \ $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; done; done @@ -689,7 +675,7 @@ # swt db for dir in `cat %{SOURCE10}`; do for j in `find $RPM_BUILD_ROOT/$dir -name \*.jar`; do - gcj-dbtool -f $RPM_BUILD_ROOT%{_libdir}/%{name}/mappings/jdt.db \ + gcj-dbtool -f $gcjdbdir/libswt3-gtk2.db \ $j `echo $j | sed "s:$RPM_BUILD_ROOT/::" | sed "s:%{_datadir}:%{_libdir}:"`.so; done; done @@ -698,97 +684,44 @@ rm -rf $RPM_BUILD_ROOT %post ecj -dbLocation=`gcj-dbtool -p` -if ! [ -e $dbLocation ]; then - dirname $dbLocation | xargs mkdir -p - gcj-dbtool -n $dbLocation -fi - -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %post jdt -dbLocation=`gcj-dbtool -p` -if ! [ -e $dbLocation ]; then - dirname $dbLocation | xargs mkdir -p - gcj-dbtool -n $dbLocation -fi - -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %post pde -dbLocation=`gcj-dbtool -p` -if ! [ -e $dbLocation ]; then - dirname $dbLocation | xargs mkdir -p - gcj-dbtool -n $dbLocation -fi - -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %post platform -dbLocation=`gcj-dbtool -p` -if ! [ -e $dbLocation ]; then - dirname $dbLocation | xargs mkdir -p - gcj-dbtool -n $dbLocation -fi +rebuildgcjdb.sh %{_libdir} -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi touch --no-create %{_datadir}/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then gtk-update-icon-cache %{_datadir}/icons/hicolor fi %post -n %{libname}-gtk2 -dbLocation=`gcj-dbtool -p` -mkdir -p `dirname $dbLocation` -if ! [ -e $dbLocation ]; then - gcj-dbtool -n $dbLocation -fi - -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %postun ecj -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %postun jdt -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %postun pde -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} %postun platform -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} + touch --no-create %{_datadir}/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then gtk-update-icon-cache %{_datadir}/icons/hicolor fi %postun -n %{libname}-gtk2 -dbLocation=`gcj-dbtool -p` -if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then - gcj-dbtool -m $dbLocation `find %{_libdir}/%{name}/mappings -name \*.db` $dbLocation -fi +rebuildgcjdb.sh %{_libdir} # FIXME: add the native directories to these lists %files ecj @@ -797,8 +730,7 @@ %{_datadir}/%{name}/plugins/org.eclipse.jdt.core_3.* %{_datadir}/java/jdtcore*.jar # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/ecj.db +`gcj-dbtool -p %{_libdir}`/ecj.db %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.core_3.1.0/jdtCompilerAdapter.jar.so @@ -816,8 +748,7 @@ %{_javadir}/swt-mozilla*.jar %{_javadir}/swt-cairo*.jar # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/libswt3-gtk2.db +`gcj-dbtool -p %{_libdir}`/libswt3-gtk2.db %ifarch alpha ia64 ppc64 sparc64 x86_64 %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.swt.gtk64_3.1.0/ws/gtk/swt-pi.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.swt.gtk64_3.1.0/ws/gtk/swt-mozilla.jar.so @@ -835,8 +766,7 @@ %files jdt -f %{name}-jdt.install %defattr(0644,root,root,0755) # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/jdt.db +`gcj-dbtool -p %{_libdir}`/libswt3-gtk2.db %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.debug.ui_3.1.0/jdiui.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.debug.ui_3.1.0/snippetsupport.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.jdt.debug_3.1.0/jdimodel.jar.so @@ -856,8 +786,7 @@ %files pde -f %{name}-pde.install %defattr(0644,root,root,0755) # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/pde.db +`gcj-dbtool -p %{_libdir}`/libswt3-gtk2.db %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.pde.build_3.1.0/lib/pdebuild-ant.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.pde.build_3.1.0/pdebuild.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.pde.core_3.1.0/pdecore.jar.so @@ -890,8 +819,7 @@ %{_datadir}/icons/*/*/apps/* %config(noreplace) %{_sysconfdir}/eclipse.conf # Native bits -%dir %{_libdir}/%{name}/mappings -%{_libdir}/%{name}/mappings/platform.db +`gcj-dbtool -p %{_libdir}`/libswt3-gtk2.db %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.ant.core_3.1.0/antsupport.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.compare_3.1.0/compare.jar.so %attr(0755,root,root) %{_libdir}/%{name}/plugins/org.eclipse.core.boot_3.0.0/boot.jar.so From aph at redhat.com Wed Mar 30 15:10:37 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 30 Mar 2005 16:10:37 +0100 Subject: [fedora-java] db merging script In-Reply-To: <20050329224815.GB20638@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> Message-ID: <16970.49517.917898.99294@cuddles.cambridge.redhat.com> It's been pointed out to me that if we merge db's with the obvious (find . -name 'temp-*.db' | xargs gcj-dbtool -m $DB) we run the risk of failure if arg length exceeds the operating system limit, because xargs will call gcj-dbtool several times. The right way to fix this is to have gcj-dbtool read a list of files from stdin, which is what this patch does. (find . -name 'temp-*.db' | gcj-dbtool - -m $DB) Andrew. 2005-03-30 Andrew Haley * gnu/gcj/tools/gcj_dbtool/Main.java (Fileset): New class. (getFiles): New method. (main): Add "-" argument. Read list of files from stdin when merging map databases. (usage): Add "-" argument. Minor corrections. Index: Main.java =================================================================== RCS file: /cvs/gcc/gcc/libjava/gnu/gcj/tools/gcj_dbtool/Main.java,v retrieving revision 1.9 diff -c -2 -p -r1.9 Main.java *** Main.java 25 Mar 2005 00:38:43 -0000 1.9 --- Main.java 30 Mar 2005 15:04:15 -0000 *************** public class Main *** 23,27 **** --- 23,37 ---- public static void main (String[] s) { + boolean fileListFromStdin = false; insist (s.length >= 1); + + if (s[0].equals("-")) + { + fileListFromStdin = true; + String[] newArgs = new String[s.length - 1]; + System.arraycopy(s, 1, newArgs, 0, s.length - 1); + s = newArgs; + } + if (s[0].equals("-v") || s[0].equals("--version")) { *************** public class Main *** 146,151 **** { // Merge databases. ! insist (s.length >= 3); ! try { File database = new File(s[1]); --- 156,162 ---- { // Merge databases. ! insist (s.length >= 3 ! || fileListFromStdin && s.length == 2); ! try { File database = new File(s[1]); *************** public class Main *** 156,171 **** int newSize = 0; int newStringTableSize = 0; ! PersistentByteMap[] sourceMaps = new PersistentByteMap[s.length - 2]; // Scan all the input files, calculating worst case string // table and hash table use. ! for (int i = 2; i < s.length; i++) ! { ! PersistentByteMap b ! = new PersistentByteMap(new File(s[i]), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i - 2] = b; ! } newSize *= 1.5; // Scaling the new size by 1.5 results in --- 167,188 ---- int newSize = 0; int newStringTableSize = 0; ! Fileset files = getFiles(s, 2, fileListFromStdin); ! PersistentByteMap[] sourceMaps = new PersistentByteMap[files.size()]; ! // Scan all the input files, calculating worst case string // table and hash table use. ! { ! Iterator it = files.iterator(); ! int i = 0; ! while (it.hasNext()) ! { ! PersistentByteMap b ! = new PersistentByteMap((File)it.next(), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i++] = b; ! } ! } newSize *= 1.5; // Scaling the new size by 1.5 results in *************** public class Main *** 297,310 **** + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name"); } --- 314,329 ---- + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool [-] -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " If the first arg is -, read the list from stdin\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name" ! ); } *************** public class Main *** 406,409 **** --- 425,485 ---- return hexBytes.toString(); } + + + // Return a Fileset, either from a String array or from System.in, + // depending on fileListFromStdin. + private static final Fileset getFiles(String[] s, int startPos, + boolean fileListFromStdin) + { + if (fileListFromStdin) + return new Fileset(System.in); + else + return new Fileset(s, startPos, s.length); + } } + // A Fileset is a container for a set of files; it can be created + // either from a string array or from an input stream. + class Fileset + { + LinkedHashSet files = new LinkedHashSet(); + + Fileset (String[] s, int start, int end) + { + for (int i = start; i < end; i++) + { + files.add(new File(s[i])); + } + } + + Fileset (InputStream is) + { + Reader r = new BufferedReader(new InputStreamReader(is)); + StringBuffer buf = new StringBuffer(); + try + { + int chr; + while ((chr = r.read()) != -1) + buf.append((char)chr); + } + catch (IOException _) + { + } + StringTokenizer st = new StringTokenizer(buf.toString()); + while (st.hasMoreElements ()) + { + String name = st.nextToken (); + files.add(new File(name)); + } + } + + Iterator iterator() + { + return files.iterator(); + } + + int size() + { + return files.size(); + } + } From tromey at redhat.com Wed Mar 30 19:38:00 2005 From: tromey at redhat.com (Tom Tromey) Date: 30 Mar 2005 12:38:00 -0700 Subject: [fedora-java] db merging script In-Reply-To: <200503301519.j2UFJpAv024829@littlepinkcloud.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: Andrew> The right way to fix this is to have gcj-dbtool read a list of files Andrew> from stdin, which is what this patch does. Andrew> (find . -name 'temp-*.db' | gcj-dbtool - -m $DB) This needs a corresponding gcj.texi patch. Tom From aph at redhat.com Thu Mar 31 06:01:07 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Mar 2005 07:01:07 +0100 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> Message-ID: <16971.37411.793787.473750@cuddles.cambridge.redhat.com> Tom Tromey writes: > >>>>> "Andrew" == Andrew Haley writes: > > Andrew> The right way to fix this is to have gcj-dbtool read a list of files > Andrew> from stdin, which is what this patch does. > Andrew> (find . -name 'temp-*.db' | gcj-dbtool - -m $DB) > > This needs a corresponding gcj.texi patch. Yes, but I'm waiting for feedback before I write it. Andrew. From tromey at redhat.com Thu Mar 31 18:29:19 2005 From: tromey at redhat.com (Tom Tromey) Date: 31 Mar 2005 11:29:19 -0700 Subject: [fedora-java] db merging script In-Reply-To: <16971.37411.793787.473750@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> Message-ID: >> This needs a corresponding gcj.texi patch. Andrew> Yes, but I'm waiting for feedback before I write it. I think the idea is sound, and needed. I think we should also support reading "find -0" output, i.e. '\0'-separated strings. That would let us support file names with spaces in them, and other oddities. Tom From aph at redhat.com Thu Mar 31 18:42:51 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Mar 2005 19:42:51 +0100 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> Message-ID: <16972.17579.880662.402733@cuddles.cambridge.redhat.com> Tom Tromey writes: > >> This needs a corresponding gcj.texi patch. > > Andrew> Yes, but I'm waiting for feedback before I write it. > > I think the idea is sound, and needed. > > I think we should also support reading "find -0" output, > i.e. '\0'-separated strings. That would let us support file names > with spaces in them, and other oddities. Okay. This is why I like to wait for comments... So we have an additional "-0" arg to dbtool? Andrew.