Summary: | [hotbug] Java Version 1.8 of project facet java does not exist in Kepler SR2 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [WebTools] WTP Common Tools | Reporter: | Fred Bricon <fbricon> | ||||||||
Component: | Faceted Project Framework | Assignee: | Carl Anderson <ccc> | ||||||||
Status: | RESOLVED FIXED | QA Contact: | Konstantin Komissarchik <konstantin> | ||||||||
Severity: | critical | ||||||||||
Priority: | P1 | CC: | cbridgha, ccc, chris, chris, daniele.cascato, david_williams, eclipse, fbricon, kaloyan, konstantin, manderse, mike.milinkovich, naci.dai, neil.hauge, niko, public, raghunathan.srinivasan, sebastian.schneider, shr31223, thatnitind, tobias.gierke, wayne.beaton | ||||||||
Version: | 3.5.2 | Flags: | ccc:
pmc_approved?
(david_williams) raghunathan.srinivasan: pmc_approved+ ccc: pmc_approved? (naci.dai) neil.hauge: pmc_approved+ ccc: pmc_approved? (cbridgha) ccc: pmc_approved? (kaloyan) konstantin: review- |
||||||||
Target Milestone: | 3.5.2 P | ||||||||||
Hardware: | All | ||||||||||
OS: | All | ||||||||||
Whiteboard: | PMC | ||||||||||
Bug Depends on: | 426884, 428468, 522750 | ||||||||||
Bug Blocks: | |||||||||||
Attachments: |
|
Description
Fred Bricon
2014-03-18 16:14:35 EDT
I note that the two blockers (bug 426884 and bug 428468) are fixed. What needs to be done in order to resolve this one? Is there a feature patch available for WTP Kepler SR2? I am asking because as noted on the cross-projects list[1] the Eclipse Foundation would like to raise awareness of our community's support for Java 8. It has been pointed out that for this story to be complete, a working WTP would be nice as well :) Please advise. [1] http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10439.html I will volunteer to put a feature patch together if no one else is working on this already. Created attachment 241354 [details]
Feature Patch Repo
Finished patch repo for Kepler SR2. I don't have access to upload anything to WTP downloads area, so someone else will have to do the honors. The only caveat is that the repo isn't signed. It's been tested.
Created attachment 241355 [details]
Feature Patch Source
A zip of projects required to build the feature patch, in case it needs to be tweaked.
Thank you, Konstantin. I hope this gets picked up fast. The pain here is quite big at the moment without. Folks, we have a process. Fred should have opened this as a [hotbug_request], since until now it was not officially accepted as a hotbug. This is not a blocker, it is critical functionality. (And highest priority, thus P1.) I am taking the patch used for bug 426884 and tweaking it to fit a Kepler SR2 patch. Once this is made, an official, signed build will be done on build.eclipse.org, and then PMC approval will be sought to make a public patch. All of this is as per our documented processes, see http://wiki.eclipse.org/WTP/Hotbug_Policy and http://wiki.eclipse.org/WTP_PMC_Defect_Review for references. Note that making a publicly-available patch does not preclude us from participating in a Kepler SR3 release, should there be one. My apologies for opening this request as [hotbug] instead of [hotbug_request]. That was my intent. I should have re-re-re-read the hotbug policy faq :/ Created attachment 241409 [details]
Proposed patch for Java 8 facet support
The one thing I cannot easily do is to bump the prereq of org.eclipse.jdt.core to 3.9.50 - that would require installing the Kepler Java 8 JDT into our build, which is not an easy addition. If the PMC feels that that change is necessary, I can update the build infrastructure to do so (but it will take time). This patch is now available for testing from http://download.eclipse.org/webtools/patches/drops/R3.5.2/P-3.5.2-20140329045715/repository , and I am asking for PMC approval to include the patch into the WTP Kepler repository at http://download.eclipse.org/webtools/repository/kepler , thus officially making this a public patch. I am asking Konstantin to do one more review of what I have done to make sure that everything was done properly. Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This is a hotbug, and something that WTP and the Eclipse Foundation itself wants supported. Is there a work-around? If so, why do you believe the work-around is insufficient? There is no work-around. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? The fix has been tested by hand, the Java EE JUnit bucket has been run against this fix, and a patch build has been done. Also, this same fix has been rolled into the WTP 3.6 M7 builds, and is being tested there. Give a brief technical overview. Who has reviewed this fix? The Java 8 facet has been added to the plugin.xml, and three supporting classed were modified to handle it in a similar fashion to all of the previous Java facets. Konstantin coded the original patch for Luna, and I backported it to Kepler. The same feature patch was created to install the updated plugin as was created for WTP 3.2.5. As such, I would state that both Konstantin and myself have reviewed this fix. What is the risk associated with this fix? Medium - There has been enough testing done of this patch that I am satisfied that it can be included, but this patch has not had thorough testing (yet), and I was not able to force a prereq on the Java 8 JDT support for Kepler. However, note that this patch is something that a user must find and install for himself, and as such will not cause issues for the vast majority of Eclipse Kepler users. There are problems with this patch alternative or at least it doesn't follow typical Eclipse patch practices. First, each patch id should carry name/id of the problem it is patching so that if tomorrow we needed to patch an unrelated issue in the same feature, those two patches can co-exist in the same repo and the user can choose to install one or the other. Second, the patched plugin version should be [original-version].[original-qualifier]-[patch-id]. It is important to keep patching plugin version very close, but slightly higher than the patched plugin. You don't want to treat the version like you would a service release as that can mess up a future service release, for instance. Thirdly, the patch feature version is 3.5.2.qualifier. While that shouldn't cause any problems, it isn't what you typically do with patch versions. You typically start at 1.0.0 and count the revisions of fix for that one issue. I recommend that you use the source that I attached instead. In addition to the above, I took care to word and label the patch in a pattern consistent to that used for JDT and PDE patches, so that if we have an aggregate patch repo, the user will have a consistent experience across projects. Alright, 1. Installed fresh Eclipse Kepler SR2 for Java EE Developers Then through "new software": 2. Java8 Support: http://download.eclipse.org/eclipse/updates/4.3-P-builds/ 3. Java 8 Facets: http://download.eclipse.org/webtools/patches/drops/R3.5.2/P-3.5.2-20140329045715/repository 4. New m2e milestone: http://download.eclipse.org/technology/m2e/milestones/1.5 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=420848) Now everything seems to work fine for me again. Thanks. (In reply to Konstantin Komissarchik from comment #11) > There are problems with this patch alternative or at least it doesn't follow > typical Eclipse patch practices. First, each patch id should carry name/id > of the problem it is patching so that if tomorrow we needed to patch an > unrelated issue in the same feature, those two patches can co-exist in the > same repo and the user can choose to install one or the other. Second, the > patched plugin version should be > [original-version].[original-qualifier]-[patch-id]. It is important to keep > patching plugin version very close, but slightly higher than the patched > plugin. You don't want to treat the version like you would a service release > as that can mess up a future service release, for instance. Thirdly, the > patch feature version is 3.5.2.qualifier. While that shouldn't cause any > problems, it isn't what you typically do with patch versions. You typically > start at 1.0.0 and count the revisions of fix for that one issue. > > I recommend that you use the source that I attached instead. In addition to > the above, I took care to word and label the patch in a pattern consistent > to that used for JDT and PDE patches, so that if we have an aggregate patch > repo, the user will have a consistent experience across projects. Konstantin, before we begin a discussion about the feature patch and the plugin version id, one simple question: Are the changes to the Java classes and the plugin.xml correct? > one simple question: Are the changes to the Java classes and the plugin.xml
> correct?
These changes seem to be consistent with my original patch.
I tested the patch works with Kepler SR2 + the JDT/Java 8 patch + m2e 1.4.1 from bug #431546 (In reply to Konstantin Komissarchik from comment #11) > There are problems with this patch alternative or at least it doesn't follow > typical Eclipse patch practices. First, each patch id should carry name/id > of the problem it is patching so that if tomorrow we needed to patch an > unrelated issue in the same feature, those two patches can co-exist in the > same repo and the user can choose to install one or the other. Second, the > patched plugin version should be > [original-version].[original-qualifier]-[patch-id]. It is important to keep > patching plugin version very close, but slightly higher than the patched > plugin. You don't want to treat the version like you would a service release > as that can mess up a future service release, for instance. Thirdly, the > patch feature version is 3.5.2.qualifier. While that shouldn't cause any > problems, it isn't what you typically do with patch versions. You typically > start at 1.0.0 and count the revisions of fix for that one issue. > > I recommend that you use the source that I attached instead. In addition to > the above, I took care to word and label the patch in a pattern consistent > to that used for JDT and PDE patches, so that if we have an aggregate patch > repo, the user will have a consistent experience across projects. OK, let's start with- this patch follows standard WTP patch policy. This patch isn't a bug fix, where we would do it as you recommend, this is essentially a mini-release of a fix that should be made available to all WTP users. WTP has only done a handful of these over the last few years, and they are cumulative in nature - WTP 3.5.1 is one example, where two problems were severe enough to merit public patches that were put into the public repository- see bug 419804 and bug 419889 . Before that, for WTP 3.4.1, there was bug 390993. I can list more examples, but they all follow the same format. Now, JDT and PDE may release bug fixes with version ids like you mention, but notice that the JDT support for Java 8 does not have a lot of [original-version].[original-qualifier]-[patch-id] plugins... in fact, it has none. Also note that each Eclipse project is allowed to follow its own rules/behaviors, and this patch is consistent with the WTP rules and behaviors. And the patch that I provided is built/signed on build.eclipse.org. The PMC has approved the patch, and Konstantin has stated that the technical changes are correct, it is only the packaging. Unless there is objection by the PMC (which has had more than one day to review these changes, and has not objected), this is our patch build for adding the Java 8 facet to Kepler SR2. The advice I give is based on many years developing and managing several build systems, including packaging and distributing countless patches. Far more than WTP has ever shipped. You may choose to ignore it and I expect that I will be overruled, but my -1 vote stands. Do we have a page similar to https://wiki.eclipse.org/JDT/Eclipse_Java_8_Support_(BETA) with instructions on what to do for the patch? Is http://download.eclipse.org/webtools/patches/drops/R3.5.2/P-3.5.2-20140329045715/repository just what we point people to? (In reply to Nitin Dahyabhai from comment #18) > Do we have a page similar to > https://wiki.eclipse.org/JDT/Eclipse_Java_8_Support_(BETA) with instructions > on what to do for the patch? Is > http://download.eclipse.org/webtools/patches/drops/R3.5.2/P-3.5.2- > 20140329045715/repository just what we point people to? We do not (yet) have a page similar to the JDT one. Yes, we just point people to the repository - that link should also be on the overall Java 8 for Kepler page. And of course, the Java EE EPP was repackaged with this fix, for those that want to just download it that way. |