New Eclipse RPMs

[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:

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

[Ziga Mahkovec]

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:
>  
>  http://people.redhat.com/overholt/eclipse/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

[Andrew Overholt]

* Ziga Mahkovec <ziga.mahkovec(a)klika.si&gt; [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:
>  > 
>  > http://people.redhat.com/overholt/eclipse/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

[Tom Tromey]

> >>>> "Ziga" == Ziga Mahkovec
> <ziga.mahkovec(a)klika.si&gt; 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

[Ziga Mahkovec]

On Thu, 2005-03-17 at 17:26 -0700, Tom Tromey wrote:
>  >>>>> "Ziga" == Ziga Mahkovec
> <ziga.mahkovec(a)klika.si&gt; 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

[Tom Tromey]

> >>>> "Ziga" == Ziga Mahkovec
> <ziga.mahkovec(a)klika.si&gt; 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

[Colin Walters]

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:
>
> http://people.redhat.com/overholt/eclipse/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 :)).

[Andrew Overholt]

* Colin Walters <walters(a)redhat.com&gt; [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:
>  >
>  >http://people.redhat.com/overholt/eclipse/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

[Peter Backlund]

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:
>
> http://people.redhat.com/overholt/eclipse/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

[Anthony Green]

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

[Anthony Green]

On Wed, 2005-03-02 at 09:26 -0800, Anthony Green wrote:
>  [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. 
Bah.  Of course I meant "all of the java programs in Fedora Core".

AG