Community
Participate
Working Groups
There is a new Eclipse license (EUA) that includes a new line about EDL. And, rather than do a "mass file/property update" we should move to the new "PDE build" technique to reference the license file, which is then included at build-time, so future updates are easier. This issue is discussed in Kim's blog post; http://relengofthenerds.blogspot.com/2011/01/implementing-shared-licenses-with-37m5.html I'll try a few test features ... say, xml features, just to make sure it works as expected then provide patches/instructions for a mass update.
So far, I've tried the basic changes "by hand" in the XML features, and from a casual inspection, seems to work as advertised. org.eclipse.wst.xml_core.feature org.eclipse.wst.xml_sdk.feature org.eclipse.wst.xml_tests.feature org.eclipse.wst.xml_ui.feature org.eclipse.wst.xml_userdoc.feature I wrote a small utility to automate some of the changes, such as removing files, and update feature.properties and build.properties. While the utility acts on all features in workspace, I committed and released only these wst.common ones ... to verify that they also work ok in a build, and I didn't overlook anything. org.eclipse.wst.common_core.feature org.eclipse.wst.common_sdk.feature org.eclipse.wst.common_tests.feature org.eclipse.wst.common_ui.feature org.eclipse.wst.common.fproj.feature org.eclipse.wst.common.fproj.sdk.feature
On the surface, seems like the new licenses are being picked up as desired, since our license consistency test shows: # Features with conforming license: 13 # Features with different license: 92 So, I'll continue to switch over those projects I have commit rights too ... and eventually provide patches to those I don't. (probably next week).
Just to be explicit, if anyone does not want to move to the new type of license support (where it is retrieved dynamically) then please leave a note here you'd like to "opt out". If you do opt out, you'll need to update to the new EUA as you normally would ... now, and in the future. That is the advantage of the new dynamic technique ... for future changes, there would be little or no change to make to pick up the new license version. But, otherwise, have to "manually" update all the files/feature properties, etc., everything the license changes. I can think of two reasons why someone might not want or be able to move to that new form of license support: a) they do "feature builds" using something other than PDE builder or b) for some reason they can not move to a 37M5 based PDE build (that wouldn't be the case for anything being built as part of WTP's main build ... but, just saying, in general, that's a reason ... but, everyone should be able to, as far as I know).
This was fixed in M6. Thanks.
