Community
Participate
Working Groups
It seems that windows executables (eclipse.exe and eclipsec.exe) are "copied up" from binary location to "root" of in pom of org.eclipse.equinox.core. Others (I think all others) are copied "up" to root only closer to making products or deltapack, namely the (funky) "configuration feature", in pom of eclipse.platform.releng.tychoeclipsebuilder/rcp.config. Does anyone recall why this is? Seems to me they should all be one place or the other (all in org.eclipse.equinox.core or all in "configuration feature"). At best, this makes the build confusing, or worse, error prone or "hard to change" for one product vs. another.
I believe the history of this issue comes from Bug 380695. It's been awhile but I suspect the reason we added it here was because the build.properties specifies the root files. Unfortunately when it try to check the entire history of build.properties with "gitk build.properties" it simply says that the build.properties included all the root definitions in it's initial commit.
To add to the confusion, this funny "copy up" also occurs in org.eclipse.equinox.starterkit.product.feature again, only for windows. That feature, is used in the EclipseRTOSGiStarterKit.product file, but does seem to "offer much" ... other then these windows executables, and includes these two features: org.eclipse.equinox.p2.core.feature org.eclipse.equinox.core.feature My guess is we could remove the org.eclipse.equinox.starterkit.product.feature and "move up" some of what its doing directly to the EclipseRTOSGiStarterKit.product That feature also "restricts" the target-platform-configuration specifically to these 5 platforms ... which is NOT honored, by the time we make "the product". linux,gtk,x86 linux,gtk,x86_64 win32,win32,x86 win32,win32,x86_64 macosx,cocoa,x86_64 If we really want to restrict to those 5, that should probably go in "the product" pom, as well.
Tom, can you confirm those 5 platforms are the only ones we want to produce this "product" for? I know we currently have mac 32 bit on download page, but that seems useless, these days. I've done some local testing, and by moving stuff "up" to the product definition/build ... and it then does only produce those 5 platforms. By moving stuff around, we can get rid of eclipse.platform.releng.tychoeclipsebuilder/osgistarter.config.launcher and we can get rid of rt.equinox.bundles/features/org.eclipse.equinox.starterkit.product.feature I should note: I'm doing this work on "starter kit", not because it is so important by itself, but it is a smaller example to start with cleaning up some of the "junk" in our build. I am hoping what I learn here, can then be applied elsewhere. If you say "yes", only those 5, I'll attach patches. If we want all platforms, say, 5 on download site, and rest in repository, I'll need to do some more work. I may want to experiment a little more with removing/moving the "copy root" sections of org.eclipse.equinox.core, but otherwise, I think this is the right approach, given history and what we have. -- and getting rid of stuff is always a good idea, if you ask me :) (That is, it's not really contributing anything, except confusion and clutter).
No more work planned for M4.
Sorry for the late response, this one got buried in my inbox. (In reply to David Williams from comment #3) > Tom, can you confirm those 5 platforms are the only ones we want to produce > this "product" for? I know we currently have mac 32 bit on download page, > but that seems useless, these days. I'm fine getting rid of the 32-bit mac version here for the starter kit.
I won't "experiment" during last week of milestone, but do want to improve this early in M6.
I will experiment now, though :) I've committed changes to 'tychobuilder' project to the "starterkit" is built in a much simpler, self contained way. It has worked well on my local test builds, but ... part of change I could make locally was to remove the org.eclipse.equinox.starterkit.product.feature from equinox. I'll attach patch in next comment, for that ... doing a test build now to see if it builds without that patch (removal) ... we do not use it directly, but it is an example of a pom having an "outside of tree" influence, which I've heard is not a good practice in Maven (Actually, I heard it is a bad practice :) -- so best to get rid of the whole thing, even if no immediate negative impact. Here's a small commit in "releng" to no longer "include" that feature in another should-not-be-needed feature (... fixing prototypes never ends :). http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=17a85d926b49e01ac4cc1d39e1153f6bcd2d2716 And here is the big change, to "tycho builder" where we remove the "configuration feature" and just do it all we need to do in product definition. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=8192de903829cd3451637158ff962fa6326898c0 That "product definition" itself and/should move "down" to equinox someday ... when equinox has its own "releng" project (module).
Created attachment 239320 [details] patch to remove starter kit feature module from repo pom So the final clean up (for this starter kit stuff) is in the repository rt.equinox.bundles. 1) in root pom of that repository remove <module>features/org.eclipse.equinox.starterkit.product.feature</module> Making that change, makes the feature "dead code" ... so just as well remove it.
Created attachment 239321 [details] alternative patch to remove modele descriptor, AND the whole module! I'd just get rid of any mention of "starter kit product' in equinox ... and not to worry, you can have it back any time you ready to do you own releng! :) (You know, at a lower "build equinox only" level.
Tom, or other equinox committers, the test build seemed to work fine even with the remaining 'junk' left in rt.equinox.bundles. But if at all possible, please remove the '<module>...' line from repo pom, and even better remove the feature project/module. That will help, by Tuesday's I build, for us to get a "pure" build that can be better tested on Macs and Windows (since those are signed in I-builds. So far, I'm been counting on Linux "working" (where, it does not need to be signed).
The two patches are the same :) but I will use them to remove the whole module.
Fixed in rt.equinox.bundles with commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=3a7f17d65ba4a870db4de35868c7fa92acaa75db
Sorry about selecting the wrong files and thanks for taking the trouble to sort it out. During a test build, I learned (that I had forgotten) that we create the tar for macos in a post-build step (to maintain symbolic link) so for ....macosx-cocoa-x86.tar.gz we basically had an empty tar file. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=c1b99642a3a558c6986d0e99d645b9124988406d We might still get a bad link on DL page ... depends on how smart the "index" custom ant task was made, and haven't had time to track that down. The "template" for DL page is at http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/equinox/publishingFiles/templateFiles/index.php.template and you can see the tell-tale sign of computed starter kits at line 113. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/equinox/publishingFiles/templateFiles/index.php.template#n113 So, at this point, we'll know soon enough if more work is needed there. I'll check after Tuesday's 8 AM I-build.
As feared, the custom ant task that produces ("indexes") the download file is not very smart, so now the Mac 32 bit version is still shown, but gives "NA" for size, and if clicked, it gives an unusual 404 error message, naturally. http://download.eclipse.org/equinox/drops/I20140128-0800/index.php In principle, I don't think we should depend on the custom and task so much, since PHP is perfectly capable of handling cases like this and then all the "logic" is in one place. I've added it in many other part of DL pages. In short, use PHP to as "does this file abc exist", if so { produce the PHP/HTML to display it. ( } {If not, skip it} The following is a "dump" of that the HTML turns out to me ... so its this part (the <td> elemenets) that would have to be (condidtionally) produced by the PHP. <div class="homeitem3col"> <h3><a onclick="expandCollapse('osgistarterkits.bundles');"><img id="osgistarterkits.bundles.button" src="http://eclipse.org/equinox/images/downarrow.png"></a> OSGi starter kits</h3> <p>A useful collection of Equinox bundles packaged as a ready to run system. This include the framework, p2 and other frequently used service implementations. </p> <div id="osgistarterkits.bundles" class=""> <table width="100%" border="0" cellpadding="0" cellspacing="0"> <tbody><tr><td width="5%"></td><td width="78%"></td><td width="9%"></td><td width="8%"></td></tr> <tr><td align="center"><img src="/equinox/images/OK.gif" alt="OK"></td> <td><a href="download.php?dropFile=EclipseRT-OSGi-StarterKit-I20140128-0800-win32-win32-x86.zip">EclipseRT-OSGi-StarterKit-I20140128-0800-win32-win32-x86.zip</a></td> <td>6.3M</td> <td><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-win32-win32-x86.zip.md5"><img src="/equinox/images/md5.png" alt="md5"></a><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-win32-win32-x86.zip.sha1"><img src="/equinox/images/sha1.png" alt="sha1"></a></td> </tr> <tr><td align="center"><img src="/equinox/images/OK.gif" alt="OK"></td> <td><a href="download.php?dropFile=EclipseRT-OSGi-StarterKit-I20140128-0800-win32-win32-x86_64.zip">EclipseRT-OSGi-StarterKit-I20140128-0800-win32-win32-x86_64.zip</a></td> <td>6.3M</td> <td><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-win32-win32-x86_64.zip.md5"><img src="/equinox/images/md5.png" alt="md5"></a><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-win32-win32-x86_64.zip.sha1"><img src="/equinox/images/sha1.png" alt="sha1"></a></td> </tr> <tr><td align="center"><img src="/equinox/images/OK.gif" alt="OK"></td> <td><a href="download.php?dropFile=EclipseRT-OSGi-StarterKit-I20140128-0800-linux-gtk-x86.tar.gz">EclipseRT-OSGi-StarterKit-I20140128-0800-linux-gtk-x86.tar.gz</a></td> <td>6.4M</td> <td><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-linux-gtk-x86.tar.gz.md5"><img src="/equinox/images/md5.png" alt="md5"></a><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-linux-gtk-x86.tar.gz.sha1"><img src="/equinox/images/sha1.png" alt="sha1"></a></td> </tr> <tr><td align="center"><img src="/equinox/images/OK.gif" alt="OK"></td> <td><a href="download.php?dropFile=EclipseRT-OSGi-StarterKit-I20140128-0800-linux-gtk-x86_64.tar.gz">EclipseRT-OSGi-StarterKit-I20140128-0800-linux-gtk-x86_64.tar.gz</a></td> <td>6.4M</td> <td><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-linux-gtk-x86_64.tar.gz.md5"><img src="/equinox/images/md5.png" alt="md5"></a><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-linux-gtk-x86_64.tar.gz.sha1"><img src="/equinox/images/sha1.png" alt="sha1"></a></td> </tr> <tr><td align="center"><img src="/equinox/images/OK.gif" alt="OK"></td> <td><a href="download.php?dropFile=EclipseRT-OSGi-StarterKit-I20140128-0800-macosx-cocoa-x86.tar.gz">EclipseRT-OSGi-StarterKit-I20140128-0800-macosx-cocoa-x86.tar.gz</a></td> <td>N/A</td> <td><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-macosx-cocoa-x86.tar.gz.md5"><img src="/equinox/images/md5.png" alt="md5"></a><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-macosx-cocoa-x86.tar.gz.sha1"><img src="/equinox/images/sha1.png" alt="sha1"></a></td> </tr> <tr><td align="center"><img src="/equinox/images/OK.gif" alt="OK"></td> <td><a href="download.php?dropFile=EclipseRT-OSGi-StarterKit-I20140128-0800-macosx-cocoa-x86_64.tar.gz">EclipseRT-OSGi-StarterKit-I20140128-0800-macosx-cocoa-x86_64.tar.gz</a></td> <td>6.2M</td> <td><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-macosx-cocoa-x86_64.tar.gz.md5"><img src="/equinox/images/md5.png" alt="md5"></a><a href="http://download.eclipse.org/equinox/drops/I20140128-0800/checksum/EclipseRT-OSGi-StarterKit-I20140128-0800-macosx-cocoa-x86_64.tar.gz.sha1"><img src="/equinox/images/sha1.png" alt="sha1"></a></td> </tr> </tbody></table> </div> </div>
And just not to lose track of it, the main purpose of this bug is to clean up the "inconsistent" copying of resources and at least have one way of doing it. So, that'll be important to finish by M6. The hard part of this, is doing it so the "delta pack" is correct, as well as our actual "products".
(In reply to David Williams from comment #14) > As feared, the custom ant task that produces ("indexes") the download file > is not very smart, so now the Mac 32 bit version is still shown, but gives > "NA" for size, and if clicked, it gives an unusual 404 error message, > naturally. > > http://download.eclipse.org/equinox/drops/I20140128-0800/index.php > Actually, I think I found where this can be fixed in "template files". http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=8e49d777e7f4b7d7a5adfba79d988264ebf4d9d6
Created attachment 240295 [details] patch to remove "copy up" items I've done some local builds where I've removed the "copy up" parts of this POM, and all still seemed to work fine. I did move the "copy" part in with the other "copy parts" in the pom of "rcp.config" in "tychobuilder" -- and honestly not even sure it is required there :) [and, should say, "will soon", since just in my local repo so far]. But I think the right approach is to consolidate what ever copying we need, and not have it spread around here and there. I did find it important to remove to "root" statement from build.properties, or Tycho would throw and exception ... "can't change permissions or make symbolic links if file does not exist" and fail to build (not just warning). If you agree, I'd like to make this change after this week's I-build (and, might be more than one, to day :) ... but would be good to "get it done" before M6.
Created attachment 240296 [details] corresponding consolidation patch Just to document it, here's what it looks like where I "consolidate" the "copy-up" to rcp.config. Note I commented out the permissions settings (since others seemed not to have that and seemed to work without it) and I commented out the "overwrite = true" (since none of the others had that and seems to work without it). I don't think these changes need to be perfectly coordinated ... once I change rcp.config, the equinox.core.feature part of that code will probably simply become useless.
(In reply to David Williams from comment #17) > If you agree, I'd like to make this change after this week's I-build (and, > might be more than one, to day :) ... but would be good to "get it done" > before M6. Fine with me. I can release at the end of day, depending on how the I-Build is looking.
(In reply to Thomas Watson from comment #19) > (In reply to David Williams from comment #17) > > If you agree, I'd like to make this change after this week's I-build (and, > > might be more than one, to day :) ... but would be good to "get it done" > > before M6. > > Fine with me. I can release at the end of day, depending on how the I-Build > is looking. BTW, I made my change yesterday, so feel free to change your piece. and close this as fixed (and then help keep an eye open for issues :) Be aware too of bug 429093. The point we want to end up is that all "executables" are in the "executable feature" ... but all other "product resources" are in the "product" section of the build.
(In reply to David Williams from comment #16) > (In reply to David Williams from comment #14) > > As feared, the custom ant task that produces ("indexes") the download file > > is not very smart, so now the Mac 32 bit version is still shown, but gives > > "NA" for size, and if clicked, it gives an unusual 404 error message, > > naturally. > > > > http://download.eclipse.org/equinox/drops/I20140128-0800/index.php > > > > Actually, I think I found where this can be fixed in "template files". > > http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/ > commit/?id=8e49d777e7f4b7d7a5adfba79d988264ebf4d9d6 I verified this change fixed the web page.
(In reply to Thomas Watson from comment #19) > (In reply to David Williams from comment #17) > > If you agree, I'd like to make this change after this week's I-build (and, > > might be more than one, to day :) ... but would be good to "get it done" > > before M6. > > Fine with me. I can release at the end of day, depending on how the I-Build > is looking. Friendly reminder :) [Once done, I think I can "clean up" some of the "product poms" a little more.]
(In reply to David Williams from comment #22) > (In reply to Thomas Watson from comment #19) > > (In reply to David Williams from comment #17) > > > If you agree, I'd like to make this change after this week's I-build (and, > > > might be more than one, to day :) ... but would be good to "get it done" > > > before M6. > > > > Fine with me. I can release at the end of day, depending on how the I-Build > > is looking. > > Friendly reminder :) > [Once done, I think I can "clean up" some of the "product poms" a little > more.] I got this ready to push up to master, but waiting for a good I-Build first.
(In reply to Thomas Watson from comment #23) > (In reply to David Williams from comment #22) > > (In reply to Thomas Watson from comment #19) > > > (In reply to David Williams from comment #17) > > > > If you agree, I'd like to make this change after this week's I-build (and, > > > > might be more than one, to day :) ... but would be good to "get it done" > > > > before M6. > > > > > > Fine with me. I can release at the end of day, depending on how the I-Build > > > is looking. > > > > Friendly reminder :) > > [Once done, I think I can "clean up" some of the "product poms" a little > > more.] > > I got this ready to push up to master, but waiting for a good I-Build first. Finally did this in: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=e311a338e7140795814e95bac36f877a86659c94 David, I will leave to you to close this bug as fixed.
I think we are 90% done here ... but, I would like to investigate a bit more if there is a reason or way we can avoid "copying up" the "eclipsec.exe" for Windows. I think the only reason we do is to "set executable permission" ... and off hand, seems that could be done by the "executable feature" itself, or something -- and, as far as I know, might already be being handled, and there is no reason to "copy up" at all! Plus, there are some issues where for Mac OS only, I think, where we are still getting an extra un-renamed copy of 'launcher' from somewhere ... in addition to the renamed version of it named "eclipse". Plus, the "copy ups" we still have from "swt binaries" needs to be investigated. I'm not so much looking to change that, but currently we do during "validate" phase -- which assumes they are already "done" and ready to copy from the very beginning -- which is true as things are now -- but I think technically should be done during "process-resources" phase, since I believe there is some process/build of natives that can happen in generate-resources phase ... and if not now, there should be :) so best to change to "process-resources" if no negative effects. Plus, in "rcp.config", there is still some "junk" left around that's not used ... and I believe even the "p2.inf" is mis-named for a "feature". (Might have opened another bug, for that, ah ... yes, bug 429418). So will leave open into M7 to finish these investigations.
This overlaps with bug 427428 ... but will investigate "finishing" this work for RC1.
Mass moving 5 releng bugs to RC2 -- will do proper triage tomorrow (5/15).
I'm going to count this as "fixed" for 4.4 RC1 ... in part since bug 407109 was fixed then. While there is still some "clean up" to do, that's mostly related to "configuration feature", and will be tracked in bug 401037 ... I don't think are are any major "inconsistencies" left.
