Bugzilla – Full Text Bug Listing
| Summary: | Provide jdt.annotation.1.1.0 unambiguously | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | VERIFIED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | manoj.palat, srikanth_sankaran |
| Version: | 4.4 | ||
| Target Milestone: | 4.5 M4 | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=449520 | ||
| Whiteboard: | |||
|
Description
Ed Willink
As requested off-line. The lack of versions for import was a major pain during the Luna release cycle since the original Wiki recommendation to use import was totally messed up by the Java 8 distribution. You successfully broke 100% of your users who had followed your advice. Moving to an optional require-bundle resolved most of the issues, but I occasionally get a new nightmare when I accidentally have a non-optional for which IIRC JDT gives a very confusing message about inconsistent Java 8 support when I have no Java 8 anywhere. Clearly non-optional means ignore explicit versions to P2. (This is probably the same bug that inhibits installation of ASM3 from Orbit when ASM5 is already installed.) The new problem affecting my users is that when my user does export plugins to get a distribution, the distribution has the wrong/new JDT annotation plugin. All of this would be solved by eliminating the idiotic needless aspiration that incompatible same-named bundles can co-exist. If I can change all my manifest/build plugin references to org.eclipse.jdt.annotation_7_1.1.0 (still org.eclipse.jdt.annotation in Java source) it will be clear what is required. (In reply to Ed Willink from comment #1) > The lack of versions for import was a major pain during the Luna release > cycle what versions were lacking? > since the original Wiki recommendation to use import The wiki pointed to the help, which described what the quickfix did at each respective release. I *believe* the broken scenario you are referring to is the approach via build.properties # additional.bundles. > was totally messed up by the Java 8 distribution. We admitted to have given advice that was no longer suitable when Java 8 was released. Still there was the reasonable option to fix that approach using an explicit target platform. In my vocabulary "totally messed up" has a different meaning > Moving to an optional require-bundle resolved most of the issues, but I > occasionally get a new nightmare when I accidentally have a non-optional for > which IIRC JDT gives a very confusing message about inconsistent Java 8 > support when I have no Java 8 anywhere. That is too vague for being acted upon. Please describe the exact problem or let's agree this approach is working. > Clearly non-optional means ignore explicit versions to P2. "Clearly"? To whom? You are saying P2 cannot handle legal OSGi situations? Can you please cite the corresponding bug against P2? > The new problem affecting my users is that when my user does export plugins > to get a distribution, the distribution has the wrong/new JDT annotation > plugin. Please provide reproducible steps. As you know well, I'm not the power that decides about bundle names, but for forwarding this request to the JDT leads, this report would need to keep to the facts, and provide a precise description of which exact procedures create wrong results. I am sorry but in the same way that you are frustrated by JDT naming gateways, this has exhausted my patience. I will start shipping org.eclipse.ocl.jdt.annotation. (In reply to Ed Willink from comment #3) "Interesting" interpretation of my comment. Well, with no reproducible problem there's nothing for us to fix. Verified for Eclipse Mars 4.5 M4 using build I20141209-2000 |