Closed reprogrammer closed 13 years ago
e4f428ffbf6824dddf11a422e1d1c01544156569 .. 1a345d457514cce242d59bdb1efe9e11c8df7a9e replaced the version specific feature patches by a single patch that becomes generic using the post processing scripts.
ce94e5ce6113e1b85ea878d7ad08dffc55117cb4 fixed the shebangs of the Ruby scripts based on the discussion with @vazeqxi.
Merged the branch widen-feature-patch-ranges
containing the fix for this issue into master
.
CodingSpectator modifies a few plug-ins of Eclipse, and installs these modified plug-ins using Eclipse feature patches. The feature patches are applied on the features that contain the modified plug-ins. The plug-ins that CodingSpectator modifies are parts of the JDT, Platform and UDC features. The current feature patching mechanism used by CodingSpectator is limited because it patches specific versions of the target features (JDT, Platform and UDC). Therefore, every time the user updates Eclipse to a newer version that changes any of the JDT, Platform and UDC features, the update mechanism goes through but CodingSpectator silently stops to operate, if CodingSpectator patches for the new version of Eclipse do not yet exist.
We have dealt with similar problems in issues #36, #37, #40 and #161. Since Eclipse might update the JDT and Platform and UDC features several times during the lifetime of our study, generating feature patches that target specific versions becomes tedious.
We have to either make our feature patch mechanism more flexible by generating a patch for a wider range of versions or prevent the user from updating Eclipse to a newer version for which CodingSpectator doesn't yet offer a patch. The solution mentioned but ignored in issue #40 may help us produce a more flexible patch. And, if we add a plug-in to the CodingSpectator feature that depends on modified versions of Eclipse plug-ins, Eclipse will prevent the user from updating to a newer version of Eclipse without CodingSpectator feature patches.