Hi,
I'm having some platform and other issues building these in the build system, so in the meantime if anyone wants to try what will become the new 3.1-series RPMs:
http://people.redhat.com/overholt/eclipse/rpms/
The debuginfo package is here:
http://overholt.ca/rpms/eclipse-debuginfo-3.1.0_fc-0.M5.6.i386.rpm
Andrew
On Fri, 2005-02-25 at 11:48 -0500, Andrew Overholt wrote:
I'm having some platform and other issues building these in the build system, so in the meantime if anyone wants to try what will become the new 3.1-series RPMs:
I gave these a spin and they work great. The only problem I had so far was with opening XML files. I attached a sample file (a web application descriptor) which, when opened in Eclipse, produces the attached exception. Any XML file with a DOCTYPE seems to trigger this.
Interestingly, it works fine if I remove the gnu.gcj.precompiled.db.path argument, so this might be an ahead-of-time compilation issue. I wasn't able to isolate a simple test case though.
* Ziga Mahkovec ziga.mahkovec@klika.si [2005-02-26 19:56]:
On Fri, 2005-02-25 at 11:48 -0500, Andrew Overholt wrote:
I'm having some platform and other issues building these in the build system, so in the meantime if anyone wants to try what will become the new 3.1-series RPMs:
I gave these a spin and they work great.
That's great news! Thanks for trying them out.
Interestingly, it works fine if I remove the gnu.gcj.precompiled.db.path argument, so this might be an ahead-of-time compilation issue. I wasn't able to isolate a simple test case though.
Hmm. Interesting. I'll look into it. Can you please file a bug in RH bugzilla?
Thanks,
Andrew
On Fri, 2005-02-25 at 11:48 -0500, Andrew Overholt wrote:
Hi,
I'm having some platform and other issues building these in the build system, so in the meantime if anyone wants to try what will become the new 3.1-series RPMs:
It'd be nice if you could run createrepo in there.
Anyways, I tried the RPMs and they seem to work pretty well (at least "Team Synchronizing" doesn't crash which helps a lot :)).
* Colin Walters walters@redhat.com [2005-02-28 17:54]:
On Fri, 2005-02-25 at 11:48 -0500, Andrew Overholt wrote:
Hi,
I'm having some platform and other issues building these in the build system, so in the meantime if anyone wants to try what will become the new 3.1-series RPMs:
It'd be nice if you could run createrepo in there.
I would, but the platform issues and build system issues are almost resolved so they'll be in rawhide later this week.
Anyways, I tried the RPMs and they seem to work pretty well (at least "Team Synchronizing" doesn't crash which helps a lot :)).
Cool.
Andrew
fre 2005-02-25 klockan 11:48 -0500 skrev Andrew Overholt:
Hi,
I'm having some platform and other issues building these in the build system, so in the meantime if anyone wants to try what will become the new 3.1-series RPMs:
First of all, I just want to say that I've run those rpms too, and they work well. Team Synchronization Perspective now works, which is a big improvment over 3.0.1.
I'd like to know why gij is needed at all, when Eclipse is (supposedly) compiled into a native binary? I noticed that both .jar and .so are shipped with the eclipse-* rpms. Is there a document explaining this strategy anywhere, or could you elaborate a little on this here on the list? I'm guessing it has to do with run-time loading of bytecode plugins?
/Peter Backlund
On Tue, 2005-03-01 at 16:08 +0100, Peter Backlund wrote:
I'd like to know why gij is needed at all, when Eclipse is (supposedly) compiled into a native binary?
gij is just a tiny program that loads the requested class and invokes its main() method. It doesn't have any additional interpreter code above and beyond what's already in libgcj.so.
There are a couple of approaches you can take to building a native executable with gcj.
[1] Link your program together using "gcj --main=foo.bar.MainClass". This pretty much mirrors the C or C++ way of thinking. You end up with an executable whose "main()" is foo.bar.MainClass.main().
[2] Build your classes into .so files and load them on demand. This is what we're doing for Eclipse and (hopefully) all of the java programs in Eclipse. We use the tiny "gij" program to kick things off.
It turns out that it's much simpler to get existing java programs to run using this second approach. For one thing, you can use all of the existing wrapper shell scripts and programs (/usr/bin/eclipse, /usr/bin/ant, etc) instead of having to create/link a new main executable. There are no real downsides to this approach either.
AG
"Ziga" == Ziga Mahkovec ziga.mahkovec@klika.si writes:
Ziga> I gave these a spin and they work great. The only problem I had so far Ziga> was with opening XML files. I attached a sample file (a web application Ziga> descriptor) which, when opened in Eclipse, produces the attached Ziga> exception. Any XML file with a DOCTYPE seems to trigger this.
Ziga> !MESSAGE Unable to initialize editor: org.eclipse.ui.DefaultTextEditor java.net.MalformedURLException: Absolute URL required with null context
I forwarded this to Chris Burdess and he wrote a fix that is in GNU Classpath.
I could send the patch if someone wants to test it. Otherwise it will have to wait until I get my tree back in a sane state so I can try it out.
Tom
On Thu, 2005-03-17 at 17:26 -0700, Tom Tromey wrote:
"Ziga" == Ziga Mahkovec ziga.mahkovec@klika.si writes:
Ziga> I gave these a spin and they work great. The only problem I had so far Ziga> was with opening XML files. I attached a sample file (a web application Ziga> descriptor) which, when opened in Eclipse, produces the attached Ziga> exception. Any XML file with a DOCTYPE seems to trigger this.
Ziga> !MESSAGE Unable to initialize editor: org.eclipse.ui.DefaultTextEditor java.net.MalformedURLException: Absolute URL required with null context
I forwarded this to Chris Burdess and he wrote a fix that is in GNU Classpath.
I could send the patch if someone wants to test it. Otherwise it will have to wait until I get my tree back in a sane state so I can try it out.
I'd be willing to test the patch. Given that this was actually a native compilation issue[1] (it works fine in interpreted mode), does this patch work around a compiler issue?
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149915
"Ziga" == Ziga Mahkovec ziga.mahkovec@klika.si writes:
I could send the patch if someone wants to test it. Otherwise it will have to wait until I get my tree back in a sane state so I can try it out.
Ziga> I'd be willing to test the patch. Given that this was actually a native Ziga> compilation issue[1] (it works fine in interpreted mode), does this Ziga> patch work around a compiler issue? Ziga> [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149915
Thanks for pointing this out. The reason I didn't send the patch is that it is purely on the runtime side, so probably wouldn't have helped.
Tom
java-devel@lists.fedoraproject.org
-
Andrew Overholt -
Anthony Green -
Colin Walters -
Peter Backlund -
Tom Tromey -
Ziga Mahkovec