Community
Participate
Working Groups
These IUs are still missing from the build repo: < org.eclipse.equinox.executable_root.carbon.macosx.ppc < org.eclipse.equinox.executable_root.carbon.macosx.x86 < org.eclipse.equinox.executable_root.cocoa.macosx.ppc < org.eclipse.equinox.executable_root.cocoa.macosx.x86 < org.eclipse.equinox.executable_root.cocoa.macosx.x86_64 < org.eclipse.equinox.executable_root.gtk.aix.ppc < org.eclipse.equinox.executable_root.gtk.aix.ppc64 < org.eclipse.equinox.executable_root.gtk.hpux.ia64_32 < org.eclipse.equinox.executable_root.gtk.linux.ppc < org.eclipse.equinox.executable_root.gtk.linux.ppc64 < org.eclipse.equinox.executable_root.gtk.linux.s390 < org.eclipse.equinox.executable_root.gtk.linux.s390x < org.eclipse.equinox.executable_root.gtk.linux.x86 < org.eclipse.equinox.executable_root.gtk.linux.x86_64 < org.eclipse.equinox.executable_root.gtk.solaris.sparc < org.eclipse.equinox.executable_root.gtk.solaris.x86 < org.eclipse.equinox.executable_root.motif.aix.ppc < org.eclipse.equinox.executable_root.motif.hpux.ia64_32 < org.eclipse.equinox.executable_root.motif.linux.x86 < org.eclipse.equinox.executable_root.motif.solaris.sparc < org.eclipse.equinox.executable_root.win32.win32.ia64 < org.eclipse.equinox.executable_root.win32.win32.x86 < org.eclipse.equinox.executable_root.win32.win32.x86_64 < org.eclipse.equinox.executable_root.wpf.win32.x86 Do we know enough about the build.properties root properties to generate these? PW
Which build.properties provides these IUs?
There's something weird going on here. As part of the build, rt.equinox.framework/bundles/org.eclipse.equinox.executable/target.build.properties is copied over to build.properties, and then that generates the root file? PW
(In reply to comment #2) > There's something weird going on here. As part of the build, > rt.equinox.framework/bundles/org.eclipse.equinox.executable/target.build. > properties is copied over to build.properties, and then that generates the > root file? > > PW I found if I copied the target.build.properties over Tycho will generate the org.eclipse.equinox.executable_* files. I guess we need to understand what the correct procedure is here.
Note that several of these configurations are obsolete and we should just remove them, especially if they cause trouble for CBI. See most recent comments in bug 337334. In particular, Carbon, Motif, WPF, and 32-bit Linux PPC are long dead configurations.
From what I can tell. customBuildCallbacks.xml is used to download binaries from rt.equinox.binaries and then copies target.build.xml and target.build.properties to build.xml and build.properties. The renamed build.xml is then used to copy binaries in a bunch of folders such as "${feature.base}/hpux.gtk.ia64_32/${collectingFolder}". It's unclear to me where "feature.base" and "collectingFolder" comes from. Finally the build.properties defines where all the root files are (/bin and /contributed). If I rename target.build.properties and to build.properties (and overwrite the existing one). With a few modifications to remove some configurations that cannot be found. I'm able to successfully produce the org.eclipse.equinox.executable_root.* Krzysztof provided a patch previously [1] that does the work of customBuildCallbacks.xml (and I guess target.build.properties?) by copying the /bin and /contributed directories from rt.equinox.binaries from the aggregator submodule. Would it be sufficient to add a maven step to overwrite build.properties with target.build.properties? [1] http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.equinox.executable/pom.xml?h=R3_8_maintenance#n300
(In reply to comment #5) > If I rename target.build.properties and to build.properties (and overwrite > the existing one). With a few modifications to remove some configurations > that cannot be found. I'm able to successfully produce the > org.eclipse.equinox.executable_root.* Could you also make sure you remove the platforms John mentions: In particular, Carbon, Motif, WPF, and 32-bit Linux PPC are long dead configurations. > > Krzysztof provided a patch previously [1] that does the work of > customBuildCallbacks.xml (and I guess target.build.properties?) by copying > the /bin and /contributed directories from rt.equinox.binaries from the > aggregator submodule. > > > Would it be sufficient to add a maven step to overwrite build.properties > with target.build.properties? Does Krzysztof's patch do some of the work but not the final target->build.properties step? It sounds fine to me, but will copying it over make it available for when tycho needs it? PW
(In reply to comment #6) > (In reply to comment #5) > > Krzysztof provided a patch previously [1] that does the work of > > customBuildCallbacks.xml (and I guess target.build.properties?) by copying > > the /bin and /contributed directories from rt.equinox.binaries from the > > aggregator submodule. > > > > > > Would it be sufficient to add a maven step to overwrite build.properties > > with target.build.properties? > > Does Krzysztof's patch do some of the work but not the final > target->build.properties step? It sounds fine to me, but will copying it > over make it available for when tycho needs it? I tried adding an ant step to copy target.build.properties over but it seems like Tycho does not pick it up (although it does pick it up on the 2nd run when it's already there) no matter what maven phase I set the copy task to run in. I'm not sure what to try next. Is it possible to merge the 2 build.properties and target.build.properties?
The org.eclipse.equinox.executable feature is unique in that the feature as it is delivered to the user is a "source" feature: it contains a build.properties file. It is a feature that the user will be including in their builds. This means that there are actually 3 forms of this feature: Form 1 The feature as it resides in our source control. Here, the build.properties describes how to build form 2. Here, "target.build.properties" will be renamed so that form 2 has it as "build.properties". The built version of this (form 2) will have p2 group IU id "org.eclipse.equinox.exectuable" instead of the normal "org.eclipse.equinox.executable.feature.group". There is also the IU "org.eclipse.equinox.executable.feature.jar" which is the jar IU containing form 2. This IU does not contribute root files. See the build.properties/p2.group.id property, this is interpreted by PDE/Build's GatherFeatureTask to modify the group IU name. Form 2 The feature as it is after we build form 1, this is delivered to the user and will be a "source" feature that they include in their builds. Here, the build.properties is the file that was originally target.build.properties in form 1. This build.properties list all the root files. Building this results in Form 3, which is basically deployed root files only. There will be p2 IU "org.eclipse.equinox.executable.feature.group" which requires all the root IUs. There is no feature.jar for form 3. Form 3 The result of building form 2. This is the "org.eclipse.equinox.executable.feature.group" IU and the root file IUs. The installed form of this is just root files and no feature on disk. These will be the inputs to the branding iron which results in the final IUs for the User's product. Note that historically p2.publisher has never been capable of properly building either form 1 or form 2 without pde/build being involved. (I don't know if this has changed since I stopped actively working on the project).
Created attachment 223727 [details] equinox-iu.patch If I understood correctly in the end result we need to produce 2 types of packages: org.eclipse.equinox.executable-3.6.0-SNAPSHOT.jar, containing target.build.properties and target.build.xml As well as org.eclipse.equinox.executable_root.configuration-root.zip for each of the platform configurations defined in target.build.properties. The attached patch removes configurations mentioned by John: Carbon, Motif, WPF, and 32-bit Linux PPC. In addition to that I also removed root.qnx.photon.x86=bin/photon/qnx/x86 which also did not seem to exist. It also adds the configurations (modified) from target.build.properties to the regular build.properties so that Tycho will produce the configuration-root packages. The pain point with this patch is there's duplicate configuration in that the root= configurations need to be maintained in both build.properties and target.build.properties. With this patch I was able to produce the following configurations: org.eclipse.equinox.executable-3.6.0-SNAPSHOT.jar org.eclipse.equinox.executable_root.cocoa.macosx.ppc-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.cocoa.macosx.x86-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.cocoa.macosx.x86_64-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.aix.ppc-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.aix.ppc64-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.hpux.ia64_32-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.linux.ppc64-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.linux.s390-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.linux.s390x-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.linux.x86-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.linux.x86_64-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.solaris.sparc-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.gtk.solaris.x86-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.win32.win32.x86-3.6.0.v20120926-2000-root.zip org.eclipse.equinox.executable_root.win32.win32.x86_64-3.6.0.v20120926-2000-root.zip
OK, I've re-read comment #8 and done some more digging. We need to produce 2 separate things: In the first phase, we need to produce a feature IU, but with an ID of org.eclipse.equinox.executable (instead of o.e.e.executable.feature.group) and org.eclipse.equinox.executable.feature.jar. The jar should contain everything, and have target.build.properties copied over build.properties, and should include that build.properties. Same thing for target.build.xml: PDE: bin/ contributed/ feature.properties license.html build.properties eclipse_update_120.jpg feature.xml META-INF/ build.xml epl-v10.html gtk_root/ motif_root/ CBI: bin feature.properties META-INF contributed feature.xml motif_root eclipse_update_120.jpg gtk_root target.build.properties epl-v10.html license.html target.build.xml We currently produce the incorrect IU for the feature.group and we need the target.* to become "real" In the second phase, we need to create the o.e.e.executable.feature.group IU with *no* artifact, but with the root file IUs as well as the requirement on the launcher IUs Thanh, do you know if we have the opportunity to modify the metadata for the feature? Either configuring the p2-metadata goal of tycho-p2-plugin or modifying the p2content.xml before it's consumed by the rest of the tycho build?
(In reply to comment #10) > Thanh, do you know if we have the opportunity to modify the metadata for the > feature? Either configuring the p2-metadata goal of tycho-p2-plugin or > modifying the p2content.xml before it's consumed by the rest of the tycho > build? Unfortunately I'm not familiar with this area, as far as I know I don't think Tycho allows modifying the p2 metadata.
Igor, how many steps are their between when the p2 metadata is generated (I'm assuming it's the p2artifacts.xml and p2content.xml files) and it's consumed by the rest of the system (either within that bundle or in the other bundles) ? If tycho doesn't have hooks to massage the p2 metadata, then in this instance could we either 1) run XSLT on the p2content.xml to make it look like we want or 2) add a goal to maven-cbi-plugin load up the p2content.xml using the existing tycho helpers, fix the content, and re-write it? PW
http://mojo.codehaus.org/xml-maven-plugin/examples/transform-basic.html can run xslt for us PW
Created attachment 224428 [details] p2 artifacts with patch
Created attachment 224429 [details] p2 content with patch
Created attachment 224601 [details] artifacts REPO PDE generates
Created attachment 224602 [details] content REPO PDE generates
(In reply to comment #12) > If tycho doesn't have hooks to massage the p2 metadata p2.inf [1] next to feature.xml should allow for some p2 metadata tweaking [2]. [1] http://wiki.eclipse.org/Equinox/p2/Customizing_Metadata [2] http://wiki.eclipse.org/Tycho/Release_Notes/0.14
(In reply to comment #18) > p2.inf [1] next to feature.xml should allow for some p2 metadata tweaking note bug 395821 though
(In reply to comment #18) > (In reply to comment #12) > > If tycho doesn't have hooks to massage the p2 metadata > > p2.inf [1] next to feature.xml should allow for some p2 metadata tweaking > [2]. I talked to John earlier, and p2.inf (which would allow us to create the new IU) won't allows us to remove requirements or provides (it does additions well), and won't allow us to change the ID of the IU itself. PW
Created attachment 224806 [details] convert p2content.xml This XSL will modify the p2content.xml file to: 1) have the correct o.e.equinox.executable IU with requirements on launchers and root files 2) have an o.e.equinox.executable.feature.group IU with requirements only on the launchers. PW
Created attachment 224809 [details] Update the p2content.xml This runs a transform on the p2content.xml. I'm running a test build to see if it has the desired effect. PW
(In reply to comment #21) > Created attachment 224806 [details] > convert p2content.xml > > This XSL will modify the p2content.xml file to: > An XSL solution sounds like a brilliant quick fix ... but ... I wonder if that's the right "production quality" solution? We've always advised people not to think of the p2 repos as XML files, but to use APIs instead. (The fact and details of the XML being an "implementation detail" subject to change, as well as in general, XSL transforms are notoriously fragile, especially when there is not a schema that defines the XML. I don't mean to pooh pooh your work here, even before you've confirmed it and I'll admit I have just barely glanced at this bug, but thought I'd ask if this XSL is seen as the final solution? Is there a bug open to improve in the builder itself, if that's the right approach?
(In reply to comment #23) > I don't mean to pooh pooh your work here, even before you've confirmed it > and I'll admit I have just barely glanced at this bug, but thought I'd ask > if this XSL is seen as the final solution? Is there a bug open to improve in > the builder itself, if that's the right approach? Oh, this is a hackety-hack-hack. In that respect o.e.equinox.executable is a hack in PDE build (it's run twice, with changed content, partially through both customized and custom build scripts). I wouldn't want this as a final solution, as amusing as it is. The "best" solution that I can think of is to write a maven-cbi-plugin goal that uses the same code as the tycho p2 plugin to load the "local" p2 repo, generate the secondary IU, and then re-write the "local" p2 repo. Then get that plugin/goal to run immediately after the p2-metadata goal, and it would be re-written. But that's not in my current plan. PW
For anyone in the tycho know: It looks like I'm updating that p2content.xml at the correct time, and that's being published as the p2metadata into the local maven repo. But my new IU is not appearing in the eclipse.platform.repository build repo. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.repository/pom.xml?h=R4_2_maintenance Is it because while o.e.equinox.executable.feature.group is probably mentioned from master the new IU is not? Suggestions on how to include that IU? PW
(In reply to comment #8) > Form 2 > The feature as it is after we build form 1, this is delivered to the user and > will be a "source" feature that they include in their builds. What kind of builds are we talking about here? PDE headless builds? In Tycho, we only use the org.eclipse.equinox.executable.feature.group IU. If you should still need to replicate some source artifacts into multiple CBI projects, the right approach would be to use the Maven assembly plugin to package these files ("form 1") and undpack them with the Maven dependency plugin in "form 2" projects.
(In reply to comment #26) > (In reply to comment #8) > > Form 2 > > The feature as it is after we build form 1, this is delivered to the user and > > will be a "source" feature that they include in their builds. > What kind of builds are we talking about here? PDE headless builds? In > Tycho, we only use the org.eclipse.equinox.executable.feature.group IU. Yes, PDE headless builds that use our build repo as input need o.e.equinox.executable IU as well as the o.e.equinox.executable.feature.group. > If you should still need to replicate some source artifacts into multiple > CBI projects, the right approach would be to use the Maven assembly plugin > to package these files ("form 1") and undpack them with the Maven dependency > plugin in "form 2" projects. There are other features (like RCP and Platform I think) where we use relative copy paths where this is probably the pattern we should use. But in this case, the project generates all of the artifacts that we need, we just need an extra IU. PW
(In reply to comment #25) > Is it because while o.e.equinox.executable.feature.group is probably > mentioned from master the new IU is not? Suggestions on how to include that > IU? Can anyone think of a reason why the p2content.xml looks correct, and is published to the local maven repo, but only one of the IUs is picked up by the eclipse-repository task? PW
(In reply to comment #28) > (In reply to comment #25) > > Is it because while o.e.equinox.executable.feature.group is probably > > mentioned from master the new IU is not? Suggestions on how to include that > > IU? > > Can anyone think of a reason why the p2content.xml looks correct, and is > published to the local maven repo, but only one of the IUs is picked up by > the eclipse-repository task? > > PW One guess ... could it be related to the "number of units" attribute? I tried your XSL in my workspace, against the PDE p2 content.xml attached to this bug, and it reproduced everything, and added one additional (duplicate) node: <unit id="org.eclipse.equinox.executable.feature.group" version="3.6.0.v20121119-2010" .... </unit> [So, far is that what you are expecting?] But, I noticed <units> parent still says "17" (though there is now 18, in the new file).
(In reply to comment #29) > One guess ... could it be related to the "number of units" attribute? I > tried your XSL in my workspace, against the PDE p2 content.xml attached to > this bug, and it reproduced everything, and added one additional (duplicate) > node: > > <unit id="org.eclipse.equinox.executable.feature.group" > version="3.6.0.v20121119-2010" > .... > </unit> Yes, it's supposed to duplicate one node and modify the first one to be id="org.eclipse.equinox.executable". > But, I noticed <units> parent still says "17" (though there is now 18, in > the new file). That # is only used to prime the collections used to store elements in p2 AFAIK, it's not a hard or fast limit. PW
(In reply to comment #28) > Can anyone think of a reason why the p2content.xml looks correct, and is > published to the local maven repo, but only one of the IUs is picked up by the > eclipse-repository task? eclipse-repository aggregates from the seed units (i.e. categories and products) published in the module. From these all (strict - if includeAllDependencies=false) dependencies are aggregated.
OK, I thought I could just add a requires from the master feature (because we don't provide that anyway). requires.1.namespace=org.eclipse.equinox.p2.iu requires.1.name=org.eclipse.equinox.executable requires.1.range=[0.0.0,5.0.0] That's definitely making it into the master metadata, but is then failing before it even gets started with: [INFO] Computing target platform for MavenProject: master:master:3.4.0-SNAPSHOT @ /opt/public/eclipse/builds/R4_2_maintenance/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.releng/features/master/pom.xml .... [INFO] Resolving dependencies of MavenProject: master:master:3.4.0-SNAPSHOT @ /opt/public/eclipse/builds/R4_2_maintenance/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.releng/features/master/pom.xml [INFO] Cannot complete the request. Generating details. [INFO] Cannot complete the request. Generating details. [INFO] {osgi.ws=gtk, osgi.os=linux, osgi.arch=x86, org.eclipse.update.install.features=true} [ERROR] Cannot resolve project dependencies: [ERROR] Software being installed: master.feature.group 3.4.0.qualifier [ERROR] Missing requirement: master.feature.group 3.4.0.qualifier requires 'org.eclipse.equinox.executable [0.0.0,5.0.0]' but it could not be found
So the required element is in the master p2content.xml but because o.e.equinox.executable IU doesn't exist yet, it blows up. Maybe I can make it optional? PW
(In reply to comment #33) > > Maybe I can make it optional? Yes. Trying again. PW
requires.1.namespace=org.eclipse.equinox.p2.iu requires.1.name=org.eclipse.equinox.executable requires.1.range=[0.0.0,5.0.0] requires.1.optional=true This allows my build to go forward, and the optional required element is in master and is included when eclipse.platform.repository is generated. But that require isn't enough to include the org.eclipse.equinox.executable IU Suggestion? PW
(In reply to comment #35) > requires.1.namespace=org.eclipse.equinox.p2.iu > requires.1.name=org.eclipse.equinox.executable > requires.1.range=[0.0.0,5.0.0] > requires.1.optional=true > > This allows my build to go forward, and the optional required element is in > master and is included when eclipse.platform.repository is generated. > > But that require isn't enough to include the org.eclipse.equinox.executable > IU > > Suggestion? > > PW greedy=true?
(In reply to comment #36) > > greedy=true? Trying that now. PW
(In reply to comment #37) > (In reply to comment #36) > > > > greedy=true? OK, that didn't work either. The required element is generated for the master.feature.group IU, but the o.e.equinox.executable IU is never included in the eclipse.platform.repository metadata repo. PW
Maybe the transform should be applied in the eclipse-repository after all of the IUs have been collected. See http://stuartsierra.com/maven2/org/apache/hadoop/hadoop-core-with-dependencies/0.18.3/hadoop-core-with-dependencies-0.18.3.pom for how to unjar the content.jar. PW
The change was released into 4.2.2 in 3 commits: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_2_maintenance&id=e4dbf5a5a4ac75b8d0a73b6153b7e4abb6a296a0 http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_2_maintenance&id=ea9efcf590d312f7afac29c24360e44c9f9588f7 http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_2_maintenance&id=6b7dc39b3cb7a59251dfd2cfb55eafbd20177ffb It still needs a step to update or re-create the content.jar in target/repository with the transformed content.xml. This does appear to create the IU we need in the build repo, eclipse.platform.repository module. But I haven't verified that it's correct yet, and the zipped repos we create with the http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/repos?h=R4_2_maintenance repo p2.mirror scripts appear incorrect, see http://download.eclipse.org/eclipse/staging/cbi/drops4/M20121231-0716/ where the org.eclipse.rcp repo is .24 M instead of 48 M (see bug 395506) PW
I guess the second part of this is generating the correct feature.group, and that involves updating the build.properties to look more like the target.build.properties. Two possibilities I can think of: 1) we clone the feature and have the tycho version in a different directory. 2) we make build.properties the target.b.p version, and use a PDE build postFetch step to put it back the way it is now. Any other suggestions? PW
I believe this is "our" bug now, right?
Yes, I think I'll try going forward with my IU XSLT plan. PW
Tom, could you please pull and apply https://github.com/paulweb515/rt.equinox.framework/commit/df1002027eb14ffa25ba24559ef5e5cea3cfffa6 I basically: 1) copied bundles/org.eclipse.equinox.executable to features/org.eclipse.equinox.executable.feature 2) added the expanded root file checks to the main build.properties (from target.build.properties) 3) pointed the module from one to the other This will leave the original untouched and not interfere with current PDE builds, but allow us to move forward and finish this bug. PW
(In reply to comment #44) > Tom, could you please pull and apply > https://github.com/paulweb515/rt.equinox.framework/commit/ > df1002027eb14ffa25ba24559ef5e5cea3cfffa6 > > I basically: > > 1) copied bundles/org.eclipse.equinox.executable to > features/org.eclipse.equinox.executable.feature > > 2) added the expanded root file checks to the main build.properties (from > target.build.properties) > > 3) pointed the module from one to the other > > This will leave the original untouched and not interfere with current PDE > builds, but allow us to move forward and finish this bug. > > PW Done in commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=b22f25b711d260fe88c83d320dde89a9f56db7d6
Paul, can you comment here? I assume all done?
They're currently wrong, this still needs more work. PW
FWIW, the fix for bug 402343 seems to have brought the executable back into my build output.
Paul, I'd like to revisit the necessity of this ... or, understand it in great detail. You've said "its needed for those still using PDE build against our repo" ... but, what breaks for them if we don't provide this? Is this the case where we include "extra" platforms, that not everyone wants, and then in that case, they have to go to extra trouble and specify explicitly which platforms they want (or, don't want)? If that's all it is, then I think that may simply be a new limitation we (and they) would have to live with. I'm asking because I'm just now seeing how convoluted our "repo story" is. We currently build our main repo out of "pieces" of the repos created my Tycho/Maven. Fine. But then we turn around and build "pieces" of our smaller repos out of our main repo instead of using the Tycho/Maven repos directly (e.g. see bug 407130). This seems unsupportable to me. We need a much more modular story for future, and I see this XSL stuff as one of things that will be in the way of that. So, am hoping we can get rid of it.
(In reply to comment #49) > Paul, I'd like to revisit the necessity of this ... or, understand it in > great detail. > > You've said "its needed for those still using PDE build against our repo" > ... but, what breaks for them if we don't provide this? I'm not sure of the "why" the 2 IUs are there, slightly different from each other, except that it's required for certain aspects of PDE Build (related to the launcher and the branding of executables). We're close with the XSL, but we're still not quite there, if my analysis of m5a and m7 is correct. The 3 important elements to compare between the 2 repos are: <unit id="org.eclipse.equinox.executable" <unit id="org.eclipse.equinox.executable.feature.group" <unit id="org.eclipse.equinox.executable.feature.jar" There metadata between m5a and m7 should be comparable, but I'm seeing more requires in m5a on one of the IUs that in m7 PW
(In reply to comment #50) > (In reply to comment #49) > > Paul, I'd like to revisit the necessity of this ... or, understand it in > > great detail. > > > > You've said "its needed for those still using PDE build against our repo" > > ... but, what breaks for them if we don't provide this? > > I'm not sure of the "why" the 2 IUs are there, slightly different from each > other, except that it's required for certain aspects of PDE Build (related > to the launcher and the branding of executables). > Comment #8 above describes the 3 forms of the executable feature. The IU "org.eclipse.equinox.executable" is expected to be form 2. The executable.feature.group, executable.feature.jar, and the _root* IUs are expected to be form 3. Whether a user wants form 2 or form 3 depends on the details of his product build. If the required form is not provided, users' product builds will either fail, or just not have launchers in them. Note that "users' builds" includes exporting from the UI. Perhaps headless releng builds are moving to tycho/maven, but I'm not aware of any replacement for PDE export from the UI.
(In reply to comment #51) > (In reply to comment #50) > > (In reply to comment #49) > Whether a user wants form 2 or form 3 depends on the details of his product > build. > If the required form is not provided, users' product builds will either > fail, or just not have launchers in them. > > Note that "users' builds" includes exporting from the UI. Perhaps headless > releng builds are moving to tycho/maven, but I'm not aware of any > replacement for PDE export from the UI. What does "depends on the details of his product build." mean? You mean there is some choice they make in the UI? Or some combination of things they specify?
Created attachment 230555 [details] org.eclipse.rcp.configuration.feature.group in M6a A related question, does a proper PDE target _need_ org.eclipse.rcp.configuration.feature.group I've ended up deleting our 'feature.group', but it seems related to this issue.
Comment on attachment 230555 [details] org.eclipse.rcp.configuration.feature.group in M6a Mis labeled as from M6, but I mean M5a ... will reattach.
Created attachment 230575 [details] org.eclipse.rcp.configuration.feature.group in M5a version produced by last PDE built milestone
Created attachment 230576 [details] org.eclipse.rcp.configuration.feature.group in M6 version produced by Tycho build in M6
I wanted to attached to the two IUs, org.eclipse.rcp.configuration.feature.group since they are so different ... PDE version "requires" 47 other "IUs" ... the CBI version only 18! I'm trying to get an idea from you experts, Andrew, if this is "critically important" or if this org.eclipse.rcp.configuration.feature.group was always just some "convenience". Also, Paul, as this is produced as a normal part of CBI build, in eclipse.platform.releng.tychoeclipsebuilder/rcp.config this might be a better "spot" for the XSL transforms, etc., so that in theory, we could make sure all repos produced by CBI build "included" it, not just "add it at the end" in the main repo. Doing so would be more likely to produce same results from "plain, local" CBI build, rather than depend on our production scripts. Just an idea.
FWIW, I'm not sure if it is related, but the latest Kepler M7 repo is missing a PDE JUnit Runtime IU that has been available before (bug 407375).
(In reply to comment #57) > I wanted to attached to the two IUs, > org.eclipse.rcp.configuration.feature.group > > since they are so different ... PDE version "requires" 47 other "IUs" ... > the CBI version only 18! > > I'm trying to get an idea from you experts, Andrew, if this is "critically > important" or if this org.eclipse.rcp.configuration.feature.group was always > just some "convenience". > > Also, Paul, as this is produced as a normal part of CBI build, in > eclipse.platform.releng.tychoeclipsebuilder/rcp.config > this might be a better "spot" for the XSL transforms, etc., so that in > theory, we could make sure all repos produced by CBI build "included" it, > not just "add it at the end" in the main repo. Doing so would be more likely > to produce same results from "plain, local" CBI build, rather than depend on > our production scripts. Just an idea. The rcp.config names its one included feature as <feature id="org.eclipse.equinox.executable" /> Should that change now to <feature id="org.eclipse.equinox.executable.feature" /> given the change in comment 44 and comment 45?
Paul, as you finish this work, can I remind you to rejar the content.xml file after the transform. Its for bug 403597.
Could the "nearly correct" version of this be the reason/cause of bug 407588?
Please retarget if still planned for 4.3.
Comparing the o.e.equinox.executable between the last PDE build (M5a) and a current CBI build (ignoring versions and ranges): This shows removals of archs and windowing systems that we no longer support: carbon, cocoa.ppc, motif, wpf, and win32.ia64. And a replacement of hpux.ia64_32 with hpux.ia64. This all seems reasonable. IU o.e.equinox.executable: < required name=org.eclipse.equinox.launcher.win32.win32.ia64 namespace=org.eclipse.equinox.p2.iu IU o.e.equinox.executable.feature.group: < required name=org.eclipse.equinox.executable_root.carbon.macosx.ppc namespace=org.eclipse.equinox.p2.iu < required name=org.eclipse.equinox.executable_root.carbon.macosx.x86 namespace=org.eclipse.equinox.p2.iu < required name=org.eclipse.equinox.executable_root.cocoa.macosx.ppc namespace=org.eclipse.equinox.p2.iu 10426c11409 < required name=org.eclipse.equinox.executable_root.gtk.hpux.ia64_32 namespace=org.eclipse.equinox.p2.iu --- > required name=org.eclipse.equinox.executable_root.gtk.hpux.ia64 namespace=org.eclipse.equinox.p2.iu 10444,10453d11426 < required name=org.eclipse.equinox.executable_root.motif.aix.ppc namespace=org.eclipse.equinox.p2.iu < required name=org.eclipse.equinox.executable_root.motif.hpux.ia64_32 namespace=org.eclipse.equinox.p2.iu < required name=org.eclipse.equinox.executable_root.motif.linux.x86 namespace=org.eclipse.equinox.p2.iu < required name=org.eclipse.equinox.executable_root.motif.solaris.sparc namespace=org.eclipse.equinox.p2.iu < required name=org.eclipse.equinox.executable_root.win32.win32.ia64 namespace=org.eclipse.equinox.p2.iu 10458,10459d11430 < required name=org.eclipse.equinox.executable_root.wpf.win32.x86 namespace=org.eclipse.equinox.p2.iu 10489,10490d11459 < required name=org.eclipse.equinox.launcher.win32.win32.ia64 namespace=org.eclipse.equinox.p2.iu If this is not enough to build with PDE we'll open other bugs for new problems. PW
This was fixed back in M7 and verified now. PW
(In reply to Paul Webster from comment #44) > 1) copied bundles/org.eclipse.equinox.executable to > features/org.eclipse.equinox.executable.feature That was a very bad idea, since it broke all history and makes investigations in an already difficult area even more difficult. Next time, please do it right and use something like git filter-branch --subdirectory-filter ... to keep the history available. The mess with the leftover original sources has eventually been cleaned up with bug 420471 comment 24: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/bundles/org.eclipse.equinox.executable?id=72c26472b6269957b427fbc4b5251d5f3d047745 To show blame annotations for the deleted files, select that commit in the EGit History view, find the (deleted) file in the list, and use context menu > Show Annotations.
(In reply to Markus Keller from comment #65) > > That was a very bad idea, since it broke all history and makes > investigations in an already difficult area even more difficult. OK, I agree we do want to keep history intact for tracing back problem.s > > Next time, please do it right and use something like > git filter-branch --subdirectory-filter ... > to keep the history available. filter-branch would have required everyone to do a reset on origin/master though. Maybe another approach would have been to do a git mv to the new location and then if it was still needed for a little while at the old one, copy it back there. PW
Bummer, I completely missed that this was an easy move inside the same repo. No git magic would have been necessary at all. Just a single commit that contained the copied files at the new location and the file removals. (E)Git is smart enough to find and follow simple file renames/moves. It just can't do that if the copy and remove operations happen in separate commits. The "git filter-branch --subdirectory-filter" solution would have been applicable for moves into another repo. The second step after the filter-branch would have been to merge the filtered repo into the master branch of the target repo. That way, the target repo's history would have stayed untouched and only the copied/moved content would have gotten new commit IDs.
(In reply to Markus Keller from comment #67) > Bummer, I completely missed that this was an easy move inside the same repo. I missed it too, sorry about that. I'll keep my eye out in the future. PW
(In reply to Paul Webster from comment #68) > (In reply to Markus Keller from comment #67) > > Bummer, I completely missed that this was an easy move inside the same repo. > > I missed it too, sorry about that. I'll keep my eye out in the future. > > PW I ended up at this bugzilla because I was trying to get the full history of some of these touched library files. The simple history of the file (e.g. everything in rt.equinox.framework.git/features/org.eclipse.equinox.executable.feature) ends at commit b22f25b71 which is this bug's commit. To help the next person, you can get better history using "git log --follow -C -C -- <file>" on specific files, or similarly for blame "git blame --follow -C -C -- <file>"
