Community
Participate
Working Groups
Just like we did for Java 8 work, we need to be able to produce builds from the BETA_JAVA9 branch. The requirements being: Goals: 1. Get SDK builds to self-host for our own builds 2. Be prepared to build our Java 8 work when we move the code into 'master'. We don't have a timeline yet for this. Unlike Java 8, though, we don't need a feature patch for Luna service releases.
(In reply to Jay Arthanareeswaran from comment #0) > Just like we did for Java 8 work, we need to be able to produce builds from > the BETA_JAVA9 branch. The requirements being: > > Goals: > 1. Get SDK builds to self-host for our own builds > 2. Be prepared to build our Java 8 work when we move the code into 'master'. > We don't have a timeline yet for this. > > Unlike Java 8, though, we don't need a feature patch for Luna service > releases. But we need a feature patch for normal 4.5 builds. Goal should be to have this along with 4.5 M7. NOTE: Those builds must not be mirrored, like the P,X and Y-builds we had for Java 8. For the P-build we had an update site: http://download.eclipse.org/eclipse/updates/4.3-P-builds/ I'd expect to see something like that for Java 9 too, i.e. http://download.eclipse.org/eclipse/updates/4.5-P-builds/ Wiki pages that need to be produced for Java 9: https://wiki.eclipse.org/JDT/Eclipse_Java_8_Support_For_Kepler https://wiki.eclipse.org/JDT/Eclipse_Java_8_Support_%28BETA%29
I've started looking at this, and will document what I know, and assumptions made, ... so you all can correct me when I'm wrong. First priority will be to do "whole SDK build" using 'master' of most projects, but for 3 repos: eclipse.jdt.core: BETA_JAVA9 eclipse.jdt.debug: BETA_JAVA9 eclipse.jdt.ui: BETA_JAVA9 (it appears pde.ui has no BETA_JAVA9, at least yet). First priority will get to build as a "test build" ... i.e. nothing tagged, unit tests not ran, not on download page. I forget difference of X and Y builds, before, but I'll use "Y" builds for these "whole builds". (reserve X for "Experimental"). After that, I'm assuming, priority is to have on DL page, and have JUnit tests running, for these "whole builds". Last, I'm assuming the priority is to produce a "patch build". Given the timing, not sure if "M7" will matter, or if RC1 will suffice .... we'll see how quickly it goes, I guess. Let me know if any mistaken assumptions so far.
(In reply to David Williams from comment #2) Thought of a few more assumptions, that I think were true before, as well. Once we start putting things on DL page, and running Unit tests, I am assuming you'd want the "Y" builds tagged in git repo. I am assuming you'd want a scheduled Y build once per week (or, 'on demand', if you needed an extra one). Once I produce "P" builds, these will not be tagged in Git repos, and will not run unit tests on "patched version". But, still have their own repo.
I made a number of small changes to master, to help "prepare the way" for the BETA_JAVA9 builds. Then branched master (at HEAD, shortly after I20150505-2000 build/tag). And then made the few substantial changes to build the SDK, repo, etc., using BETA_JAVA9 branches for the 3 repositories that have one. These builds will be "Y" builds. For the 4.5-Y-builds repo, since it is used to put the new builds, but also used as the "comparator" repo, I used a variant of our standard pattern, and added http://download.eclipse.org/eclipse/updates/4.5-I-builds/ as one child of the composite. That way, all the things that are not branched, will normally get "no change" or a reasonable change in qualifier, but at same time not changing anything for I-builds themselves. I have started a Y-build on eclipse.org, and it will kick off a whole set of unit tests (just like I-builds) ... but no performance tests, yet. Initially the build will be "hidden" ... as long as it looks reasonable, and Jay, and others agree, I'll "make visible". That way you can control the timing of when you have something to say about it, in a note, or prepared wiki page. [If not obvious, the build is "performed" with Java 8, and the Unit tests ran with Java 8 or Java 7. I'm guessing someday we'll have a version of Java 9 you'd like to use. I investigate "patch build" in the week ahead (assuming that's still desired) ... but, would like to understand it's purpose, time-lines, and urgency.
(In reply to David Williams from comment #4) > Initially the build will be "hidden" ... This also means no mirroring, right? For Java 8, the webmaster had to add a filter for those (IIRC).
(In reply to Dani Megert from comment #5) > (In reply to David Williams from comment #4) > > Initially the build will be "hidden" ... > > This also means no mirroring, right? For Java 8, the webmaster had to add a > filter for those (IIRC). Just being "hidden" won't prevent mirroring. That's all controlled by "prefixes". (the 'buildHidden' is just a little PHP trick). So, we'll have to ask: Webmasters, we don't recall, do you have a "negative" filter to prevent content from mirroring, or a "positive one" that allows things to be mirrored? Which ever, we'd like builds from our site that begin "Y" or "P" to not be mirrored. Similar for whole update sites, 4.5-Y-builds, and 4.5-P-builds. Can you confirm? Or, add to "exclude" list? Thanks,
(In reply to David Williams from comment #4) > I have started a Y-build on eclipse.org, and it will kick off a whole set of > unit tests (just like I-builds) ... but no performance tests, yet. > > Initially the build will be "hidden" ... as long as it looks reasonable, and > Jay, and others agree, I'll "make visible". That way you can control the > timing of when you have something to say about it, in a note, or prepared > wiki page. Eclipse downloads: http://download.eclipse.org/eclipse/downloads/drops4/Y20150506-0317/ Build logs and/or test results (eventually): http://download.eclipse.org/eclipse/downloads/drops4/Y20150506-0317/testResults.php Check unanticipated comparator messages: http://download.eclipse.org/eclipse/downloads/drops4/Y20150506-0317/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt Software site repository: http://download.eclipse.org/eclipse/updates/4.5-Y-builds Specific (simple) site repository: http://download.eclipse.org/eclipse/updates/4.5-Y-builds/Y20150506-0317 (Tests are still running ... but, they are running!) Let me know if anything looks "off".
(In reply to David Williams from comment #6) > > Webmasters, we don't recall, do you have a "negative" filter to prevent > content from mirroring, or a "positive one" that allows things to be > mirrored? We have a list of directories that we exclude from mirrors. I think this small fragment: *drops4/X* *drops4/Y* , should keep most of your content from being mirrored. I've also tweaked another section that was: */eclipse/updates/4.3-X* */eclipse/updates/4.4-Y* to be */eclipse/updates/*-X* */eclipse/updates/*-Y* so that we can hopefully future proof a bit. -M.
(In reply to Eclipse Webmaster from comment #8) > (In reply to David Williams from comment #6) > > > > Webmasters, we don't recall, do you have a "negative" filter to prevent > > content from mirroring, or a "positive one" that allows things to be > > mirrored? > > We have a list of directories that we exclude from mirrors. I think this > small fragment: *drops4/X* *drops4/Y* , should keep most of your content > from being mirrored. > > I've also tweaked another section that was: */eclipse/updates/4.3-X* > */eclipse/updates/4.4-Y* to be */eclipse/updates/*-X* */eclipse/updates/*-Y* > so that we can hopefully future proof a bit. > > -M. Thanks Matt, for the quick reaction. I agree that appears to cover it. (And, should not effect others.)
(In reply to David Williams from comment #3) > Once we start putting things on DL page, and running Unit tests, I am > assuming you'd want the "Y" builds tagged in git repo. Expect some failures at this stage 'if' tests are run with JDK 9. I have raised bug 466944 to fix the test framework.
(In reply to Jay Arthanareeswaran from comment #10) > (In reply to David Williams from comment #3) > > Once we start putting things on DL page, and running Unit tests, I am > > assuming you'd want the "Y" builds tagged in git repo. > > Expect some failures at this stage 'if' tests are run with JDK 9. I have > raised bug 466944 to fix the test framework. Ok, thanks for the heads up. Not sure we have resolved a few remaining questions. 1) How often would you like these BETA builds? Weekly? What day and and time? How about Thursday's 8 AM (Eastern) just so it's most removed from other builds and tests. 2) Ready to "make them visible"? 3) When is a "patch build" needed? (what is the "target" going to be? Mars release?). But, assume it is just available from our download page as "experimental" ... not considered "released" of course. 4) I guess eventually someone needs to update wiki pages (I've not looked at older ones, to see what they say ... not sure how much work is involved, or if mostly "copy/paste").
(In reply to David Williams from comment #11) > Not sure we have resolved a few remaining questions. > > 1) How often would you like these BETA builds? Weekly? What day and and > time? > How about Thursday's 8 AM (Eastern) just so it's most removed from other > builds and tests. I think for now "on demand" is good enough. Jay? > 2) Ready to "make them visible"? You mean on our downloads page? Currently I wouldn't do so. > 3) When is a "patch build" needed? (what is the "target" going to be? Mars > release?). But, assume it is just available from our download page as > "experimental" ... not considered "released" of course. Yes, Mars if we are satisfied. Or later if not. > 4) I guess eventually someone needs to update wiki pages (I've not looked at > older ones, to see what they say ... not sure how much work is involved, or > if mostly "copy/paste"). This has started but needs work, see https://wiki.eclipse.org/Java9
(In reply to Dani Megert from comment #12) > (In reply to David Williams from comment #11) > > Not sure we have resolved a few remaining questions. > > > > 1) How often would you like these BETA builds? Weekly? What day and and > > time? > > How about Thursday's 8 AM (Eastern) just so it's most removed from other > > builds and tests. > > I think for now "on demand" is good enough. Jay? Yep, that's what I was going to say too.
Hi David, Sorry to nag, but is there any update on this?
(In reply to Jay Arthanareeswaran from comment #14) > Hi David, > > Sorry to nag, but is there any update on this? I assume you mean on the feature patch, and the answer is "no" ... except that Dani told me yesterday that "next week would be nice" :) So, I will bump it up on my to do list. Thanks,
One step in preparing a "Beta Java 9" feature patch is to update the Beta Java 9 build to "match" the Mars release build. This mostly required updating the "pre-reqs" and no longer using snapshots and staged version of CBI and Tycho. Plus I "fixed" all the non-BETA_JAVA9 repositories at I20150603-2000 tag, in the repositories.txt file. You should check my work to confirm no other repositories have "join BETA_JAVA9" train: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/streams/repositories.txt?h=BETA_JAVA9 = = = = The build, after all these changes, is at http://download.eclipse.org/eclipse/downloads/drops4/Y20150608-2132/ One thing you'll need to address is the "comparator errors", as seen in http://download.eclipse.org/eclipse/downloads/drops4/Y20150608-2132/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt I assume those are "not good"? FYI, the report says it "compares to .../updates/4.5-Y-builds but that repository is a composite that also in includes .../updates/4.5-I-builds (So, in other words, is also comparing to our "final builds" for Mars). My guess is, to 'fix' this issue, you will have to 'touch' org.eclipse.jdt.ui org.eclipse.jdt.debug.ui in the BETA_JAVA9 branch ... BUT, could also indicate an unexpected effect of some change in compiler?
Created attachment 254230 [details] byte files compared during build
Created attachment 254231 [details] byte files compared during build These two tar files are produced during the build, which should allow you to more easily compare "what's different" about the byte codes. Good luck ... let me know if/when fixed or touched and I'll do another build of "everything". (We need to make sure that build is correct, before creating a feature patch).
(In reply to David Williams from comment #16) > BUT, could also indicate an unexpected effect of some change in compiler? Assuming we use the same version of compiler that was used for the last Mars build, I don't have a good explanation. We can try the 'touch' option, perhaps?
(In reply to David Williams from comment #16) > The build, after all these changes, is at > > http://download.eclipse.org/eclipse/downloads/drops4/Y20150608-2132/ Thanks David. I downloaded and checked to find the following basics working as expected: 1. Supports 1.9 EE and associates appropriate JRE if available. 2. Able to create plain Java projects with 1.9 SE and a plugin project with 1.9 BREE. 3. Basic JDT features, such as compiling, reconciling, editing, outline view, hierarchy etc. working with JDK 9 in build path.
(In reply to Jay Arthanareeswaran from comment #19) > (In reply to David Williams from comment #16) > > BUT, could also indicate an unexpected effect of some change in compiler? > > Assuming we use the same version of compiler that was used for the last Mars > build, I don't have a good explanation. We can try the 'touch' option, > perhaps? It is, that's part of what I updated to make sure BETA_JAVA9 parent pom was in sync with master branch. And you can see is "logs", in several places, bug perhaps compile logs is most definitive last Mars I-build: http://download.eclipse.org/eclipse/downloads/drops4/I20150603-2000/compilelogs/plugins/org.eclipse.compare_3.5.600.v20150420-1449/@dot.xml http://download.eclipse.org/eclipse/downloads/drops4/Y20150608-2132/compilelogs/plugins/org.eclipse.compare_3.5.600.v20150420-1449/@dot.xml I will try again, and remove "old" Y-builds from comparator repo ... just to make sure nothing "matches" that first build, from quite a long time ago.
(In reply to David Williams from comment #21) > (In reply to Jay Arthanareeswaran from comment #19) > > (In reply to David Williams from comment #16) > I will try again, and remove "old" Y-builds from comparator repo ... just to > make sure nothing "matches" that first build, from quite a long time ago. I've removed "both" Y-builds from the "composite" in 4.5-Y-builds, so the next build will use ONLY the 4.5-I-builds in "comparator". But, I left the two directories on file system, so if needed, can access them directly with .../updates/4.5-Y-builds/Y20150506-0317 .../updates/4.5-Y-builds/Y20150608-2132 That should give us cleanest build possible. I'll re-post when that build is complete.
(In reply to David Williams from comment #16) > Plus I "fixed" all the non-BETA_JAVA9 repositories at I20150603-2000 tag, in > the repositories.txt file. Looks good. > One thing you'll need to address is the "comparator errors", as seen in > > http://download.eclipse.org/eclipse/downloads/drops4/Y20150608-2132/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt > > > I assume those are "not good"? They are "good", i.e. expected. The previous build in the http://download.eclipse.org/eclipse/updates/4.5-Y-builds/ update site was Y20150506-0317, which is very likely a build that was produced by a compiler that produced bad class files (between bug 445231 and bug 466675). The class file differences are exactly that problem. > My guess is, to 'fix' this issue, you will have to 'touch' > org.eclipse.jdt.ui > org.eclipse.jdt.debug.ui I've merged master into the BETA_JAVA9 branch in both of these repos. jdt.ui was actually a fast-forward, while jdt.debug was a merge with a new merge commit. => Both projects got touched for the next Y-build. Ready to go at any time.
(In reply to Markus Keller from comment #23) > => Both projects got touched for the next Y-build. Ready to go at any time. I *think* this test build probably got the latest changes (but I started it, before seeing this comment, so not positive). Let me know if easy for you to tell ... and, if not (either easy, or didn't get) I'll do another). Are the debug changes still (only) test related? Seemed to be only test related when I glanced at changes yesterday.
(In reply to David Williams from comment #24) > (In reply to Markus Keller from comment #23) > > > => Both projects got touched for the next Y-build. Ready to go at any time. > > I *think* this test build probably got the latest changes (but I started it, > before seeing this comment, so not positive). > > Let me know if easy for you to tell ... and, if not (either easy, or didn't > get) I'll do another). > > Are the debug changes still (only) test related? Seemed to be only test > related when I glanced at changes yesterday. Sorry, forgot to paste the main part: Eclipse downloads: http://download.eclipse.org/eclipse/downloads/drops4/Y20150609-1150/ Build logs and/or test results (eventually): http://download.eclipse.org/eclipse/downloads/drops4/Y20150609-1150/testResults.php Software site repository: http://download.eclipse.org/eclipse/updates/4.5-Y-builds Specific (simple) site repository: http://download.eclipse.org/eclipse/updates/4.5-Y-builds/Y20150609-1150
(In reply to David Williams from comment #24) > I *think* this test build probably got the latest changes (but I started it, > before seeing this comment, so not positive). All good. http://download.eclipse.org/eclipse/downloads/drops4/Y20150609-1150/buildlogs/relengdirectory.txt and the empty comparator log confirm that the build includes my changes. > Are the debug changes still (only) test related? Seemed to be only test > related when I glanced at changes yesterday. Not sure which changes you're talking about. The bad class files were in the launch configuration dialog. However, I don't think they caused real issues, since those INNERCLASS entries don't seem to be necessary for the JVM. Comparing BETA_JAVA9 to master shows that jdt.debug's only changes at this time are in the org.eclipse.jdt.launching plug-in (add support for the JavaSE-1.9 EE).
(In reply to Markus Keller from comment #26) > > Comparing BETA_JAVA9 to master shows that jdt.debug's only changes at this > time are in the org.eclipse.jdt.launching plug-in (add support for the > JavaSE-1.9 EE). Thanks. I think I was using some primitive method of seeing "what's changed" (such as searching for that disclaimer in copyright :\ ) But, the purpose was to get a specific list of plugins that have changed, that would need to go into a feature patch. I'll need to look closer (and/or get JDT's Team" list) but what I've seen so far is o.e.jdt.core o.e.jdt.ui, o.e.jdt.launching
These are the bundles in BETA_JAVA9 that actually changed w.r.t. 4.5RC4: org.eclipse.jdt.core org.eclipse.jdt.core.tests.compiler org.eclipse.jdt.launching In the jdt.ui repo, there wasn't actually any change so far. Since there's no new source/classfile version constant for 1.9 yet, not even the usual suspects on the Java Compiler preference page were affected.
(In reply to Markus Keller from comment #28) > These are the bundles in BETA_JAVA9 that actually changed w.r.t. 4.5RC4: > > org.eclipse.jdt.core > org.eclipse.jdt.core.tests.compiler > org.eclipse.jdt.launching > > In the jdt.ui repo, there wasn't actually any change so far. Since there's > no new source/classfile version constant for 1.9 yet, not even the usual > suspects on the Java Compiler preference page were affected. Glad I asked! (and I will assume, unless you say otherwise org.eclipse.jdt.core.tests.compiler is unit tests only, so would not be part of a patched feature. Thanks!
(In reply to David Williams from comment #6) > Webmasters, we don't recall, do you have a "negative" filter to prevent > content from mirroring, or a "positive one" that allows things to be > mirrored? > > Which ever, we'd like builds from our site that begin "Y" or "P" to not be > mirrored. Similar for whole update sites, 4.5-Y-builds, and 4.5-P-builds. > > Can you confirm? Or, add to "exclude" list? Our mirroring/exclusion is already complex as it is... if you don't want it mirrored, by not host it on build.eclipse.org? (In reply to Eclipse Webmaster from comment #8) > I've also tweaked another section that was: */eclipse/updates/4.3-X* > */eclipse/updates/4.4-Y* to be */eclipse/updates/*-X* */eclipse/updates/*-Y* > so that we can hopefully future proof a bit. > > -M. Matt, don't forget to update download.php with the same patterns. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=466453#c5
D'oh. I've updated download.php. -M.
(In reply to Denis Roy from comment #30) > Our mirroring/exclusion is already complex as it is... if you don't want it > mirrored, by not host it on build.eclipse.org? Well ... for similar reason ... being on "downloads" fits in to our build and test process ... which is already pretty complex as it is. "It's just a matter of programming" that we could add more checks and branching, etc., to also handle "build.eclipse.org" sites better ... just a matter of finding the time. But if you say the word, I'll at least open a feature enhancement, so we know we *should* do it, at some point -- but do appreciate your help at this point in time. [Plus, I thought, and might be wrong, that eventually at some point, we would make these more visible and public, but, that was just my assumption, I could be wrong, and we can't really do that until Java 9 is released?]
I was just wondering, and your explanation makes perfect sense.
(In reply to David Williams from comment #29) > (In reply to Markus Keller from comment #28) > > These are the bundles in BETA_JAVA9 that actually changed w.r.t. 4.5RC4: > > > > org.eclipse.jdt.core > > org.eclipse.jdt.core.tests.compiler > > org.eclipse.jdt.launching > > > > In the jdt.ui repo, there wasn't actually any change so far. Since there's > > no new source/classfile version constant for 1.9 yet, not even the usual > > suspects on the Java Compiler preference page were affected. > > Glad I asked! (and I will assume, unless you say otherwise > org.eclipse.jdt.core.tests.compiler > is unit tests only, so would not be part of a patched feature. > > Thanks! I've produced the first draft version of a "patched feature" for JDT committers to try out and confirm it is as you think it should be. Should add only the 'core' and 'launching' bundles to a about to be released SDK. p2 repo is at: http:/http/download.eclipse.org/eclipse/updates/4.5-P-builds The DL page still needs LOTS of work (such as, still says Java 8! :\ but, I plan to make it basically as we had for Java 8 patch: http://download.eclipse.org/eclipse/downloads/drops4/P20150612-1118/ Not sure why batch compiler is not showing or linking there ... but, they are on DL site. I assume you want them to be. These are their file names, if you want to DL directly to confirm being built correctly. Just add name to the end of the web page URL and you should be able to DL them. ecj-P20150612-1118.jar ecjsrc-P20150612-1118.jar Thanks for any "early feedback". With luck, I should have time to finish the webpage over the weekend.
(In reply to David Williams from comment #34) > ecj-P20150612-1118.jar > ecjsrc-P20150612-1118.jar Thanks David. Unfortunately there was a bug with the Java 9 work that was causing the batch compiler to crash. I have fixed it now and we are going to have a another build for the batch compiler to be useful. Not necessarily today, though.
(In reply to Jay Arthanareeswaran from comment #35) > (In reply to David Williams from comment #34) > > ecj-P20150612-1118.jar > > ecjsrc-P20150612-1118.jar > > Thanks David. Unfortunately there was a bug with the Java 9 work that was > causing the batch compiler to crash. I have fixed it now and we are going to > have a another build for the batch compiler to be useful. Not necessarily > today, though. That's fine. I sort of expect this to be an ongoing process. I will at least make progress on the web pages before doing another build, then hit two birds with one stone.
(In reply to David Williams from comment #36) > I will at least make progress on the web pages before doing another build, > then hit two birds with one stone. Next pass is done. Web page is now sort of generic ... will need to add all the "cautionary" language, link to wiki, etc. http://download.eclipse.org/eclipse/downloads/drops4/P20150615-0220/ And update site: http://download.eclipse.org/eclipse/updates/4.5-P-builds/P20150615-0220/ And let me tell you a story. Even after being told "must be ran with Java 9", I just figured it'd "fail", or something ... BUT, when I tried to re-start one of my IDEs with previous Java 9 patch, my whole system hung! And that's a Linux system! And, I mean it HUNG ... even after killing all Java and eclipse processes (using a shell from another machine) the UI would not re-draw, or accept any interaction. Surely that's not what you meant, right? Was this a random coincidence? (If not, I'd count that a unacceptable damaging). I was afraid to see if I could re-produce it ... not knowing what could possibly cause that sort of hang. So, I might be over reacting, but I spent some time to modify eclipse.ini on install of the patch, to add -Dosgi.requiredJavaVersion=1.9. Do let me know if that is not desired. Also, be aware, when patch is first installed, and user is prompted to "restart" then it will restart, even if running with Java 8 (this is related to long standing quirk of p2 and luncher, where the restart after installation/update is not a pure, fresh "restart". But, once it is shutdown, then the next time it's run (with less that Java 1.9) the user will get a not very friendly (but, understandable) message that 1.9 is needed. Again, let me know if I have misunderstood, and you want them to go ahead and run with Java 1.8, and it's just a matter that "Java 9" would not work. = = = = = I can make a pass at the cautionary language (probably by late Tuesday) or, feel free to tell me what you want it to say, if you already know. (I plan to just follow what is in the copyright statements of the BETA files.) Be sure to test ... let me know if it is not picking up the right code, or something! (Especially, since I needed to put in some "hacks", to get Tycho to build it ... I'm still not sure the patch is correctly "constrained" to apply to just one version.)
(In reply to David Williams from comment #37) I can't reproduce such a crash, and I don't see how the updated bundles could cause that. But maybe it's a bug in your jdk9 preview? I've used the update site to install P20150612-1118, and I could restart with jdk8_u45 without a crash or otherwise weird behavior. As expected, the build path of a Java 9 project could not be resolved, and I got this exception: java.nio.file.ProviderNotFoundException: Provider "jrt" not found at java.nio.file.FileSystems.getFileSystem(FileSystems.java:224) at org.eclipse.jdt.internal.compiler.util.Util.walkModuleImage(Util.java:740) at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.computeChildren(JarPackageFragmentRoot.java:103) ... After updating to P20150615-0220, I couldn't launch with jdk8 any more, and with jdk-9-ea-bin-b63 the build path was correctly resolved. => Patch looks good. > Also, be aware, when patch is first installed, and user is prompted to > "restart" then it will restart, even if running with Java 8 (this is related > to long standing quirk of p2 and luncher, where the restart after > installation/update is not a pure, fresh "restart". I did get the "Incompatible JVM [..] Version: 1.9 or greater is required." dialog after I clicked "Yes" in the "Do you want to restart?" dialog. I had launched Eclipse with "$ ./eclipse -vm ~/bin/jdk8/bin".
(In reply to Markus Keller from comment #38) > (In reply to David Williams from comment #37) > I can't reproduce such a crash, and I don't see how the updated bundles > could cause that. But maybe it's a bug in your jdk9 preview? I don't have any jdk9 preview on my system. Maybe that's the problem. :) More likely a weird coincidence? > [...] > After updating to P20150615-0220, I couldn't launch with jdk8 any more, and > with jdk-9-ea-bin-b63 the build path was correctly resolved. > > => Patch looks good. Ok, good, and you do mean "looks good", even with the "java 9 required" restriction? Or, should I remove that? > I did get the "Incompatible JVM [..] Version: 1.9 or greater is required." > dialog after I clicked "Yes" in the "Do you want to restart?" dialog. I had > launched Eclipse with "$ ./eclipse -vm ~/bin/jdk8/bin". Ok, was that on Linux? (that's what I was using). If not, I think we might have ended up with slightly different "restart methods" for the different platforms? I know on Windows, some extra work is done to "swap" the eclipse executable, but not sure that's done on all platforms?
Created attachment 254439 [details] jdt feature with hard coded version Obsoleting old attachments, which were a quirk of timing. And, may I request the "eclipse.jdt" repository be branched, to BETA_JAVA9 as well? (Or, if you want, you might want to call it BETA_JAVA9_PATCH). And, then apply the attached patch which hard codes the version to what it was for the Mars release. (And, then, I will also have to turn off comparator replacement, for that feature). I am thinking I might have time to _try_ creating the patch "from a full build repository". Currently, I have a "fake feature" in releng to serve this role ... but, I'm mostly wondering if there is "a better way" to do this sort of thing, in general. The problem is the way Tycho creates repositories with patched features ... see bug 389698 ... if a patch feature says it "requires" an exact version, of the feature it is patching, Tycho expects that feature to be "present", even if it is not actually used in the the new "patch repository" (I suspect this is because it expects to produce things that can be tested during the build, which we don't really do ... but ... Tycho seems to feature that. This is a low priority request. I think what we have is workable ... I am most just curious if there is a better way. (And, some experiments on my local system, indicated it'd probably work ... but ... I was doing lots of experiments to get this to work ... so always a chance it still won't. Thanks,
(In reply to David Williams from comment #39) > > => Patch looks good. > > Ok, good, and you do mean "looks good", even with the "java 9 required" > restriction? Or, should I remove that? I didn't have a clear opinion on that, so I tried to evade that question :) Discussed again with Dani, and we agreed that the restriction should be removed again. The problem is that p2 can't require a Java 9 JRE at update time. With the restriction, a user who just wants to try the patch can brick his install if he doesn't have access to a Java 9 JRE. > Ok, was that on Linux? Yes. Our old x86 Ubuntu 12.04.
(In reply to David Williams from comment #40) I've pushed your patch to BETA_JAVA9_PATCH. BETA_JAVA9 should be reserved for topic branches that produce a full build and that are eventually supposed to be merged into master.
(In reply to Markus Keller from comment #42) > (In reply to David Williams from comment #40) > I've pushed your patch to BETA_JAVA9_PATCH. Thank you. I've not tried any new method yet, but hope to in the days ahead. But have rebuilt without the hard Java 9 requirement: http://download.eclipse.org/eclipse/downloads/drops4/P20150615-1541/ I also added wording to spell out some of the qualifications (about "early work, not a JSR"), added similar wording to category and feature patch description, and on DL page fixed a link and file name so the "zipped repository" is now also available. I also included a link to wiki page, at https://wiki.eclipse.org/Java9 though as noted above "needs work" (which, someone beside me will have to do). So ... in some ways, this could be considered "done", from my point of view, but will leave open a bit, in case others suggest improvements, and while I investigate other methods of producing the patch. I also still want to test if the patch is "specific" enough For example, it currently says the patch scope is tied to version 0.0.0 of o.e.jdt.feature.group. I thought it was supposed to be [3.11.0.v20150603-2000,3.11.0.v20150603-2000] ... I may have to do a PDE build to see how it's "supposed" to be. :)
The feature and plug-in qualifiers should end with "_BETA_JAVA9", like e.g. for Java 8: org.eclipse.rcp.java8patch_1.0.0.v20140213-0104_BETA_JAVA8 org.eclipse.jdt.core_3.9.2.v20140213-0104_BETA_JAVA8.jar The category name should be: "Eclipse Java 9 Support (BETA) for Mars" The category description must mention the legal blurb first, i.e. "Eclipse Java 9 Support (BETA) for Mars - LEGAL BLURB - ANY OTHER DESCRIPTION"
(In reply to Dani Megert from comment #44) > The feature and plug-in qualifiers should end with "_BETA_JAVA9", like e.g. > for Java 8: > org.eclipse.rcp.java8patch_1.0.0.v20140213-0104_BETA_JAVA8 > org.eclipse.jdt.core_3.9.2.v20140213-0104_BETA_JAVA8.jar > > The category name should be: "Eclipse Java 9 Support (BETA) for Mars" > The category description must mention the legal blurb first, i.e. > > "Eclipse Java 9 Support (BETA) for Mars - LEGAL BLURB - ANY OTHER > DESCRIPTION" I've made the changes for descriptions and category name, but, the qualifier change does not seem possible ... at least not in any easy way that I know of. I tried the "method" we would have used in PDE, but is just left a literal ".qualifier" as in ".qualifier_BETA_JAVA9". PLUS, from what I can see, we did NOT use that in the Java 8 patch. From the archives: $ unzip java8patch-P20140317-1600-repository.zip -d j8 Archive: java8patch-P20140317-1600-repository.zip inflating: j8/index.htmlORIG creating: j8/features/ inflating: j8/features/org.eclipse.jdt.java8patch_1.0.0.v20140317-1956.jar inflating: j8/features/org.eclipse.jdt.a2.java8patch_1.0.0.v20140317-1956.jar inflating: j8/features/org.eclipse.pde.java8patch_1.0.0.v20140317-1956.jar inflating: j8/siteHOLD.xml inflating: j8/content.jar extracting: j8/artifacts.jar creating: j8/plugins/ inflating: j8/plugins/org.eclipse.pde.launching_3.6.101.v20140213-1419.jar inflating: j8/plugins/org.eclipse.jdt.launching_3.7.50.v20140317-1921.jar inflating: j8/plugins/org.eclipse.pde.api.tools.ui_1.0.450.v20140313-2003.jar inflating: j8/plugins/org.eclipse.jdt.ui_3.9.50.v20140317-1811.jar inflating: j8/plugins/org.eclipse.jdt.debug.ui_3.6.250.v20140317-1921.jar inflating: j8/plugins/org.eclipse.jdt.compiler.tool_1.0.250.v20140316-1836.jar inflating: j8/plugins/org.eclipse.pde.api.tools_1.0.550.v20140313-2003.jar inflating: j8/plugins/org.eclipse.jdt.apt.core_3.3.550.v20140316-1836.jar inflating: j8/plugins/org.eclipse.jdt.annotation_1.1.0.v20140129-1625.jar inflating: j8/plugins/org.eclipse.jdt.debug_3.8.50.v20140317-1921.jar inflating: j8/plugins/org.eclipse.jdt.junit_3.7.250.v20140317-1811.jar inflating: j8/plugins/org.eclipse.jdt.apt.ui_3.3.350.v20140316-1836.jar inflating: j8/plugins/org.eclipse.jdt.apt.pluggable.core_1.0.400.v20131113-0353.jar inflating: j8/plugins/org.eclipse.jdt.junit.core_3.7.250.v20140317-1811.jar inflating: j8/plugins/org.eclipse.jdt.compiler.apt_1.0.650.v20140316-1836.jar inflating: j8/plugins/org.eclipse.jdt.core_3.9.50.v20140317-1741.jar inflating: j8/plugins/org.eclipse.jdt.annotation_2.0.0.v20140317-1808.jar = = = = = I just noticed the checksums for "zipped repository" are not being generated ... so ... I still need to fix that, but thought I'd publish this note, in case anyone wants to review/confirm things are as expected. Also, note, after the next build, which should be "deliverable" (as far as I know) I will remove all older versions from downloads and 4.5-P-builds ... let me know if anyone has a need for one of the old ones.
Here's the the "final" build ... unless others see fixes that are needed. http://download.eclipse.org/eclipse/downloads/drops4/P20150616-1707/ To document some of the lingering issues: - Are constraints correct? Tight enough? It appears they were the same for our Java 8 patch, so I think in practical terms we should be fine. But, for truly enterprise strength patches, we'd need to get this understood better. (And, off the top of my head, I can not really say it is wrong, the way it is ... just going off old WTP memories at the moment). - the source feature patch does not have the "patch" icon. Until now ... this Java 9 patch ... we have never even provided "source patch features". Now that I can do that, I see it's missing the correct "red cross" icon. It appears that in the meta data, only the IU of 'org.eclipse.jdt.java9patch.feature.group' (and not the 'org.eclipse.jdt.java9patch.source.feature.group' IU) has the <patchScope> element, and the property <property name='org.eclipse.equinox.p2.type.patch' value='true'/> - The jars in the patch repo are signed, but they are not "pack200'd". Honestly do not know why ... but ... is more a "nice to have", than a practical problem. May be a simple limitation in our script? perhaps these jars are not normally packed? ... but, have not investigated). - (Still) requires a "hack" to provide a fake version of the feature being patched, just to satisfy Tycho's "resolution process" while executing 'eclipse-repository' packaging. I doubt if matters at all, in end result (perhaps only if running tests, during the build). - We are not putting "batch compiler" in patch repo (this is one normally named, as an IU, org.eclipse.jdt.core.compiler.batch. We probably could if desired, but do not know of a strong need for it. = = = = = I will close this as "fixed" ... to signify I believe it is done, but feel free to re-open if problems seen. I will also delete older builds and repositories now.
(In reply to David Williams from comment #45) > but, the qualifier change does not seem possible ... at least not > in any easy way that I know of. I tried the "method" we would have used > in PDE, but is just left a literal ".qualifier" as in > ".qualifier_BETA_JAVA9". > PLUS, from what I can see, we did NOT use that in the Java 8 patch. We did have it. The listing you provided is for the official feature patch that was provided after Java 8 went live. Before we had e.g. org.eclipse.jdt.core_3.9.2.v20140213-0104_BETA_JAVA8 The problem with not doing this is that it will be very hard to tell whether the plug-in is the original one or the patched one. Note that for the official Java 8 patch we used 50 as service number, so that it was easy to detect. So, it would really be good to have that "_BETA_JAVA8" qualifier. But don't invest more than half a day.
> "Eclipse Java 9 Support (BETA) for Mars - LEGAL BLURB - ANY OTHER DESCRIPTION" The first dash has been replaced with a dot: "Eclipse Java 9 Support (BETA) for Mars. LEGAL BLURB - ANY OTHER DESCRIPTION" We always used to used a dash i.e. "Eclipse Java 9 Support (BETA) for Mars - LEGAL BLURB. ANY OTHER DESCRIPTION" The root entry should also get the same description. Currently it only says: "Eclipse Java 9 Support (BETA) for Mars"
Ok, see what you think of this one. http://download.eclipse.org/eclipse/downloads/drops4/P20150618-1815/ = = = = = = = I was able to figure our the suffix part, being reminded by this Tycho FAQ, and seeing their example used a 'prefix' (as we do as well). https://wiki.eclipse.org/Tycho/FAQ#How_do_I_embed_a_configurable_build_version.3F So, now we still have the 'v' prefix ... and also a _BETA_JAVA9" suffix ... and date is still based on Git commit. = = = = I also fixed the icon on source feature patch, by adding a p2.inf to the sourceTemplateFeature that has simply properties.0.name = org.eclipse.equinox.p2.type.patch properties.0.value = true Still no "patch scope" for source feature, only runtime feature. = = = = I changed the wording as best as I can interpret what you want, Dani. But I suggest in the future, it would be easier for us both for you to provide a patch with exactly what you want, especially when it gets down to periods and dashes, since I do not really see any reason for why such minor details matter (i.e. I am obviously not learning anything that I will remember the next time it comes up.)
(In reply to David Williams from comment #49) > Ok, see what you think of this one. > > http://download.eclipse.org/eclipse/downloads/drops4/P20150618-1815/ > > = = = = = = = > > I was able to figure our the suffix part, being reminded by this Tycho FAQ, > and seeing their example used a 'prefix' (as we do as well). > > https://wiki.eclipse.org/Tycho/FAQ#How_do_I_embed_a_configurable_build_version.3F > > > So, now we still have the 'v' prefix ... and also a _BETA_JAVA9" suffix ... > and date is still based on Git commit. Awesome!
(In reply to David Williams from comment #46) > Here's the the "final" build ... unless others see fixes that are needed. What's the regular schedule for follow-up builds? Weekly, e.g. on Monday? I've just released a bunch of fixes for bug 470613 and its blockers, and it would be good to have this included before we announce the 4.5-P-builds widely. Note that this includes the first changes in the org.eclipse.jdt.ui bundle.
(In reply to Markus Keller from comment #51) > (In reply to David Williams from comment #46) > What's the regular schedule for follow-up builds? Weekly, e.g. on Monday? Mostly whatever you need. If the code is ready, I could do Monday (Sunday at 8 might be better, if all is ready from your end?) > Note that this includes the first changes in the org.eclipse.jdt.ui bundle. Thank you for being explicit. (that will take a little new work). In general, I am under the impression we do not need "regular builds", but can do them "on demand", at this point. Feel free to correct me if I am mistaken. I'm fine either way. If on demand, I suggest a cloned bug be open for each new request, with detail such as you've provided. (In future).
(In reply to David Williams from comment #52) > Mostly whatever you need. If the code is ready, I could do Monday (Sunday at > 8 might be better, if all is ready from your end?) Yes, all is ready, so whenever you have time (doesn't have to be on the weekend;)
(In reply to Markus Keller from comment #53) > (In reply to David Williams from comment #52) > > Mostly whatever you need. If the code is ready, I could do Monday (Sunday at > > 8 might be better, if all is ready from your end?) > > Yes, all is ready, so whenever you have time (doesn't have to be on the > weekend;) Here is a "full build" using the BETA_JAVA9 branch of jdt.ui (in addition to what we had). I primarily do this so we can run the unit tests ... and, they will not be done for a while ... but, putting the link here, so you know. http://download.eclipse.org/eclipse/downloads/drops4/Y20150621-1953/
(In reply to David Williams from comment #54) > (In reply to Markus Keller from comment #53) > > (In reply to David Williams from comment #52) > > > Mostly whatever you need. If the code is ready, I could do Monday (Sunday at > > > 8 might be better, if all is ready from your end?) > > > > Yes, all is ready, so whenever you have time (doesn't have to be on the > > weekend;) > > Here is a "full build" using the BETA_JAVA9 branch of jdt.ui (in addition to > what we had). I primarily do this so we can run the unit tests ... and, they > will not be done for a while ... but, putting the link here, so you know. > > http://download.eclipse.org/eclipse/downloads/drops4/Y20150621-1953/ And, ... the patch build: http://download.eclipse.org/eclipse/downloads/drops4/P20150621-2238/ [I am assuming someone else handles what ever is needed for market place client.]
(In reply to David Williams from comment #55) > http://download.eclipse.org/eclipse/downloads/drops4/P20150621-2238/ The org.eclipse.jdt.ui bundle didn't make it into the 4.5-P-build: http://download.eclipse.org/eclipse/updates/4.5-P-builds/P20150621-2238/plugins/?d contains org.eclipse.jdt.ui_3.11.0.v20150527-0925.jar, which is the version from RC4.
(In reply to Markus Keller from comment #56) > (In reply to David Williams from comment #55) > > http://download.eclipse.org/eclipse/downloads/drops4/P20150621-2238/ > > The org.eclipse.jdt.ui bundle didn't make it into the 4.5-P-build: > http://download.eclipse.org/eclipse/updates/4.5-P-builds/P20150621-2238/ > plugins/?d contains org.eclipse.jdt.ui_3.11.0.v20150527-0925.jar, which is > the version from RC4. Sorry about that. (I did look ... but, not closely enough). Try http://download.eclipse.org/eclipse/updates/4.5-P-builds/P20150622-0925/ Thanks,
(In reply to David Williams from comment #57) > (In reply to Markus Keller from comment #56) > > (In reply to David Williams from comment #55) > > > http://download.eclipse.org/eclipse/downloads/drops4/P20150621-2238/ > > > > The org.eclipse.jdt.ui bundle didn't make it into the 4.5-P-build: > > http://download.eclipse.org/eclipse/updates/4.5-P-builds/P20150621-2238/ > > plugins/?d contains org.eclipse.jdt.ui_3.11.0.v20150527-0925.jar, which is > > the version from RC4. > > Sorry about that. (I did look ... but, not closely enough). > > Try > http://download.eclipse.org/eclipse/updates/4.5-P-builds/P20150622-0925/ > > Thanks, And ... I meant to explain (so hopefully remember next time) ... I forgot to include it in the "outer most" pom, where modules are listed: <modules> <module>../../eclipse-platform-parent</module> <module>../../eclipse.platform.releng.prereqs.sdk</module> <module>org.eclipse.jdt.dummy</module> <module>org.eclipse.jdt-feature-dummy</module> <module>../../eclipse.jdt.core/org.eclipse.jdt.core</module> <module>../../eclipse.jdt.debug/org.eclipse.jdt.launching</module> <module>../../eclipse.jdt.ui/org.eclipse.jdt.ui</module> <module>org.eclipse.jdt.java9patch</module> <module>eclipse.releng.repository.java9patch</module> </modules> So, the feature (where I did add it) was just pulling what ever it found in "pre-req" repository.
(In reply to David Williams from comment #57) > http://download.eclipse.org/eclipse/updates/4.5-P-builds/P20150622-0925/ This build is good (includes all latest changes). (In reply to David Williams from comment #55) > [I am assuming someone else handles what ever is needed for market place > client.] That someone is called p2. The marketplace entry is just a glorified http://download.eclipse.org/eclipse/updates/4.5-P-builds/ The only imperfection I could spot is that this repository calls itself "The Eclipse Project repository" instead of e.g. "Eclipse Java 9 (BETA)".
(In reply to Markus Keller from comment #59) > That someone is called p2. The marketplace entry is just a glorified > http://download.eclipse.org/eclipse/updates/4.5-P-builds/ Ok, good to know. I will then, remove the few older sites from that composite, just in case someone get's to "playing around" :) ... we don't need bugs open of "earlier" versions. [Unless someone tells me they need to stay]. > The only imperfection I could spot is that this repository calls itself > "The Eclipse Project repository" instead of e.g. "Eclipse Java 9 (BETA)". Ok, thanks. I might change that, then. While never listed as a requirement, I think it'd be a good idea to mark for "statistics gathering" so we can see how many people install it. I think the market place client collects their own ... but, would be good to know if everyone gets it that way, or if some go directly to .../eclipse/updates/4.5-P-builds/ So, am re-opening, just not to forget to remove the older ones. If I can mark for statistics (and I think script allows name change too) with an hour or two of work, I'll do that too.
Just to cross-reference, I did try to make use of the JAVA_BEA9_PATCH branch to use the hard coded version of jdt feature, (and build the patch from the repository only) but that didn't work, because then did not "match" what "eclipse SDK" was expecting to find and "pull in". Not sure exactly what was going wrong, but opened bug 470733 to possibly investigate the general issue in more detail at some future time.
(In reply to David Williams from comment #60) > So, am re-opening, just not to forget to remove the older ones. > > If I can mark for statistics (and I think script allows name change too) > with an hour or two of work, I'll do that too. I did remove old ones. I did add new name (I modeled it on the Java 8 Patch repository name ... and is a little too long ... but, not worth shorting, IMHO). Also saw I had not add yet added mirrorURL, so I did that. Also added the metadata to enable "stats" for both features, runtime and source (mostly for experience). I think they only update the "stats database" once per day ... but, I installed one of each, (meaning runtime would have been installed twice) so should be able to check tomorrow and see if any stats are showing up for "java9patch". The full values used for various properties are below, in case it helps. <property name='p2.statsURI' value='http://download.eclipse.org/stats/eclipse/updates/4.5-P-builds/P20150622-0925'/> <property name='download.stats' value='org.eclipse.jdt.java9patch_1.0.0.v20150622-0644_BETA_JAVA9'/> <property name='download.stats' value='org.eclipse.jdt.java9patch.source_1.0.0.v20150622-0644_BETA_JAVA9'/>
(In reply to David Williams from comment #62) > > Also added the metadata to enable "stats" for both features, runtime and > source (mostly for experience). I think they only update the "stats > database" once per day ... but, I installed one of each, (meaning runtime > would have been installed twice) so should be able to check tomorrow and see > if any stats are showing up for "java9patch". > I did confirm that "stats" show up, by running query at https://dev.eclipse.org/committers/committertools/stats.php Note, that entering just "java9patch" will give both p2 downloads, and also the downloads of the zipped repository (that most recent, official one, named ava9patch-P20150622-0925-repository.zip). But, if you want "p2 only", you can use the full feature name, of org.eclipse.jdt.java9patch For the record, a query on "java8patch" shows 35575 total downloads, but that is only for the zipped repository. I must not have done the p2 feature correctly? = = = = = = = = = Be sure to tell me if the "patch build page" is supposed to be made visible at some point. http://download.eclipse.org/eclipse/downloads/drops4/P20150622-0925/ And, not sure how bad this is ... but, the zipped repo, and batch compiler are being mirrored. I guess because the files themselves do not start with 'P'?
I would like to request for rebuild as we have seen people running into problems with the latest JRE 9. David, would you like a new bug or can we use this for further builds?
I've prefer a new one. We should have close this one with some target ... when did we do it? Mars Release? Luna Service? I'll just mark as "4.5" for now, and clone this one. = = = = = Off topic: Here's the "stats" for previous version ... not as many as I would have expected ... assuming the stats from Market Place work as expected. /stats/eclipse/updates/4.5-P-builds/P20150622-0925/org.eclipse.jdt.java9patch_1.0.0.v20150622-0644_BETA_JAVA9 373 /stats/eclipse/updates/4.5-P-builds/P20150622-0925/org.eclipse.jdt.java9patch.source_1.0.0.v20150622-0644_BETA_JAVA9 31
(In reply to David Williams from comment #65) > Off topic: > > Here's the "stats" for previous version ... not as many as I would have > expected ... assuming the stats from Market Place work as expected. I have release some more changes today that enable the support with JRE 8. Perhaps this will help a better adoption. I have merged master into BETA_JAVA9. Perhaps other JDT and PDE components would like too, before we do the next build? Copying Sarika and Noopur.
David, we are all set for the new build from the BETA_JAVA9 branch.
