Community
Participate
Working Groups
I was experimenting ... er, testing .. some EPP Packages, and thought I'd try to "import source" using taking advantage of the Eclipse-Source information. I happened to be using the JavaScript IDE EPP package, from RC2. Had to install PDE to get the functionality. And then, went through the steps to "import", "plugins and fragments", "source from repository", selected all from current target (which was same as current runtime). I checked the box to give me the HEAD version (instead of tagged version). It did fairly well, but eventually hit an error ... displaying this in a dialog The server reported an error while performing the "cvs expand-modules" command. : cvs version: cannot find module `org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.http.jetty6project=org.eclipse.equinox.http.jetty' - ignored Looking at the manifest of org.eclipse.equinox.http.jetty bundle (on file system) sure enough, there is a stray-looking '6' there at the start of manifest continuation line. Makes be wonder if some character got split into its bytes? But, also a project="..." clause I've not seen before. Eclipse-SourceReferences: scm:cvs:pserver:dev.eclipse.org:/cvsroot/rt: org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.http.jetty 6;project="org.eclipse.equinox.http.jetty";tag=v20110502 I suspect (at some level) this is a "PDE Build" problem ... but, thought I'd start off here at the home of the bundle in case this bundle is special, for some reason, and maybe you'd recognize something. One of the aspect that makes this a bad problem, is that the import stopped there, on that one. I got 38 imported ... with 326 in the file system of the installation (in the "plugins" directory). I tried again, selecting all except that one "bad one", and that time, the rest of them went to completion. There were only 254 imported ... guess its not 325 since not all the bundles provide Eclipse-Sources directive. HTH
Well ... guess the '6' is not stray, after all. Looking in map files from a recent build, it is part of the module name: plugin@org.eclipse.equinox.http.jetty,2.0.0=v20110502,kmoir@dev.eclipse.org:/cvsroot/rt,,org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.http.jetty6 Looks like the manifest is probably correct, but the fetch factory drops the semicolon? ...http.jetty6project=org.ec... instead of ...http.jetty6;project=org.ec... not sure if it is related to the numeral, or not.
Moving to PDE build
And now moving to "Team" ... this is in the cvs import part of the code. I've confirmed that it only happens if "HEAD" is selected. If "Current version" is selected it works fine. I've stepped through the code, and basically there's a "removeTag" routine that not only removes tags and versions attributes, but also removes semicolons, so the end of the module name and the word "project" get no delimiter. This is in CVSScmUrlImportWizardPage. A URL such as scm:cvs:pserver:dev.eclipse.org:/cvsroot/rt:org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.http.jetty6;tag="v20110502";project="org.eclipse.equinox.http.jetty" gets passed into removeTag(URI scmUri) ... and, bascially, all semicolons removed (as well as "tag=...". I tried just adding in the semicolon, if there were trailing properties to keep, such as at line 234 sb.append(";" + params[k]); But then somehow ended up with TWO semicolens! So ... will have to look at again when I'm awake :)
Created attachment 196788 [details] patch to maintain semicolons Patch against head. The reason why just blindly adding a semicolon resulted in two semicolons being added, was that the string split tokenizer can (and was) returning am empty string as one of its results (I guess from initial semicolon), so those were always being (unnecessarily) appended to the string buffer ... which of course are normally never noticed ... but are when another character (the semicolon) was added a long with it. So, the cure for that is just to make sure the parameters length is greater than zero before appending it.
Created attachment 196823 [details] zip containing lists of bundles and values for Eclipse-SourceReferences I wrote a little utility to scan repository jars, parse out the "Eclipse-SourceReferences" from MANIFEST.MF files, to see if this "project=" issue was wide spread. I learned two things: 1. The use of Eclipse-SourceReferences is disappointingly low (less that 20%). 2. Of those that use Eclipse-SourceReferences (about 750 bundles out of 4250) only a small number contain the "project=" tag (14 bundles do). Additionally, of those 14, most of those come from Orbit, for which "get from HEAD" doesn't do any practical good anyway. So ... I think should be fixed (such as in maintenance release?) to avoid incomplete operation of long list of imports ... but, can't say its a huge problem. Bundles not using Eclipse-SourceReferences at all is a bigger problem. :(
(In reply to comment #5) > 1. The use of Eclipse-SourceReferences is disappointingly low (less that 20%). > while totally off topic to this bug, David, is there nothing we can do about this? AFAIK it's just setting the property: "generateSourceReferences=true" and it's the one of the most useful things for eclipse plugin developers, especially for contributing small patches to other projects. Maybe a plea to cross-projects? PW
There are several issues reported in this bug which should be split into separate ones: - wrong parsing - aborting when a failure is hit instead of continuing and then report all issues - not reporting bundles that have no source info
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. -- The automated Eclipse Genie.
This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
