Community
Participate
Working Groups
There's been several issues with this "special feature" already (and fixed), but it is still far from correct, so thought I'd open this bug to track work on it specifically, and make "observations" as I go, in case others know more of history or purpose. Its main purpose is to provide some "configuration" data in p2 content meta file, so that as a product is built (for specific platform, etc.) this special IU is required and "fills in" necessary data. It is likely related to a number of other bugs, such as bug 402051, bug 407314, and perhaps even bug 407109 and bug 407433 and bug 394216.
Marking for RC1, since, I think, fixing this is a prereq for fixing many other remaining bugs, but, do not have a clear solution "in hand". First to note that as I commented and attached in bug 394216 comment 57, the PDE version of this IU "requires" 47 other "IUs" ... the CBI version only 18! Another thing to note, in the PDE build, this "rcp.config" project was defined as a "product" that included the _feature_ org.eclipse.equinox.executable. That may have been a feature "created on the fly", since only recently, Paul and Tom made a "real" org.eclipse.equinox.executable feature. See bug 394216 comment 45. If that is the same thing (conceptually) we may want to start "building" the rcp.config.product again (it currently exists in the folder, but is not built or materialized by the pom). Another note, as I mentioned in bug 402051 comment 20, this is where we used to set folder permissions, links, etc., but Tyhco does not support root.*.folders, and while they offer a "work around", not sure we can get that to work in a short time ... but ... seems promising. Last note, in PDE build, we would not "materialize" this feature, it would be only a configuration IU. That worked in PDE because it "knew" if a feature had no bin.includes, it would not actually create the feature. There seems no way to do that, with Tycho. If we remove it "by force" (such as with p2.remove) then in some contexts the "repository" will seem broken, that a required feature is missing ... even though the feature itself is completely void of bundles or other features. Might be easier to "hand write" a huge p2.inf file to provide all the data we want. ? :) One concern I have is that some of the work that used to be done by this "configuration IU" is obviously still getting done, somewhere, somehow, so we might be over-complicating our build by not knowing what central place is the right place or way to accomplish some of these things that this configuration IU used to do for us in PDE build.
Just to document another change I think might be necessary, or, "more correct", it that in our rcp.config pom, there are some places we "copy resources", such as about.html files, etc., during the "validate" phase. This is the very first phase that occurs (at least, in Maven, see http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html) and assumes that everything in "equinox.binaries" is already "perfectly correct". But, there is some processing done in launcher-binary-parent during the process-resources phase. This is a "Tycho phase" and is not well documented then it occurs in relation to Maven phases ... but, it just seems intuitive that our rcp.config processing should match what's done in launcher-binary-parent.
Created attachment 230989 [details] patch to revert previous attempts There's a section on POM that I was initially using to not have to explicitly include "configuration feature" in products (see bug 401037). But, not including it explicitly seemed to break a few subtle things between M6 and M7, such as see bug 407314 bug 407109. Since we are now including it explicitly, I'd like to remove this "workaround". AFAIK, it is interfering with the normal flow of events and still causing problems, such as with bug 402051.
Paul, while this is not a "fix" for this bug, will you still review/comment that you think it's safe. BTW, forgot to mention another section of the configuration was an attempt to "work around" us having packed.gz files in our sliced repos, but since learned that was because of something else (see bug 405808) and fixed in another way. So, again, this patch is just to remove unnecessary things, whose side-effects are not well understood.
(In reply to comment #4) > Paul, while this is not a "fix" for this bug, will you still review/comment > that you think it's safe. Looks safe to me. PW
I'm tempted to close as "won't fix", but will leave open in case it helps searches. But, I've tried everything I know to get this IU to be more like the one from PDE builds, and nothing seems to work or have any effect. If we really need this item to be "just like" it was before ... it may require some plan 'ol Java programming to produce it ... our own custom maven task, or something. Here's a summary: The old PDE one (from 4.3 M5) required about 47 IUs ... of all three "build time IU" varieties, such as org.eclipse.rcp.configuration_root.win32.win32.x86_64 toolingorg.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.launcher.win32.win32.x86 etc. Plus, even though (partially) defined as a feature, there was not actual feature produced, due to PDE knowing not to (for cases where feature.properties had no "bin.includes". I say "partially" since there was also a "product definition" of same name, that is currently basically ignored by Tycho build setup. Not to mention some scripts which used PDE advanced functions to create "container features, etc., in order to produce it. The Tycho one has turned this item into a "mere feature". Its visible in "installed products", and only has "config roots" as required IUs. It requires "the feature", plus about 16 "build time" config root IUs org.eclipse.rcp.configuration_root.cocoa.macosx.x86_64 org.eclipse.rcp.configuration_root.gtk.linux.x86 org.eclipse.rcp.configuration_root.gtk.linux.x86_64 etc. I believe this construct should not be used in the future (or, radically changed) as it is partially what contributes to having a "monolithic build". It seems as currently is, it is merely a convenient place to do some "central" configuration. What is unclear is how its changes will effect those doing product builds from "delta pack" or similar.
I'm going to count this as a "dup" of bug 401037. As far as I know, the "differences" here aren't causing any problems, and once bug 401037 is resolved, we'll consider the whole issue resolved. *** This bug has been marked as a duplicate of bug 401037 ***
