Community
Participate
Working Groups
3.7 M4. Adopt new feature that allows to share the license file.
Since this involves modifying all the feature.xml files, I think we should also take the opportunity to remove all the update and discovery URLs from our feature.xml files. Those URLs are now specified by our products, and in p2 there is no association with repositories at the feature granularity so they are not needed. Removing them gives product builders full control over where updates for their product come from. These URLs seem to be badly out of date anyway (referring to 3.5 repo in some cases). After those two changes, the only thing that will need updating every year is the feature version. Since we have tooling to help remind us when these need changing, overall it should simplify our feature management quite a bit.
(In reply to comment #1) > I think we should also > take the opportunity to remove all the update and discovery URLs from our > feature.xml files. Those URLs are now specified by our products, and in p2 > there is no association with repositories at the feature granularity so they > are not needed. I guess the only reason for leaving it in would be to give a hint for those who check out the feature directly from the repository but that's not enough to leave it in.
*** Bug 333352 has been marked as a duplicate of this bug. ***
List of eclipse and equinox features that need to be changed org.eclipse.core.runtime.feature - missing license org.eclipse.cvs org.eclipse.cvs.source org.eclipse.equinox.compendium.sdk org.eclipse.equinox.core.feature org.eclipse.equinox.core.sdk org.eclipse.equinox.executable org.eclipse.equinox.jmx.client.feature - missing license org.eclipse.equinox.jmx.common.feature - missing license org.eclipse.equinox.jmx.server.feature - missing license org.eclipse.equinox.p2.core.feature org.eclipse.equinox.p2.discovery.feature org.eclipse.equinox.p2.extras.feature org.eclipse.equinox.p2.sdk org.eclipse.equinox.p2.user.ui org.eclipse.equinox.p2.user.ui.source org.eclipse.equinox.sdk org.eclipse.equinox.server.core org.eclipse.equinox.server.jetty org.eclipse.equinox.server.p2 org.eclipse.equinox.server.servletbridge org.eclipse.equinox.serverside.sdk org.eclipse.equinox.server.simple org.eclipse.equinox.starterkit.product.feature org.eclipse.equinox.weaving.sdk org.eclipse.help org.eclipse.help.source org.eclipse.jdt org.eclipse.jdt.source org.eclipse.pde org.eclipse.pde.api.tools.ee.fragments org.eclipse.pde.build.feature org.eclipse.pde.build.product.feature org.eclipse.pde.junit.runtime.addon org.eclipse.pde.junit.runtime.standalone org.eclipse.pde.source org.eclipse.platform org.eclipse.platform.source org.eclipse.rcp org.eclipse.rcp.source org.eclipse.releng.tools org.eclipse.sdk org.eclipse.sdk.examples org.eclipse.sdk.examples.source org.eclipse.sdk.tests org.eclipse.test
For the Eclipse project licenses, I plan to include them from the RCP feature. For the Equinox project feature licenses, I plan to include them from the org.eclipse.equinox.sdk feature. John, does this sound okay? Separating them now in case the two projects have separate builds at some time in the future.
Created attachment 186090 [details] patch for sdk feature Patch for sdk feature, will add patches for 45 remaining features when the test build is successful...
Created attachment 186095 [details] patch to remove exisiting license and update build.properties
I talked to Dean about this and he suggested it might be a better idea to create a standalone license feature. Thus it would have a version that would only reflect the version of the license. If I use the rcp feature, we will have to update all the features each time the rcp feature version is incremented.
Created attachment 186233 [details] screen shot I tried adding a license feature today and it worked.. sort of. The license feature is included in the rcp feature. However, when I look at the feature lists in the installation details, the license feature is as including containing all the other features, not the SDK feature. I'll attach a screen shot.
Ping me today I'd like to take a look and the configuration.
Created attachment 186300 [details] screen shot Talked to Dean this morning and he mentioned that I didn't need to include the license feature in the rcp feature since it would be included automatically. In any case, the license feature still appears in the installation details and the attached screen shot shows. Is this a problem?
I'm very puzzled by this. The patch as released does not actually build or deploy the license feature. The contents of the license feature folder are simply used to replace the appropriate information in the features being built. The license feature itself should not be showing up in the build results at all. Are you sure it is not being required directly by some feature?
No, it's not required or included in any features. It's just referenced as the license.
Talked to Kim and it appears that the "License Feature" is not actually built as part of the repository and does not end up in the feataure directory of the built Eclipse ... so the question is how is it ending up on that UI page. I'm going to take a look at it.
Andrew, as we discussed at lunch, I checked the metadata and org.eclipse.license wasn't there. Here is the build directory if you are interested in looking at it /builds/N201101071154
I believe this is just the org.eclipse.license/feature.properties entries overwriting the properties in org.eclipse.sdk/feature.properties In particular, featureName and description. In the UI you are still seeing the org.eclipse.sdk feature there, it just has had its name and description changed. Removing featureName and description (and also perhaps providerName & updateSiteName) from org.eclipse.license/feature.properties should fix things. Dean, this is why I had suggested before that LicenseReplaceTask should only copy over the properties we know are associated with the license. However, I'm not sure why the build didn't just fail, there is code there that should throw exception on conflicting properties. We should figure out why this didn't happen.
Thanks Andrew, I'm running a test build now with those changes.
I made the changes that Andrew suggested last night for N20110112-2000 and the license feature still appears as "featureName" in the about's configuration details. I'll attach a screen shot. Also, the releng tests need to be modified to skip checking for about.htmls in the modified features.
Created attachment 186723 [details] screen shot from N20110112-2000
(In reply to comment #18) > Also, the releng tests need to be modified to skip checking for about.htmls in > the modified features. Is there not still a requirement for the deployed features to have about.htmls? The license feature can contribute an about.html to each feature in the same way it contributes license text. Just add it to the org.eclipse.license feature and include it in org.eclipse.license/build.properties/bin.includes
Sorry Andrew, I meant "license.html" but wrote "about.html". The missing license.html files in the feature are causing releng failures.
Created attachment 186736 [details] patch
Created attachment 186737 [details] patch
Created attachment 186942 [details] patch for help,pde,platform,jdt,cvs, sdk.examples and org.eclipse.test features
Dean, how are the sourceTemplate features supposed to be configured so the source features are generated with the appropriate license? I updated the build.properties to exclude the license files and removed the licenses from the directory assuming that they would be included from the binary feature but this is not the case.
Source features should not be different from any other feature. As long as the source feature.xml file references a license feature, and that license feature is referenced in the map file for the build the license should be incorporated into the source feature just as it is for the other features you have been building.
The source features don't include a feature.xml. The feature.xmls are generated from the binary feature. Looking at the generated source feature.xml for rcp, it doesn't include the license -bash-3.00$ cat feature.xml <?xml version="1.0" encoding="UTF-8"?> <feature id="org.eclipse.rcp.source" version="3.7.0.N20110117-2000-9FB3FkSFPw545348B46-10z" label="%featureName" provider-name="%providerName" image="eclipse_update_120.jpg" > <description > %description </description> <copyright > %copyright </copyright> <license url="%licenseURL"> %license </license> <url> <update url="http://download.eclipse.org/eclipse/updates/3.5" label="%updateSiteName"/> </url> <plugin id="com.ibm.icu.source" version="4.2.1.v20100412" unpack="false"/> <plugin id="org.eclipse.core.commands.source" version="3.6.0.N2011011 .... You can look at the sourceFeatureTemplates here http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.sdk-feature/features/org.eclipse.rcp/sourceTemplateFeature/
Looks like I missed a change required in PDE when generating source features. I think I have a fix that I am testing now and can release. Assuming that works, I guess that means you would need to patch the builder with the change as well ... as long as you felt comfortable doing that. Otherwise, I guess we would have to wait until after M5 when you would consume the fix normally.
There's somethin' wrong with the build today I don't know what it is Something's wrong with our license files We're livin' on the edge We're livin' on the edge We're livin' on the edge We're livin' on the edge I'm happy to patch our builder. As discussed earlier in my office, if you could export me a new pde build bundle with your fix, this would be great. I'll run a test build.
Dean, the new pde build you gave me didn't work - the license isn't included. -bash-3.00$ pwd (on eclipsebuildserv) /builds/N201101181125/src/features/org.eclipse.rcp.source -bash-3.00$ more feature.xml <?xml version="1.0" encoding="UTF-8"?> <feature id="org.eclipse.rcp.source" version="3.7.0.N20110118-1125-9FB3FkSFPw545348C44248u" label="%featureName" provider-name="%providerName" image="eclipse_update_120.jpg" > <description > %description </description> <copyright > %copyright </copyright> <license url="%licenseURL"> %license </license> <url>
I'm debugging the problem now. Initial findings looks like I missed some changes in SourceGenerator that need to be updated.... Like SourceGenerator.writeFeature(). I'll let you know when I have something.
Created attachment 187341 [details] more patches For equinox.sdk, pde.api.tools.fragments, pde.build.feature, pde.build.product.feature, pde.junit.runtime.addon, pde.junit.runtime.standalone,org.eclipse.releng.tools
John, do you want an equinox committer to apply patches for the remaining 20 equinox features to patch or can I do it?
Created attachment 187386 [details] patch patch for remaining equinox features
Created attachment 187390 [details] more patches for equinox and sdk.tests feature
(In reply to comment #33) > John, do you want an equinox committer to apply patches for the remaining 20 > equinox features to patch or can I do it? Probably easiest for you to do it - I suspect there aren't many with commit rights to all equinox features (I certainly don't).
Verified that all the features have their licenses included from the license feature in I20110124-0916. I had to revert the changes for org.eclipse.equinox.executable and org.eclipse.sdk.tests because they caused the build to fail, I think they may have custom build scripts.
Created attachment 187776 [details] patch for sdk.tests and equinox.executable
changing the milestone, the sdk.tests and equinox executable still use the old format.
I checked out 'head' of org.eclipse.license, and the license.html file seemed like the old one (and didn't match the text in the feature.properties file). It should be updated, right? Or have I misunderstood. Also ... I am assuming it is normal and expected that other projects can/should use this same "license feature", even if from your project's repo, in order to ensure consistency, right? If so, there will need to be some way to well document which tagged version we should use in our map files. (I was going to use the version in your blog, v20110121, but see that is already out of date). I guess we could simply check your map files published with a build ... but, would be nice if there as an easier, more noticeable, if not automatic way. Any suggestions?
Created attachment 188456 [details] proposed patch for license.html and epl-v10.html I also noticed the epl-v10.html document is one of the "old" versions that has a bunch of "microsoft word" generated tags and styles, instead of the more modern, neutral one, that is currently on eclipse.org/legal site, at http://www.eclipse.org/org/documents/epl-v10.php see the link on the right, which points to http://www.eclipse.org/org/documents/epl-v10.html (and you can use "save as ..." from the php page to get a local file of raw html)
David, the update to new license file is in progress in bug 336092. I updated to use the shared license before we had the new license file.
Created attachment 189328 [details] patch to include license feature when generating launcher products
Remaining two features are fixed. Tagged for I-build and updated builder.
I upgraded to I20110225 this morning and saw two licenses (4.1 build). Was the change made for both streams, or is there a separate bug for 4.1 adopting it?
I didn't change the 4.1 specific features. The 3.7 features that 4.1 consumes unchanged should be okay assuming that they use a M6 or greater as their builder. Andrew, what version of basebuilder does the 4.1 build use?
The 4.1 SDK is using a basebuilder tagged v20101019 with a few additions (ie git). The 4.1 build is using a R4_HEAD branched version of the org.eclipse.rcp, org.eclipse.platform & org.eclipse.sdk features, this branch does not appear to have the license changes. I raised bug 338720
