Bug 521969 - RCP source bundles appear to be missing from the Eclipse PDE
RCP source bundles appear to be missing from the Eclipse PDE
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Overholt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-08 17:32 EDT by Mat Booth
Modified: 2009-10-19 03:57 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-19 03:57:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Target Platform Patch (708 bytes, patch)
2009-09-09 16:40 EDT, Mat Booth
no flags Details | Diff

  None (edit)
Description Mat Booth 2009-09-08 17:32:48 EDT
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?)
Comment 1 Andrew Overholt 2009-09-09 09:01:32 EDT
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.
Comment 2 Andrew Overholt 2009-09-09 09:51:51 EDT
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.
Comment 3 Andrew Overholt 2009-09-09 11:36:55 EDT
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?
Comment 4 Mat Booth 2009-09-09 13:57:01 EDT
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.
Comment 5 Andrew Overholt 2009-09-09 14:42:11 EDT
(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!
Comment 6 Mat Booth 2009-09-09 16:40:32 EDT
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@matbooth.co.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@redhat.com> 1:3.5.0-0.9
 - Remove all testframework sources, patches, build and etc.
Comment 7 Andrew Overholt 2009-09-10 10:12:48 EDT
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.
Comment 8 Mat Booth 2009-09-10 15:44:07 EDT
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.
Comment 9 Andrew Overholt 2009-09-10 15:52:03 EDT
(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.
Comment 10 Mat Booth 2009-09-10 15:58:24 EDT
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...
Comment 11 Andrew Overholt 2009-09-11 10:00:31 EDT
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?
Comment 12 Mat Booth 2009-09-11 10:04:37 EDT
Might as well, if there's nothing more we can do.
Comment 13 Alexander Kurtakov 2009-10-02 02:31:16 EDT
Is this bug fixed ?
Comment 14 Alexander Kurtakov 2009-10-19 03:57:13 EDT
I'm considering this bug fixed and closing.
Please reopen if there are still problems.

Note You need to log in before you can comment on or make changes to this bug.