Community
Participate
Working Groups
Build Identifier: WTP 3.2 The PublisherDelegate is meant to be the replacement of the old PublishTask framework to provide better support. In the old PublishTask, the PublishTask had the information on the list of delta kind information for the PublishTask to decide what publish task action to take on the modules. However, in the new PublishDelegate, the delta kind is not available on the task model so the PublishDelegate will not have enough information to decide what action to be done. This request to add the delta kind information of each module to the task module so that the PublishDelegate will have access to that info. Reproducible: Always
Angel, please assign this one to me.
Created attachment 167233 [details] v1.0 A new object org.eclipse.wst.server.core.TaskModel.TASK_DELTA_KINDS has been added to the task model of the PublishDelegate to pass the delta kind information to provide the equivalent information as the old PublishTask. Adopter do not need to react to this change unless the adopter want to make use of this new information.
This looks like something we should fix for 3.2, since it missing functionality. Since we are now in RC1 mode, this defect will require lead approval and one PMC vote as per http://wiki.eclipse.org/WTP_3.2_Ramp_down_Plan_for_Helios#RC1.
Created attachment 167327 [details] v1.1 Updated patch to deprecate old method to maintain compatibility.
Patch v1.1 looks good. Thanks for the adjustment to deprecating the old method. Elson, please fill in the PMC template and I can then raise it for PMC approval.
* 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. The PublisherDelegate is meant to be the replacement of the old PublishTask framework to provide better support. In the old PublishTask, the PublishTask had the information on the list of delta kind information for the PublishTask to decide what publish task action to take on the modules. Therefore, missing the delta information will mean that we are regressing in terms of functions from the new API. The adopter will not be able to handle the module removal case properly and cause problems on publish when a module has been removed. The existing adopter will not need to react to this change if they decided not to do so and things will still be working as before. They can be benefit from this change if they decided to extract the delta information from the task model. * Is there a work-around? If so, why do you believe the work-around is insufficient? There is no workaround on this problem. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Tested scenario: 1. If the deprecated method is being used for calling the publisher, the behaviour will be exactly the same as before the patch. 2. Also, tested the scenario where the new method is being use which is the default, the delta information gets passed on to the adopter correctly. * Give a brief technical overview. Who has reviewed this fix? Angel has reviewed this fix. * What is the risk associated with this fix? Risk should be minimal since the code will behave as before the change if the adopter do not explicitly use the new delta information.
Changes committed to HEAD, with a slight modification. There was an error in the javadoc where the deprecated method had a extra @param tag, I removed it and committed the code.
Changes released to HEAD
New Gerrit change created: https://git.eclipse.org/r/108940
