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
17 years, 11 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
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
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, 1 month
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, 1 month
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, 1 month
eclipse wtp + tomcat5 couldn't work
by Sagi Ye
hello,
Fedora core 4 installed and updated ( by yum )
to the most lated version.
Apache & Tomcat is installed. http://localhost:8080 check is OK.
The eclipse web tool (wtp 0.7) installed via eclipse's
"software updates" feature.
Now I failed to add the Tomcat server to eclipse's reach.
In the "New Server Runtime" dialog, eclipse refused to accept
"/usr/share/tomcat5" as the "Tomcat installation directory" where
I checked do tomcat resides.
I just wondered what are eclipse looking for and how it check for
a valid server runtime. Or could it be cause that the installation
of Tomcat differs in FC4 to other platforms?
--
Sagi Ye <sagi.ye(a)gmail.com>
18 years, 2 months
aot-compile-rpm improvements
by Gary Benson
I made some changes to aot-compile-rpm this past few days, with the
result that it can now cope with jars within jars (required for ears,
rars and some wars), incorrectly named classes (the other wars) and
classes not in jarfiles at all. If your package contains such things
you will find extra solibs and databases being built.
This affects tomcat5 and jonas which I'm now rebuilding. When that's
done they will have natively compiled applications.
Cheers,
Gary
18 years, 2 months
Should non-native Eclipse be noarch?
by Ian Pilcher
I am trying to use the Rawhide SRPM to build non-native Eclipse 3.1
packages for FC4. (I am using the Java 1.5.0 RPMS from JPackage.)
When building with gcj is disabled, this SPEC file sets the BuildArch to
noarch. This causes the build to fail, because eclipse_arch gets set to
i386 instead of ix86.
I'm not sure what the correct fix is. Should a non-native Eclipse build
*really* be noarch? There sure seems to be a lot of platform-specific
stuff in there, and I note that JPackage's Eclipse 3.0.x packages are
i586.
So, I can either:
* Set the BuildArch to i586 for non-native builds, or
* Rework the SPEC file to set eclipse_arch to ix86 for non-native
builds.
Suggestions welcome. Thanks!
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
18 years, 2 months