Community
Participate
Working Groups
As of Mars we no longer support Mac OS X Universal 32-bit. The corresponding build no longer needs to be produced.
Guess we should "aim early" for this to minimize changes of surprising anyone?
Step 1: This commit should prevent from being published on DL page, whether we build it or not ... Effects SDK, Platform, and SWT Jars. (Not, we got rid of the 32 bit version of "Starter Kit" long ago. ... not sure if there is any "32 bit launchers" left on Equinox page?
(In reply to David Williams from comment #2) > Step 1: > > This commit should prevent from being published on DL page, whether we build > it or not ... Effects SDK, Platform, and SWT Jars. (Not, we got rid of the > 32 bit version of "Starter Kit" long ago. ... not sure if there is any "32 > bit launchers" left on Equinox page? Sorry, forgot to paste in the commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=34afc34e8c299590b5bf686318f36b2c2292db5d As for equinox: Did see we are still producing it, as a launcher, and this next commit should suffice to keep it from bing "published" (though, will be be built, on file system, and in p2 repository. So far.
What is it about that final paste? :) Here's the commit to removes if from equinox publishing.
(In reply to David Williams from comment #4) > What is it about that final paste? :) > > Here's the commit to removes if from equinox publishing. Obviously working too late! HERE is the commit to remove it from equinox publishing: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=0979af5baf15b5506b53d4b99294a64e5dd60461
This is the main commit, to remove the platform from the list of "environments" from the maven/Tycho build. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=e09e5a56848127308197c483c3eb324f67211ef2
And this commit removes half a dozen miscellaneious places were referred to this platform ... tests files, etc. (though we've not tested in years). I'm sure we'll find other things to change ... but, believe I can start a test build to make sure we do, at least, still build.
(In reply to David Williams from comment #7) http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=d0064096b0c125af8da6be30143c08f079c0fa49
Thanks Markus. I've also opened bug 443506, since my test build failed on e4.rcp feature, since the fragments it "includes" are no longer built.
John, or Markus (since I think Dani is out) ... Do you think we should 'push ahead with this' for M2? To me, it's pretty important to "do early" (such as M2) but this is our last week, before "stabilization week" and appears there's some work to do to get it removed ... since so far, not one person has applied my suggested patches :) ... but even more, that bug 443538 seems to fail mysteriously .... PLUS ... there might be implications I'm not fully aware of ... such as were/are there any "file system fragments" for this OS? JDT Launcher fragments? I'm sure we could get all that resolved in a few days ... but probably not before the I-build tomorrow morning. If if was up to me alone, I'd say "push ahead" ... but ... not sure what other teams are working on and if they can devote attention to this now ... so, Guidance welcome,
(In reply to David Williams from comment #10) > ... but even more, that bug 443538 seems to fail mysteriously This does seem to have been cause by a simple "typo" in my test environment. Am re-testing now.
FWIW, my local test build works just fine, if the changes in the 3 "depends on" bugs are made.
(In reply to David Williams from comment #12) > FWIW, my local test build works just fine, if the changes in the 3 "depends > on" bugs are made. Even the unit tests passed, on my test machine ... well, as good as they always do ... I always have about 25 errors, for reasons I've not investigated. BTW, the commit in comment 7 and 8 was wrong. I accidentally commented out a copy of the solaris SDK. Rather than simply 'fix', I'd like to revert, and re-do, so the number of commits are kept to a minimum. I think if we decide to not do in M2, I think the commit in comment 6 is the only one that would have to be reverted. That would result it it still being built, but, just not "published" in a visible way (though, would still be in the repository).
(In reply to David Williams from comment #13) > BTW, the commit in comment 7 and 8 was wrong. I accidentally commented out a > copy of the solaris SDK. Rather than simply 'fix', I'd like to revert, and > re-do, so the number of commits are kept to a minimum. The revert commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=36efd6be63d5532a8534b48cc6176755805f5fa8 The corrected commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=284a013c2305736db6597f6971c19ab177666183
(In reply to David Williams from comment #10) Sorry, that was too late for my time zone. I agree that we should go ahead now and I've released the platform.ui fix that made the N-build fail (bug 443506). I've not released the gtk.solaris.x86 removal, since I still found references to that platform, and I'm not sure everything is ready for that.
http://download.eclipse.org/eclipse/downloads/drops4/I20140909-0800/buildFailed-pom-version-updater : [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.jdt.launching.ui.macosx 1.0.300.qualifier requires 'org.eclipse.swt.cocoa.macosx 0.0.0' but it could not be found Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=5d76af1ef68f47b76084ba52b19e42158c86759a
There are quite a few more poms that contain <environment> <os>macosx</os> <ws>cocoa</ws> <arch>x86</arch> </environment> Some (e.g. org.eclipse.e4.ui.workbench.renderers.swt.cocoa) also contain a variant with <arch>x86_64</arch>, but many don't and will probably be the next point of failure.
(In reply to Markus Keller from comment #17) > There are quite a few more poms that contain > <environment> > <os>macosx</os> > <ws>cocoa</ws> > <arch>x86</arch> > </environment> > > Some (e.g. org.eclipse.e4.ui.workbench.renderers.swt.cocoa) also contain a > variant with <arch>x86_64</arch>, but many don't and will probably be the > next point of failure. Yes, you were right. Not sure why these didn't who up in my "test runs" -- too many moving parts, I guess. Can you correct? [ERROR] Cannot resolve project dependencies: [ERROR] Software being installed: org.eclipse.e4.ui.workbench.renderers.swt.cocoa 0.11.200.qualifier [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.e4.ui.workbench.renderers.swt.cocoa 0.11.200.qualifier requires 'org.eclipse.swt.cocoa.macosx 0.0.0' but it could not be found [ERROR] [ERROR] Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.eclipse.e4.ui.workbench.renderers.swt.cocoa 0.11.200.qualifier to org.eclipse.swt.cocoa.macosx 0.0.0.; No solution found because the problem is unsatisfiable.] -> [Help 1] [ERROR] [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
* Necessary changes I found with $grep -r --color=always -C 1 -n "<ws>cocoa</ws>" . eclipse.platform.resources/bundles/org.eclipse.core.filesystem.macosx/pom.xml-38- => filed bug 443611, Daniel R will take care of it eclipse.platform.ui/bundles/org.eclipse.e4.ui.workbench.renderers.swt.cocoa/pom.xml-37- eclipse.platform.ui/bundles/org.eclipse.ui.cocoa/pom.xml-38- rt.equinox.bundles/bundles/org.eclipse.equinox.region.tests/regionTestTarget.target-20- => I'll fix these. * Bundles that should eventually be removed, but that shouldn't be blocking: eclipse.platform.swt.binaries/bundles/org.eclipse.swt.cocoa.macosx/ rt.equinox.framework/bundles/org.eclipse.equinox.launcher.cocoa.macosx/
(In reply to Markus Keller from comment #15) > (In reply to David Williams from comment #10) > Sorry, that was too late for my time zone. I agree that we should go ahead > now and I've released the platform.ui fix that made the N-build fail (bug > 443506). I've not released the gtk.solaris.x86 removal, since I still found > references to that platform, and I'm not sure everything is ready for that. Are you saying we are supposed to remove x86 solaris? I.E. that, that is a plan item too? (I wouldn't be surprised, but just don't recall seeing it).
(In reply to Markus Keller from comment #19) > eclipse.platform.resources/bundles/org.eclipse.core.filesystem.macosx/pom. > xml-38- > => filed bug 443611, Daniel R will take care of it I wrongly thought Daniel was a Resources committer. John A is jumping in. > eclipse.platform.ui/bundles/org.eclipse.e4.ui.workbench.renderers.swt.cocoa/ > pom.xml-37- > eclipse.platform.ui/bundles/org.eclipse.ui.cocoa/pom.xml-38- Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=728dd3fce0b42fef5a863ec1ec6fce91afbeaa33 > rt.equinox.bundles/bundles/org.eclipse.equinox.region.tests/regionTestTarget. > target-20- I don't think this is relevant (tests not run in the build; match in *.target). Fixed anyway with http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=086b332129800ae73fa070b761a6e41bd0bdb188
(In reply to David Williams from comment #20) > Are you saying we are supposed to remove x86 solaris? Nope, *you* were saying that in bug 443506 comment 1 :-) I guess that was a Copy/Paste error... Bug 443611 has been released as well, so we're ready for a rebuild.
Remove Mac 32 bit from org.eclipse.e4.rcp https://git.eclipse.org/r/33126
(In reply to Lars Vogel from comment #23) > Remove Mac 32 bit from org.eclipse.e4.rcp > > https://git.eclipse.org/r/33126 Lars, is this different from bug 443506 and the patch attached there? Or, just an issue with Gerrit catching up with our canonical repo?
(In reply to David Williams from comment #24) > (In reply to Lars Vogel from comment #23) > > Remove Mac 32 bit from org.eclipse.e4.rcp > > > > https://git.eclipse.org/r/33126 > > Lars, is this different from bug 443506 and the patch attached there? > Or, just an issue with Gerrit catching up with our canonical repo? Ah, sorry, didn't see that bug. I applied the patch as it repaired the Gerrit build trigger. Applied with https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=36a46338c0ea76f560d99e0d26f56d777fcbc08e
(In reply to Lars Vogel from comment #23) Thanks, Lars. I accidentally brought that part back when I reverted the removal of the solaris launcher. David, this will probably break the build again.
(In reply to Markus Keller from comment #26) > (In reply to Lars Vogel from comment #23) > Thanks, Lars. I accidentally brought that part back when I reverted the > removal of the solaris launcher. David, this will probably break the build > again. Yes, that's what I'm seeing in my local test build. So ... is the Gerrit patch applied? I'll cancel the ongoing build and start again, if so.
(In reply to David Williams from comment #27) > (In reply to Markus Keller from comment #26) > > (In reply to Lars Vogel from comment #23) > > Thanks, Lars. I accidentally brought that part back when I reverted the > > removal of the solaris launcher. David, this will probably break the build > > again. > > Yes, that's what I'm seeing in my local test build. > > So ... is the Gerrit patch applied? I'll cancel the ongoing build and start > again, if so. Oh, nm, I see it was applied. (Not, leave it there ... :)
(In reply to David Williams from comment #28) > > So ... is the Gerrit patch applied? I'll cancel the ongoing build and start > > again, if so. > > Oh, nm, I see it was applied. (Not, leave it there ... :) Meant "now, leave it there ..." :) :)
Yes, please cancel and restart. With another grep, I saw some more remainders, but these should not break the build: $ grep -r --color=always -C 1 -n "cocoa.x86[^_]" . - some pde.build tests contain strings "eclipse-macosx.cocoa.x86.zip" - the org.eclipse.equinox.executable.feature/resources/build.xml and related .properties files contain e.g. a "rootFilesmacosx_cocoa_x86" target. But those files look defunct, since cocoa_x86_64 is not even called.
(In reply to Markus Keller from comment #30) > Yes, please cancel and restart. > > With another grep, I saw some more remainders, but these should not break > the build: > $ grep -r --color=always -C 1 -n "cocoa.x86[^_]" . > > - some pde.build tests contain strings "eclipse-macosx.cocoa.x86.zip" > - the org.eclipse.equinox.executable.feature/resources/build.xml and related > .properties files contain e.g. a "rootFilesmacosx_cocoa_x86" target. But > those files look defunct, since cocoa_x86_64 is not even called. In case you didn't notice I "just missed" canceling previous build, but my next local build succeeded, so I'm counting this bug fixed. I know bug 443511 was left open to address "minor" cleanup and suggest other bugs be open to address other "cleanup" items as they are found. In my view, it's still fine to list this items as "blocked" by additional work needed, even though marked fixed. Even though not literally blocked, serves a nice role of tracking "everything involved with removing a platform" ... which sure seems more complicated than it should be :) Besides those listed above by Markus, I have a feeling there will still be issues with "download page" (dead link for swt jar) ... but, I think most accurate to mark "fixed" to signify it will be not be in M2. (i.e. no turning back :)
