Hello and SVN subclipse plugin

[Robert Marcano]

Hello everyone on the list.. I have been working on packaging subclipse,
the Eclipse Subversion plugin in order to add it to Fedora Extras.

After learning how to generate RPMs with the correct gcj compiled
libraries, I am nearly ready to finish it, but I am stuck on a problem
(see
http://www.marcanoonline.com/downloads/fedora/package_submissions/subclip...)

The SVNClient class is not found by gij, but when it is ran under Sun
JVM, it is found.

After fixing this. there are only two things remaining, package
ganymed.jar and javasvn.jar as external RPMs and not use the binaries
that are on the subclipse repository (why everyone store binaries on
their repositories.. yuck :-P)

Anyone knows what can be the cause of this problem?. I see that all the
classes and classpath references are ok, even the a process is loading
the correct shared libraries

/usr/lib/gcj/svnClientAdapter/svnClientAdapter-1.0.1.jar.so
/usr/share/java/svnClientAdapter-1.0.1.jar
/usr/lib/libsvnjavahl-1.so.0.0.0
/usr/lib/svn-javahl/svn-javahl.jar

All the packages (SRPMs, RPMS, and spec files) can be downloaded from 

http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse

Thanks in advance
________________________________________
Robert Marcano
マルカノ・ロバート。日本語の学生。

web: http://www.marcanoonline.com/
gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD

[Benjamin Konrath]

Hi Robert, 

On Thu, 2006-04-20 at 16:11 -0400, Robert Marcano wrote:
>  Hello everyone on the list.. I have been working on packaging
> subclipse,
>  the Eclipse Subversion plugin in order to add it to Fedora Extras. 
<snip>

That's great! I was planning to look into packaging subclipse tomorrow,
but it seems you have a head start on me :) 

I don't know off hand why your getting that error, but I do have few
questions about your general build procedure: First, do you have
instructions for generating those source tarballs? Andrew Overholt and I
have been putting instructions for generating these in the comments of
the spec file. We're hoping that we will be able to share these
instructions with other distros and documenting these steps allows
others to reproduce the tarball easily. 

Next, would you consider using the build procedure outlined here?:

https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00...

This would eliminate the need to generate the build.xml's with Eclipse
and then add them in as a patch. For small projects, this is not a big
deal, but it would get annoying for larger features or if you had to do
a lot of packaging. Generating a source tarball would then be a simple
as checking out the correct tag from cvs, deleting any jars and
compressing it up. Long term I'd like to get the upstream projects to
use Eclipse to export source drops that are compatible with this plugin
builder when they spin a release. This would avoid problem with projects
that don't properly tag cvs.

The plugin builder is not quite ready yet. My plan is to fix the last
few problems tomorrow and whip up some test rpms early next week. I'll
probably start with what you posted if that's ok. If you IRC, I hang out
on freenode in #fodora-java and my nick is scsibear.

Anyway, I hope we can work together on getting this into Extras. I know
the there are a lot of people waiting for this plugin to get packaged
up.

Cheers, Ben

[Robert Marcano]

On Thu, 2006-04-20 at 19:16 -0400, Ben Konrath wrote:
>  Hi Robert, 
>  
>  On Thu, 2006-04-20 at 16:11 -0400, Robert Marcano wrote:
>  > Hello everyone on the list.. I have been working on packaging subclipse,
>  > the Eclipse Subversion plugin in order to add it to Fedora Extras.
>  <snip>
>  
>  That's great! I was planning to look into packaging subclipse tomorrow,
>  but it seems you have a head start on me :) 
>  
>  I don't know off hand why your getting that error, but I do have few
>  questions about your general build procedure: First, do you have
>  instructions for generating those source tarballs? Andrew Overholt and I
>  have been putting instructions for generating these in the comments of
>  the spec file. We're hoping that we will be able to share these
>  instructions with other distros and documenting these steps allows
>  others to reproduce the tarball easily.  
I have uploaded two fetch* scripts one to download svnClientAdapter
sources, and the other for subclipse. The scripts also remove a few DLLs
that are on the repository because they will not be needed

http://www.marcanoonline.com/downloads/fedora/package_submissions/subclip...
http://www.marcanoonline.com/downloads/fedora/package_submissions/subclip...

I think that they can be added to the SRPMs as unused sources

>  
>  Next, would you consider using the build procedure outlined here?:
>  
>  https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00... 
no problem... I will try it

>  
>  This would eliminate the need to generate the build.xml's with Eclipse
>  and then add them in as a patch. For small projects, this is not a big
>  deal, but it would get annoying for larger features or if you had to do
>  a lot of packaging. Generating a source tarball would then be a simple
>  as checking out the correct tag from cvs, deleting any jars and
>  compressing it up. Long term I'd like to get the upstream projects to
>  use Eclipse to export source drops that are compatible with this plugin
>  builder when they spin a release. This would avoid problem with projects
>  that don't properly tag cvs.
>  
>  The plugin builder is not quite ready yet. My plan is to fix the last
>  few problems tomorrow and whip up some test rpms early next week. I'll
>  probably start with what you posted if that's ok. If you IRC, I hang out
>  on freenode in #fodora-java and my nick is scsibear. 
mine is robmv

>  
>  Anyway, I hope we can work together on getting this into Extras. I know
>  the there are a lot of people waiting for this plugin to get packaged
>  up.
>  
>  Cheers, Ben
>   
________________________________________
Robert Marcano
マルカノ・ロバート。日本語の学生。

web: http://www.marcanoonline.com/
gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD

[Benjamin Konrath]

Hi Robert, 

I sat down on Friday to fix up the pluginbuilder stuff, but I ended up
not liking that solution too much. One of the biggest problems is that
it's difficult to display build information during the compilation
because Eclipse does the build file generation and the building
internally. Obviously displaying this information is important for rpm
builds - if there were a problem, there would be no way to figure out
what was going on. I could have hacked this in, but I found a different
way to do things which is better because we won't have to maintain the
pluginbuilder plugin.

What I did was create a generic releng plugin that features/plugins can
use to hide the details of the Eclipse releng process. The source
archive should be a tarred up eclipse project checked directly out of
cvs or svn. The source archive could also be a tar.gz or zip exported by
eclipse at the same time the features/plugins are exported as a
deployable plugin or feature. I'm going to write a little doc that
explains how to do this so that we can get upstream people to do this in
the future. One of the subclipse developers saw my previous post and
said he would be interested in helping out.

I updated the subclipse and svn-client-adapter rpms that you posted and
and changed a few things:

http://people.redhat.com/bkonrath/eclipse/

I may have been a little aggressive with the changes, so feel free to
slap me if you don't like anything or if anything is incorrect :)

As far as the actual compilation goes, all you have to do is this:

java -cp %{eclipse_base}/startup.jar \ 
     -Duser.home=$homedir                              \
     org.eclipse.core.launcher.Main                    \
     -application org.eclipse.ant.core.antRunner       \
     -Dtype=feature                                    \
     -Did=org.tigris.subversion.subclipse              \
     -DbaseLocation=%{eclipse_base}                    \
     -Dbuilder=%{_builddir}/package-build              \
     -DsourceDirectory=$(pwd)                          \
     -f %{eclipse_base}/plugins/org.eclipse.pde.build_3.1.2/scripts/build.xml

Just set the type and id, everything else is just template. There's
other templated stuff in there, but I think it's relatively straight
forward. 

It's unfortunate that subclipse is a little complicated because it makes
things look more confusing than they are. Given a source tarball and a
feature id, it's possible to generate a template for these spec files.
I'll probably whip something up when I have some time.

To test this build method, I packaged up PHPeclipse in about 40mins.
Most of the time was spent figuring out how to check out the correct
version of the source. Now that's not say things are perfect, but I
think this method is the best way to proceed. I'm sure there will be
some problems with other plugins, but the pde.build process is very
flexible so I think we'll be able to sort out any problems that arise.

As far the 'SVNClient class not found problem' goes, I noticed that this
only happens when the subversion-javahl rpm is installed. Maybe we can
mark the subversion-javahl rpm as a conflicting package for now and
carry on with getting this into extras. I think subclipse can work
without the javahl jar so we should be ok. If you could file a bug about
this in the redhat bugzilla, that would be great.

Robert, once we put the generic releng scripts in the SDK rpm, would you
be interested in being the subclipse rpm maintainer?

If anybody has any questions or comments about what's going on with
packaging plugins I would be glad to hear them.

Cheers, Ben

[Robert Marcano]

On Thu, 2006-04-27 at 02:15 -0400, Ben Konrath wrote:
>  Hi Robert, 
>  
>  I sat down on Friday to fix up the pluginbuilder stuff, but I ended up
>  not liking that solution too much. One of the biggest problems is that
>  it's difficult to display build information during the compilation
>  because Eclipse does the build file generation and the building
>  internally. Obviously displaying this information is important for rpm
>  builds - if there were a problem, there would be no way to figure out
>  what was going on. I could have hacked this in, but I found a different
>  way to do things which is better because we won't have to maintain the
>  pluginbuilder plugin.
>  
>  What I did was create a generic releng plugin that features/plugins can
>  use to hide the details of the Eclipse releng process. The source
>  archive should be a tarred up eclipse project checked directly out of
>  cvs or svn. The source archive could also be a tar.gz or zip exported by
>  eclipse at the same time the features/plugins are exported as a
>  deployable plugin or feature. I'm going to write a little doc that
>  explains how to do this so that we can get upstream people to do this in
>  the future. One of the subclipse developers saw my previous post and
>  said he would be interested in helping out. 
Nice..

>  
>  I updated the subclipse and svn-client-adapter rpms that you posted and
>  and changed a few things:
>  
>  http://people.redhat.com/bkonrath/eclipse/
>  
>  I may have been a little aggressive with the changes, so feel free to
>  slap me if you don't like anything or if anything is incorrect :) 
no slap for you... the changes are for a better spec file

>  
>  As far as the actual compilation goes, all you have to do is this:
>  
>  java -cp %{eclipse_base}/startup.jar \ 
>       -Duser.home=$homedir                              \
>       org.eclipse.core.launcher.Main                    \
>       -application org.eclipse.ant.core.antRunner       \
>       -Dtype=feature                                    \
>       -Did=org.tigris.subversion.subclipse              \
>       -DbaseLocation=%{eclipse_base}                    \
>       -Dbuilder=%{_builddir}/package-build              \
>       -DsourceDirectory=$(pwd)                          \
>       -f %{eclipse_base}/plugins/org.eclipse.pde.build_3.1.2/scripts/build.xml
>  
>  Just set the type and id, everything else is just template. There's
>  other templated stuff in there, but I think it's relatively straight
>  forward. 
>  
>  It's unfortunate that subclipse is a little complicated because it makes
>  things look more confusing than they are. Given a source tarball and a
>  feature id, it's possible to generate a template for these spec files.
>  I'll probably whip something up when I have some time.
>  
>  To test this build method, I packaged up PHPeclipse in about 40mins.
>  Most of the time was spent figuring out how to check out the correct
>  version of the source. Now that's not say things are perfect, but I
>  think this method is the best way to proceed. I'm sure there will be
>  some problems with other plugins, but the pde.build process is very
>  flexible so I think we'll be able to sort out any problems that arise.
>  
>  As far the 'SVNClient class not found problem' goes, I noticed that this
>  only happens when the subversion-javahl rpm is installed. Maybe we can
>  mark the subversion-javahl rpm as a conflicting package for now and
>  carry on with getting this into extras. I think subclipse can work
>  without the javahl jar so we should be ok. If you could file a bug about
>  this in the redhat bugzilla, that would be great. 
ummm interesting, when subversion-javahl is not installed
SVNClientAdapter reverts to use the JavaSVN version. I think that a
little patch to disable and remove the svnjavahl.jar jar file insode the
plugin can do the trick too

>  
>  Robert, once we put the generic releng scripts in the SDK rpm, would you
>  be interested in being the subclipse rpm maintainer? 
Sure... I will try this changes, complete the TODOs and then submit it
to extras

>  
>  If anybody has any questions or comments about what's going on with
>  packaging plugins I would be glad to hear them.
>  
>  Cheers, Ben
>   
________________________________________
Robert Marcano
マルカノ・ロバート。日本語の学生。

web: http://www.marcanoonline.com/
gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD

[Benjamin Konrath]

On Thu, 2006-04-27 at 08:51 -0400, Robert Marcano wrote:
>  On Thu, 2006-04-27 at 02:15 -0400, Ben Konrath wrote:
>  > The source archive could also be a tar.gz or zip exported by
>  > eclipse at the same time the features/plugins are exported as a
>  > deployable plugin or feature. I'm going to write a little doc that
>  > explains how to do this so that we can get upstream people to do this in
>  > the future. One of the subclipse developers saw my previous post and
>  > said he would be interested in helping out. 
OK, here's the doc:

http://people.redhat.com/bkonrath/eclipse/exporting-buildable-source-arch...

I just posted a message to the subclipse list asking them to provide a
proper source archive and I talked to a phpeclipse developer on irc
today who said that he would provide a source archive too.

>  > I updated the subclipse and svn-client-adapter rpms that you
> posted and
>  > and changed a few things:
>  > 
>  > http://people.redhat.com/bkonrath/eclipse/
>  > 
>  > I may have been a little aggressive with the changes, so feel free to
>  > slap me if you don't like anything or if anything is incorrect :)
>  
>  no slap for you... the changes are for a better spec file 
Phew :) One thing I forgot was to put a 'Provides   eclipse-svn'. Do you
think this is a good idea?

>  ummm interesting, when subversion-javahl is not installed
>  SVNClientAdapter reverts to use the JavaSVN version. I think that a
>  little patch to disable and remove the svnjavahl.jar jar file insode the
>  plugin can do the trick too 
Yeah that would work and it's probably a little better if we're trying
to get this into Extras. BTW, can you put me in the CC field of the
package review request once it gets going? Thanks.

>  > Robert, once we put the generic releng scripts in the SDK rpm,
> would you
>  > be interested in being the subclipse rpm maintainer?
>  
>  Sure... I will try this changes, complete the TODOs and then submit it
>  to extras 
Ok, I'll put this package-build stuff into the main SDK and update the
Eclipse in FC5.

Ben

[Robert Marcano]

On Thu, 2006-04-27 at 22:45 -0400, Ben Konrath wrote:

>  I just posted a message to the subclipse list asking them to provide
> a
>  proper source archive and I talked to a phpeclipse developer on irc
>  today who said that he would provide a source archive too. 
that will be nice, since svnClientAdapter is being marked as version
1.0.1 but this is the version of subclipse, svnClientAdapter is not
correctly tagged on the repository since 0.9.4 and currently the
build.properties says it is 0.9.35, but I do not trust that value

...

>  > ummm interesting, when subversion-javahl is not installed
>  > SVNClientAdapter reverts to use the JavaSVN version. I think that a
>  > little patch to disable and remove the svnjavahl.jar jar file insode the
>  > plugin can do the trick too 
I just finished this part, removing the svnjavahl.jar did not made the
trick work. I needed to patch a few lines of subclipse to set javasvn as
the default SVN interface.

>  
>  Yeah that would work and it's probably a little better if we're trying
>  to get this into Extras. BTW, can you put me in the CC field of the
>  package review request once it gets going? Thanks.
>  
>  > > Robert, once we put the generic releng scripts in the SDK rpm, would you
>  > > be interested in being the subclipse rpm maintainer?
>  > 
>  > Sure... I will try this changes, complete the TODOs and then submit it
>  > to extras
>  
>  Ok, I'll put this package-build stuff into the main SDK and update the
>  Eclipse in FC5.
>  
>  Ben
>  
>   
________________________________________
Robert Marcano
マルカノ・ロバート。日本語の学生。

web: http://www.marcanoonline.com/
gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD

[Andrew Overholt]

Hi Ben,

* Ben Konrath <bkonrath(a)redhat.com&gt; [2006-04-27 02:16]:
>  
>  [...] but I found a different way to do things which is better because we
>  won't have to maintain the pluginbuilder plugin.
>  
>  What I did was create a generic releng plugin that features/plugins can
>  use to hide the details of the Eclipse releng process. 
Nice!  Can you post this?

Andrew

[Benjamin Konrath]

On Thu, 2006-04-27 at 08:52 -0400, Andrew Overholt wrote:
>  Hi Ben,
>  
>  * Ben Konrath <bkonrath(a)redhat.com&gt; [2006-04-27 02:16]:
>  > 
>  > [...] but I found a different way to do things which is better because we
>  > won't have to maintain the pluginbuilder plugin.
>  > 
>  > What I did was create a generic releng plugin that features/plugins can
>  > use to hide the details of the Eclipse releng process.
>  
>  Nice!  Can you post this? 
It's in the subversion srpm in package-build.tar.gz:

http://people.redhat.com/bkonrath/eclipse/subclipse-1.0.1-1.src.rpm

Ben

[Tom Tromey]

> >>>> "Robert" == Robert Marcano
> <robert(a)marcanoonline.com&gt; writes: 
Robert> The SVNClient class is not found by gij, but when it is ran under Sun
Robert> JVM, it is found.

Do you get a stack trace in the .log file (or elsewhere)?
That might help us diagnose the problem.

Tom

[Tom Tromey]

Robert> The SVNClient class is not found by gij, but when it is ran under Sun
Robert> JVM, it is found.

Tom> Do you get a stack trace in the .log file (or elsewhere)?
Tom> That might help us diagnose the problem.

Mark pointed out that you did supply a backtrace and I just didn't
see it there in front of me.  Sorry about that.

This looks strange:

java.lang.ClassNotFoundException: org.tigris.subversion.javahl.SVNClient not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}

... since it doesn't seem like it should be using the system class
loader here.  But sometimes these class-not-found traces are odd.

I guess I would start by trying to see what class loader is really
being used to load this code.  If that is wrong things usually go bad;
then you'd have to track down why that went wrong.

If it is the right loader (and the error message is what is weird)
then the problem may be simpler to track down... bad linking or
something.

Are you BC-compiling this code?  You can try interpreting, sometimes
that makes link problems go away.  In this case there may be some
workarounds...

Tom

[Robert Marcano]

On Fri, 2006-04-21 at 09:20 -0600, Tom Tromey wrote:
>  Robert> The SVNClient class is not found by gij, but when it is
> ran under Sun
>  Robert> JVM, it is found.
>  
>  Tom> Do you get a stack trace in the .log file (or elsewhere)?
>  Tom> That might help us diagnose the problem.
>  
>  Mark pointed out that you did supply a backtrace and I just didn't
>  see it there in front of me.  Sorry about that.
>  
>  This looks strange:
>  
>  java.lang.ClassNotFoundException: org.tigris.subversion.javahl.SVNClient not found in
> gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar],
> parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} 
debugging with (it is an static method)

System.out.println(JhlClientAdapter.class.getClassLoader());

showed:

org.eclipse.core.runtime.adaptor.EclipseClassLoader@2d78620


>  ... since it doesn't seem like it should be using the system
> class
>  loader here.  But sometimes these class-not-found traces are odd.
>  
>  I guess I would start by trying to see what class loader is really
>  being used to load this code.  If that is wrong things usually go bad;
>  then you'd have to track down why that went wrong.
>  
>  If it is the right loader (and the error message is what is weird)
>  then the problem may be simpler to track down... bad linking or
>  something.
>  
>  Are you BC-compiling this code?  You can try interpreting, sometimes
>  that makes link problems go away.  In this case there may be some
>  workarounds... 
I disabled aot-compile-rpm for the svnClientAdapter and subclipse RPMs
in order to run with the interpreter, the same problem

>  
>  
>  Tom
>   
________________________________________
Robert Marcano
マルカノ・ロバート。日本語の学生。

web: http://www.marcanoonline.com/
gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD

[Tom Tromey]

> >>>> "Robert" == Robert Marcano
> <robert(a)marcanoonline.com&gt; writes: 
Robert> debugging with (it is an static method)
Robert> System.out.println(JhlClientAdapter.class.getClassLoader());
Robert> showed:
Robert> org.eclipse.core.runtime.adaptor.EclipseClassLoader@2d78620

Ok.  That looks correct enough.

> From the stack trace: 
java.lang.ClassNotFoundException: org.tigris.subversion.javahl.SVNClient not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
   at java.net.URLClassLoader.findClass (libgcj.so.7)
   at java.lang.ClassLoader.loadClass (libgcj.so.7)
   at java.lang.ClassLoader.loadClass (libgcj.so.7)
   at org.tigris.subversion.svnclientadapter.javahl.JhlClientAdapter.isAvailable
(svnClientAdapter-1.0.1.jar.so)


What does JhlClientAdapter.isAvailable() look like?  On what class
loader is it calling loadClass()?

Robert> I disabled aot-compile-rpm for the svnClientAdapter and subclipse RPMs
Robert> in order to run with the interpreter, the same problem

This rules out most of the linking oddities that might ordinarily
cause problems.  Offhand I don't know what to suggest :-(.  If I were
looking into this I would probably start by 

Tom

[Dimi Paun]

On Tue, 2006-04-25 at 18:55 -0600, Tom Tromey wrote:
>  This rules out most of the linking oddities that might ordinarily
>  cause problems.  Offhand I don't know what to suggest :-(.  If I were
>  looking into this I would probably start by 
>  
>  Tom 
Oh, come on, finish the sentence, the tension is killing us :)

-- 
Dimi Paun <dimi(a)lattica.com&gt;
Lattica, Inc.

[Tom Tromey]

> >>>> "Dimi" == Dimi Paun
> <dimi(a)lattica.com&gt; writes: 
> > This rules out most of the linking oddities that might
> ordinarily
> > cause problems.  Offhand I don't know what to suggest :-(.  If I were
> > looking into this I would probably start by  
Dimi> Oh, come on, finish the sentence, the tension is killing us :)

Oops :-)

I meant to say that I would start by BC-compiling the plugin and
stepping through isAvailable with gdb, to see what goes wrong.  This
is kind of a pain to do, though, since gdb doesn't work so well with
exceptions, and class loading typically throws several during the
normal course of operation.

Tom

[Robert Marcano]

On Tue, 2006-04-25 at 18:55 -0600, Tom Tromey wrote:

>  
>  What does JhlClientAdapter.isAvailable() look like?  On what class
>  loader is it calling loadClass()? 
The isAvailable method is really a ugly

http://subclipse.tigris.org/source/browse/subclipse/tags/subclipse/1.0.1/...

ignoring the Windows part of the code, this method loads the javahl JNI
library. I tried removing it in order to see if the problem is caused by
loading two times the same library (I readed somewhere that one JNI
library can not be loaded by two different classloaders) but this does
not solved the problem

>  
>  Robert> I disabled aot-compile-rpm for the svnClientAdapter and subclipse RPMs
>  Robert> in order to run with the interpreter, the same problem
>  
>  This rules out most of the linking oddities that might ordinarily
>  cause problems.  Offhand I don't know what to suggest :-(.  If I were
>  looking into this I would probably start by  
well, this will take some time for me because i am not an expert
debugging with gdb, but this is an excuse to learn it :-).

>  
>  Tom 
________________________________________
Robert Marcano
マルカノ・ロバート。日本語の学生。

web: http://www.marcanoonline.com/
gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD

[Tom Tromey]

Robert>
http://subclipse.tigris.org/source/browse/subclipse/tags/subclipse/1.0.1/...

Robert> well, this will take some time for me because i am not an expert
Robert> debugging with gdb, but this is an excuse to learn it :-).

Yeah :-)

Looking at the code I think it could be a libgcj runtime linker bug.
It may be trying to load and link SVNClient at class initialization
time -- but that is too early.

Well, this is one theory anyway.  Some of the available evidence
points away from it (the stack trace looks odd).  You could test this
by changing this class to only refer to SVNClient via reflection --
use forName to find the class and then use newInstance to make
instances of it.

Tom

[Benjamin Konrath]

On Mon, 2006-05-01 at 08:53 -0600, Tom Tromey wrote:
>  Well, this is one theory anyway.  Some of the available evidence
>  points away from it (the stack trace looks odd).  You could test this
>  by changing this class to only refer to SVNClient via reflection --
>  use forName to find the class and then use newInstance to make
>  instances of it. 
This is very strange. I poked around a bit this evening but didn't get
anywhere. I was mostly looking through the OSGi class loading stuff
though. You can get more information about what the class loaders are
doing by running eclipse with the attached options file. To use it, run
eclipse like this:

eclipse -consolelog -debug path/to/options.txt

Ben

[Robert Marcano]

Packages has been submitted to review for inclusion in extras with the
javahl interface temporarily disabled

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191014
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191015
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191016
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191017

________________________________________
Robert Marcano
マルカノ・ロバート。日本語の学生。

web: http://www.marcanoonline.com/
gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD