Community
Participate
Working Groups
Created attachment 178427 [details] patch In WTP 3.2 the import code was updated to use the selected runtime's highest supported version when importing projects with no deployment descriptor. However, this code does not affect modules that were imported as binary. The version for these modules can be determined by using JavaEEQuickPeek. However, this code currently just defaults the version to EE5 for binary modules that contain no DD. The attached patch updates the JavaEEQuickPeek to be consistent with the import operation and returns an EE6 version if the runtime supports it and EE5 if it does not.
approved.. changes are not actually that big, lots of repetitive fixes
* 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. On import, the JEE version is currently not consistent between binary and non-binary projects that have no deployment descriptor. For non-binary projects the version is EE 6 if the selected runtime supports it and EE 5 if it does not. The JavaEEQuickPeek class determines the versions for binary archives and just defaults them to EE 5 when they do not contain a deployment descriptor. * Is there a work-around? If so, why do you believe the work-around is insufficient? No workaround exists * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Existing JUnits have been run. * Give a brief technical overview. Who has reviewed this fix? The JavaEEQuickPeek code will be updated to be consistent with the import operation code. The returned JEE version will be based on the runtime's highest supported version. Chuck has reviewed this fix. * What is the risk associated with this fix? minimal - since no facet or deployment descriptor exist for these binary archives the version (whether EE 5 or EE 6) is not going to break anything. This API would be used primarily for display purposes.
My first thought was this was a relatively minor usability issue, but IMing with Chuck, he pointed out we've had a lot of complaints about usability of "dependency UI" and while good progress has been made on other fronts, this is a remaining issue that will be important to complete that overall usability story. And seems safe enough. (And, we'll have to rebuild anyway, to pick up versioning fixes).
code checked into both 32M and HEAD streams
