Community
Participate
Working Groups
In a given project managed by the deployment assembly - if a jar reference is in place (either in workspace or out.. if the jar is removed or renamed.... the UI doesn't handle the missing entry gracefully (I would expect a red X on the entry indicating the reference can't be resolved) When the page is openend after the delete - you get the message "The currently displayed page contains invalid values." --- completely broken. Only way to fix is to manually edit the .component file
I think the main problem here is that references that cannot be resolved are not even shown in the deployment assembly page, which can be really confusing. We should display all references, no matter if they can be resolved or not, and shown an error (or warning?) for those entries that cannot be resolved
The problem isn't just hte UI but the underlying core API, which ignores references that "do not exist" and simply do not return them at all. This should be fixed, yeah.
Yes, the method VirtualComponent.getReferences(Map<String, Object> options) returns only the references that exist. This behavior is there since 2006. So, instead of just changing this behavior to return all the references (no matter if they exist or not), I was thinking to add a new constant in IVirtualComponent to allow callers to include the non-existing references as well. I'm afraid that if we start including the non-existing references, we could break some adopter's code.
Created attachment 201591 [details] Proposed patch (R3_2_maintenance) This is a proposed patch, which will show a new error (UI change)in the deployment descriptor when an entry (e.g. a jar, a folder, a project) cannot be found, because it was moved, renamed or deleted. This patch was created using the code form R3_2_maintenance.
Summary of the main changes: - EARVirtualComponent and J2EEModuleVirtualComponent: They now handle a new constant to retrive all the references, included the references to elements that cannot be resolved - plugin.xml in org.eclipse.jst.j2ee.ui: Added a new verifier for Java EE modules (EAR, EJB, Web project, web fragments, connector, app client and utility). This verifier will handle these modules and any target runtime (this verifier will run for any runtime, even if there is no runtime at all), and will do this basic validation for missing entries. - NonResolvableVirtualComponent: a new class for virtual components whose underlying project is not accessible - VirtualComponent: Chane the method getAllReferences() to return all references, including the possible deleted references (the javadoc of this method currently mentions that this method returns possibly deleted references, but that was not true) - IVirtualComponent: add a new constant to retrieve all the references. - DefaultDeploymentAssemblyVerifier: New class. This verifier will do basic validation for missing entries in the deployment assembly page - VerifierRegistry: Allow verifiers not related to a target runtime.
approved
PMC Review requested due to UI change * 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. Validating and showing errors in case entries in the deployment assembly page do not exist is a basic functionality that should be included, to prevent errors. * Is there a work-around? If so, why do you believe the work-around is insufficient? Editing the .component file manually * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? The code has been tested manually. * Give a brief technical overview. Who has reviewed this fix? The fix consist on showing a new error message for each entry in the deployment assembly page that cannot be resolved. For example, a reference to a project, or a jar (both external or from workspace), or a folder. * What is the risk associated with this fix? Low.
Quite a big patch, but since Chuck has reviewed and approved it, then I am fine.
Created attachment 201954 [details] Version 2 of patch (R3_2_maintenance) While I was preparing to commit the first patch, I realized that files org.eclipse.wst.common.modulecore.ui/src/org/eclipse/wst/common/componentcore/ui/messages.properties and org.eclipse.wst.common.modulecore.ui/src/org/eclipse/wst/common/componentcore/ui/Messages.java were affected by another bug (354768). So I'm updating the patch so it can be applied after the patch for bug 354768. The changes are minimal compared with the first version of the patch.
Created attachment 202007 [details] Same patch, but for HEAD I had to create a new version of the patch for HEAD, because the file org.eclipse.wst.common.modulecore/modulecore-src/org/eclipse/wst/common/componentcore/internal/StructureEdit.java was changed in HEAD, but not in R3_2_maintenance, so the patch for R3_2_maintenance cannot be directly applied to HEAD. I'm attaching the patch for HEAD.
Code committed to R3_2_maintenance and HEAD for WTP 3.2.5, 3.3.1 and 3.4.
