3:11 p.m.
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
6:16 p.m.
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
7:54 a.m.
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
10:20 a.m.
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
10:54 a.m.
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
7:55 p.m.
>>>> "Robert" == Robert Marcano
<robert(a)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
10:36 p.m.
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>
Lattica, Inc.
10:13 a.m.
>>>> "Dimi" == Dimi Paun
<dimi(a)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
1:15 a.m.
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
7:33 a.m.
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
7:51 a.m.
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
7:52 a.m.
Hi Ben,
* Ben Konrath <bkonrath(a)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
10:21 a.m.
On Thu, 2006-04-27 at 08:52 -0400, Andrew Overholt wrote:
Hi Ben,
* Ben Konrath <bkonrath(a)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
9:45 p.m.
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
10:57 p.m.
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
9:53 a.m.
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
12:32 a.m.
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
11:01 p.m.
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
6561
days inactive
6579
days old
java-devel@lists.fedoraproject.org
18 comments
5 participants
participants (5)
-
Andrew Overholt -
Benjamin Konrath -
Dimi Paun -
Robert Marcano -
Tom Tromey