Bugzilla – Full Text Bug Listing
| Summary: | [CBI] org.eclipse.rcp.configuration is in CBI builds, but not PDE builds | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Williams <david_williams> | ||||||
| Component: | Releng | Assignee: | David Williams <david_williams> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P2 | CC: | daniel_megert, igor, irbull, pascal.rapicault, pwebster, tjwatson | ||||||
| Version: | 4.2.1 | ||||||||
| Target Milestone: | 4.5 M7 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 459558 | ||||||||
| Bug Blocks: | 434596 | ||||||||
| Attachments: |
|
||||||||
|
Description
David Williams
Pascal, Ian, Tom ... any of you put it back in CBI builder on purpose? But leave it out of PDE builder? I thought this is one of those special build-time features that is used by the PDE build but doesn't actually appear in the output repository as a feature. That might mean it's not needed in CBI build but I'm not certain. See also: http://dev.eclipse.org/mhonarc/lists/cbi-dev/msg00393.html Looking deeper, I think you are right John. Its basically an "empty feature" (has no included or required plugins or features) but the "configuration" looks the same in old and new builders. I know PDE build has a "feature" that it would omit a feature if it had no bin= included in its build.properties (which this one does not). Looks like it is used to include various data and permissions settings in p2 meta data. I'm assuming its still required for that (and not sure what CBI produced repo looks like yet). *** Bug 401791 has been marked as a duplicate of this bug. *** If we can't figure out how to get rid of this empty feature in distributions, we should at least make it a proper feature. Currently shows up with in about fox with keys for name and provider, etc.
featureName 1.0.0.v20130220-1928 org.eclipse.rcp.configuration.feature.group providerName
(In reply to comment #5) > If we can't figure out how to get rid of this empty feature in > distributions, we should at least make it a proper feature. Currently shows > up with in about fox with keys for name and provider, etc. > > featureName 1.0.0.v20130220-1928 > org.eclipse.rcp.configuration.feature.group providerName I'm going to "export" the feature.properties file in the build.properties file; bin.includes = eclipse.platform.releng.tychoeclipsebuilder/rcp.config/feature.properties to see if that improves this "fake feature". Might also fix fix bug 405499 ? (In reply to comment #6) > (In reply to comment #5) > I'm going to "export" the feature.properties file in the build.properties > file; > > bin.includes = > eclipse.platform.releng.tychoeclipsebuilder/rcp.config/feature.properties > This long form is what the build.properties editor inserted, and did not work. (i.e. was not exported with feature.xml). I changed by hand to the usual bin.includes = feature.properties And then it was exported. And, it did at least fix its name and provider name (still no license or copyright, but not sure that matters as much, at least it doesn't look stupid on the very first "about box" screen). > Might also fix fix bug 405499 ? No effect on this bug 405499. I'd still like to "get rid of" this feature ... but that'll take some trial and error. It wasn't easy, but after a few days of trying un-documented (or poorly documented) Tycho/Maven features, was able to get this to work as expected. At least, I think so. :) Have released to build and see what falls out. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=4aa2622011ed90061196ce33c8e3686e34bb23f8 (In reply to comment #8) > It wasn't easy, but after a few days of trying un-documented (or poorly > documented) Tycho/Maven features, was able to get this to work as expected. > > At least, I think so. :) > > Have released to build and see what falls out. > > http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/ > commit/?id=4aa2622011ed90061196ce33c8e3686e34bb23f8 Missed this important part of the change in my first commit, http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=ff2379092b6e851c78c6bcecf8e03cfebd8961a7 Igor, I'm not sure if you (or Paul?) originally wrote this part of the prototype, but if you could sanity check these changes, I'd appreciate it. Originally, the prototype the "products" _included_ the "empty configuration features", just to get the "p2 config data", but I think if we list it as as "extrarequirement" in the POM, the p2.inf files that go with with products are enough to "pull in" the required p2 metadata. Apparently. (That's sort of the way it worked with PDE builds). Adding it to the "main" repository was a bit more of a "leap", for me, but it seems to work just fine, in my local test builds -- my first use of a p2-metadata only repository. Tonight's (Sunday, 8 PM) build will be the first public build its in. If it seems reasonable, no tests break horribly, then Tuesday's I-build would be the best one to compare to the "last known good PDE build". Paul, this might help the issue you are having with bug 394216 ... if not actually solve it. (I've never quite understood what was happening with that bug -- original state vs. what you are accomplishing with XSL -- so I might be off base). If doesn't solve it directly ... perhaps similar techniques would help -- help avoid that XSL stuff :) ? Mostly just FYI for both of you, but comments/feedback welcome. But, I'll be very happy not to have to include an empty feature in our "products". (PS, still some motif type junk being included by equinox executable feature ... not sure why that was never cleaned up?) This change first appeared in M7. Verified in I20130505-2000. I think we will have to live with this for Kepler, due to several of the issues/bugs referenced in bug 407703. It may turn out to simply be required, with Tycho. But, there are complicating factors that suggest we might not ALWAYS have to have it "visible". First complicating factor: the "Reactor Build Order" is largely determined by relationships defined in features and bundle manifests (but "module order") does seem to play a role. In all 48 hours of experimenting for bug 407703, it was very difficult to get this feature built "in the right order" ... for example, some "products" would be built before this feature was. (if feature not included in the product). The second complicating factor, is that this is intended to be "the central place" where many "root" directives are defined and configured, but in digging through the code, they are defined ALL OVER THE PLACE! So, I think, it is hard to know which "takes effect" once the product is built, and the only way to ensure these take priority it to include it as a feature. Given time, we could better investigate and sort through these issues, but ... not during RCs. While I'm still testing, "including" this feature, along with some other tweaks, appears to fix bug 402051, bug 407314, and bug 407109. Before I forget, long term we should probably "move away" from having a "central config" feature, and move much of what is done there, to the "defining feature" of a "product", such as "eclipse.sdk feature", "eclipse.rcp feature", etc. That would seem to help lead to less monolithic builds, as well as git rid of this "empty feature"; but not sure of all implications. David, the bug as described in the summary *is* fixed. Are you planning to unfix it again? (In reply to comment #15) > David, the bug as described in the summary *is* fixed. Are you planning to > unfix it again? Yes, it is unfixed. I had to add back the feature as an explicit "includes" to fix bugs such as bug 407109. ... There might be other ways, but several things about Tycho build is different in this area, and I think for now to have the explicit dependency is best (only?) way to make sure things happen "in the right order", and that right actions occur when they need to. *** Bug 407703 has been marked as a duplicate of this bug. *** (In reply to David Williams from comment #17) > *** Bug 407703 has been marked as a duplicate of this bug. *** Just to emphasize it, this dup bug 407703 contains potentially important information ... just doesn't make sense to leave both open. While I'm at it, want to cross-reference to an old bug: Bug 276125 - Structure configuration metadata for reuse which is "different", but seems closely related. I believe we could almost remove this feature from our "product builds" and they would work fine ... now that bug 407109 was fixed ... EXCEPT we'd also, likely, have to "clean up" and "make consistent" a lot of the p2.inf data in our product definitions -- and its too late in Luna to try that -- AND, I suspect, we still MIGHT need this feature for "delta pack". Note that this is more than a "cosmetic difference" in PDE builds, but I believe this is at the heart of bugs such as to following: Bug 432379 - Eclipse executable delivered two times in SDK Plus, as mentioned in that bug, from looking at the metadata in an installed SDK, we may "install" and "cleanup" a number of (unnecessary) times. Note, I'm marking as a "planned" for Mars ... and once fixed, we may evaluate need and safety of making the fix in SR1 too. I'm going to update this bug, with some history and issues learned while investigating bug 457071. First, it appears some adopters depend on this "feature" in ways we were not aware of. So, can not remove it, unless we have clear "alternative" directions. Second, I emailed Andrew to get any history he knew about, such as "was this intended as "API"? He did point me to bug 276125 (mentioned above) and said he's not sure why it was never closed (but, my guess it the "architects" knew we did not have a "complete story") which is even worse, now, since we've changed builders. But, I think as a "team", we need to decide if we want reusable CUs as part of our deliverables. Some "new news" was a pointer to where "rcp.config" was born: bug 266488 comment 37. Plus, one of Andrew's blog posts, where he explicitly says "not API" (or, not usable by everyone, or something to that effect). See http://aniefer.blogspot.com/2011/01/releng-tricks-from-e4-and-orion.html?showComment=1296768949694#c1387786922184166003 None of this changes what we do for 4.4.2, for bug 457071, but I wanted to be sure not to lose this history, as we decide what to do "for future". One thing I've only recently become aware of, is that our deliverable RCP SDK says "This p2 repository consists of the Eclipse Rich Client Platform base bundles and their source and the RCP delta pack." This adds to the idea not to deliver "delta pack" separately ... but also might serve as a delivery mechanism for "rcp.config", even if we do not use it in our "Platform build", per se. [And, no, I have not thought through pros and cons :) ... just making these notes so I won't forget.] The RCP SDK is basically the "rcp.id" product we deliver to the Simultaneous Release (under "Runtime Targets"). I'm not sure how many people use it, or if it is even documented ... but on the surface, seems like it was intended as "the next generation delta pack" ... to my naive understanding of it. Created attachment 250195 [details] listing of contents of *executable_root* in repo In bug 457071, attachment 250194 [details], I've provided contents of "*configuration_root* for each platform, to show that only 'eclipse' exists there. (in addition to unnecessary legal files). In *this* attachment, I've included contents of *exececutable_roots*, which shows that executables are named 'launcher' (with the one exception of 'eclipsec.exe' for windows). Plus, here in "executables" is the "Info.plist" for Mac's. (But, no icons, etc.). I'll have to read up on original bug better, but think the original thinking behind "configuration units" is that they were literally "touch point actions" only" ... no "artifacts" to re-use, per se. As a reminder, see also bug 457071 comment 19 about only one CU can attach to it's "host" based on "highest matches" ... which explains a lot of the odd naming and levels that we've ended up with ... but is good to know, once we begin to make more uniform and simpler. Created attachment 250196 [details]
zipped up lists of configs and execs from Eclipse 3.7
Just to show "counter example", If I go back to 3.7 it appears both the "executable roots" and the "configuration roots" contain more "content" than they do now ... some *but not all* icons even.
Not sure how/when/why the change too place (if "due to Tycho" only, only something more) ... and, still think it's "up to us" to decide what we want to provide (especially if we don't need it ourselves).
(In reply to David Williams from comment #23) > Created attachment 250196 [details] > zipped up lists of configs and execs from Eclipse 3.7 > > Just to show "counter example", If I go back to 3.7 it appears both the > "executable roots" and the "configuration roots" contain more "content" than > they do now ... some *but not all* icons even. > > Not sure how/when/why the change too place (if "due to Tycho" only, only > something more) ... and, still think it's "up to us" to decide what we want > to provide (especially if we don't need it ourselves). As another point of "reference data" back in 3.7, we had 56 "archive files" in the repo's binary directory. Now in 4.4.2, we have 120! Either number is high enough it demonstrates the complexity of "sorting this out", much less "getting it right". With changes made for bug 462815 (but primarily bug 459558) I'm going to count this as "fixed". Not so much that "things are like they used to be", but I've simply "gotten rid of" the configuration feature in our "products". It is still in our repository, for legacy users, but we ourselves do not make use of it. |