java-devel September 2005

java-devel@lists.fedoraproject.org

23 participants
20 discussions

Start a nNew thread

AbiWord gcj help request
by Andrew Overholt 20 Sep '05

20 Sep '05

http://www.advogato.org/person/msevior/diary.html?start=56 Andrew

2 1

Re: [fedora-java] dependency issues with java-1.4.2-gcj-compat
by Gary Benson 19 Sep '05

19 Sep '05

David Farning wrote: > On Thu, 2005-09-15 at 13:42 +0100, Gary Benson wrote: > > David Farning wrote: > > > When running yum install eclips* I got all sorts of > > > /usr/bin/rebuild-gcj-db: No such file or directory > > > errors until I manually installed java-1.4.2* > > > > It sounds like rpm is _still_ not ordering dependencies correctly. > > There should be a bug open against rpm for this, but if not please > > file one. > > I did a bit of searching on this it would seem to be the > %if %{gcj_support} > .... > Requires(post): java-gcj-compat >= 1.0.31 > Requires(postun): java-gcj-compat >= 1.0.31 > .... > > are causing problem because they don't...wait for it...work! That's the one. > Would there be a problem with > > %if %{gcj_support} > .... > Requires: java-gcj-compat >= 1.0.31 > .... > > ie. would it hurt it -compat were present all the time not just > during post and unpost? The Short answer is no, since Requires(*) implies Requires. The long answer is that Requires on its own is not in force during rpm transactions. Augmented Requires(*) dependencies specify that it must be present at certain points within the transaction _in_addition_to_ inbetween transactions. Cheers, Gary own, Requires on its own.

5 7

Improving Fedora javadoc
by Anthony Green 16 Sep '05

16 Sep '05

There are a couple of big problems with our javadoc situation right now: - We don't install javadoc for the core classes. - There are no links between javadoc packages. If would be nice to fix this for FC5. Here are my suggested actions: 1. If we aren't going to modify the gcc spec file to generate libgcj javadoc, then we should use something like this package, which builds core javadoc from the libgcj-src RPM... http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm 2. Modify all our spec files to include links between packages. 3. All the javadoc gets installed in directories under /usr/share/javadoc. It would be nice if there were a top level index.html to tie them all together. We could add a %post(un) script to maintain this file. 4. The Eclipse help system should refer to this top level index.html, so it shows up along with the other Eclipse docs. Maybe it could also go on the main Gnome menu under Applications/Programming. Any other ideas? It all starts with [1], which we've discussed before but I'm afraid we're kind of stalled on. AG

5 20

dependency issues with java-1.4.2-gcj-compat
by David T Farning 16 Sep '05

16 Sep '05

I just got around to installing native eclipse on the devel branch and have found what appears to be a dependency issues with java-1.4.2-gcj-compat. When running yum install eclips* I got all sorts of /usr/bin/rebuild-gcj-db: No such file or directory errors until I manually installed java-1.4.2* (I didn't keep a log cause I wasn't sure what was happening yet) When attempting to yum remove eclipse* I get the following .... Removing : xerces-j2 ####################### [ 1/65] Removing : eclipse-jdt-devel ####################### [ 2/65] Removing : ant-nodeps ####################### [ 3/65] Removing : eclipse-pydev ####################### [ 4/65] Removing : ant-apache-bcel ####################### [ 5/65] Removing : ldapjdk ####################### [ 6/65] Removing : jakarta-commons-httpclient ####################### [ 7/65] Removing : ant-jsch ####################### [ 8/65] Removing : ant-apache-resolver ####################### [ 9/65] Removing : ant-trax ####################### [10/65] Removing : geronimo-specs-compat ####################### [11/65] Removing : xalan-j2 ####################### [12/65] Removing : mx4j ####################### [13/65] Removing : eclipse-platform-devel ####################### [14/65] Removing : ant-jdepend ####################### [15/65] Removing : jakarta-commons-collections ####################### [16/65] Removing : jakarta-commons-fileupload ####################### [17/65] Removing : java-1.4.2-gcj-compat ####################### [18/65] Removing : jakarta-commons-logging ####################### [19/65] /var/tmp/rpm-tmp.61501: line 1: /usr/bin/rebuild-gcj-db: No such file or directory error: %postun(jakarta-commons-logging-1.0.4-2jpp_6fc.i386) scriptlet failed, exit status 127 Removing : eclipse-rcp-devel ####################### [20/65] Removing : jakarta-commons-dbcp ####################### [21/65] Removing : ant-javamail ####################### [22/65] ... The /usr/bin/rebuild-gcj-db: No such file or directory error shows up just after java-1.4.2-gcj-compat has been removed. If I manually reinstall java-1.4.2-gcj-compat I can successfully remove jakarta-commons-logging. Should I look into this deeper and file a bug report? -dtf

4 4

jpackage-utils on FC4 (x86_64 issue mainly)
by Carwyn Edwards 15 Sep '05

15 Sep '05

Why does macros.jpackage in jpackage-utils-1.6.3 on FC4 still use %{_prefix}/lib/jvm references while jpackage.org macros.jpackage in jpackage-utils-1.6.4 (1.6.3 too allegedly) uses %{_libdir}/jvm? The really confusing part is that FC4 seems to have picked up jpackage-utils up _after_ the change was made in the jpackage.org version!? (around 1.6.3 when the chagelog lists the change at 1.6.2). The end result is that the FC4 x86_64 gcj-compat package is in /usr/lib/jvm rather than /usr/lib64/jvm. The unfortunate thing though is that the link part of the alternative slaves also end up pointing at /usr/lib/jvm. I hit this while trying to finish off the Jpackage jdk cleanups I started a while back. Updating to jpackage-utils 1.6.4 from jpackage.org then trying to install a x86_64 Jdk built against it fails if the gcj-compat package is installed as the alternatives link names are different: 1:java-1.5.0-sun ########################################### [ 14%] link /usr/lib/jvm-exports/jre incorrect for slave jre_exports (/usr/lib64/jvm-exports/jre jre_exports) The culprit being: --slave /usr/lib64/jvm-exports/jre jre_exports /usr/lib64/jvm-exports/jre-1.5.0-sun .. which of course conflicts with the link name already installed against "jre_exports" for gcj-compat which lists jre_exports as being a link from /usr/lib/jvm-exports/jre. The workaround is to stick with the jpackage-utils in FC4 I guess. Still it's a good example of how mixing JPackage and FC4 can cause problems. Carwyn

1 0

Java developer needed to help with Fedora Docs Project infrastructure
by Tommy Reynolds 14 Sep '05

14 Sep '05

Hi, All! Over at the Fedora Docs Project, we have a problem that we think you can help with. Our developers use XML DocBook so that we can generate both HTML and PDF forms of the document from the same originals. The HTML generation works great, but the PDF generation is broken. Our current tool "xmlto" uses TeX to render to PDF, but that hasn't been maintained for a long time. We can use Apache FOP for the rendering but don't want to use the JVM version because it doesn't have an open license. So, here is how you could help. We'd first like to get Apache FOP native compiled using gcj and then maybe add in some open-source PNG or JPG rendering libraries. If you would like to help, you can reply on this list or contact me privately at: Tommy.Reynolds(a)MegaCoder.com I look forward to hearing from you!

3 2

Eclipse
by qwejustin 11 Sep '05

11 Sep '05

Does anyone know when eclipse will be updated next? My understanding is that there have not been a update since 3.1.0_fc-0.M6.22 thanks

2 1

GNU Classpath distro DevJam
by Mark Wielaard 07 Sep '05

07 Sep '05

Hi all, Various Debian packagers and developers are interested in coming together to improve the Free Software tool chain, the programs and the free runtime environments for software written in the java programming language. For such a meeting we would like to include packagers from various distributions to coordinate on library names, dependency and versioning. And to share experiences on how to integrate and map dependencies of tools like ant and maven when creating traditional GNU/Linux distribution packages. So we are proposing a developer and packager meeting around coordinating and improving the state of packaging of large scale applications written in the java programming language using the GNU Classpath, gcj and other free java-like tool chains for the various GNU/Linux distributions. Please see DevJam wiki for details: http://java.debian.net/index.php/DevJam We hope to get together a group of (20 till 30) people wanting to do some hands on hacking to show the state of the art in packaging. Resulting in the availability of several new packages, improvements to the free tool chains and cross-distribution packaging conventions quickly after the meeting. One of the ideas to keep the cost down for now is sharing the meeting with another group in Oldenburg, Germany, from September 21st to September 25th. http://meeting.ffis.de/Oldenburg2005/ If you are interested please add you name and thoughts about how to make such a meeting most effective to the wiki! And please contact us if you are interested in sponsoring the effort. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/

3 5

java-gcjHEAD-compat fixes
by Thomas Fitzsimmons 06 Sep '05

06 Sep '05

Hi, I fixed some things in java-gcjHEAD-compat: - removed the file conflicts with java-gcj-compat, so java-gcjHEAD-compat will install cleanly beside other java-gcj-compat installations - added "javac" to the installed tools, using Gary's bootstrap ecj jar Here are Andrew's instructions for creating a JPackage alternative for GCJ HEAD: https://www.redhat.com/archives/fedora-devel-java-list/2005-May/msg00046.ht… The installation of these packages runs smoothly now. Tom

3 8

new version of gcjwebplugin
by Justin Conover 06 Sep '05

06 Sep '05

https://savannah.nongnu.org/projects/gcjwebplugin/ https://savannah.nongnu.org/forum/forum.php?forum_id=3991 Does anyone know if there are still security concerns with this version? >From the Main page that shows the warning, but not the new version http://www.nongnu.org/gcjwebplugin/news.html WARNING: The current version does not provide a security manager capable of handling Java (tm) applets. Applets have UNRESTRICTED access to your computer. This means they can do anything you can do, like deleting all your important data.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel September 2005