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
