Description of problem: I have the latest Rawhide eclipse-rcp and eclipse-pde and installed, and when I choose File->New->Target Definition and then select the "Base RCP with Source" template, the target definition editor tells me it cannot find the org.eclipse.rcp.source feature. Version-Release number of selected component (if applicable): eclipse-pde.i686 1:3.5.0-0.9.fc12 eclipse-platform.i686 1:3.5.0-0.9.fc12 eclipse-rcp.i686 1:3.5.0-0.9.fc12 How reproducible: Everytime, follow the steps given above. Expected results: All the source bundles should be built and available somewhere (in the PDE rpm?)
The features are present in the eclipse-pde package but aren't getting picked up by the dropins mechanism. Oddly, I see other .source features in my installed features list.
What's even weirder is that in my latest profile (~/.eclipse/<blah>/p2/org.eclipse.equinox.p2.engine/profileRegistry/PlatformProfile.profile/<highest number>.profile, I see the RCP feature IU listed. I generated p2 metadata for the whole SDK, removed the eclipse-pde RPM and was able to install PDE and the rcp.source feature from the generated repo. I'm going to debug and see what's up with the target definition code.
It appears that this is due to the way target definition was re-worked to use p2. See these upstream bugs: https://bugs.eclipse.org/bugs/show_bug.cgi?id=254623 https://bugs.eclipse.org/bugs/show_bug.cgi?id=232418 I was able to get the rcp.source feature listed by adding it explicitly using /usr/lib/eclipse/dropins/sdk/features as a location. Is this an acceptable workaround for you, Mat?
I see. So I assume they do not put the platform/rcp source bundles in dropins for the upstream distribution, why do we differ in that respect? If it's a ball-ache to move where the RCP Source out of dropins, we should at least patch the template so that it is looking in the correct place... The workaround is fine, thanks for looking into it. Now I know where the source is (${eclipse_home}/dropins/sdk) I can get on with it, but it wasn't obvious to me why it didn't work -- I should have spent more time digging around to see why the source wasn't where PDE expected it to be.
(In reply to comment #4) > So I assume they do not put the platform/rcp source bundles in dropins for the > upstream distribution, why do we differ in that respect? Because we want people to be able to install just the Platform and not the entire SDK (Platform + JDT + PDE + sources). This is for people who want just, say, the CDT. In the past we did weird hacky things like modify config.ini in %post/%postun but it was incredibly flaky. And with p2 that doesn't work anymore :) Dropins, for all its warts, is the easiest solution to merging p2 and RPM. > If it's a ball-ache to move where the RCP Source out of dropins, we should at > least patch the template so that it is looking in the correct place... Would you be able to provide a patch for that? I think it's a reasonable thing to patch. > The workaround is fine, thanks for looking into it. Now I know where the source > is (${eclipse_home}/dropins/sdk) I can get on with it, but it wasn't obvious to > me why it didn't work -- I should have spent more time digging around to see > why the source wasn't where PDE expected it to be. This is a complicated issue. Filing a bug is the best that could be expected of anyone. Thanks for finding it!
Created attachment 360338 [details] Target Platform Patch Sure, I've attached the patch. It's fairly trivial. Because it takes bloody ages to build Eclipse, I've only tried a "make prep" so far to make sure the patch applies cleanly, but I can't image what could go wrong. See below for proposed changes to the spec file (also trivial): Index: eclipse.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse/devel/eclipse.spec,v retrieving revision 1.662 diff -u -r1.662 eclipse.spec --- eclipse.spec 31 Aug 2009 10:43:32 -0000 1.662 +++ eclipse.spec 9 Sep 2009 20:37:02 -0000 @@ -30,7 +30,7 @@ Summary: An open, extensible IDE Name: eclipse Version: %{eclipse_majmin}.%{eclipse_micro} -Release: 0.9%{?dist} +Release: 0.10%{?dist} License: EPL Group: Text Editors/Integrated Development Environments (IDE) URL: http://www.eclipse.org/ @@ -127,6 +127,11 @@ Patch49: %{name}-add-ppc64-filesystem.patch +# Make sure the shipped target platform templates are looking in the correct +# location for source bundles (see RHBZ # 521969). This does not need to go +# upstream. +Patch50: %{name}-target-platform-template.patch + BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: ant BuildRequires: jpackage-utils >= 0:1.5, make, gcc @@ -637,6 +642,9 @@ #%patch48 -p3 #popd +# target platform template patch +%patch50 -p0 + sed -i -e 's|org.eclipse.ecf;bundle-version="1.2.0",|org.eclipse.ecf;bundle-version="[3.0.0,4.0.0)",|' \ -e 's|org.eclipse.ecf.filetransfer;bundle-version="2.0.0",|org.eclipse.ecf.filetransfer;bundle-version="[3.0.0,4.0.0)",|' \ plugins/org.eclipse.equinox.p2.metadata.repository/META-INF/MANIFEST.MF @@ -1405,6 +1413,10 @@ #%{_libdir}/%{name}/configuration/org.eclipse.equinox.source %changelog +* Wed Sep 09 2009 Mat Booth <fedora.uk> 1:3.5.0-0.10 +- Patch the target platform templates so they find all the required source + bundles (see RHBZ # 521969). + * Mon Aug 31 2009 Alexander Kurtakov <akurtako> 1:3.5.0-0.9 - Remove all testframework sources, patches, build and etc.
Thanks for the patch. It looks fine to me. I've applied it and pushed a build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1668179 We can close this when we've verified it fixes the problem.
I tried the i686 packages of that build from Koji and the problem is fixed, but you have to do an "eclipse -clean" before you see it as fixed. I guess it must cache it somewhere.
(In reply to comment #8) > I tried the i686 packages of that build from Koji and the problem is fixed, but > you have to do an "eclipse -clean" before you see it as fixed. I guess it must > cache it somewhere. Ugh. Hopefully only for those that have used it before.
I bet there's no easy way to get Eclipse to clean itself the first time it's used after an update otherwise you'd probably already be doing it. I could put something in the Eclipse beat of the F12 release notes...
You're right about not being able to make it clean after update. I don't think it's worth the release notes as I doubt many people are editing their target definitions. Thanks, though. Should we close this?
Might as well, if there's nothing more we can do.
Is this bug fixed ?
I'm considering this bug fixed and closing. Please reopen if there are still problems.