Bugzilla – Full Text Bug Listing
| Summary: | import as source project creates invalid project | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Christian Sell <cse> | ||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | bradleyjames, david_williams, hudsonr, isobe, ppshah | ||||
| Version: | 3.1 | ||||||
| Target Milestone: | 3.1 RC4 | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Christian Sell
a plugin that has no code in it will result in a simple project. No need to subject such a project to a Java builder. What plugin are you referring to? in my case, I was importing org.eclipse.gef.examples.logic, which is a java plugin with lots of code. As I said, I had to manually fix the .project file so that even java search would work. Tried this several times. I had the same issue but it was with the org.eclipse.gef.examples.shapes. I imported org.eclipse.gef and it was fine so I'm curious if it's something just with the GEF example projects or if it effects others as well. This also affects importing the example as binary. What good is an example if it isn't indexed or editable by whoever imported it? Wassim, please investigate and see if there is a containable workaround GEF can do to avoid this bug for 3.1, which would decrease the severity. Randy, I suspect (but haven't verified yet) this is happening because said plugin does not export any of its packages. Would it be acceptable if you exported at least one package in said plugin's manifest.mf and marked it as internal? The current criteria for giving a plugin a Java nature upon import is: 1. it declares one or more libraries OR 2. it exports > 1 package OR 3. it exports >= 1 bundle listed in one of its Require-Bundle header. Case #3 is too restrictive and is causing the problem here. It should be modified to be 3. if the plugin has a Require-Bundle header present, give it a Java nature. The would make sense since Require-Bundle "should" indicate that this plugin requires other plug-ins to compile and hence has Java code. Note that there has been myths/confusions about what Require-Bundle should mean/imply, and it has been clarified recently by Jeff (bug 97383). Another workaround would be to add the header: Bundle-Classpath: . to the manifests of your samples. With this workaround, case #1 in comment 6 will pass and you don't need to touch your exported packages. In other words, and leaf-node plug-in shipped as a JAR is affected? "and" --> "any" Any leaf-node that does not have a Bundle-Classpath header and does not reexport any of its dependencies is susceptible to this, yes. Unfortunately, as annoying as this is and as trivial as the fix is, I cannot sell this as a post-RC4 stop-ship bug, since the workaround in comment 7 is acceptable until 3.1.1 is released. By "hacking" the already built jars in GEF samples I have confirmed the workaround in comment 7 works ... with one important clarification. It should be Bundle-ClassPath: . (capital P in path). I'm surprised its so case sensitive, and the PDE Editor doesn't even give a warning :) So, as an aside, is there any PDE (or runtime?) debug option to turn on that would list warnings in console if bundles contained unrecognized tags? or attributes? And to confirm ... the work-around is bascially the default value for Bundle-ClassPath, right? So it could not effect the PDE generated auto-builds? Sorry for the typo in comment 7. If you had used the Runtime page to add the library, you would have gotten the correct syntax. We don't give a warning on any unrecognized header because you are allowed to have any header you want in the manifest.mf, including 'Bundle-Monkey' :-) We don't flag a missing Bundle-ClassPath header either because plug-ins are not required to have it of course. So the runtime page is certainly highly recommended. >the work-around is bascially the default value for Bundle-ClassPath, right? Correct. To the runtime, the dot is implicit when Bundle-ClassPath is missing. > Unfortunately, as annoying as this is and as trivial as the fix is, I cannot
> sell this as a post-RC4 stop-ship bug, since the workaround in comment 7 is
> acceptable until 3.1.1 is released.
We are also post-RC4. As far as acceptability of the workaround, we'll have
test how it affects our build process.
> And to confirm ... the work-around is bascially the default value for
> Bundle-ClassPath, right? So it could not effect the PDE generated auto-builds?
The src portion of the build is not PDE-genned, right?
Not sure what the question in comment 14 mean exactly, but I presume it is referring to the build.properties etc. In which case, with the 'dot' workaround I am suggesting, your build process and build.properties are unaffected and would remain unchanged. Worth fixing in 3.1. Wassim, can you attatch the patch. Please: 1) Attach a proposed patch 2) Describe a value/risk ratio 3) Are there alternatives to fixing it (readme, workarounds, 3.1.1) Created attachment 24042 [details]
patch
This will take care of all the problems.
a project will be give a Java nature if any of the following conditions are
met:
1. declares >= 1 libraries
2. declares >= 1 dependencies
3. declares >= 1 Import-Package
4. exports >= 1 package.
dejan, we got +1 from KevinH. The patch looks safe and the value is real. +1 *** Bug 101764 has been marked as a duplicate of this bug. *** +1. For the patch. Logic looks good. Code looks good. All SDK plug-ins and examples import without problems. The examples.undo has Java nature added. fixed. I just verified that all gef projects are imported successfully with source and a java nature. Randy, please note that gef.examples.flow and gef.examples.logic, as they appear in the build, are missing a line break at the end of the file. This will cause the JRE parser and consequently PDE, to ignore the last header. Please fix before you ship. EMF had the same problem. Something is happening during the build process. Which files are you referring to in those projects? The manifests? In RC4, the manifest.mf for gef.examples.flow was missing a line break at the end causing the Eclipse-AutoStart header to be ignored by the JRE parser. In 0627, all the gef plug-ins get a clean bill of health. |