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/subclipse/...)
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
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/msg00060...
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
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/subclipse/... http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/...
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/msg00060...
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
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
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
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-archive...
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
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
Hi Ben,
* Ben Konrath bkonrath@redhat.com [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
On Thu, 2006-04-27 at 08:52 -0400, Andrew Overholt wrote:
Hi Ben,
- Ben Konrath bkonrath@redhat.com [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
"Robert" == Robert Marcano robert@marcanoonline.com 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
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
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
"Robert" == Robert Marcano robert@marcanoonline.com 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
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" == Dimi Paun dimi@lattica.com 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
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/svn...
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
Robert> http://subclipse.tigris.org/source/browse/subclipse/tags/subclipse/1.0.1/svn...
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
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
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
java-devel@lists.fedoraproject.org
-
Andrew Overholt -
Benjamin Konrath -
Dimi Paun -
Robert Marcano -
Tom Tromey