> Hey Phil - are there any plans to package the GEF plugin? I'd like to
> use this Eclipse for my project, but it requires GEF.
Not planned for Core, but I think it would be a great candidate for
Extras. The GEF plug-in is already packaged for RHEL, so it would only
be a matter of adding the native smarts to the GEF rpm. We were really
limited by space in what we could put in Core :{
> I looked at how you packaged the CDT plugin but I don't understand how
> you put the source tree together.
The source tree is basically the releng plugin that all eclipse.org
projects provide, with pre-fetched source. So the CDT group provide
their own releng plugin, and we use it. All Eclipse hosted projects use
this approach. You can find details on releng plug-ins here:
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.releng.basebuilder/readme.html?rev=HEAD&content-type=text/html
We have to make some alterations to the assumptions that those releng
plug-ins make (they make the assumption that it is okay to cvs co -r
{tag} the code right at build time - we disagree, due to various
security/code quality/infrastructure issues); they also attempt to
download an upstream Eclipse SDK to build against - again we disagreed
and disabled. These changes are applied as a patch against the
sdk/customTargets.xml, and the platform/customTargets.xml
So basically we pre-fetch the CDT code (in results/) and disable cvs
access in the releng plugin. Then we invoke a headless Eclipse via the
PDE build scripts (See link above) which will compile the code and
deliver a zip or tarball depending on platform.
Next we take that tar ball, extract any jars and build them to .so. We
build a database of each jar (actually classes in each jar) to -> .so
and register them in a database with gcj-dbtool. Then at post, as each
plugin is installed, we merge that plugin database with the main
eclipse.db so the corresponding .so can be loaded for whatever .class is
being executed.
Links to the webcvs version of the CDT releng plugin are here:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-releng/?
cvsroot=Tools_Project
We've been debating this build approach (the pde builds) for awhile. Is
it is good approach? That's up for debate; we've talked about changing
it. Ben Konrath has been experimenting with a different build approach.
Once the dust settles on test 1, this would be a good place to debate
alternate build methods that a) don't stray too far away from the
upstream build process and make it painful to integrate; b) allow
friendlier third party building outside of rpm that does not require a
week's learning about the pde build method.
Regards
Phil
