From gbenson at redhat.com Wed Feb 1 08:53:28 2006 From: gbenson at redhat.com (Gary Benson) Date: Wed, 1 Feb 2006 08:53:28 +0000 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1138740075.21962.20.camel@FC4a.CHD.hubick.com> References: <1138662354.9819.14.camel@localhost.localdomain> <1138692634.12668.74.camel@FC4a.CHD.hubick.com> <2ee1c2b30601311204v1a91d207gc0131bedf047ab49@mail.gmail.com> <1138740075.21962.20.camel@FC4a.CHD.hubick.com> Message-ID: <20060201085326.GB5194@redhat.com> Chris Hubick wrote: > So although Fedora recommends the use of JPackage for installing > alternate Java Runtime Environments... It's designed to _allow_ the use of alternative JREs from JPackage but I wouldn't say it _recommends_ it. As far as I'm concerned Fedora recommends using the Free Software runtime and development environment and working with us to fix any bugs or deficiencies you find. > ...there is a good chance unmodified JPackage applications will > not work with the default Runtime Environment shipped with Fedora. There is also a good chance that unmodified JPackage applications will work just fine. GCJ 4.1's lazy loading and the fast improving Swing implementation mean that it is rapidly becoming the case that the only applications that will not work are those that use undocumented and unsupported calls to Sun-specific classes. Cheers, Gary From green at redhat.com Wed Feb 1 18:39:27 2006 From: green at redhat.com (Anthony Green) Date: Wed, 01 Feb 2006 10:39:27 -0800 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <2ee1c2b30601311204v1a91d207gc0131bedf047ab49@mail.gmail.com> References: <1138662354.9819.14.camel@localhost.localdomain> <1138692634.12668.74.camel@FC4a.CHD.hubick.com> <2ee1c2b30601311204v1a91d207gc0131bedf047ab49@mail.gmail.com> Message-ID: <1138819167.31387.87.camel@localhost.localdomain> On Tue, 2006-01-31 at 14:04 -0600, Weiqi Gao wrote: > Has anyone noticed the implicit contradiction between "you should use > the JDK from the JPackage repo" and "you should not use the JPackage > repo"? The relationship between JPackage and Fedora Core is complicated. I wish it were simpler. What we really have in FC is a fork of JPackage where we've removed all dependencies on non-free software, so we're only partly compatible with the JPackage repository. >From what I can tell the JPackage project is moving in that same direction as well. They appear to be dropping "non-free" dependencies from their "free" packages. Can anybody confirm that this is their actual plan? AG From kwade at redhat.com Wed Feb 1 21:22:11 2006 From: kwade at redhat.com (Karsten Wade) Date: Wed, 01 Feb 2006 13:22:11 -0800 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1138662354.9819.14.camel@localhost.localdomain> References: <1138662354.9819.14.camel@localhost.localdomain> Message-ID: <1138828931.5151.488.camel@erato.phig.org> On Mon, 2006-01-30 at 15:05 -0800, Anthony Green wrote: > I've been really bad about preparing the FC5 release notes for java. I > wrote the followup up today, which I think covers the number 1 issue. > Comments? We moved some of the content around to come up with this: http://fedoraproject.org/wiki/Docs/Beats/PackageNotes/Java I'm doing clean-up for the test3 snapshot, so your changes are JIT. Now, if you could give me some good news about packaging FOP for Extras ... Chris Hubick -- got your comments. The content has changed since your original reply. Can you look back at the page and see which of your concerns still exist? Feel free to edit the Wiki directly. If you think you need your changes vetted, make sure that sundaram at redhat.com remains on the Cc: (though he is probably on this list already.) - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- 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 chris at hubick.com Wed Feb 1 22:05:43 2006 From: chris at hubick.com (Chris Hubick) Date: Wed, 01 Feb 2006 15:05:43 -0700 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1138828931.5151.488.camel@erato.phig.org> References: <1138662354.9819.14.camel@localhost.localdomain> <1138828931.5151.488.camel@erato.phig.org> Message-ID: <1138831543.2384.25.camel@FC4a.CHD.hubick.com> On Wed, 2006-02-01 at 13:22 -0800, Karsten Wade wrote: > On Mon, 2006-01-30 at 15:05 -0800, Anthony Green wrote: > > I've been really bad about preparing the FC5 release notes for java. I > > wrote the followup up today, which I think covers the number 1 issue. > > Comments? > > We moved some of the content around to come up with this: > > http://fedoraproject.org/wiki/Docs/Beats/PackageNotes/Java > Chris Hubick -- got your comments. The content has changed since your > original reply. Can you look back at the page and see which of your > concerns still exist? The last note says: > Jpackage is a Java software repository compatible with Fedora. I think this language could lead to exactly the problem I had with FC4, where users will read this and run out an do a yum update from the JPP repository, not knowing it will mess up their FC Java. > Avoid installing third-party packages that are not compatible with > the JPackage repository. > Do not install RPM packages from vendors such as Sun Microsystems, > IBM, or BEA without first repackaging them using the appropriate > JPackage wrapper or compatibility package. Failure to do so leads > to unpredictable results. I also think this language is a little strong/absolute sounding. I personally would offer more of a "doing so *can* lead to problems with the shipped solutions" stance (if you don't know what you are doing). That is to say, if you do go ahead and take a stock FC5 box and install Sun's RPM and non-jpackage Java software, as long as your path's are right, it *will* probably work. The other thing I notice is the complete lack of another note clause resembling the proposed: "Please note that despite utilizing the JPackage installation guidelines, several of the Java application software packages shipped with Fedora have been slightly modified from those provided by JPackage, in order to work out of the box with the included compiler and runtime environment. Additionally, the Fedora packages also include pre-compiled fast and optimized native binary code alongside the original Java bytecode JAR files. As a result, if you modify your Yum configuration and update to application software packages shipped directly through the JPackage Yum repository, you will end up with an unpredictable mix of bytecode and binary software. So although Fedora allows the use of JPackage for installing alternate Java Runtime Environments, JPackage is not necessarily recommended for the Java application software packages which use that runtime. Users wishing to maintain a supported software platform, by using the Free Java Runtime Environment shipped with Fedora, are advised to only update their systems with Java application software packages provided through the Fedora and Fedora Extras Yum repositories, and not directly through JPackage unless they also plan to switch to one of their alternate/proprietary Java runtimes. The Fedora provided application software packages should continue to work with other Java Runtime Environments which follow JPackage guidelines, but as stated above, there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora." Do people not think this is a good idea then? Too verbose? I hesitate to edit the wiki myself, as historically I have been just a lowly Fedora user, I don't know what you dev's want, and don't want to step on anyones toes, and lastly as a programmer, my spelling, punctuation, capitalization, and grammar skills need some... ehh... refinement (as if you couldn't tell already :). -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From green at redhat.com Wed Feb 1 22:36:32 2006 From: green at redhat.com (Anthony Green) Date: Wed, 01 Feb 2006 14:36:32 -0800 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1138831543.2384.25.camel@FC4a.CHD.hubick.com> References: <1138662354.9819.14.camel@localhost.localdomain> <1138828931.5151.488.camel@erato.phig.org> <1138831543.2384.25.camel@FC4a.CHD.hubick.com> Message-ID: <1138833392.31387.129.camel@localhost.localdomain> On Wed, 2006-02-01 at 15:05 -0700, Chris Hubick wrote: > The last note says: > > > Jpackage is a Java software repository compatible with Fedora. > > I think this language could lead to exactly the problem I had with FC4, > where users will read this and run out an do a yum update from the JPP > repository, not knowing it will mess up their FC Java. Totally agreed. JPackage is only partially compatible with FC. > > Avoid installing third-party packages that are not compatible with > > the JPackage repository. > > > Do not install RPM packages from vendors such as Sun Microsystems, > > IBM, or BEA without first repackaging them using the appropriate > > JPackage wrapper or compatibility package. Failure to do so leads > > to unpredictable results. > > I also think this language is a little strong/absolute sounding. I > personally would offer more of a "doing so *can* lead to problems with > the shipped solutions" stance (if you don't know what you are doing). > That is to say, if you do go ahead and take a stock FC5 box and install > Sun's RPM and non-jpackage Java software, as long as your path's are > right, it *will* probably work. I like the strong wording. My understanding is that the Sun RPM won't work for certain things if you have SELinux enabled because they don't set the file attributes during install. This is something we can fix in the JPackage wrapper. I also think it's in everybody's best interest if Sun, IBM, BEA _did_ package their systems using the JPackage guidelines, so spreading the meme that it is a requirement is a good idea. In a sense, it also "breaks" alternatives, since users may put /opt/whatever in their path. Why encourage something that is just bad practice? > The other thing I notice is the complete lack of another note clause > resembling the proposed: > > "Please note that despite utilizing the JPackage installation > guidelines, several of the Java application software packages shipped > with Fedora have been slightly modified from those provided by JPackage, > in order to work out of the box with the included compiler and runtime > environment. Additionally, the Fedora packages also include > pre-compiled fast and optimized native binary code alongside the > original Java bytecode JAR files. As a result, if you modify your Yum > configuration and update to application software packages shipped > directly through the JPackage Yum repository, you will end up with an > unpredictable mix of bytecode and binary software. So although Fedora > allows the use of JPackage for installing alternate Java Runtime > Environments, JPackage is not necessarily recommended for the Java > application software packages which use that runtime. Users wishing to > maintain a supported software platform, by using the Free Java Runtime > Environment shipped with Fedora, are advised to only update their > systems with Java application software packages provided through the > Fedora and Fedora Extras Yum repositories, and not directly through > JPackage unless they also plan to switch to one of their > alternate/proprietary Java runtimes. The Fedora provided application > software packages should continue to work with other Java Runtime > Environments which follow JPackage guidelines, but as stated above, > there is a good chance unmodified JPackage applications will not work > with the default Runtime Environment shipped with Fedora." > > Do people not think this is a good idea then? Too verbose? I'd like to hear some other opinions on this. Personally, I wish there was a way to say something similar in fewer words... How about... * A note about the JPackage Project RPM repository. Fedora Core includes many packages derived from the excellent JPackage Project. These packages have been forked to remove non-free software dependencies and to make use of GCJ's ahead-of-time compilation feature. Fedora users should use the Fedora repositories for updates to these packages, and the JPackage repository for packages not provided by Fedora. ???? AG From i.pilcher at comcast.net Wed Feb 1 23:13:10 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 01 Feb 2006 17:13:10 -0600 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1138833392.31387.129.camel@localhost.localdomain> References: <1138662354.9819.14.camel@localhost.localdomain> <1138828931.5151.488.camel@erato.phig.org> <1138831543.2384.25.camel@FC4a.CHD.hubick.com> <1138833392.31387.129.camel@localhost.localdomain> Message-ID: Anthony Green wrote: > * A note about the JPackage Project RPM repository. Fedora Core > includes many packages derived from the excellent JPackage Project. > These packages have been forked to remove non-free software dependencies > and to make use of GCJ's ahead-of-time compilation feature. Fedora > users should use the Fedora repositories for updates to these packages, > and the JPackage repository for packages not provided by Fedora. At the very least, it need to clearly state that blindly adding the JPackage repo to one's yum configuration can have "bad consequences". -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From kwade at redhat.com Mon Feb 6 07:16:40 2006 From: kwade at redhat.com (Karsten Wade) Date: Sun, 05 Feb 2006 23:16:40 -0800 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: References: <1138662354.9819.14.camel@localhost.localdomain> <1138828931.5151.488.camel@erato.phig.org> <1138831543.2384.25.camel@FC4a.CHD.hubick.com> <1138833392.31387.129.camel@localhost.localdomain> Message-ID: <1139210201.27661.295.camel@erato.phig.org> On Wed, 2006-02-01 at 17:13 -0600, Ian Pilcher wrote: > Anthony Green wrote: > > * A note about the JPackage Project RPM repository. Fedora Core > > includes many packages derived from the excellent JPackage Project. > > These packages have been forked to remove non-free software dependencies > > and to make use of GCJ's ahead-of-time compilation feature. Fedora > > users should use the Fedora repositories for updates to these packages, > > and the JPackage repository for packages not provided by Fedora. > > At the very least, it need to clearly state that blindly adding the > JPackage repo to one's yum configuration can have "bad consequences". Does this set the right tone? http://fedoraproject.org/wiki/Docs/Beats/PackageNotes/Java Please adjust as you see fit. Technically this content is frozen for translation, but if we can get in a good version early enough tomorrow, I know I can squeeze it into the files being translated. Thanks - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- 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 Mon Feb 6 19:24:52 2006 From: tromey at redhat.com (Tom Tromey) Date: 06 Feb 2006 12:24:52 -0700 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1138833392.31387.129.camel@localhost.localdomain> References: <1138662354.9819.14.camel@localhost.localdomain> <1138828931.5151.488.camel@erato.phig.org> <1138831543.2384.25.camel@FC4a.CHD.hubick.com> <1138833392.31387.129.camel@localhost.localdomain> Message-ID: Anthony> I also think it's in everybody's best interest if Sun, IBM, Anthony> BEA _did_ package their systems using the JPackage Anthony> guidelines, so spreading the meme that it is a requirement is Anthony> a good idea. In a sense, it also "breaks" alternatives, Anthony> since users may put /opt/whatever in their path. Why Anthony> encourage something that is just bad practice? I think we ought to make a strong attempt to push this, while it could still have some effect. We can always soften it later if we don't convince upstream. Tom From tromey at redhat.com Mon Feb 6 19:30:18 2006 From: tromey at redhat.com (Tom Tromey) Date: 06 Feb 2006 12:30:18 -0700 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1139210201.27661.295.camel@erato.phig.org> References: <1138662354.9819.14.camel@localhost.localdomain> <1138828931.5151.488.camel@erato.phig.org> <1138831543.2384.25.camel@FC4a.CHD.hubick.com> <1138833392.31387.129.camel@localhost.localdomain> <1139210201.27661.295.camel@erato.phig.org> Message-ID: >>>>> "Karsten" == Karsten Wade writes: Karsten> Does this set the right tone? Karsten> http://fedoraproject.org/wiki/Docs/Beats/PackageNotes/Java I think this is the correct URL: http://fedoraproject.org/wiki/Docs/Beats/PackageNotesJava This content looked reasonable to me. BTW there is a typo in the JavaFAQ wiki page -- it says "wierd" and not "weird". Tom From kwade at redhat.com Tue Feb 7 21:42:59 2006 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Feb 2006 13:42:59 -0800 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: References: <1138662354.9819.14.camel@localhost.localdomain> <1138828931.5151.488.camel@erato.phig.org> <1138831543.2384.25.camel@FC4a.CHD.hubick.com> <1138833392.31387.129.camel@localhost.localdomain> <1139210201.27661.295.camel@erato.phig.org> Message-ID: <1139348579.16883.18.camel@erato.phig.org> On Mon, 2006-02-06 at 12:30 -0700, Tom Tromey wrote: > >>>>> "Karsten" == Karsten Wade writes: > > Karsten> Does this set the right tone? > Karsten> http://fedoraproject.org/wiki/Docs/Beats/PackageNotes/Java > > I think this is the correct URL: > > http://fedoraproject.org/wiki/Docs/Beats/PackageNotesJava Thanks, I had to rename it last night. > BTW there is a typo in the JavaFAQ wiki page -- it says "wierd" and > not "weird". Fixed. Let me know what your Wiki username is, and I'll add you to the EditGroup for the future. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- 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 kwade at redhat.com Tue Feb 7 21:47:22 2006 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Feb 2006 13:47:22 -0800 Subject: [fedora-java] status on FOP, Saxon Message-ID: <1139348842.16883.24.camel@erato.phig.org> Since FC5 has slipped its schedule so far out, we were hoping we might get a toolchain using an ecj compiled FOP into test3. We're currently relying upon a hacked version of xmlto that includes FOP and Saxon as targets, and we need to get FOP and Saxon in Fedora Extras to justify the upstream maintainer accepting the patch. 1. Where are we on a natively compiled FOP? 2. Can we compile Saxon with ecj as well? 3. Are there any volunteers to package these for Extras? AFAIK, _no_one_ has a 100% free modern DocBook XML toolchain that builds PDFs without a hitch and is in-step with the upstream DocBook project. Fedora Documentation Project wants to provide that free toolchain, and we are relying upon you all to help us get there. Thanks - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- 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 Feb 8 06:23:10 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 08 Feb 2006 01:23:10 -0500 Subject: [fedora-java] status on FOP, Saxon In-Reply-To: <1139348842.16883.24.camel@erato.phig.org> References: <1139348842.16883.24.camel@erato.phig.org> Message-ID: <1139379790.5455.111.camel@tortoise.toronto.redhat.com> Hi, On Tue, 2006-02-07 at 13:47 -0800, Karsten Wade wrote: > Since FC5 has slipped its schedule so far out, we were hoping we might > get a toolchain using an ecj compiled FOP into test3. > > We're currently relying upon a hacked version of xmlto that includes FOP > and Saxon as targets, and we need to get FOP and Saxon in Fedora Extras > to justify the upstream maintainer accepting the patch. > > 1. Where are we on a natively compiled FOP? I've been focusing on getting upstream Batik building on GNU Classpath. To support all of its features, we need to implement javax.imageio.plugins.jpeg for which there is currently a partial implementation that I'm working to finish. This work will probably not be completed before FC5 final ships. That said, we may be able to pare some of these features out of Batik to support just enough for FOP to run. I just noticed that JPackage has already packaged FOP, Saxon and Batik and that we include them in RHAPS, so I'm going to see how far I get building them on the free stack. > 2. Can we compile Saxon with ecj as well? I'm not sure; I'll let you know how far I get. > 3. Are there any volunteers to package these for Extras? Yes, I'll package and maintain them since they're excellent test cases for GNU Classpath's Java2D support. > > AFAIK, _no_one_ has a 100% free modern DocBook XML toolchain that builds > PDFs without a hitch and is in-step with the upstream DocBook project. > Fedora Documentation Project wants to provide that free toolchain, and > we are relying upon you all to help us get there. Yes, Batik is my top priority for my GNU Classpath work. While that work is ongoing I may be able to rig something for FOP-use in the short term. Tom From fitzsim at redhat.com Wed Feb 8 23:31:34 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 08 Feb 2006 18:31:34 -0500 Subject: [fedora-java] status on FOP, Saxon In-Reply-To: <1139379790.5455.111.camel@tortoise.toronto.redhat.com> References: <1139348842.16883.24.camel@erato.phig.org> <1139379790.5455.111.camel@tortoise.toronto.redhat.com> Message-ID: <1139441494.5455.126.camel@tortoise.toronto.redhat.com> Hi, On Wed, 2006-02-08 at 01:23 -0500, Thomas Fitzsimmons wrote: > Hi, > > On Tue, 2006-02-07 at 13:47 -0800, Karsten Wade wrote: > > Since FC5 has slipped its schedule so far out, we were hoping we might > > get a toolchain using an ecj compiled FOP into test3. > > > > We're currently relying upon a hacked version of xmlto that includes FOP > > and Saxon as targets, and we need to get FOP and Saxon in Fedora Extras > > to justify the upstream maintainer accepting the patch. > > > > 1. Where are we on a natively compiled FOP? > > I've been focusing on getting upstream Batik building on GNU Classpath. > To support all of its features, we need to implement > javax.imageio.plugins.jpeg for which there is currently a partial > implementation that I'm working to finish. This work will probably not > be completed before FC5 final ships. > > That said, we may be able to pare some of these features out of Batik to > support just enough for FOP to run. I just noticed that JPackage has > already packaged FOP, Saxon and Batik and that we include them in RHAPS, > so I'm going to see how far I get building them on the free stack. > > > 2. Can we compile Saxon with ecj as well? > > I'm not sure; I'll let you know how far I get. I worked my way through building Batik's dependencies today. Most of them are not in Fedora Core or Extras so I'll have to maintain them myself. Here's the list so far: libreadline-java ht2html ant-contrib jython mysql-connector-java With a few hacks around Sun-specific classes these packages all build on the free stack. Batik also requires Rhino which requires jaxen, dom4j and maven, which itself has 80 dependencies most of which are not in Fedora. I'm hoping that Rhino is only needed for SVG Javascript support and that I can build Batik without this support. I assume you don't need it for documentation. I'll keep you updated on my progress building Batik-sans-Rhino. > > > 3. Are there any volunteers to package these for Extras? > > Yes, I'll package and maintain them since they're excellent test cases > for GNU Classpath's Java2D support. Actually these packages should be maintained in Fedora Extras by the RHAPS maintainers. I'll see if this is an option. Tom From caolanm at redhat.com Thu Feb 9 19:07:10 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 09 Feb 2006 19:07:10 +0000 Subject: [fedora-java] OOo inside eclipse Message-ID: <1139512030.22675.1.camel@localhost.localdomain> OpenOffice.org as a eclipse editor plugin, might be interesting to see if this would all work under fedora. C. From caolanm at redhat.com Thu Feb 9 19:15:14 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 09 Feb 2006 19:15:14 +0000 Subject: [fedora-java] OOo inside eclipse In-Reply-To: <1139512030.22675.1.camel@localhost.localdomain> References: <1139512030.22675.1.camel@localhost.localdomain> Message-ID: <1139512515.22675.3.camel@localhost.localdomain> On Thu, 2006-02-09 at 19:07 +0000, Caolan McNamara wrote: > OpenOffice.org as a eclipse editor plugin, might be interesting to see > if this would all work under fedora. sigh! might help if I mentioned the link http://ubion.ion.ag/plonesoftwarecenter/003officeintegrationeditor C. From overholt at redhat.com Thu Feb 9 19:15:21 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 9 Feb 2006 14:15:21 -0500 Subject: [fedora-java] OOo inside eclipse In-Reply-To: <1139512030.22675.1.camel@localhost.localdomain> References: <1139512030.22675.1.camel@localhost.localdomain> Message-ID: <20060209191521.GC3081@redhat.com> * Caolan McNamara [2006-02-09 14:07]: > OpenOffice.org as a eclipse editor plugin, might be interesting to see > if this would all work under fedora. Is there something out there? Andrew From overholt at redhat.com Fri Feb 10 18:57:58 2006 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 10 Feb 2006 13:57:58 -0500 Subject: [fedora-java] OOo inside eclipse In-Reply-To: <1139512515.22675.3.camel@localhost.localdomain> References: <1139512030.22675.1.camel@localhost.localdomain> <1139512515.22675.3.camel@localhost.localdomain> Message-ID: <20060210185757.GK9862@redhat.com> * Caolan McNamara [2006-02-09 14:15]: > On Thu, 2006-02-09 at 19:07 +0000, Caolan McNamara wrote: > > OpenOffice.org as a eclipse editor plugin, might be interesting to see > > if this would all work under fedora. > > sigh! might help if I mentioned the link > > http://ubion.ion.ag/plonesoftwarecenter/003officeintegrationeditor I played with this a bit yesterday. I had to add some Eclipse .files to get things to build, but it all built fine. I couldn't get past the part of the configuration where I had to enter my install location of OpenOffice.org, though. Also, all the messages are in German so it's hard to figure out what I'm entering incorrectly :) I see that it's LGPL so I can re-distribute the source with my .project, etc., right? I can provide that if someone wants to try. I also ran into some sort of weird X error that Tom Tromey suggests might be caused by: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25375 Andrew From green at redhat.com Fri Feb 10 20:34:40 2006 From: green at redhat.com (Anthony Green) Date: Fri, 10 Feb 2006 12:34:40 -0800 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1139348579.16883.18.camel@erato.phig.org> References: <1138662354.9819.14.camel@localhost.localdomain> <1138828931.5151.488.camel@erato.phig.org> <1138831543.2384.25.camel@FC4a.CHD.hubick.com> <1138833392.31387.129.camel@localhost.localdomain> <1139210201.27661.295.camel@erato.phig.org> <1139348579.16883.18.camel@erato.phig.org> Message-ID: <1139603681.3367.443.camel@localhost.localdomain> Karsten - is too late to make changes to the wiki? I want to add a note about how people should include the results of "which java && java -version && which javac && javac -version" in all their java related bug reports. It's important to know what alternative somebody is using before we start looking into problems with Eclipse, etc. AG From kwade at redhat.com Sun Feb 12 18:25:06 2006 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Feb 2006 10:25:06 -0800 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1139603681.3367.443.camel@localhost.localdomain> References: <1138662354.9819.14.camel@localhost.localdomain> <1138828931.5151.488.camel@erato.phig.org> <1138831543.2384.25.camel@FC4a.CHD.hubick.com> <1138833392.31387.129.camel@localhost.localdomain> <1139210201.27661.295.camel@erato.phig.org> <1139348579.16883.18.camel@erato.phig.org> <1139603681.3367.443.camel@localhost.localdomain> Message-ID: <1139768706.11779.177.camel@erato.phig.org> On Fri, 2006-02-10 at 12:34 -0800, Anthony Green wrote: > Karsten - is too late to make changes to the wiki? It's never too late. We take regularly scheduled snapshots for the release notes. The shipping release notes always point to the latest snapshot, at the very top of the notes. > I want to add a note about how people should include the results of > > "which java && java -version && which javac && javac -version" > > in all their java related bug reports. It's important to know what > alternative somebody is using before we start looking into problems with > Eclipse, etc. Since we have snapped the Wiki for test3 but are still working on fixing our build of it, I'll insert this request directly into the XML and a matching one on the Wiki. Cheers - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- 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 caolanm at redhat.com Mon Feb 13 08:12:09 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Mon, 13 Feb 2006 08:12:09 +0000 Subject: [fedora-java] OOo inside eclipse In-Reply-To: <20060210185757.GK9862@redhat.com> References: <1139512030.22675.1.camel@localhost.localdomain> <1139512515.22675.3.camel@localhost.localdomain> <20060210185757.GK9862@redhat.com> Message-ID: <1139818329.26124.14.camel@localhost.localdomain> On Fri, 2006-02-10 at 13:57 -0500, Andrew Overholt wrote: > * Caolan McNamara [2006-02-09 14:15]: > > On Thu, 2006-02-09 at 19:07 +0000, Caolan McNamara wrote: > > > OpenOffice.org as a eclipse editor plugin, might be interesting to see > > > if this would all work under fedora. > > > > sigh! might help if I mentioned the link > > > > http://ubion.ion.ag/plonesoftwarecenter/003officeintegrationeditor > > I played with this a bit yesterday. I had to add some Eclipse .files to > get things to build, but it all built fine. I couldn't get past the part > of the configuration where I had to enter my install location of > OpenOffice.org, though. Also, all the messages are in German so it's hard > to figure out what I'm entering incorrectly :) I'd have guessed "/usr/lib/openoffice.org2.0" as the install location, though it may be /usr/lib/openoffice.org2.0/program. I *assume* that this all revolves around getting /usr/lib/openoffice.org2.0/program/libofficebean.so into action. C. From overholt at redhat.com Mon Feb 13 16:10:35 2006 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 13 Feb 2006 11:10:35 -0500 Subject: [fedora-java] OOo inside eclipse In-Reply-To: <1139818329.26124.14.camel@localhost.localdomain> References: <1139512030.22675.1.camel@localhost.localdomain> <1139512515.22675.3.camel@localhost.localdomain> <20060210185757.GK9862@redhat.com> <1139818329.26124.14.camel@localhost.localdomain> Message-ID: <20060213161035.GC26471@redhat.com> * Caolan McNamara [2006-02-13 03:12]: > On Fri, 2006-02-10 at 13:57 -0500, Andrew Overholt wrote: > > > > > > http://ubion.ion.ag/plonesoftwarecenter/003officeintegrationeditor > > > > I played with this a bit yesterday. I had to add some Eclipse .files to > > get things to build, but it all built fine. I couldn't get past the part > > of the configuration where I had to enter my install location of > > OpenOffice.org, though. Also, all the messages are in German so it's hard > > to figure out what I'm entering incorrectly :) > > I'd have guessed "/usr/lib/openoffice.org2.0" as the install location, > though it may be /usr/lib/openoffice.org2.0/program. I *assume* that > this all revolves around > getting /usr/lib/openoffice.org2.0/program/libofficebean.so > into action. Yeah, it was trying to load libofficebean.so. I did manage to figure out /usr/lib/openoffice.org2.0 (and also tried /program) but ran into the xlib issue that I mentioned. If anyone wants a copy of my workspace with all the dot files, etc. set up, I can put it online somewhere. Andrew From mailinglists at erwinrol.com Tue Feb 14 18:10:20 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 14 Feb 2006 19:10:20 +0100 Subject: [fedora-java] Open Xchange Message-ID: <1139940620.17385.178.camel@xpc.home.erwinrol.com> Hey all, I am working on a RPM for Open Xchange (http://www.open-xchange.org/) for FC5. Since OX uses some com.sun stuff it is a bit of a hack. First i added a CVS snapshot of the classpath javamail becuase OX needed the Rights class, that i could not find in the "normal" FC5 javamail. This all doesn't really work yet but it compiles. Since you need to login in OX before you can do something that is the first thing that should work, and here is the next problem, i need a LdapName class. I found one in the apache directory package but thats huge (like 5 times bigger than OX) and needs maven to compile. Does anybody know a good replacement for LdapName ? Than some general questions on how to install java programs, for example the default "make install" of OX installs its jar files in /usr/lib64/open-xchange/. Wouldn't /usr/share/java/open-xchange/ be better ? How to deal with different versions on the same package, for example the mentioned javamail package, i now have it as /usr/share/java/open-xchange/ox_javamail.jar, since it is only of use to OX (it is a CVS snappshot, i don't want to break other applications with it). TIA, Erwin From tromey at redhat.com Tue Feb 14 19:05:13 2006 From: tromey at redhat.com (Tom Tromey) Date: 14 Feb 2006 12:05:13 -0700 Subject: [fedora-java] Open Xchange In-Reply-To: <1139940620.17385.178.camel@xpc.home.erwinrol.com> References: <1139940620.17385.178.camel@xpc.home.erwinrol.com> Message-ID: >>>>> "Erwin" == Erwin Rol writes: Erwin> I am working on a RPM for Open Xchange (http://www.open-xchange.org/) Erwin> for FC5. Since OX uses some com.sun stuff it is a bit of a hack. First i Erwin> added a CVS snapshot of the classpath javamail becuase OX needed the Erwin> Rights class, that i could not find in the "normal" FC5 javamail. This Erwin> all doesn't really work yet but it compiles. There was a thread about this last year. One relevant message: http://lists.gnu.org/archive/html/classpath/2005-07/msg00141.html Erwin> Since you need to login in OX before you can do something that is the Erwin> first thing that should work, and here is the next problem, i need a Erwin> LdapName class. I found one in the apache directory package but thats Erwin> huge (like 5 times bigger than OX) and needs maven to compile. Erwin> Does anybody know a good replacement for LdapName ? Offhand, I don't. This class is new in 1.5, we don't have an implementation in Classpath yet. Erwin> Than some general questions on how to install java programs, for example Erwin> the default "make install" of OX installs its jar files Erwin> in /usr/lib64/open-xchange/. Wouldn't /usr/share/java/open-xchange/ be Erwin> better ? Yeah. Though it is possible, I suppose, for their jar file to be platform-dependent -- e.g. if they do the trick of stuffing a .so into the jar. (But, more likely it is just the old style of using lib and not share.) Erwin> How to deal with different versions on the same package, for Erwin> example the mentioned javamail package, i now have it Erwin> as /usr/share/java/open-xchange/ox_javamail.jar, since it is only of use Erwin> to OX (it is a CVS snappshot, i don't want to break other applications Erwin> with it). For this, I don't know. Tom From kwade at redhat.com Wed Feb 15 01:45:57 2006 From: kwade at redhat.com (Karsten Wade) Date: Tue, 14 Feb 2006 17:45:57 -0800 Subject: [fedora-java] status on FOP, Saxon In-Reply-To: <1139441494.5455.126.camel@tortoise.toronto.redhat.com> References: <1139348842.16883.24.camel@erato.phig.org> <1139379790.5455.111.camel@tortoise.toronto.redhat.com> <1139441494.5455.126.camel@tortoise.toronto.redhat.com> Message-ID: <1139967958.18050.40.camel@erato.phig.org> On Wed, 2006-02-08 at 18:31 -0500, Thomas Fitzsimmons wrote: > I worked my way through building Batik's dependencies today. Most of > them are not in Fedora Core or Extras so I'll have to maintain them > myself. Here's the list so far: Just a follow-up, thanks for the update. If there is anything that Fedora Documentation Project folks can do to help ... and we'll be testing Saxon and FOP as soon as the packages are in Extras, so you have that help ... just let myself, Tommy Reynolds , and/or fedora-docs-list. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- 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 mark at klomp.org Wed Feb 15 09:22:49 2006 From: mark at klomp.org (Mark Wielaard) Date: Wed, 15 Feb 2006 10:22:49 +0100 Subject: [fedora-java] status on FOP, Saxon In-Reply-To: <1139967958.18050.40.camel@erato.phig.org> References: <1139348842.16883.24.camel@erato.phig.org> <1139379790.5455.111.camel@tortoise.toronto.redhat.com> <1139441494.5455.126.camel@tortoise.toronto.redhat.com> <1139967958.18050.40.camel@erato.phig.org> Message-ID: <1139995369.4579.8.camel@localhost.localdomain> Hi Karsten, On Tue, 2006-02-14 at 17:45 -0800, Karsten Wade wrote: > Just a follow-up, thanks for the update. If there is anything that > Fedora Documentation Project folks can do to help ... and we'll be > testing Saxon and FOP as soon as the packages are in Extras, so you have > that help ... just let myself, Tommy Reynolds > , and/or fedora-docs-list. I believe in this case the problem is well understood. But if anybody that has some application that doesn't work (completely) on the free stack using gcj at this time attends Fosdem next week (February 25 and 26) in Brussels please stop by in the "GNU Classpath & Friends" room: http://www.fosdem.org/2006/index/dev_room_classpath/ http://developer.classpath.org/mediation/Fosdem2006 We have a "Show your App/Hack your App" session that would be a great time to sit down and get things integrated/fixed. Sometimes the gcj/classpath hackers don't know which programs/libraries are out there and/or how they fit together and sometimes the packagers/users don't know which compiler/library/runtimes tricks can be used to get things working. It also help us set priorities for things to work on. Knowing there are eager users to try out your stuff is always encouraging! :) Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From overholt at redhat.com Sun Feb 19 16:03:08 2006 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 19 Feb 2006 11:03:08 -0500 Subject: [fedora-java] Eclipse 3.2M5 and ant.java.version Message-ID: <20060219160308.GA7197@redhat.com> Hi, I attempted to build $subj yesterday but ran into a snag with their new 1.5 stuff in org.eclipse.jdt.apt (Annotation Processing Tools). We'll have to work with the Eclipse releng team to get some conditional compilation and inclusion of apt set up instead of the current "don't build if not using a 1.5 JDK". In the meantime, however, I found an issue with libcj and ant.java.version. ant.java.version is the property that the Eclipse uses to determine what JVM/JDK is being used. It is implemented like this [1]: Class.forName("java.lang.Readable"); javaVersion = JAVA_1_5; and if we look in libgcj: $ unzip -l /usr/share/java/libgcj-4.1.0.jar | grep java.lang.Readable 197 02-06-06 03:44 java/lang/Readable.class So with a simple test.xml [2], we get: [echo] java.version is 1.5 Is there a way we can get around this without patching ant or removing the 1.5 class library stuff from libgcj? Andrew [1] http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/util/JavaEnvUtils.java?view=markup (line 102) [2] From aph at redhat.com Sun Feb 19 16:14:59 2006 From: aph at redhat.com (Andrew Haley) Date: Sun, 19 Feb 2006 16:14:59 +0000 Subject: [fedora-java] Eclipse 3.2M5 and ant.java.version In-Reply-To: <20060219160308.GA7197@redhat.com> References: <20060219160308.GA7197@redhat.com> Message-ID: <17400.39299.963294.2616@zapata.pink> Andrew Overholt writes: > Hi, > > I attempted to build $subj yesterday but ran into a snag with their new 1.5 > stuff in org.eclipse.jdt.apt (Annotation Processing Tools). We'll have to > work with the Eclipse releng team to get some conditional compilation and > inclusion of apt set up instead of the current "don't build if not using a > 1.5 JDK". > > In the meantime, however, I found an issue with libcj and ant.java.version. > > ant.java.version is the property that the Eclipse uses to determine what > JVM/JDK is being used. It is implemented like this [1]: > > Class.forName("java.lang.Readable"); > javaVersion = JAVA_1_5; > > and if we look in libgcj: > > $ unzip -l /usr/share/java/libgcj-4.1.0.jar | grep java.lang.Readable > 197 02-06-06 03:44 java/lang/Readable.class > > So with a simple test.xml [2], we get: > > [echo] java.version is 1.5 > > Is there a way we can get around this without patching ant or removing the > 1.5 class library stuff from libgcj? Suggest we patch ant to use System.getProperty("java.version") and push that patch upstream. Andrew. From mailinglists at erwinrol.com Sun Feb 19 16:13:27 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 19 Feb 2006 17:13:27 +0100 Subject: [fedora-java] status on FOP, Saxon In-Reply-To: <1139995369.4579.8.camel@localhost.localdomain> References: <1139348842.16883.24.camel@erato.phig.org> <1139379790.5455.111.camel@tortoise.toronto.redhat.com> <1139441494.5455.126.camel@tortoise.toronto.redhat.com> <1139967958.18050.40.camel@erato.phig.org> <1139995369.4579.8.camel@localhost.localdomain> Message-ID: <1140365607.17385.362.camel@xpc.home.erwinrol.com> On Wed, 2006-02-15 at 10:22 +0100, Mark Wielaard wrote: > Hi Karsten, > > I believe in this case the problem is well understood. But if anybody > that has some application that doesn't work (completely) on the free > stack using gcj at this time attends Fosdem next week (February 25 and > 26) in Brussels please stop by in the "GNU Classpath & Friends" room: > http://www.fosdem.org/2006/index/dev_room_classpath/ > http://developer.classpath.org/mediation/Fosdem2006 > > We have a "Show your App/Hack your App" session that would be a great > time to sit down and get things integrated/fixed. Sometimes the > gcj/classpath hackers don't know which programs/libraries are out there > and/or how they fit together and sometimes the packagers/users don't > know which compiler/library/runtimes tricks can be used to get things > working. It also help us set priorities for things to work on. Knowing > there are eager users to try out your stuff is always encouraging! :) It is a shame i can't be there, because I am currently working on Open Xchange for GCJ, and that brings up some missing stuff in classpath, especially the Naming and Ldap support. I got a mega hack in place now, that uses parts of the latest classpath CVS, the apache directory CVS and some own code. If anybody in interested in it and wants to take a look, i can upload a SRPM later today. Keep in mind that Open Xchange isn't all that easy to setup (yer not done with installing the RPM, because LDAP and postgres also have to be instialized with data and access rights). - Erwin From aph at redhat.com Sun Feb 19 16:40:08 2006 From: aph at redhat.com (Andrew Haley) Date: Sun, 19 Feb 2006 16:40:08 +0000 Subject: [fedora-java] Eclipse 3.2M5 and ant.java.version In-Reply-To: <17400.39299.963294.2616@zapata.pink> References: <20060219160308.GA7197@redhat.com> <17400.39299.963294.2616@zapata.pink> Message-ID: <17400.40808.543508.166615@zapata.pink> We could just rip out java.lang.Readable from our sources for now since we don't use it anyway. But that way is a gcc/libgcj rebuild for no very good reason... Andrew. From mark at klomp.org Sun Feb 19 17:03:57 2006 From: mark at klomp.org (Mark Wielaard) Date: Sun, 19 Feb 2006 18:03:57 +0100 Subject: [fedora-java] Eclipse 3.2M5 and ant.java.version In-Reply-To: <20060219160308.GA7197@redhat.com> References: <20060219160308.GA7197@redhat.com> Message-ID: <1140368637.4791.28.camel@localhost.localdomain> Hi Andrew, On Sun, 2006-02-19 at 11:03 -0500, Andrew Overholt wrote: > In the meantime, however, I found an issue with libcj and ant.java.version. > > ant.java.version is the property that the Eclipse uses to determine what > JVM/JDK is being used. It is implemented like this [1]: > > Class.forName("java.lang.Readable"); > javaVersion = JAVA_1_5; Ugh, that is kind of a lame test. It is a feature test that is used to set a global version. sigh. If you need a global version checking System.getProperty("java.version") seems more appropriate. We have the Readable, Closeable, Flushable interfaces since they don't require any new 1.5 language or runtime features. If you would test like the above a much better marker class would be java.lang.Enum since that does need 1.5 language and runtime features being present. I would propose either pushing a version check based on System.getProperty("java.version"), or if upstream insists on class loading based checks to change Readable to Enum. > Is there a way we can get around this without patching ant or removing the > 1.5 class library stuff from libgcj? There might be an evil hack possible if you can force loading the ant JavaEnvUtil class with a custom ClassLoader that overrides loadClass() to explicitly disallow loading java.lang.Readable. That is extremely ugly though and depends on finding the correct point in your application that loads this specific ant task. It seems ant.java.version is set way too early for such a hack to work easily though. Does your application really need the ${ant.java.version}? Can't it use ${java.version}? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gbenson at redhat.com Mon Feb 20 09:00:05 2006 From: gbenson at redhat.com (Gary Benson) Date: Mon, 20 Feb 2006 09:00:05 +0000 Subject: [fedora-java] Eclipse 3.2M5 and ant.java.version In-Reply-To: <17400.39299.963294.2616@zapata.pink> References: <20060219160308.GA7197@redhat.com> <17400.39299.963294.2616@zapata.pink> Message-ID: <20060220090004.GA5477@redhat.com> Andrew Haley wrote: > Andrew Overholt writes: > > So with a simple test.xml [2], we get: > > > > [echo] java.version is 1.5 > > > > Is there a way we can get around this without patching ant or > > removing the 1.5 class library stuff from libgcj? > > Suggest we patch ant to use System.getProperty("java.version") > and push that patch upstream. Presumably there's a reason they don't already do this. Cheers, Gary From aph at redhat.com Mon Feb 20 10:01:30 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 Feb 2006 10:01:30 +0000 Subject: [fedora-java] Eclipse 3.2M5 and ant.java.version In-Reply-To: <20060220090004.GA5477@redhat.com> References: <20060219160308.GA7197@redhat.com> <17400.39299.963294.2616@zapata.pink> <20060220090004.GA5477@redhat.com> Message-ID: <17401.37754.31348.171119@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Andrew Overholt writes: > > > So with a simple test.xml [2], we get: > > > > > > [echo] java.version is 1.5 > > > > > > Is there a way we can get around this without patching ant or > > > removing the 1.5 class library stuff from libgcj? > > > > Suggest we patch ant to use System.getProperty("java.version") > > and push that patch upstream. > > Presumably there's a reason they don't already do this. I looked at the history of that file, and they have never done this. There's no explanation as to why. Andrew. From gbenson at redhat.com Mon Feb 20 10:33:04 2006 From: gbenson at redhat.com (Gary Benson) Date: Mon, 20 Feb 2006 10:33:04 +0000 Subject: [fedora-java] Eclipse 3.2M5 and ant.java.version In-Reply-To: <17401.37754.31348.171119@zapata.pink> References: <20060219160308.GA7197@redhat.com> <17400.39299.963294.2616@zapata.pink> <20060220090004.GA5477@redhat.com> <17401.37754.31348.171119@zapata.pink> Message-ID: <20060220103304.GC5477@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Andrew Haley wrote: > > > Andrew Overholt writes: > > > > So with a simple test.xml [2], we get: > > > > > > > > [echo] java.version is 1.5 > > > > > > > > Is there a way we can get around this without patching ant > > > > or removing the 1.5 class library stuff from libgcj? > > > > > > Suggest we patch ant to use System.getProperty("java.version") > > > and push that patch upstream. > > > > Presumably there's a reason they don't already do this. > > I looked at the history of that file, and they have never done this. > There's no explanation as to why. The version detection was moved from org.apache.tools.ant.Project, where it has been since the initial CVS import over six years ago. I guess the reason for it is lost in the mists of time... Cheers, Gary From overholt at redhat.com Mon Feb 20 16:16:39 2006 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 20 Feb 2006 11:16:39 -0500 Subject: [fedora-java] Eclipse 3.2M5 and ant.java.version In-Reply-To: <1140368637.4791.28.camel@localhost.localdomain> References: <20060219160308.GA7197@redhat.com> <1140368637.4791.28.camel@localhost.localdomain> Message-ID: <20060220161639.GA20304@redhat.com> Hi Mark, * Mark Wielaard [2006-02-19 12:04]: > > Does your application really need the ${ant.java.version}? > Can't it use ${java.version}? I've suggested using ${java.version} to the Eclipse releng team. We will see what happens. Use ${java.version} instead of ${ant.java.version}: https://bugs.eclipse.org/bugs/show_bug.cgi?id=128671 Make APT dependent upon JDK/JVM version: https://bugs.eclipse.org/bugs/show_bug.cgi?id=128673 Andrew From fitzsim at redhat.com Wed Feb 22 05:45:59 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 22 Feb 2006 00:45:59 -0500 Subject: [fedora-java] freeing FOP Message-ID: <1140587159.1404.190.camel@tortoise.toronto.redhat.com> Hi, I finished building FOP and its dependencies on the free Java stack. To pare the dependency tree I built Batik without Rhino support. If such a feature-limited Batik is acceptable in Fedora Extras then we'll only need to add about five new packages, rather than the ~80 packages we'd need for a Rhino-enabled Batik. Batik 1.6 also has dependencies on com.sun classes in its JPEG- and TIFF-encoding code. These dependencies have been removed in Batik CVS but for now I've disabled JPEG- and TIFF- output in my test RPM. Unfortunately, FOP has two non-free dependencies, neither of which has a free drop-in replacement. These are Jimi and JAI, both image-handling frameworks. From the FOP error output it seems that JAI is the preferred framework with Jimi providing a fallback. It may be possible to provide a second fallback that uses the standard ImageIO framework which is implemented in the free stack, but that will require upstream changes. For now free FOP cannot handle images. To test my FOP RPM I ran build-hig-pdf.sh from the GNOME Human Interface Guidelines CVS repository. I've attached a log of the console output and the generated PDF. A GCJ bug is preventing the compilation of FOP's hyphenation patterns which explains why FOP can't find them. I'll file a bug for this shortly. Perhaps the documentation team can review the attached PDF? Shall I go ahead and propose FOP and its dependencies for Fedora Extras inclusion, even though it currently lacks image support? I'm wondering if that would be a good way for the docs team to track my progress and offer feedback. Obviously until the image support issues are resolved the packages will have to be considered preview-quality. Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: fop-hig-output.log.gz Type: application/x-gzip Size: 8140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hig.pdf.gz Type: application/x-gzip Size: 295953 bytes Desc: not available URL: From kwade at redhat.com Thu Feb 23 22:38:32 2006 From: kwade at redhat.com (Karsten Wade) Date: Thu, 23 Feb 2006 14:38:32 -0800 Subject: [fedora-java] Re: freeing FOP In-Reply-To: <1140587159.1404.190.camel@tortoise.toronto.redhat.com> References: <1140587159.1404.190.camel@tortoise.toronto.redhat.com> Message-ID: <1140734312.8018.113.camel@erato.phig.org> On Wed, 2006-02-22 at 00:45 -0500, Thomas Fitzsimmons wrote: > Hi, > > I finished building FOP and its dependencies on the free Java stack. To > pare the dependency tree I built Batik without Rhino support. If such a > feature-limited Batik is acceptable in Fedora Extras then we'll only > need to add about five new packages, rather than the ~80 packages we'd > need for a Rhino-enabled Batik. Rhino is the Mozilla JavaScript interpreter, right? We don't have any need for that I know of. When someone else with such a need packages Rhino for Extras, I suppose we can add support back in. Tommy informed me that our main usage of Batik is for batik-rasterizer for SVG files. If batik-rasterizer works without Rhino, we're fine. > Batik 1.6 also has dependencies on com.sun classes in its JPEG- and > TIFF-encoding code. These dependencies have been removed in Batik CVS > but for now I've disabled JPEG- and TIFF- output in my test RPM. > > Unfortunately, FOP has two non-free dependencies, neither of which has a > free drop-in replacement. These are Jimi and JAI, both image-handling > frameworks. From the FOP error output it seems that JAI is the > preferred framework with Jimi providing a fallback. It may be possible > to provide a second fallback that uses the standard ImageIO framework > which is implemented in the free stack, but that will require upstream > changes. For now free FOP cannot handle images. Our images need is only for PNG support. That lets us output to screen and printed formats. Does it just strip out/ignore image calls in the FO? > To test my FOP RPM I ran build-hig-pdf.sh from the GNOME Human Interface > Guidelines CVS repository. I've attached a log of the console output > and the generated PDF. A GCJ bug is preventing the compilation of FOP's > hyphenation patterns which explains why FOP can't find them. I'll file > a bug for this shortly. > > Perhaps the documentation team can review the attached PDF? Shall I go > ahead and propose FOP and its dependencies for Fedora Extras inclusion, > even though it currently lacks image support? I'm wondering if that > would be a good way for the docs team to track my progress and offer > feedback. Obviously until the image support issues are resolved the > packages will have to be considered preview-quality. The attached PDF looks stellar, from a visual/format stand point. I didn't see any visual bugs in my comb through, and it was nice to see things such as URLs finally formatted well, such as, this is the link text [URI]. We can't really use it in production without image support, but I'm sure some of us would like to see how it handles our most difficult XML to PDF conversions. Thanks so much for working on this. Let us know how the packaging progresses, and I'll roust up a few folks who have been complaining about PDF output and give this to test with. :) - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- 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 silfreed-fedoralist at silfreed.net Sat Feb 25 04:45:34 2006 From: silfreed-fedoralist at silfreed.net (Douglas E. Warner) Date: Fri, 24 Feb 2006 23:45:34 -0500 Subject: [fedora-java] PHPEclipse, Subclipse, and Webtools plugins for Eclipse Message-ID: <200602242345.40337.silfreed-fedoralist@silfreed.net> I've recently just discovered the Eclipse IDE, and so far have been very impressed with it. I've been using the PHPEclipse and Subclipse plugins just by unzipping the plugins into my /usr/share/eclipse/plugins directory, but I know that these are just the jar files and aren't natively compiled like Eclipse is. I'm interested in helping getting these compiled, but unfortunately it's been very difficult for me to find information on how to compile plugins by hand for Eclipse. If anyone can provide any pointers or information, I'd be very appreciative. http://phpeclipse.de/ http://subclipse.tigris.org/ http://www.eclipse.org/webtools/ -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From overholt at redhat.com Sat Feb 25 15:54:13 2006 From: overholt at redhat.com (Andrew Overholt) Date: Sat, 25 Feb 2006 10:54:13 -0500 Subject: [fedora-java] PHPEclipse, Subclipse, and Webtools plugins for Eclipse In-Reply-To: <200602242345.40337.silfreed-fedoralist@silfreed.net> References: <200602242345.40337.silfreed-fedoralist@silfreed.net> Message-ID: <20060225155413.GA521@redhat.com> Hi Doug, * Douglas E. Warner [2006-02-24 23:46]: > I've recently just discovered the Eclipse IDE, and so far have been very > impressed with it. I'm glad. > I've been using the PHPEclipse and Subclipse plugins just > by unzipping the plugins into my /usr/share/eclipse/plugins directory, You can also install them without root access by using the Eclipse update manager. They will then be installed into ~/.eclipse but will obviously only be available to the user who performed the installed. > I'm interested in helping getting these compiled, but unfortunately it's been > very difficult for me to find information on how to compile plugins by hand > for Eclipse. Packaging plugins is the larger issue IMO. It's difficult to find a consisten way of getting the source and building it. Ben Konrath has been working hard on this and has a few potential solutions. I'll let him respond when he gets a chance. As for natively-compiling the bytecode, it's probably best if you can use aot-compile-rpm. I know this is designed for use with RPMs, but if you can examine the script and see what it does, it'll be closest to how things are done at RPM build time. If you can't figure out what to do, come back and we can give detailed instructions. Once we get things sorted out, it'd be awesome if you wanted to package some of these plugins for Fedora Extras :) Andrew From silfreed-fedoralist at silfreed.net Sat Feb 25 20:30:53 2006 From: silfreed-fedoralist at silfreed.net (Douglas E. Warner) Date: Sat, 25 Feb 2006 15:30:53 -0500 Subject: [fedora-java] PHPEclipse, Subclipse, and Webtools plugins for Eclipse In-Reply-To: <20060225155413.GA521@redhat.com> References: <200602242345.40337.silfreed-fedoralist@silfreed.net> <20060225155413.GA521@redhat.com> Message-ID: <200602251530.59062.silfreed-fedoralist@silfreed.net> On Saturday 25 February 2006 10:54, Andrew Overholt wrote: > You can also install them without root access by using the Eclipse update > manager. ?They will then be installed into ~/.eclipse but will obviously > only be available to the user who performed the installed. That's good to know - thanks! > Packaging plugins is the larger issue IMO. ?It's difficult to find a > consisten way of getting the source and building it. ?Ben Konrath has been > working hard on this and has a few potential solutions. ?I'll let him > respond when he gets a chance. > > As for natively-compiling the bytecode, it's probably best if you can use > aot-compile-rpm. ?I know this is designed for use with RPMs, but if you can > examine the script and see what it does, it'll be closest to how things are > done at RPM build time. ?If you can't figure out what to do, come back and > we can give detailed instructions. > > Once we get things sorted out, it'd be awesome if you wanted to package > some of these plugins for Fedora Extras :) When reading the archives I did come across some threads mentioning the difficulty of packaging plugins and new scripts to ease the pain, but the level of detail was way over my head for a language I'm not too familiar with (yet). I'm definitely looking towards building RPMs one I figure out how to get the stuff compiled natively - but I figured I needed to take it one step at a time. Thanks for your help! -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From gcarr at lanl.gov Tue Feb 28 21:52:48 2006 From: gcarr at lanl.gov (Gary P Carr) Date: Tue, 28 Feb 2006 14:52:48 -0700 Subject: [fedora-java] Strange Java problems on multiheaded workstations Message-ID: <6.2.5.6.2.20060228145150.02aeef90@lanl.gov> We are running Sun java 1.4.2_08 on RHEL 4 workstation. We recently configured a workstation with six heads as three virtual screens (0.0, 0.1, 0.2) using twinview. The workstation is a Dell with a dual port NVIDIA Quadro FX1400, and a quad port NVIDIA Quadro4 200/400 NVS. All the normal X programs we run behave as expected. They open their displays on the screen specified by the DISPLAY variable, either :0.0, :0.1, or :0.2. The java programs all open their displays on :0.0, no matter what the DISPLAY variable is set to. If DISPLAY=:0.1, or DISPLAY=:0.2, java opens it's window on :0.0. Even stranger, we have a java menu program , call it treepm, that runs other programs. If we run treepm from :0.1, it opens its display on :0.0. But, any normal Xwindow program run from the treepm menu display will open on :0.1. When we had this system configured as a single virtual :0.0 display using twinview and Xinerama, everything worked fine. But, of course, the only display was :0.0. Has anyone seen this problem before, or anything like it?