Bug 430637 - [hotbug] Java Version 1.8 of project facet java does not exist in Kepler SR2
Summary: [hotbug] Java Version 1.8 of project facet java does not exist in Kepler SR2
Status: RESOLVED FIXED
Alias: None
Product: WTP Common Tools
Classification: WebTools
Component: Faceted Project Framework (show other bugs)
Version: 3.5.2   Edit
Hardware: All All
: P1 critical with 6 votes (vote)
Target Milestone: 3.5.2 P   Edit
Assignee: Carl Anderson CLA
QA Contact: Konstantin Komissarchik CLA
URL:
Whiteboard: PMC
Keywords:
Depends on: 426884 428468 522750
Blocks:
  Show dependency tree
 
Reported: 2014-03-18 16:14 EDT by Fred Bricon CLA
Modified: 2017-09-25 11:11 EDT (History)
22 users (show)

See Also:
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-

Attachments
Feature Patch Repo (151.26 KB, application/x-zip-compressed)
2014-03-28 00:23 EDT, Konstantin Komissarchik CLA 		no flags Details
Feature Patch Source (143.34 KB, application/x-zip-compressed)
2014-03-28 00:25 EDT, Konstantin Komissarchik CLA 		no flags Details
Proposed patch for Java 8 facet support (8.68 KB, patch)
2014-03-28 22:00 EDT, Carl Anderson CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Fred Bricon CLA 2014-03-18 16:14:35 EDT 
+++ This bug was initially created as a clone of Bug #426884 +++

I have a problem with my maven webapp and jdk 1.8.
I have installed jdk 1.8, the JDT/Eclipse Java 8 Support (BETA) and Eclipse Maven Support (http://download.eclipse.org/technology/m2e/milestones/1.5)
After I changed the java version of my webapp to jdk 1.8 I got following error message when try to update my maven project.
"Could not update project webapp configuration
 Version 1.8 of project facet java does not exist"
Attached a screenshot.
Best regards
D.C
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Explain why you believe this is a stop-ship defect:
* It's impossible to create a Java EE project (with or without Maven) using the new Java 8 support released for Kepler SR2. 

Is there a work-around? If so, why do you believe the work-around is insufficient?
* There is no workaround.

How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added?
* A patch exists for the Luna stream (see bug #426884), but no unit tests are attached.

Give a brief technical overview. Who has reviewed this fix?
* The fix adds proper Java 8 Facet support when Java 8 is detected. The patch was created by Konstantin Komissarchik

What is the risk associated with this fix?
* Low. The patch is fairly straightforward


So we (Red Hat), would like to see this patch applied as a feature patch for Kepler SR2, along the Java 8 support patch that was released today.
Comment 1 Mike Milinkovich CLA 2014-03-27 14:34:41 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
Comment 2 Konstantin Komissarchik CLA 2014-03-27 17:18:32 EDT 
I will volunteer to put a feature patch together if no one else is working on this already.
Comment 3 Konstantin Komissarchik CLA 2014-03-28 00:23:07 EDT 
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.
Comment 4 Konstantin Komissarchik CLA 2014-03-28 00:25:30 EDT 
Created attachment 241355 [details]
Feature Patch Source

A zip of projects required to build the feature patch, in case it needs to be tweaked.
Comment 5 Olaf Krische CLA 2014-03-28 06:56:30 EDT 
Thank you, Konstantin. I hope this gets picked up fast. The pain here is quite big at the moment without.
Comment 6 Carl Anderson CLA 2014-03-28 20:56:45 EDT 
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.
Comment 7 Fred Bricon CLA 2014-03-28 21:01:15 EDT 
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 :/
Comment 8 Carl Anderson CLA 2014-03-28 22:00:58 EDT 
Created attachment 241409 [details]
Proposed patch for Java 8 facet support
Comment 9 Carl Anderson CLA 2014-03-28 22:04:10 EDT 
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).
Comment 10 Carl Anderson CLA 2014-03-29 08:06:28 EDT 
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.
Comment 11 Konstantin Komissarchik CLA 2014-03-29 11:58:08 EDT 
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.
Comment 12 Olaf Krische CLA 2014-03-31 06:18:43 EDT 
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.
Comment 13 Carl Anderson CLA 2014-03-31 09:59:45 EDT 
(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?
Comment 14 Konstantin Komissarchik CLA 2014-03-31 11:49:00 EDT 
> 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.
Comment 15 Fred Bricon CLA 2014-03-31 12:03:37 EDT 
I tested the patch works with Kepler SR2 + the JDT/Java 8 patch + m2e 1.4.1 from bug #431546
Comment 16 Carl Anderson CLA 2014-04-01 09:45:09 EDT 
(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.
Comment 17 Konstantin Komissarchik CLA 2014-04-01 10:19:51 EDT 
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.
Comment 18 Nitin Dahyabhai CLA 2014-05-27 15:42:07 EDT 
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?
Comment 19 Carl Anderson CLA 2014-05-28 09:38:31 EDT 
(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.