From overholt at redhat.com Fri Dec 1 18:45:46 2006 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 1 Dec 2006 13:45:46 -0500 Subject: [fedora-java] Patch: Automake Editor (just Makefile editor for now) Message-ID: <20061201184544.GA10747@redhat.com> Hi Jeff, Attached is a patch to add an automake editor extension to the autotools plugin. It is just a re-use of the CDT's existing Makefile editor for now, but it at least gives us syntax highlighting :) Okay to commit? Thanks, Andrew 2006-12-01 Andrew Overholt * src/com/redhat/eclipse/cdt/autotools/editors/automake: New directory. * src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java: New file. Simple extension of MakefileEditor for now. * plugin.xml: Add automake editor. -------------- next part -------------- ### Eclipse Workspace Patch 1.0 #P com.redhat.eclipse.cdt.autotools Index: plugin.xml =================================================================== RCS file: /cvs/eclipse/autotools/com.redhat.eclipse.cdt.autotools/plugin.xml,v retrieving revision 1.20 diff -u -r1.20 plugin.xml --- plugin.xml 29 Nov 2006 23:01:34 -0000 1.20 +++ plugin.xml 1 Dec 2006 18:42:11 -0000 @@ -658,6 +658,19 @@ id="com.redhat.eclipse.cdt.autotools.editor.autoconf" name="%Autoconf.editor.name"/> + + + + + - + + + + + + + Index: src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java =================================================================== RCS file: src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java diff -N src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java 1 Jan 1970 00:00:00 -0000 @@ -0,0 +1,7 @@ +package com.redhat.eclipse.cdt.autotools.editors.automake; + +import org.eclipse.cdt.make.internal.ui.editor.MakefileEditor; + +public class AutomakeEditor extends MakefileEditor { + +} -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjohnstn at redhat.com Fri Dec 1 19:22:30 2006 From: jjohnstn at redhat.com (Jeff Johnston) Date: Fri, 01 Dec 2006 14:22:30 -0500 Subject: [fedora-java] Re: Patch: Automake Editor (just Makefile editor for now) In-Reply-To: <20061201184544.GA10747@redhat.com> References: <20061201184544.GA10747@redhat.com> Message-ID: <457080F6.6040505@redhat.com> Ok. -- Jeff J. Andrew Overholt wrote: > Hi Jeff, > > Attached is a patch to add an automake editor extension to the autotools > plugin. It is just a re-use of the CDT's existing Makefile editor for > now, but it at least gives us syntax highlighting :) > > Okay to commit? > > Thanks, > > Andrew > > 2006-12-01 Andrew Overholt > > * src/com/redhat/eclipse/cdt/autotools/editors/automake: New directory. > * src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java: > New file. Simple extension of MakefileEditor for now. > * plugin.xml: Add automake editor. > > > ------------------------------------------------------------------------ > > ### Eclipse Workspace Patch 1.0 > #P com.redhat.eclipse.cdt.autotools > Index: plugin.xml > =================================================================== > RCS file: /cvs/eclipse/autotools/com.redhat.eclipse.cdt.autotools/plugin.xml,v > retrieving revision 1.20 > diff -u -r1.20 plugin.xml > --- plugin.xml 29 Nov 2006 23:01:34 -0000 1.20 > +++ plugin.xml 1 Dec 2006 18:42:11 -0000 > @@ -658,6 +658,19 @@ > id="com.redhat.eclipse.cdt.autotools.editor.autoconf" > name="%Autoconf.editor.name"/> > > + + id="org.eclipse.cdt.make.editor" > + name="MakefileEditor" > + point="org.eclipse.ui.editors"> > + + name="AutomakeEditor" > + icon="icons/sample.gif" > + contributorClass="org.eclipse.cdt.make.internal.ui.editor.MakefileEditorActionContributor" > + class="com.redhat.eclipse.cdt.autotools.editors.automake.AutomakeEditor" > + id="com.redhat.eclipse.cdt.autotools.editors.AutomakeEditor"> > + > + > + > point="org.eclipse.ui.contexts"> > @@ -686,5 +699,16 @@ > id="com.redhat.eclipse.cdt.autotools.ui.editors.text.show.tooltip" > name="%ShowTooltip.name"/> > > - > + > + > + + base-type="org.eclipse.core.runtime.text" > + priority="high"/> > + > + > + + content-type="com.redhat.eclipse.cdt.autotools.automake" > + file-names="Makefile.am" > + file-extensions="am"/> > + > > Index: src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java > =================================================================== > RCS file: src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java > diff -N src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ src/com/redhat/eclipse/cdt/autotools/editors/automake/AutomakeEditor.java 1 Jan 1970 00:00:00 -0000 > @@ -0,0 +1,7 @@ > +package com.redhat.eclipse.cdt.autotools.editors.automake; > + > +import org.eclipse.cdt.make.internal.ui.editor.MakefileEditor; > + > +public class AutomakeEditor extends MakefileEditor { > + > +} From bkonrath at redhat.com Mon Dec 4 03:06:41 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Sun, 03 Dec 2006 22:06:41 -0500 Subject: [fedora-java] Eclipse on Linux Distributions eclipse.org project approved In-Reply-To: <20061130222000.GM16792@redhat.com> References: <20061130222000.GM16792@redhat.com> Message-ID: <1165201601.4988.6.camel@plug> Hi Andrew, On Thu, 2006-11-30 at 17:20 -0500, Andrew Overholt wrote: > Last week, the project had its Creation Review [2] and it was a success! I just wanted to say thanks for all your hard work in bringing this project through the creation review. Cheers, Ben From fernando at lozano.eti.br Mon Dec 4 18:44:17 2006 From: fernando at lozano.eti.br (Fernando Lozano) Date: Mon, 04 Dec 2006 16:44:17 -0200 Subject: [fedora-java] Let's go to JavaOne! Message-ID: <45746C81.5020205@lozano.eti.br> First of all, I'm sorry for the cross-post, but I hope you'll find this message useful. While we all are extasiated with Sun GPLed JDK releases, I'm afraid many are missing the fact JavaOne call for papers was already opened and the deadline for submissions is at *December, 15*. We never had a better climate for presentations related to free software Java projects and it would be wonderful to have everyone there: Classpath, GCJ, Kaffe, Java-Gnome, JPackage, IKVM, Cacao, Sable, ... You may be wondering: ?What will I do at the big Sun tradeshow as a open source hacker?? There you'll find a great pool of potential users and contributors, most of all already oldtime users of free software like Ant, Maven, Eclipse, Tomcat or JBoss. But few of them who actually realized all free software can do for them. Most of them will still be puzzled by Sun OpenJDK announcement. The general Linux and free software community, and the general Java community, share many of the same goals and also share many ideas on how to get there. But most of the time they don't talk to each other. There a lot of misunderstadings from each other but I believe both have much to learn from the other. Java developers are yet too much corporate-driven and they need our help on how to become community-driven. Of course, many of you earn you living as open source consultants, techinical writers, or selling other IT services. The event would be a big showroom for potential customers. :-) I was there twice as a speaker, and offer my help to anyone wishing to submit proposals. And even if your proposal isn't selected, or you afraid to speak in a room that may have more than a thousand people, I may get you a place at the Java.Net community corner. If you do sumbit a talk and it is accepted, please mail me so I can see you and announce it in java.net. []s, Fernando Lozano From fernando at lozano.eti.br Mon Dec 4 18:46:43 2006 From: fernando at lozano.eti.br (Fernando Lozano) Date: Mon, 04 Dec 2006 16:46:43 -0200 Subject: [fedora-java] Re: Let's go to JavaOne! In-Reply-To: <45746C81.5020205@lozano.eti.br> References: <45746C81.5020205@lozano.eti.br> Message-ID: <45746D13.4080903@lozano.eti.br> Hi there, Forgot a very important information: the URL for submitting proposals: https://www28.cplan.com/cfp_prod/CFPLogin.jsp?wId=58LE17 []s, Fernando Lozano > First of all, I'm sorry for the cross-post, but I hope you'll find > this message useful. > > While we all are extasiated with Sun GPLed JDK releases, I'm afraid > many are missing the fact JavaOne call for papers was already opened > and the deadline for submissions is at *December, 15*. We never had a > better climate for presentations related to free software Java > projects and it would be wonderful to have everyone there: Classpath, > GCJ, Kaffe, Java-Gnome, JPackage, IKVM, Cacao, Sable, ... From bkonrath at redhat.com Tue Dec 5 00:47:14 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Mon, 04 Dec 2006 19:47:14 -0500 Subject: [fedora-java] wiki page for Fedora Eclipse packaging tasks Message-ID: <1165279634.12493.39.camel@plug> Hi, I just created a wiki page for packaging tasks that need to be done for the Eclipse Linux Project: http://wiki.eclipse.org/index.php/Linux_Packaging_Tasks There is a section for Fedora Eclipse and for common tasks. Any help with with these tasks would be appreciated, just add a note to let everyone know what task you plan on doing. Also, feel free to add tasks / ideas as you see fit. To edit the wiki page, just use your eclipse.org bugzilla account. Thanks, Ben From nicolas.mailhot at laposte.net Tue Dec 5 21:57:13 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 05 Dec 2006 22:57:13 +0100 Subject: [fedora-java] src.zip's and rpms in Eclipse In-Reply-To: <1164918343.3330.128.camel@plug> References: <456CDAE1.10006@redhat.com> <1164817735.2943.47.camel@to-dhcp1.toronto.redhat.com> <1164818423.30106.9.camel@toxic.toronto.redhat.com> <1164918343.3330.128.camel@plug> Message-ID: <1165355834.22822.4.camel@rousalka.dyndns.org> Le jeudi 30 novembre 2006 ? 15:25 -0500, Ben Konrath a ?crit : > Yeah, that a good idea and I've wanted this for a while. I was thinking > of checking a known location, for example if you add > package-version.jar, it would auto-attach package-version-src.zip. This > seems to be a convention that eclipse uses. But using a manifest file > tag would be more robust. Manifest is not robust WRT file moves. It's redundant when everyone follows the same conventions, and a PITA to track/change when you don't. Much better to specify rigid file location & naming conventions, with optional override of the root dir via an env var -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bkonrath at redhat.com Wed Dec 6 04:18:00 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 05 Dec 2006 23:18:00 -0500 Subject: [fedora-java] src.zip's and rpms in Eclipse In-Reply-To: <1165355834.22822.4.camel@rousalka.dyndns.org> References: <456CDAE1.10006@redhat.com> <1164817735.2943.47.camel@to-dhcp1.toronto.redhat.com> <1164818423.30106.9.camel@toxic.toronto.redhat.com> <1164918343.3330.128.camel@plug> <1165355834.22822.4.camel@rousalka.dyndns.org> Message-ID: <1165378680.3004.69.camel@plug> On Tue, 2006-12-05 at 22:57 +0100, Nicolas Mailhot wrote: > Le jeudi 30 novembre 2006 ? 15:25 -0500, Ben Konrath a ?crit : > > > Yeah, that a good idea and I've wanted this for a while. I was thinking > > of checking a known location, for example if you add > > package-version.jar, it would auto-attach package-version-src.zip. This > > seems to be a convention that eclipse uses. But using a manifest file > > tag would be more robust. > > Manifest is not robust WRT file moves. It's redundant when everyone > follows the same conventions, and a PITA to track/change when you don't. I was thinking of somehow specifying the absolute path to the source zip in the manifest. If the source zip is packaged by the same srpm as jar, then the location should be known and users shouldn't be just randomly moving files around. But I agree that it would be a bit of a pain to modify every java RPM to add a path its manifest specifying the location of the source zip. > Much better to specify rigid file location & naming conventions, with > optional override of the root dir via an env var Seems reasonable. Eclipse tends to use the naming convention I mentioned in my initial response (above) so this is what I've been using. As an example, the libgtk-java packages has these files in /usr/share/java/: gtk2.8-2.8.7.jar gtk2.8.jar -> gtk2.8-2.8.7.jar gtk2.8-src-2.8.7.zip gtk2.8-src.zip -> gtk2.8-src-2.8.7.zip I think we should keep this naming convention and have eclipse automatically attach a source zips with the correct name (-src.{zip,jar}) if they are in the same directory as the external jar. If ECLIPSE_JDT_JAR_SRC_ZIP_DIR is set, Eclipse could try to load a zip/jar of the same name from the directory specified by this env variable. What do you think? Ben From klaasjan at gmail.com Wed Dec 6 10:54:23 2006 From: klaasjan at gmail.com (Klaasjan Brand) Date: Wed, 6 Dec 2006 11:54:23 +0100 Subject: [fedora-java] Eclipse broken on Fedora 6? Message-ID: <8bb8e9360612060254i621e8c37jb45ac97464c3028@mail.gmail.com> Hi, I've just found out Eclipse hangs on Fedora 6 when triggering the native GTK file open dialog (when using "open file" or browsing directories). Happens on GCJ or Sun JDK 1.5 with both Fedora Eclipse and eclipse.org versions. Anyone familiar with this problem? Suggestions where it should be reported? thanks, Klaasjan Brand -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens at limasoftware.net Wed Dec 6 11:02:23 2006 From: neugens at limasoftware.net (Mario Torre) Date: Wed, 06 Dec 2006 12:02:23 +0100 Subject: [fedora-java] Eclipse broken on Fedora 6? In-Reply-To: <8bb8e9360612060254i621e8c37jb45ac97464c3028@mail.gmail.com> References: <8bb8e9360612060254i621e8c37jb45ac97464c3028@mail.gmail.com> Message-ID: <1165402943.3088.6.camel@nirvana.limasoftware.net> Il giorno mer, 06/12/2006 alle 11.54 +0100, Klaasjan Brand ha scritto: > Hi, > > I've just found out Eclipse hangs on Fedora 6 when triggering the > native GTK file open dialog (when using "open file" or browsing > directories). Happens on GCJ or Sun JDK 1.5 with both Fedora Eclipse > and eclipse.org versions. > Anyone familiar with this problem? Suggestions where it should be > reported? > > thanks, > Klaasjan Brand Hi! I have the same and filed a bug report for Eclipse, just to discover that this is related to SeLinux and DBus. A fix is under development. See bug #217843 for this. Hope that helps, Mario -- Lima Software, SO.PR.IND. s.r.l. http://www.limasoftware.net/ pgp key: http://subkeys.pgp.net/ Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From caolanm at redhat.com Wed Dec 6 11:04:11 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 06 Dec 2006 11:04:11 +0000 Subject: [fedora-java] Eclipse broken on Fedora 6? In-Reply-To: <8bb8e9360612060254i621e8c37jb45ac97464c3028@mail.gmail.com> References: <8bb8e9360612060254i621e8c37jb45ac97464c3028@mail.gmail.com> Message-ID: <1165403052.23176.5.camel@soulcrusher.caolan.org> On Wed, 2006-12-06 at 11:54 +0100, Klaasjan Brand wrote: > Hi, > > I've just found out Eclipse hangs on Fedora 6 when triggering the > native GTK file open dialog (when using "open file" or browsing > directories). Happens on GCJ or Sun JDK 1.5 with both Fedora Eclipse > and eclipse.org versions. > Anyone familiar with this problem? Suggestions where it should be > reported? Might be attempting to run the gtk file dialog from a thread, that dialog appears to only work reliably when run from gtk's "main thread". I do a bit of a dance in openoffice.org to spawn the dialog off in a gtk idle handler to get it run in the gtk main thread and wait for it to return in the original thread. C. From overholt at redhat.com Wed Dec 6 13:57:19 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 6 Dec 2006 08:57:19 -0500 Subject: [fedora-java] Eclipse broken on Fedora 6? In-Reply-To: <8bb8e9360612060254i621e8c37jb45ac97464c3028@mail.gmail.com> References: <8bb8e9360612060254i621e8c37jb45ac97464c3028@mail.gmail.com> Message-ID: <20061206135718.GA27783@redhat.com> Hi, * Klaasjan Brand [2006-12-06 05:54]: > > I've just found out Eclipse hangs on Fedora 6 when triggering the native GTK > file open dialog [...] > Anyone familiar with this problem? Suggestions where it should be reported? Yeah, as Mario said, I think you're hitting bug #217843. In general, always report things in Red Hat bugzilla. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Fri Dec 8 22:47:19 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 8 Dec 2006 22:47:19 +0000 (UTC) Subject: [fedora-java] Does anyone have working JacORB packages for FC6? Message-ID: Does anyone on this list have working JacORB packages for FC6 (using the Free Java stack, i.e. GCJ etc.)? I'm interested in JacORB because a class I'm taking at the university uses it. I tried building a package by: * reconstructing the no longer available jacorb-2.2-3jpp_8fc: - I started from jacorb-2.2-3.1mdk, which is essentially jacorb-2.2-3jpp_3fc - I removed the stuff apparently added by Mandriva (changelog entry, conditionalization of GCJ support) - I applied all the patches from the fedora-cvs-commits list leading up to 8fc - I fixed the whitespace in the GCJ 4.1 patch so it actually applies, because the mailing list software mangled the tabs in the patch to spaces * bumping the release, ending up with this: http://www.tigen.org/kevin.kofler/pcprogs/jacorb-2.2-3jpp.9.fc6.nosrc.rpm (This is an 8 KB nosrc RPM, I didn't include the source tarball for space reasons.) Unfortunately, this _does not build_ under FC6. Judging from the error output, it tries to use the wrong org.omg.CORBA classes (the libgcj ones), and I can't seem to fix that. I verified that the gcj41 patch is applied, I tried setting both classpath and bootclasspath, and also adding this: None of that works. So help from the experts would be appreciated. Kevin Kofler From tromey at redhat.com Fri Dec 8 23:04:51 2006 From: tromey at redhat.com (Tom Tromey) Date: 08 Dec 2006 16:04:51 -0700 Subject: [fedora-java] Does anyone have working JacORB packages for FC6? In-Reply-To: References: Message-ID: >>>>> "Kevin" == Kevin Kofler writes: Kevin> Does anyone on this list have working JacORB packages for FC6 Kevin> (using the Free Java stack, i.e. GCJ etc.)? Not me.. Kevin> Unfortunately, this _does not build_ under FC6. Judging from Kevin> the error output, it tries to use the wrong org.omg.CORBA Kevin> classes (the libgcj ones), and I can't seem to fix that. Could you post the error output? Perhaps with 'ant -verbose' so we can see the compiler command line? Overriding the libgcj classes at compile time ought to work ok. Tom From kevin.kofler at chello.at Sat Dec 9 00:12:55 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 9 Dec 2006 00:12:55 +0000 (UTC) Subject: [fedora-java] Re: Does anyone have working JacORB packages for FC6? References: Message-ID: Tom Tromey writes: > Kevin> Unfortunately, this _does not build_ under FC6. Judging from > Kevin> the error output, it tries to use the wrong org.omg.CORBA > Kevin> classes (the libgcj ones), and I can't seem to fix that. > > Could you post the error output? Perhaps with 'ant -verbose' so we > can see the compiler command line? Overriding the libgcj classes at > compile time ought to work ok. [javac] Compiling 6 source files to /usr/src/redhat/BUILD/JacORB_2_2/classes [javac] Using modern compiler [javac] Compilation arguments: [javac] '-d' [javac] '/usr/src/redhat/BUILD/JacORB_2_2/classes' [javac] '-classpath' [javac] '/usr/src/redhat/BUILD/JacORB_2_2/classes:/usr/share/java/ant.jar:/usr/share/ java/ant-launcher.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java/xml- commons-apis.jar:/usr/share/java/antlr.jar:/usr/share/java/ant/ant-antlr.jar:/ usr/share/java/bcel.jar:/usr/share/java/ant/ant-apache-bcel.jar:/usr/share/java/ log4j.jar:/usr/share/java/ant/ant-apache-log4j.jar:/usr/share/java/oro.jar:/usr/ share/java/ant/ant-apache-oro.jar:/usr/share/java/regexp.jar:/usr/share/java/ant /ant-apache-regexp.jar:/usr/share/java/xml-commons-resolver.jar:/usr/share/java/ ant/ant-apache-resolver.jar:/usr/share/java/jakarta-commons-logging.jar:/usr/ share/java/ant/ant-commons-logging.jar:/usr/share/java/javamail.jar:/usr/share/ java/jaf.jar:/usr/share/java/ant/ant-javamail.jar:/usr/share/java/jdepend.jar:/ usr/share/java/ant/ant-jdepend.jar:/usr/share/java/jsch.jar:/usr/share/java/ant/ ant-jsch.jar:/usr/share/java/junit.jar:/usr/share/java/ant/ant-junit.jar:/usr/ share/java/ant/ant-nodeps.jar:/usr/share/java/ant/ant-swing.jar:/usr/share/java/ jaxp_transform_impl.jar:/usr/share/java/ant/ant-trax.jar:/usr/lib/jvm/java/lib/ tools.jar:/usr/share/java/concurrent.jar:/usr/share/java/tanukiwrapper.jar:/usr/ share/java/avalon-framework.jar:/usr/share/java/avalon-logkit.jar' [javac] '-sourcepath' [javac] '/usr/src/redhat/BUILD/JacORB_2_2/src:/usr/src/redhat/BUILD/JacORB_2_2/src/ generated' [javac] '-bootclasspath' [javac] '/usr/src/redhat/BUILD/JacORB_2_2/classes:/usr/src/redhat/BUILD/JacORB_2_2/lib/ logkit-1.2.jar:/usr/src/redhat/BUILD/JacORB_2_2/lib/idl.jar:/usr/src/redhat/ BUILD/JacORB_2_2/lib/antlr-2.7.2.jar:/usr/src/redhat/BUILD/JacORB_2_2/lib/avalon -framework-4.1.5.jar:/usr/src/redhat/BUILD/JacORB_2_2/lib/concurrent-1.3.2.jar:/ usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/rt.jar:/usr/share/java/ant.jar:/usr/ share/java/ant-launcher.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java /xml-commons-apis.jar:/usr/share/java/antlr.jar:/usr/share/java/ant/ant-antlr. jar:/usr/share/java/bcel.jar:/usr/share/java/ant/ant-apache-bcel.jar:/usr/share/ java/log4j.jar:/usr/share/java/ant/ant-apache-log4j.jar:/usr/share/java/oro.jar: /usr/share/java/ant/ant-apache-oro.jar:/usr/share/java/regexp.jar:/usr/share/ java/ant/ant-apache-regexp.jar:/usr/share/java/xml-commons-resolver.jar:/usr/ share/java/ant/ant-apache-resolver.jar:/usr/share/java/jakarta-commons-logging. jar:/usr/share/java/ant/ant-commons-logging.jar:/usr/share/java/javamail.jar:/ usr/share/java/jaf.jar:/usr/share/java/ant/ant-javamail.jar:/usr/share/java/ jdepend.jar:/usr/share/java/ant/ant-jdepend.jar:/usr/share/java/jsch.jar:/usr/ share/java/ant/ant-jsch.jar:/usr/share/java/junit.jar:/usr/share/java/ant/ant- junit.jar:/usr/share/java/ant/ant-nodeps.jar:/usr/share/java/ant/ant-swing.jar:/ usr/share/java/jaxp_transform_impl.jar:/usr/share/java/ant/ant-trax.jar:/usr/lib /jvm/java/lib/tools.jar:/usr/share/java/concurrent.jar:/usr/share/java/ tanukiwrapper.jar:/usr/share/java/avalon-framework.jar:/usr/share/java/avalon- logkit.jar' [javac] '-g:none' [javac] [javac] The ' characters around the executable and arguments are [javac] not part of the command. [javac] Files to be compiled: [javac] /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/ORBSingleton.java [javac] /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/Reference.java [javac] /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/ServantDelegate.java [javac] /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/TypeCode.java [javac] /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ IORInfoImpl.java [javac] /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ ServerRequestInfoImpl.java [javac] ---------- [javac] 1. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/ORBSingleton.java (at line 37) [javac] public class ORBSingleton [javac] ^^^^^^^^^^^^ [javac] The type ORBSingleton must implement the inherited abstract method ORB.create_recursive_sequence_tc(int, int) [javac] ---------- [javac] 2. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/ORBSingleton.java [javac] (at line 525) [javac] return new org.jacorb.orb.TypeCode (org.omg.CORBA.TCKind._tk_local_interface, [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] org.omg.CORBA.TCKind._tk_local_interface cannot be resolved [javac] ---------- [javac] ---------- [javac] 3. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/Reference.java (at line 26) [javac] public class Reference [javac] ^^^^^^^^^ [javac] The serializable class Reference does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 4. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/ServantDelegate.java [javac] (at line 268) [javac] _out.write_Object(self._get_interface() ); [javac] ^^^^^^^^^^^^^^ [javac] The method _get_interface() is undefined for the type Servant [javac] ---------- [javac] ---------- [javac] 5. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/TypeCode.java (at line 40) [javac] public class TypeCode [javac] ^^^^^^^^ [javac] The serializable class TypeCode does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] 6. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/TypeCode.java (at line 69) [javac] private static boolean class_init = false; [javac] ^^^^^^^^^^ [javac] The field TypeCode.class_init is never read locally [javac] ---------- [javac] 7. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/TypeCode.java (at line 453) [javac] kind == TCKind._tk_local_interface ) [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] TCKind._tk_local_interface cannot be resolved [javac] ---------- [javac] 8. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/TypeCode.java (at line 598) [javac] case TCKind._tk_local_interface: [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] TCKind._tk_local_interface cannot be resolved [javac] ---------- [javac] 9. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/TypeCode.java (at line 624) [javac] case TCKind._tk_local_interface: [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] TCKind._tk_local_interface cannot be resolved [javac] ---------- [javac] 10. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/TypeCode.java (at line 942) [javac] kind == TCKind._tk_local_interface ) [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] TCKind._tk_local_interface cannot be resolved [javac] ---------- [javac] 11. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/TypeCode.java (at line 1080) [javac] private void set_recursive() [javac] ^^^^^^^^^^^^^^^ [javac] The method set_recursive() from the type TypeCode is never used locally [javac] ---------- [javac] 12. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/TypeCode.java (at line 1114) [javac] case TCKind._tk_local_interface: [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] TCKind._tk_local_interface cannot be resolved [javac] ---------- [javac] ---------- [javac] 13. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ IORInfoImpl.java (at line 44) [javac] public class IORInfoImpl extends org.omg.CORBA.LocalObject [javac] ^^^^^^^^^^^ [javac] The type IORInfoImpl must implement the inherited abstract method IORInfoOperations.adapter_template() [javac] ---------- [javac] 14. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ IORInfoImpl.jav [javac] a (at line 44) [javac] public class IORInfoImpl extends org.omg.CORBA.LocalObject [javac] ^^^^^^^^^^^ [javac] The type IORInfoImpl must implement the inherited abstract method IORInfoOperations.manager_id() [javac] ---------- [javac] 15. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ IORInfoImpl.java (at line 44) [javac] public class IORInfoImpl extends org.omg.CORBA.LocalObject [javac] ^^^^^^^^^^^ [javac] The type IORInfoImpl must implement the inherited abstract method IORInfoOperations.current_factory(ObjectReferenceFactory) [javac] ---------- [javac] 16. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ IORInfoImpl.jav [javac] a (at line 44) [javac] public class IORInfoImpl extends org.omg.CORBA.LocalObject [javac] ^^^^^^^^^^^ [javac] The type IORInfoImpl must implement the inherited abstract method IORInfoOperations.current_factory() [javac] ---------- [javac] 17. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ IORInfoImpl.java (at line 44) [javac] public class IORInfoImpl extends org.omg.CORBA.LocalObject [javac] ^^^^^^^^^^^ [javac] The type IORInfoImpl must implement the inherited abstract method IORInfoOperations.state() [javac] ---------- [javac] 18. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ IORInfoImpl.j [javac] ava (at line 44) [javac] public class IORInfoImpl extends org.omg.CORBA.LocalObject [javac] ^^^^^^^^^^^ [javac] The serializable class IORInfoImpl does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 19. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ ServerRequestInfoImpl.java (at line 45) [javac] public class ServerRequestInfoImpl [javac] ^^^^^^^^^^^^^^^^^^^^^ [javac] The type ServerRequestInfoImpl must implement the inherited abstract method ServerRequestInfoOperations.adapter_name() [javac] ---------- [javac] 20. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ ServerRequestIn [javac] foImpl.java (at line 45) [javac] public class ServerRequestInfoImpl [javac] ^^^^^^^^^^^^^^^^^^^^^ [javac] The type ServerRequestInfoImpl must implement the inherited abstract method ServerRequestInfoOperations.server_id() [javac] ---------- [javac] 21. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ ServerRequestInfoImpl.java (at line 45) [javac] public class ServerRequestInfoImpl [javac] ^^^^^^^^^^^^^^^^^^^^^ [javac] The type ServerRequestInfoImpl must implement the inherited abstract method ServerRequestInfoOperations.orb_id() [javac] ---------- [javac] 22. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ ServerRequest [javac] InfoImpl.java (at line 45) [javac] public class ServerRequestInfoImpl [javac] ^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class ServerRequestInfoImpl does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 23. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/poa/POA.java (at line 47) [javac] public class POA [javac] ^^^ [javac] The type POA must implement the inherited abstract method POAOperations.id() [javac] ---------- [javac] 24. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/poa/POA.java (at line 47) [javac] public class POA [javac] ^^^ [javac] The serializable class POA does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] 25. ERROR in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/poa/POA.java (at line 826) [javac] public org.omg.CORBA.Object create_reference_with_id(byte[] oid, [javac] [javac] String intf_rep_id) [javac] throws WrongPolicy [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^ [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] Exception WrongPolicy is not compatible with throws clause in POAOperations.create_reference_with_id(byte[], String) [javac] ---------- [javac] 26. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/poa/POA.java (at line 1831) [javac] Enumeration enum; [javac] ^^^^ [javac] 'enum' should not be used as an identifier, since it is a reserved keyword from source level 5.0 on [javac] ---------- [javac] 27. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/poa/POA.java (at line 1837) [javac] enum = childs.elements(); [javac] ^^^^ [javac] 'enum' should not be used as an identifier, since it is a reserved keyword from source level 5.0 on [javac] ---------- [javac] 28. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/poa/POA.java (at line 1838) [javac] while (enum.hasMoreElements()) [javac] ^^^^ [javac] 'enum' should not be used as an identifier, since it is a reserved keyword from source level 5.0 on [javac] ---------- [javac] 29. WARNING in /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/poa/POA.java (at line 1840) [javac] children[i] = (org.omg.PortableServer.POA) enum.nextElement(); [javac] ^^^^ [javac] 'enum' should not be used as an identifier, since it is a reserved keyword from source level 5.0 on [javac] ---------- [javac] 29 problems (18 errors, 11 warnings) [antcall] Exiting /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/build.xml. [ant] Exiting /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/build.xml. [ant] Exiting /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/build.xml. Kevin Kofler From neugens at limasoftware.net Sat Dec 9 16:19:41 2006 From: neugens at limasoftware.net (Mario Torre) Date: Sat, 09 Dec 2006 17:19:41 +0100 Subject: [fedora-java] Re: Does anyone have working JacORB packages for FC6? In-Reply-To: References: Message-ID: <1165681181.3151.15.camel@nirvana.limasoftware.net> Il giorno sab, 09/12/2006 alle 00.12 +0000, Kevin Kofler ha scritto: > [javac] 21. ERROR in > /usr/src/redhat/BUILD/JacORB_2_2/src/org/jacorb/orb/portableInterceptor/ > ServerRequestInfoImpl.java (at line 45) > [javac] public class ServerRequestInfoImpl > [javac] ^^^^^^^^^^^^^^^^^^^^^ > [javac] The type ServerRequestInfoImpl must implement the inherited Hello Kevin! This is a known problem. See this discussion for some hints: https://www.redhat.com/archives/fedora-devel-java-list/2005-December/msg00007.html http://www.spinics.net/linux/fedora/fedora-devel-java/msg01360.html The build file has changed a bit, so it is not immediate to get it working. I guess the best thing here would be to patch the upstream version directly to be compliant with the specs (if possible). Indeed we have a bootclasspath problem: javac handle this correctly, while ecj fails. Mario -- Lima Software, SO.PR.IND. s.r.l. http://www.limasoftware.net/ pgp key: http://subkeys.pgp.net/ Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From kevin.kofler at chello.at Sat Dec 9 16:41:44 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 9 Dec 2006 16:41:44 +0000 (UTC) Subject: [fedora-java] Re: Does anyone have working JacORB packages for FC6? References: <1165681181.3151.15.camel@nirvana.limasoftware.net> Message-ID: Mario Torre writes: > This is a known problem. > > See this discussion for some hints: > > https://www.redhat.com/archives/fedora-devel-java-list/2005-December/ msg00007.html > http://www.spinics.net/linux/fedora/fedora-devel-java/msg01360.html But the fix from that thread is already in the SRPM I built! (It was added in 2.2-3jpp_5fc, I built 2.2-3jpp_8fc.) My problem is that the fix no longer works. Kevin Kofler From overholt at redhat.com Thu Dec 14 16:24:52 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 14 Dec 2006 11:24:52 -0500 Subject: [fedora-java] Re: Error in running mgnt target on Linux. In-Reply-To: <45817A30.6080500@redhat.com> References: <87d56vb9rv.fsf@rho.meyering.net> <1165588957.3278.0.camel@localhost.localdomain> <45797B3F.6010406@redhat.com> <5787f3c10612120124v78add47axb79834efd3f2ade6@mail.gmail.com> <5787f3c10612120957l284aa7a9ncfff67c2f2b82fac@mail.gmail.com> <45817A30.6080500@redhat.com> Message-ID: <1166113492.18469.11.camel@toast.toronto.redhat.com> On Thu, 2006-12-14 at 11:22 -0500, Carl Trieloff wrote: > > I have cross posted the lists ... we have a mgnt console that is built > on RCP and would like > to get it also working on Linux. Why is there a hard requirement on the win32 bundle? Whatever is starting the management console should determine what ws.os.arch triplet (ex. win32.win32.x86 or gtk.linux.ppc) is needed. It appears that the launcher may be hard-coding for win32. But perhaps that's just my naive reading of the situation. I don't know anything about maven. Sorry. Andrew -------------- 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 Thu Dec 14 19:42:48 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 14 Dec 2006 14:42:48 -0500 Subject: [fedora-java] Re: Fwd: Error in running mgnt target on Linux. In-Reply-To: <5787f3c10612141032n2967c67fh9a37b18a49f685fa@mail.gmail.com> References: <87d56vb9rv.fsf@rho.meyering.net> <1165588957.3278.0.camel@localhost.localdomain> <45797B3F.6010406@redhat.com> <5787f3c10612120124v78add47axb79834efd3f2ade6@mail.gmail.com> <5787f3c10612120957l284aa7a9ncfff67c2f2b82fac@mail.gmail.com> <45817A30.6080500@redhat.com> <1166113492.18469.11.camel@toast.toronto.redhat.com> <5787f3c10612141030y6a59dd5dyf201459e3a6ea317@mail.gmail.com> <5787f3c10612141032n2967c67fh9a37b18a49f685fa@mail.gmail.com> Message-ID: <1166125368.19932.15.camel@toast.toronto.redhat.com> Hi, On Thu, 2006-12-14 at 18:32 +0000, Bhupendra Bhardwaj wrote: > The eclipse plugins in maven repository are available for win32 only. This seems like the root of your current problem. If you are using maven to build and it pulls its deps from some repo somewhere, then your dependencies need to be in that repo, right? However, later on you say: > The downloading of required runtime binary from eclipse is required > because the platform specific eclipse plugins are not available in > maven repository, so we can't pachage everything together for all > platforms using maven. So what if they *were* in the maven repo? Would it be able to do per-arch/os/ws builds? SWT -- and by extension RCP -- is platform-dependent. How does maven handle this situation? Andrew -------------- 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 Thu Dec 14 23:41:35 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 14 Dec 2006 18:41:35 -0500 Subject: [fedora-java] Re: Fwd: Error in running mgnt target on Linux. In-Reply-To: <5787f3c10612141541m511ab2a1j5cce4cbcdc6df616@mail.gmail.com> References: <1165588957.3278.0.camel@localhost.localdomain> <45797B3F.6010406@redhat.com> <5787f3c10612120124v78add47axb79834efd3f2ade6@mail.gmail.com> <5787f3c10612120957l284aa7a9ncfff67c2f2b82fac@mail.gmail.com> <45817A30.6080500@redhat.com> <1166113492.18469.11.camel@toast.toronto.redhat.com> <5787f3c10612141030y6a59dd5dyf201459e3a6ea317@mail.gmail.com> <5787f3c10612141032n2967c67fh9a37b18a49f685fa@mail.gmail.com> <1166125368.19932.15.camel@toast.toronto.redhat.com> <5787f3c10612141541m511ab2a1j5cce4cbcdc6df616@mail.gmail.com> Message-ID: <20061214234135.GA15314@redhat.com> Hi, * Bhupendra Bhardwaj [2006-12-14 18:41]: > Other than the jar files(compilation dependencies), the platform > specific files for runtime (dll, so etc) will be required. Those > runtime bundles should also be available to download, if we want to > package everything together. The SWT DSOs are *in* the SWT fragment (platform-specific part of the plugin ... the org.eclipse.swt.gtk.linux.x86_.jar) and will be extracted at run-time. If you're going to package this up as an RPM for your Fedora/RHEL users, you'll want to depend upon eclipse-rcp instead of bundling the runtime. Look at the RSSOwl or Azureus specfiles in Fedora Extras CVS [1] for examples. Those aren't strict RCP apps, but they're close and will give you something to work from. Andrew [1] http://cvs.fedora.redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Sun Dec 17 15:51:36 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 17 Dec 2006 15:51:36 +0000 Subject: [fedora-java] Reporting gcj bugs Message-ID: <1166370696.21598.27.camel@T7.Linux> Hi, I'm using gcj to compile some java and I'm not getting the results I'd expect out. Do I file this as usual in BZ or should I check here first if it's an oddity which doesn't need reporting? TTFN Paul -- "Mmmmmmmm....Shakira geschmiert mit schokolade" sagt Homer -------------- 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 Sun Dec 17 16:14:24 2006 From: aph at redhat.com (Andrew Haley) Date: Sun, 17 Dec 2006 16:14:24 +0000 Subject: [fedora-java] Reporting gcj bugs In-Reply-To: <1166370696.21598.27.camel@T7.Linux> References: <1166370696.21598.27.camel@T7.Linux> Message-ID: <17797.27872.656508.496194@zebedee.pink> Paul writes: > Hi, > > I'm using gcj to compile some java and I'm not getting the results I'd > expect out. Do I file this as usual in BZ or should I check here first > if it's an oddity which doesn't need reporting? It depends on what it is. Talk to us, and probably file a bugzilla if warranted. If it's an upstream bug, please make sure it gets file in gcc Bugzilla, not Fedora Bugzilla. Andrew. From paul at all-the-johnsons.co.uk Sun Dec 17 16:30:36 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 17 Dec 2006 16:30:36 +0000 Subject: [fedora-java] Reporting gcj bugs In-Reply-To: <17797.27872.656508.496194@zebedee.pink> References: <1166370696.21598.27.camel@T7.Linux> <17797.27872.656508.496194@zebedee.pink> Message-ID: <1166373036.21598.37.camel@T7.Linux> Hi Andrew, > > I'm using gcj to compile some java and I'm not getting the results I'd > > expect out. Do I file this as usual in BZ or should I check here first > > if it's an oddity which doesn't need reporting? > > It depends on what it is. Talk to us, and probably file a bugzilla if > warranted. If it's an upstream bug, please make sure it gets file in > gcc Bugzilla, not Fedora Bugzilla. Thanks - I've got two - one is in BZ, one isn't. First is that the redraw events and quitting is bust. Assuming it's not just me being a numpty, the following shows the problem import java.awt.*; import javax.swing.*; public class gridlayout extends JFrame { private JButton [] buttons; public gridlayout(String title) { super(title); Container contentPane = this.getContentPane(); contentPane.setLayout(new GridLayout(2, 3, 10, 15)); buttons = new JButton[6]; for (int i = 0; i < buttons.length; ++i) { buttons[i] = new JButton("Click " + (i + 1)); contentPane.add(buttons[i]); } } public static void main(String [] args) { JFrame f = new gridlayout("Grid Layout Demo"); f.setSize(300, 200); f.setVisible(true); } } Really simple code - it does as it's told and runs. However, move another window over it and the redraw does nothing when the 2nd window is removed to show the java app window. The second is that if I click on the close window icon, it doesn't - instead I get the error box asking if you want to wait or terminate straight away. Next one is that modal windows don't seem to be sizing themselves correctly... import java.awt.*; import java.awt.event.*; import javax.swing.*; public class modaltest extends Frame implements ActionListener { private Dialog modal; private JButton go, ok; public modaltest(String title) { super(title); go = new JButton("Go"); go.addActionListener(this); ok = new JButton("OK"); ok.addActionListener(this); modal = new Dialog(this, "A modal dialog", true); modal.setLayout(new FlowLayout()); modal.add(ok); modal.setBounds(60, 100, 180, 60); JPanel centre = new JPanel(); centre.add(go); this.add(centre, BorderLayout.CENTER); } // clicking either button cause the following method to hit in public void actionPerformed(ActionEvent e) { String label = e.getActionCommand(); if(label.equals("Go")) modal.show(); else if (label.equals("OK")) modal.hide(); } public static void main(String [] args) { Frame f = new modaltest("Modal test"); f.setSize(300, 300); f.setVisible(true); } } (yes, I know, hide() and show() are deprecated, but that shouldn't make much of a difference here). Here, if GO is clicked, the modal window is opened. However, the OK button isn't in there as it looks as if either a redraw has failed or the window is too small for the button to appear in. As I say, all three could be down to me... Any advice would be appreciated. TTFN Paul -- "Mmmmmmmm....Shakira geschmiert mit schokolade" sagt Homer -------------- 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 paul at all-the-johnsons.co.uk Sun Dec 17 17:43:43 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 17 Dec 2006 17:43:43 +0000 Subject: [fedora-java] Reporting gcj bugs In-Reply-To: <1166376405.3377.12.camel@nirvana.limasoftware.net> References: <1166370696.21598.27.camel@T7.Linux> <17797.27872.656508.496194@zebedee.pink> <1166373036.21598.37.camel@T7.Linux> <1166376405.3377.12.camel@nirvana.limasoftware.net> Message-ID: <1166377423.27614.4.camel@T7.Linux> Hi, > What version of gcj are you running? java version "1.4.2" gij (GNU libgcj) version 4.1.1 20061213 (Red Hat 4.1.1-47) I'm on rawhide, x86_64 > I've tried your examples and both seem fine: Can you bung me over a screenshot or so (off list) to make sure they're doing the same as produced using Sun's Java? > > As I say, all three could be down to me... > > I remember that we had an issue about repainting, but now I really can't look at this, maybe > in gcc/classpath bugzilla there is something, but at least with this simple case, > it works for me (I know these are the scary words for bug reporters :). /me runs away screaming! > Can you try to give us some more details (gcc version, ecj version, fedora/redhat version, > processor type and other test case etc..)? FC rawhide x86_64 ecj is not installed gcc 4.1.1 20061213 (Red Hat 4.1.1-47) I realise that rawhide eats babies, but redraw and window closing should work as should the modal example. TTFN Paul -- "Mmmmmmmm....Shakira geschmiert mit schokolade" sagt Homer -------------- 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 neugens at limasoftware.net Sun Dec 17 17:26:45 2006 From: neugens at limasoftware.net (Mario Torre) Date: Sun, 17 Dec 2006 18:26:45 +0100 Subject: [fedora-java] Reporting gcj bugs In-Reply-To: <1166373036.21598.37.camel@T7.Linux> References: <1166370696.21598.27.camel@T7.Linux> <17797.27872.656508.496194@zebedee.pink> <1166373036.21598.37.camel@T7.Linux> Message-ID: <1166376405.3377.12.camel@nirvana.limasoftware.net> Il giorno dom, 17/12/2006 alle 16.30 +0000, Paul ha scritto: > Really simple code - it does as it's told and runs. However, move > another window over it and the redraw does nothing when the 2nd window > is removed to show the java app window. What version of gcj are you running? I've tried your examples and both seem fine: [neugens at nirvana bin]$ java -version java version "1.4.2" gij (GNU libgcj) version 4.1.1 20061011 (Red Hat 4.1.1-30) I've tried the snippets and both are fine. > As I say, all three could be down to me... I remember that we had an issue about repainting, but now I really can't look at this, maybe in gcc/classpath bugzilla there is something, but at least with this simple case, it works for me (I know these are the scary words for bug reporters :). Can you try to give us some more details (gcc version, ecj version, fedora/redhat version, processor type and other test case etc..)? Mario -- Lima Software, SO.PR.IND. s.r.l. http://www.limasoftware.net/ pgp key: http://subkeys.pgp.net/ Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From paul at all-the-johnsons.co.uk Mon Dec 18 00:01:20 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 18 Dec 2006 00:01:20 +0000 Subject: [fedora-java] Reporting gcj bugs In-Reply-To: <1166399545.3152.5.camel@nirvana.limasoftware.net> References: <1166370696.21598.27.camel@T7.Linux> <17797.27872.656508.496194@zebedee.pink> <1166373036.21598.37.camel@T7.Linux> <1166376405.3377.12.camel@nirvana.limasoftware.net> <1166377423.27614.4.camel@T7.Linux> <1166399545.3152.5.camel@nirvana.limasoftware.net> Message-ID: <1166400080.30171.15.camel@T7.Linux> Hi, > > Can you bung me over a screenshot or so (off list) to make sure they're > > doing the same as produced using Sun's Java? > > Sure, here they are! Yep, they look like what I'm getting here. > > > Can you try to give us some more details (gcc version, ecj version, fedora/redhat version, > > > processor type and other test case etc..)? > > > > FC rawhide > > x86_64 > > ecj is not installed > > gcc 4.1.1 20061213 (Red Hat 4.1.1-47) > > I fear I cannot be of any help so, unless I manage to reproduce this > bug. I think it may be a rawhide bug more than anything. Things seem somewhat jiggered with Panels. Am I correct in thinking the following 1. If I create a panel and set it BorderLayout.NORTH that unless I've put something in there before placing it, the panel should take the entire top? 2. If I create a JButton (called foo) then foo.setSize(30, 30) should create a button of size 30,30? If that is the case, then JButton is goosed as well. > You said you have submitted one in bugzilla. Can you point me to the > issue number? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219946 TTFN Paul -- "Mmmmmmmm....Shakira geschmiert mit schokolade" sagt Homer -------------- 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 neugens at limasoftware.net Sun Dec 17 23:52:25 2006 From: neugens at limasoftware.net (Mario Torre) Date: Mon, 18 Dec 2006 00:52:25 +0100 Subject: [fedora-java] Reporting gcj bugs In-Reply-To: <1166377423.27614.4.camel@T7.Linux> References: <1166370696.21598.27.camel@T7.Linux> <17797.27872.656508.496194@zebedee.pink> <1166373036.21598.37.camel@T7.Linux> <1166376405.3377.12.camel@nirvana.limasoftware.net> <1166377423.27614.4.camel@T7.Linux> Message-ID: <1166399545.3152.5.camel@nirvana.limasoftware.net> Il giorno dom, 17/12/2006 alle 17.43 +0000, Paul ha scritto: > Hi, > > Can you bung me over a screenshot or so (off list) to make sure they're > doing the same as produced using Sun's Java? Sure, here they are! http://www.limasoftware.net/neugens/downloads/classpath/test/ 1, 2, 3 are from the first program, 1a, 2a from the second. These are screenshots with gcj. Sorry they are full screen, I did not had time to cut and paste. > > > As I say, all three could be down to me... > > > > I remember that we had an issue about repainting, but now I really can't look at this, maybe > > in gcc/classpath bugzilla there is something, but at least with this simple case, > > it works for me (I know these are the scary words for bug reporters :). > > /me runs away screaming! > > > Can you try to give us some more details (gcc version, ecj version, fedora/redhat version, > > processor type and other test case etc..)? > > FC rawhide > x86_64 > ecj is not installed > gcc 4.1.1 20061213 (Red Hat 4.1.1-47) I fear I cannot be of any help so, unless I manage to reproduce this bug. You said you have submitted one in bugzilla. Can you point me to the issue number? Mario -- Lima Software, SO.PR.IND. s.r.l. http://www.limasoftware.net/ pgp key: http://subkeys.pgp.net/ Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From charlescurley at charlescurley.com Wed Dec 20 14:12:21 2006 From: charlescurley at charlescurley.com (Charles Curley) Date: Wed, 20 Dec 2006 07:12:21 -0700 Subject: [fedora-java] How to get the latest j2ee and jpackage to play together? Message-ID: <20061220141221.GC15660@charlescurley.com> How does one get the latest Sun j2ee and jpackage to play together? I can find writeups for the Sun jdk, but don't seem to find any for j2ee. I think I want "JDK 5.0 Update 9 with Java EE" on http://java.sun.com/javase/downloads/index_jdk5.jsp. Thank you. -- Charles Curley /"\ ASCII Ribbon Campaign Looking for fine software \ / Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com / \ No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mark at klomp.org Fri Dec 29 19:41:56 2006 From: mark at klomp.org (Mark Wielaard) Date: Fri, 29 Dec 2006 20:41:56 +0100 Subject: [fedora-java] F7 plan (gcj/java/eclipse/swt/java-gnome/fop/batik/etc) Message-ID: <1167421316.19763.82.camel@localhost.localdomain> Hi, I saw the following thread about F7 plans and noticed we don't have any goals for gcj/eclipse/swt/java-gnome/etc http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/1551 So here are some ideas, deadlines and dependencies that might be nice to look at for F7 for the various stacks that make up the fedora-devel-java world. Please reply if you are working on any of this, if I am saying something silly/wrong or if there are more stack/application issues that you think are important for F7. The "important dates" are: - January 23 - Test1 Development Freeze - February 20 - Test2 Development Freeze - March 15 - Test3 Development Freeze - Release in April Test2 is just before Fosdem. And since all features should be in by then, it would be nice to try and create a liveCD with all "our features" on it to show off at Fosdem (Feb 24/25, Brussel, Belgium). - 1.5 language & library support in gcj This seems to be the biggest and most intrusive upgrade. But starting this early seems like a very good idea. Upstream is cleaning up some last issues. And it needs lots of testing. Would be good if something can be cooked up for Test1. Needs help from gcc-toolchain people. - Separate libgcj-rpm. Would be really nice so we can update the core class libraries separate from the core gcc compilers. Should also help with updates/dependencies since libgcj provides the mozilla plugin now and the awt libraries depend on gtk+. Would be nice if this can be done before Test2 so we can test an upgrade. Again needs help from gcc-toolchain people. - java-gcj-compat The biggest issue with this, if the 1.5-stack goes through is that gjdoc isn't 1.5 safe. If we cannot easily update gjdoc, then maybe sinjdoc could be investigated as replacement. http://www.cag.lcs.mit.edu/~cananian/Projects/GJ/#sinjdoc (Do we also need updates for javap and javah replacements?) - eclipse/swt/rcp stack 3.2 seems already good to go, and 3.3 will not come out till the middle of 2007. Azureus, RSSOwl also already seem updated. Andrew Overholt already has written down some plans for the future: http://overholt.ca/wp/?p=76 Maybe some work can be done to support the JDWP work in libgcj to get a little debugging going? And it would be nice to make sure that the ecj from eclipse and that from the gcj 1.5-stack match up. - java-gnome There are some rumors about a upgrade/rewrite, but nothing concrete as far as I have seen. If there is a rewrite that might cause some extra work for applications like Frysk. - gcj-compiled DocBook toolchain It seems we have made lots of progress with FOP and Batik since the last discussion about this: http://thread.gmane.org/gmane.linux.redhat.fedora.documentation/4582 Does anybody know where we are with that at this time? Would be nice to coordinate with the fedora-docs-list if we can provide something. - jpackage. Does it make sense to upgrade all packages to jpp 1.7 if the 1.5-stack goes in? - OpenOffice 2.2 Listed here since it does have some parts written in java. 2.2 comes out end of February. Probably needs retesting with the gcj-stack. I don't know if there are new java language/library dependencies. Some things that would be nice, but that are probably a lot of work, maybe better left for Fedora *, unless someone volunteers of course! :) - OpenJDK Still lots missing. Hopefully at Fosdem we will learn a bit more about the encumberments and when which parts of the core libraries will be liberated fully. But it might be nice to see if javac could be packaged. Or maybe a brave soul make hotspot work with classpath? - PhoneME/CACAO/MIDPath/J2MEPolish The Micro Edition world seems to really have gotten a boost from the GPL release of PhoneME. A lot of this is pretty early access. But it would be nice to have parts of this supported to show that Fedora is also a nice platform to developer for java-based mobile devices. - JBoss application server, SEAM stack Not tried yet. Parts like tomcat are already packaged. If we can get the 1.5-stack going it makes sense to look at this a bit closer. Maybe other parts can be lifted from jpackage? - Netbeans I tried this recently, but it seems still very tight to the Sun java implementation and I was unable to fully start it up on the free stack. But some dependencies like JavaHelp have been liberated (gpl+exception) now (and entered jpackage recently). Also it isn't clear whether the current license (CDDL) is acceptable (it seems unacceptable to Debian). - JOGL and WW2D should work, but I haven't done any testing recently. - japitools should really be packaged and somehow be tied in with the build system so developers/packagers can get an easy overview of whether or not a library upgrade is binary compatible or not. I am sure there is a lot missing. And as you saw none of the items above have real deadlines or people responsible, etc. So please feel free to reply with corrections add those yourself :) Cheers, Mark From mark at klomp.org Fri Dec 29 22:01:58 2006 From: mark at klomp.org (Mark Wielaard) Date: Fri, 29 Dec 2006 23:01:58 +0100 Subject: [fedora-java] Reporting gcj bugs In-Reply-To: <1166373036.21598.37.camel@T7.Linux> References: <1166370696.21598.27.camel@T7.Linux> <17797.27872.656508.496194@zebedee.pink> <1166373036.21598.37.camel@T7.Linux> Message-ID: <1167429718.19763.88.camel@localhost.localdomain> Hi Paul, On Sun, 2006-12-17 at 16:30 +0000, Paul wrote: > First is that the redraw events and quitting is bust. Assuming it's not > just me being a numpty, the following shows the problem > [...] > Really simple code - it does as it's told and runs. However, move > another window over it and the redraw does nothing when the 2nd window > is removed to show the java app window. This seems to work fine for me with gcj (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30) > The second is that if I click on the close window icon, it doesn't - > instead I get the error box asking if you want to wait or terminate > straight away. This also seems to work and just closes the window. > Next one is that modal windows don't seem to be sizing themselves > correctly... > [...] > (yes, I know, hide() and show() are deprecated, but that shouldn't make > much of a difference here). > > Here, if GO is clicked, the modal window is opened. However, the OK > button isn't in there as it looks as if either a redraw has failed or > the window is too small for the button to appear in. This also seems to work fine. You say you have 4.1.1-47, I wonder what changed since -30. It looks like a regression. But classpath-cvs-trunk plus jamvm also work fine. Cheers, Mark From tromey at redhat.com Fri Dec 29 20:09:32 2006 From: tromey at redhat.com (Tom Tromey) Date: 29 Dec 2006 13:09:32 -0700 Subject: [fedora-java] F7 plan (gcj/java/eclipse/swt/java-gnome/fop/batik/etc) In-Reply-To: <1167421316.19763.82.camel@localhost.localdomain> References: <1167421316.19763.82.camel@localhost.localdomain> Message-ID: >>>>> "Mark" == Mark Wielaard writes: Mark> - January 23 - Test1 Development Freeze Ok... Mark> - 1.5 language & library support in gcj Mark> This seems to be the biggest and most intrusive upgrade. But starting Mark> this early seems like a very good idea. Upstream is cleaning up some Mark> last issues. And it needs lots of testing. Would be good if something Mark> can be cooked up for Test1. Needs help from gcc-toolchain people. Yeah... do we know what base compiler is being used for FC7? We'll probably have to back-port all the 1.5 stuff to that. Kinda tough before the 23rd considering that we haven't merged it all to GCC mainline yet :( Mark> - Separate libgcj-rpm. This is suspended pending the core/extras merge. Mark> - java-gcj-compat Mark> (Do we also need updates for javap and javah replacements?) We don't have javap at all, do we? But we do have jcf-dump, which has not changed during all the 1.5 work. The new javah that is in Classpath will show up when we merge the gcj-eclipse branch to trunk. Mark> Maybe some work can be done to support the JDWP work in libgcj to Mark> get a little debugging going? Whatever is on the branch, we'll ship. I don't know what will work or not before the release, we'll have to ask Keith. Mark> - OpenJDK Mark> Still lots missing. Hopefully at Fosdem we will learn a bit more about Mark> the encumberments and when which parts of the core libraries will be Mark> liberated fully. But it might be nice to see if javac could be Mark> packaged. javac builds fine against classpath (as you know). I'm not sure if all the needed bits are in libgcj yet, but this is simple to fix if not. Tom From mark at klomp.org Fri Dec 29 22:57:04 2006 From: mark at klomp.org (Mark Wielaard) Date: Fri, 29 Dec 2006 23:57:04 +0100 Subject: [fedora-java] F7 plan (gcj/java/eclipse/swt/java-gnome/fop/batik/etc) In-Reply-To: References: <1167421316.19763.82.camel@localhost.localdomain> Message-ID: <1167433024.19763.97.camel@localhost.localdomain> Hi Tom, On Fri, 2006-12-29 at 13:09 -0700, Tom Tromey wrote: > >>>>> "Mark" == Mark Wielaard writes: > > Mark> - January 23 - Test1 Development Freeze > > Ok... > > Mark> - 1.5 language & library support in gcj > Mark> This seems to be the biggest and most intrusive upgrade. But starting > Mark> this early seems like a very good idea. Upstream is cleaning up some > Mark> last issues. And it needs lots of testing. Would be good if something > Mark> can be cooked up for Test1. Needs help from gcc-toolchain people. > > Yeah... do we know what base compiler is being used for FC7? > We'll probably have to back-port all the 1.5 stuff to that. > Kinda tough before the 23rd considering that we haven't merged it all > to GCC mainline yet :( I have CCed Jakub. If there is a fedora branch in gcc svn then maybe porting/patching can be done at the same time as it lands on mainline? > Mark> - Separate libgcj-rpm. > > This is suspended pending the core/extras merge. O, that is a pity. Any idea what/how long that will take? > Mark> - java-gcj-compat > Mark> (Do we also need updates for javap and javah replacements?) > > We don't have javap at all, do we? But we do have jcf-dump, which has > not changed during all the 1.5 work. You are right. Strange, since jcf-dump has a --javap mode I assumed it would be the natural wrapper for java-gcj-compat to provide javap. > The new javah that is in Classpath will show up when we merge the > gcj-eclipse branch to trunk. Will this replace gcjh? Cheers, Mark From kevin.kofler at chello.at Sun Dec 31 07:39:06 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 31 Dec 2006 07:39:06 +0000 (UTC) Subject: [fedora-java] Re: Does anyone have working JacORB packages for FC6? References: Message-ID: I've given up on aot-compiling and just used the JacORB 2.2.4 binary zipfile. This works with gij if you symlink avalon-framework-4.1.5.jar, jacorb.jar and logkit-1.2.jar into /usr/share/java/gcj-endorsed. (Also run dos2unix and chmod +x on the shell scripts in the "bin" directory.) You can then simplify the jaco script to: #!/bin/sh JACORB_HOME="/path/to/JacORB-2.2.4" export JACORB_HOME # call java interpreter exec java \ -Djacorb.home="$JACORB_HOME" \ -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB \ -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton \ "$@" (The bootclasspath hackery which the jaco script normally does doesn't work with gij, at least not for me.) At least the name server appears to start up that way, I haven't done any further testing yet. I'd of course prefer a nice native RPM, but at least this works, so I'm posting the instructions in case other people are interested. Kevin Kofler