Community
Participate
Working Groups
3.6 RC4+ (). The new support to import from repository does not work for SWT bundles: 1. start new workspace 2. File > Export... > Plug-ins and Fragments 3. select Import As: Projects from a repository 4. click 'Next' ==> SWT bundles are not in the list
I think we need to set a property generateSourceReferences=true in the custom build.xmls for the swt fragments. Andrew, is this correct?
Created attachment 171740 [details] patch Here is a patch that adds the header to the manifest. However, I'm not sure what exactly we want here. For each fragment, the patch adds the corresponding fragment cvs location. However, the fragment projects in CVS don't actually contain source code... The host swt bundle also gets the org.eclipse.swt cvs location, which is where all the source is. Perhaps people just need to import both? Darin, I don't remember, can we put two entries into the manifest header? The fragments could then list both the host (where the source is) and the fragment. Something like: Eclipse-SourceReferences: scm:cvs:pserver:dev.eclipse.org:/cvsroot/eclipse:org.eclipse.swt;tag=v2009, scm:cvs:pserver:dev.eclipse.org:/cvsroot/eclipse:org.eclipse.swt.win32.win32.x86;tag=v2009 The patch does not do this currently, it would be an easy change if both the host and fragment always shared the same qualifier, but if the host and fragment had different qualifiers then the ant scripts would get more complicated.
Bogdan suggests that putting both project cvs locations in the fragments' manifest entries would be a good thing if possible.
We do support multiple entires in the source references header (I am verifying that works). So, the headers to put into the bundle will depend on the desired outcome. I.e. what projects does the user need to have in their workspace in order to do development work on SWT?
Note, you likely need to add ';project=<name>' attributes to the header to get the right projects in the workspace. When missing, the bundle symbolic name is used as the project name, and when > 1 entry is present both would attempt to use the same project name.
Created attachment 171747 [details] patch v2 New patch adds both host and fragment to the header for the fragments. This assumes that both the host and fragment use the same qualifier tag (which Bogdan says is the case) This deserves a test build I think
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
