Bugzilla – Full Text Bug Listing
| Summary: | just a few Indigo bundles missing BREEs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> | ||||
| Component: | Cross-Project | Assignee: | David Williams <david_williams> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | minor | ||||||
| Priority: | P3 | CC: | christian.campo, mober.at+eclipse | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 347267, 347268, 347361 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
What's the problem with "non Java Bundle listing a BREE" ? Would you recommend changing these, and why? I am not either….I thought there wasnt anything bad about that practice…but I changed it anyway….:-) (In reply to comment #1) > What's the problem with "non Java Bundle listing a BREE" ? > Would you recommend changing these, and why? Well ... the BREE is meant to specify the minimum required JRE required to run the code ... and if there is no Java code in a bundle (that is, it is "doc" or resource-only) then it will be usable with any JRE, so to specify a BREE is to sort of "overly constrain" that bundle. But, I do not consider that a big problem (would probably not be a problem in practice) but is a "best practice" not to overly constrain a bundle. To be honest, I'm not sure how Eclispe/OSGi will handle these ... such if an "info center" was displaying "help" in a Java 1.5 environment, I am not sure ... would a bundle with at 1.6 BREE not be "resolved" in that environment, and therefore no displayed? Or ... does the help system just "read bundles" whether they "run" or not? All I know is there's no reason to specify it, so its usually recommend not to include it ... but is not worth doing anything risky to fix it, at this late date. Just wondering ... if we get rid of the BREE since there's no Java, perhaps the whole project shouldn't have Java Nature any more? Does it make sense for bundles to have PDE Nature but no Java Nature? While some of these Branding Plugins don't include Java today they could include Java in the future. If I just get rid of the BREE there's perhaps a risk that somebody adds Java down the road and forgets adding a BREE. (In reply to comment #4) I'm not sure there is any clearly correct answer to some of these questions ... and might depend on the development team, experience, point of development cycle, just plain 'ol personal style and preferences ...? But, here's how I'd answer ... > ... if we get rid of the BREE since there's no Java, perhaps the > whole project shouldn't have Java Nature any more? I think that's correct ... not required, might be some small performance benefit. And, in the extreme, imagine if we ever get the "Web and JavaScript and XML" type packages correctly to not include JDT, then I think you'd get log messages if you had a java nature, but no JDT installed? > Does it make sense for > bundles to have PDE Nature but no Java Nature? > Yes, usually. Such as user doc and info pop type bundles still have extensions, such as in plugin.xml, so some PDE functions could still apply. > While some of these Branding Plugins don't include Java today they could > include Java in the future. If I just get rid of the BREE there's perhaps a > risk that somebody adds Java down the road and forgets adding a BREE. Yep. I've heard some developers (in the very distant past) make the same argument about always including a "require bundle" for GEF ... "why not, we know it is always going to be present in our product, and we might need to reference from our code someday". There is a PDE compiler option, I believe it is "invalid environments"?, you can set to flag as "error" if there is a missing BREE. (I don't think it warns about a BREE that is present, but not required ... there, my report gives something extra :) But, I assume this is just a discussion because it is interesting. I'll repeat I don't consider any of these major problems ... in fact, I suspect most are minor ... and would not suggest anyone make any large scale changes this late in dev. cycle to fix these (more risk that its worth). But, it is good to make sure project teams are aware of the concept. For the record, I've opened two bugs for the bundles "from Orbit" that I'm sure will be fixed in the future: bug 347355 google.inject source bundle contains (one) class file bug 347358 a few bundles contain no BREE by RC4, not that many remain ... and a number of those listed are "false alarms", such a source bundle that just happens to have a loose .class file in it.
Java Bundles without a BREE: 10
com.google.inject.source_2.0.0.v201105231817.jar
javax.jws_2.0.0.v201005080400.jar
org.apache.commons.cli_1.2.0.v201105210650.jar
org.apache.commons.io_2.0.1.v201105210651.jar
org.apache.lucene_1.9.1.v201101211617.jar
org.eclipse.emf.doc_2.6.0.v20110606-0949.jar
org.eclipse.epf.common.ui_1.5.0.201105160919.jar
org.eclipse.mtj.example.library.source_1.0.0.201106060709.jar
org.eclipse.nebula.widgets.compositetable_1.0.0.jar
org.eclipse.rap.rwt.source_1.4.0.20110607-1118.jar
Thanks everyone.
> > Well ... the BREE is meant to specify the minimum required JRE required to run > the code ... and if there is no Java code in a bundle (that is, it is "doc" or > resource-only) then it will be usable with any JRE, so to specify a BREE is to > sort of "overly constrain" that bundle. > [...] > To be honest, I'm not sure how Eclispe/OSGi will handle these ... such if an > "info center" was displaying "help" in a Java 1.5 environment ... Given the issues with the graphiti doc mentioned in bug 348355 (see bug 348355#39) I tried testing 1.5 vs. 1.6 with a little "info center" on my local machine. (following directions in Eclipse Help) Sure enough, all else equal, running with a 1.5 jre would not "show" the graphiti doc with a 1.6 bree, but running with a 1.6 jre it would show up fine. So, while usually not a practical problem, this demonstrates that specifying a BREE in a non-java doc bundle constrains that bundle to only certain versions of a JRE, unnecessarily. Just wanted to "firm up" the advise by confirming the effect, since I previously said I wasn't sure. |
Created attachment 196618 [details] missing and distribution of BREEs in Indigo RC2 I do not consider this a major problem ... but ... hope some of these can be corrected before release? And, sorry to say ... some come from Orbit :( Academically, it's interesting to see the distribution of BREEs ... 84 now claim to require Java 1.6 ... will have to look up last years numbers.