avalon-framework and doclet classes
by Anthony Green
Gary -
I was trying to build something recently that required
org.apache.avalon.framework.logger.Log4JLogger from avalon-framework.
The avalon-framework.jar file in FC4 appears to be missing this class.
I grabbed the SRPM file from rawhide and attempted to build that
instead. The build failed with this...
[javadoc] java.lang.ClassNotFoundException: com.sun.tools.doclets.standard.Standard not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
I've seen this before. It seems that our com-sun-javadoc or
com-sun-tools-doclets-Taglet jar should be on the default classpath
somehow.
In any case, I noticed that this build of the jar file includes the
proper class, but as far as I can tell, this is the same SRPM that was
used in FC4. Why wouldn't the FC4 jar file contain the Log4JLogger
class?
Thanks!
AG
18 years, 3 months
Release Notes
by Anthony Green
The current "Java" content for the release notes (from FC4) are pretty
slim. I'll quote them below with my comments and questions...
> Fedora Core 4 users are advised not to use the Java RPM provided by
> Sun. It contains Provides that conflict with names used in packages
> provided as part of Fedora Core 4. Because of this, Sun Java might
> disappear from an installed system during package upgrade operations.
I assume this is still true. Does anybody have a pointer to the
details?
> Fedora Core 4 users should use either the RPM available from
> http://www.jpackage.org/, or manually install the Sun Java tarball
> into `/opt/`.
I think we should discourage the /opt solution, since it doesn't
integrate with out alternatives-based solution.
Also, I thought there were problems with using the binary RPM from
JPackage, and users _have_ to rebuild from the SRPM. Does anybody
know about this?
> Sun Java 1.5+ is recommended for stability purposes.
Is this really true? What about IBM or BEA? Should we even be
making specific recommendations here? Perhaps this is best
avoided.
Thanks,
AG
18 years, 5 months
Fedora Core 5 Wishlist
by Thomas Fitzsimmons
Hi,
I tried to send this yesterday but there was a problem with the Fedora
list servers.
Tom
-------- Forwarded Message --------
> From: Thomas Fitzsimmons <fitzsim(a)redhat.com>
> To: fedora-devel-java-list(a)redhat.com
> Subject: Fedora Core 5 Wishlist
> Date: Tue, 13 Sep 2005 21:16:31 -0400
>
> Hi,
>
> I've been thinking about my GCJ-related goals for Fedora Core 5, due out
> February 2006. Here's a categorized list:
>
> java-gcj-compat
> ===============
>
> - GNU Crypto fix for Eclipse extssh support:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146782
>
> Casey Marshall has already committed a Diffie-Hellman JCE provider to
> GNU Classpath so this is just a matter of testing.
>
> - import all JAWT fixes:
>
> All the necessary patches are already in GNU Classpath and libgcj so
> this is just a matter of testing that JOGL works properly on our
> java-1.4.2-gcj-compat RPM.
>
> - Jessie merged into GNU Classpath
>
> - GNU Crypto core algorithms merged into GNU Classpath
>
> - gjdoc merged into GNU Classpath and thus ...
>
> - an --enable-javadocs option to libgcj
>
> - gcjx becomes java-gcj-compat's javac and javah commands:
>
> Not sure if this one is doable in time; I don't mean full gcjx, just
> the bytecode-compiler portion of it split off into a standalone javac
> executable.
>
> - include Tritonus or some sound implementation
>
> AWT
> ===
>
> - ImageMagick backend for ImageIO
>
> - Graphics/Imaging refactoring for GTK 2.8 and Cairo
>
> - MegaMek packages in Fedora Extras:
>
> http://megamek.sourceforge.net/
>
> This just involves a few AWT bug fixes now.
>
> - fix all 1.5 japi issues in the java.awt.* packages
>
> - fix all 1.5 japi issues in the javax.imageio.* packages
>
> Swing
> =====
>
> - RHDB tools in Fedora Extras:
>
> http://sources.redhat.com/rhdb/administrator.html
>
> http://sources.redhat.com/rhdb/visualexplain.html
>
> http://sources.redhat.com/rhdb/controlcenter.html
>
> This will also require updating these tools to support PostgreSQL 8.0.
>
> - Limewire in Fedora Extras:
>
> http://www.limewire.org/
>
> It would be absolutely awesome to have this Swing app working on the
> free stack but I'm not sure it's doable in the FC5 time frame. Would
> anyone like to undertake it? ;-)
>
> SWT
> ===
>
> - Azureus in Fedora Extras:
>
> http://azureus.sourceforge.net/
>
> Again, not sure if this is doable before FC5 but this would be awesome
> to have.
>
> gcjwebplugin
> ============
>
> - implement and test security features in GNU Classpath to allow running
> untrusted bytecode
>
> It's very unlikely that this one will be finished before FC5 but I'd
> like to at least have started the implementation by then.
>
> I'm hoping this list will inspire some volunteers, especially for the
> big apps and GNU Classpath's security framework. Most of these items
> are very doable and will greatly improve the free JPackage stack on
> Fedora.
>
> Tom
>
18 years, 5 months
Native Eclipse 3.1 doesn't start
by Dominik Łeszyk
Hello,
I'm really fresh to java-fedora stuff so maybe it's the reason for my
problem: after compiling Eclipse 3.1 using the script from 'GNU
Classpath Wiki' [1] I can't start it. There is an error log:
!SESSION Tue Sep 13 13:36:30 GMT+02:00 2005
------------------------------------
!ENTRY org.eclipse.core.launcher 4 0 2005-09-13 13:36:30.114
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.ClassNotFoundException:
org.eclipse.core.runtime.adaptor.EclipseStarter not found in
org.eclipse.core.launcher.MainStartupClassLoader{urls=
[file:/home/lechique/eclipse_test/./plugins/org.eclipse.osgi_3.1.0.jar.so], parent=null}
at java.net.URLClassLoader.findClass(java.lang.String)
(/usr/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String, boolean)
(/usr/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String)
(/usr/lib/libgcj.so.6.0.0)
at org.eclipse.core.launcher.Main.invokeFramework(java.lang.String[],
java.net.URL[]) (/home/lechique/eclipse_test/startup.jar.so)
at org.eclipse.core.launcher.Main.basicRun(java.lang.String[])
(/home/lechique/eclipse_test/startup.jar.so)
at org.eclipse.core.launcher.Main.run(java.lang.String[])
(/home/lechique/eclipse_test/startup.jar.so)
at org.eclipse.core.launcher.Main.main(java.lang.String[])
(/home/lechique/eclipse_test/startup.jar.so)
at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
The compilation process went pretty smoothly (without any errors) and
path for db file (gnu.gcj.precompiled.db.path) was set correctly. I
don't understand but it seems that classloader doesn't see original jar
libraries. Am I correct? What should I do?
[1] http://developer.classpath.org/mediation/ClasspathShowcase
Best Regards,
Lechique
Pozdrawia,
Lechique
--
"Mistakes are the portals of discovery"
James Joyce
18 years, 5 months
ecj problem and patch
by Anthony Green
As discussed on #fedora-java IRC (irc.freenode.net), The Eclipse batch
compiler appears to place bootclasspath before classpath, making it
impossible to override classes in libgcj.jar. This is a problem for
jpackages wanting to use xml-commons-apis, which provides an alternate
version of org.w3c.dom.
I produced the following patch, which needs to be applied last in our
set of Eclipse patches.
Another snag I hit was that the FC4 Eclipse SRPM doesn't build anymore,
since the archived make files reference an outdated version of mozilla.
swttmp/build.sh should probably contain something like this instead of
hardcoded values:
GECKO_INCLUDES=`pkg-config mozilla-gtkmozembed --cflags`
GECKO_LIBS='pkg-config mozilla-gtkmozembed --libs`
But I see that patching this isn't simple because build.sh is extracted
from a .zip file at build time. Hopefully overholt has a good idea for
fixing this.
While eclipse didn't build - it did build enough to give me a
jdtcore.jar file I could manually install (after generating
jdtcore.jar.so by hand). My tests of the patched compiler indicate that
this is a step closer to the right solution. Can we get this into FC4
and rawhide?
AG
18 years, 6 months
Latest OO.o requires java-1.4.2-gcj-compat?
by Ian Pilcher
The latest openoffice.org update has brought back this requirement.
Why?
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
18 years, 6 months
Non-native Eclipse 3.1 builds - now what?
by Ian Pilcher
Starting with the Eclipse 3.1 SRPM in Rawhide, I've managed to build
"non-native" packages on Fedora Core 4. I had to work around the
following issues:
* nspr-devel vs. mozilla-nspr-devel: Since nspr-devel (in Rawhide)
provides mozilla-nspr-devel, I changed the BuildRequires to
mozilla-nspr-devel. The location of the header files also changes,
so I modified eclipse-libswt-mozilla.patch to look in both
/usr/include/nspr4 and /usr/include/mozilla-1.7.10/nspr.
* Location of libjawt.so: The SWT build script seems to have the IBM
JDK file layout hardcoded in its build scripts. I've bugzilla'ed
this at https://bugs.eclipse.org/bugs/show_bug.cgi?id=110199. For
now, I'm inclined to simply BuildRequire an IBM JDK for non-native
builds. Any thoughts on exactly what I should require and how I
should set JAVA_HOME would be appreciated.
* Non-native builds are not noarch. I set the ExclusiveArch's for
non-native builds to %{ix86} x86_64 ppc ppc64 ia64, which are the
architectures supported by Eclipse itself.
The real question is what next? It would be nice if the resulting SPEC
file could be used for both Fedora Core (4 and devel) and JPackage. How
should I go about "conditionalizing" things?
Note BTW, that changing the package VERSION to 3.1.0_fc is pretty nasty.
Can this be moved to the RELEASE?
Thanks!
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
18 years, 6 months
Re: [fedora-java] batik [Fwd: Re: com.sun.image.*]
by Brion Vibber
Anthony Green wrote:
> If anybody is interested in running batik on our free stack, here's some
> info on what needs doing...
Has anybody been working on this? We'd be interested in using Batik to
rasterize SVG content for Wikipedia, and as we have a bit of a free
software fetish it would be nice to make sure it can run under GCJ.
(Currently we're using librsvg, which is not totally satisfactory as
there are some things it doesn't render too well.)
If nobody's working on it, I might pick it up sometime in the next while
depending on how hard it looks. :)
-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
> --- Begin Message ---
> From: Thomas DeWeese <Thomas DeWeese Kodak com>
> To: batik-dev xmlgraphics apache org
> Subject: Re: com.sun.image.*
> Date: Wed, 24 Aug 2005 20:05:34 -0400
> Hi Anthony,
>
> Anthony Green wrote:
>
> > batik 1.6 (as packaged by jpackage.org) builds nicely on the Fedora
> > Core 4 Linux distribution with a fully Free and Open Source java stack
> > (gcj, the Eclipse compiler, etc), with the exception of a few classes
> > using com.sun.image.codec.jpeg.*.
> >
> > The com.sun.image.code.jpeg.* classes aren't part of the standard java
> > platform, and there are no Free or Open Source implementations of the
> > classes available for us to use. Can similar functionality be achieved
> > through the use of core classes, like ImageIO?
>
> I would imagine so. There are some potential issues with the
> handling of colorspaces but my understanding is that imageio
> tends to be more complete in general.
>
> > If so, are there any plans for such a migration?
>
> The basic problem is that javax.imageio is only available in
> JDK 1.4 and higher. Currently Batik target's 1.3 and higher.
> However we recently created a source tree for JDK 1.4 specific
> classes (only compiled for JDK 1.4 of course). So it might be
> possible to add to the current support with this.
>
> > Getting batik to build with free software solutions opens the door to
> > including it, and applications that depend on it, in fully free Linux
> > distributions, like Fedora and Debian.
>
> Any help from the these communities would be very welcome!
18 years, 6 months
