Community
Participate
Working Groups
Everyone remember bug 306627? Ready for more fun? Thought I'd open this bug to track progress and/or experiences and/or questions, if they come up. Eventually (closer to M6) we can do some "tests" to see who's converted, and who's not. I'm sure by now everyone knows there is a new Eclipse license (SUA) that must be used in new releases, especially for Indigo (bug 316152), And everyone probably knows there is new support which should make future changes (after this one) easier (bug 306818). But you might not know that Kim Moir wrote a very helpful blog entry on "how to" use the new license-by-reference support in 3.7 M5 PDE build. See http://relengofthenerds.blogspot.com/2011/01/implementing-shared-licenses-with-37m5.html And, pretty sure you do not know that I updated my famous "license consistency" tool to make migrating to the new type of license support a little more automated. But, not entirely automated ... lower your expectations ... some careful checking and "hand editing" will still be required. See http://wiki.eclipse.org/WTP/Releng/Tools So, eventually we'll get some "reports" in here, but suspect it is a little early to run any, since the support just came in M5, doubt too many people have converted yet. Thought it'd be useful to have this bug open, though, in case people had questions, or learned anything from experience. For example, here's one ... In WTP, we've converted some, and all seems to work fine (following Kim's excellent directions) but we do see following message in our build logs .... = = = = The entry feature@org.eclipse.license,1.0.0.qualifier has not been found. The entry feature@org.eclipse.license has been used instead. = = = = Is that normal? For the feature attributes, we specify license-feature="org.eclipse.license" license-feature-version="1.0.0.qualifier" (and specify exact qualifier in the map file) Is that not quite right, should we spec exact qualifier, even in feature.xml? Or ... a glitch in PDE builder and the log message should be ignored for now? Thanks everyone, Let the fun begin!
Ok, I add to the fun... :-) I already changed to the new license for the modeling.gmp.graphiti project, but by exchanging the files manually inside our projects. That is because we use a Buckminster build on hudson.eclipse.org and there is no Buckminster using PDE 3.7 build available. Are there any plans to make a new Buckminster version available that supports this license-by-reference feature? I know that would be quite early, but well there's this eat-you-own-dogfood-thing... ;-) Definitely not a real issue for me, just a question. Michael
David, I think you can safely ignore the error message.
>license-feature="org.eclipse.license" >license-feature-version="1.0.0.qualifier" It is very good and all, but still it is incompatible with 3.6, right? Branching the whole project for 3.7 just because of something this minor looks really amusing to me. So, is there any way to use this interesting feature at low costs? If not, then, as they say, "one old friend is better than a two new ones", meaning that the stable and compatible solution is still better despite being deprecated. P.S. So, could anyone point me on how to befriend this fine feature with 3.6 (because actually I really liked the whole idea of reducing the amount of copied license files)? :)
(In reply to comment #3) > Branching the whole project for 3.7 just because of something this minor looks > really amusing to me. So, is there any way to use this interesting feature at > low costs? If not, then, as they say, "one old friend is better than a two new > ones", meaning that the stable and compatible solution is still better despite > being deprecated. The license substitution support is only in PDE 3.7/Indigo. So, to make use of it, you must use a *builder* that is based on 3.7. This does not imply anything about the dependencies of the software being built. I.e., you could use PDE from Indigo to build software that is based on the Helios version of the platform. The license substitution support is purely a build-time concept, with no dependencies at install-time or run-time. By "stable and compatible solution", I assume you mean updating all license files by hand or using David's tool. That is certainly a viable option, especially if you only have a small number of features in your project. To be clear, nothing was deprecated here - license features are a new concept that can be used as a way of authoring and managing feature license info, but you are not compelled to use them. For a small project or plugin the concept of license features would be too heavy weight.
[repeating much of what John said, since I'd already typed it in.] (In reply to comment #3) > >license-feature="org.eclipse.license" > >license-feature-version="1.0.0.qualifier" > > It is very good and all, but still it is incompatible with 3.6, right? > Sort of. You can put these attributes in your feature.xml file, and they will show as "unrecognized attribute" in a 3.6 IDE. (There's preferences to change from error, to warning, to ignore ... but, this applies to all unrecognized attributes, of course). But sort of not. These attributes are only used at "build time" so, it is conceivable someone could build with a 3.7 based PDE builder, and then deliver to 3.6 clients. Once built, the licenses and properties, etc., look as they did before .. they are just "pulled in" during the build, instead of always being there as part of the project in your SCM. So ... won't work for everyone ... but some people might want to do that. But, let me extra clear ... a "new license" is not required for anything "in a maintenance release". We are finished with our last overall Helios maintenance release ... but of course any project is free to have their own ... but if you do ... I suggest you might want to use the "old" license in the original release just so it still "matches" all the other licenses you'd be installing with ... in which case, why bother migrating to a new license support style. But ... each project is free to decide _how_ to implement ... all we ask for Indigo is that we all use the same one, so users have an easier time of it. I knew this would be fun :)
Thanks for answers. I have something about 10 features with license files, so it will definitely be more fun to update license files just once but not ten times in a row. And PDE build do actually remove these incompatible attributes at build time, but 3.7 is still at the stage where it could be used for running builds at most but not for the plug-in development (at least JDT works way more funny than in 3.6). :) Then, it seems like features in Subversive are already up to date regarding license files matter, so I've decided to wait a little before introducing the license feature into the Subversive project. P.S. Thanks again for such a detailed answers!
I just ran my tool to check license consistency, based on the Indigo M7 repository. Below is the summary for M6 (complete details attached): Summary: ======================= Features with conforming license: 127 Features with different license: 623 Features with no license: 1 Features with extra licenses: 0 ======================= Features with no license: ======================= org.eclipse.jwt.feature.feature.group 1.0.0.v20100719-0900-7N--FJdMh0gj33jLjjgg
Created attachment 194188 [details] License consistency details for Indigo M6
Summary for M7: Summary: ======================= Features with conforming license: 320 Features with different license: 453 Features with no license: 1 Features with extra licenses: 0 ======================= I'll attach an updated full listing after RC1 declares tomorrow.
Not perfect, but better than where we were a few weeks ago. I suggest if a projects sees any of their features in the RC4 report as still using 2010 licenses, that you open a bug on yourself to fix it at some point, especially if the feature is changing anyway, in maintenance. Just as well get caught up! ... we will continue to measure and flag the deviants. But, thanks for the great improvements! Indigo will have a much better appearance to most users now without so many variations. http://build.eclipse.org/indigo/simrel/reports/licenseConsistency.html # Repository ('repoURLToTest'): file:///home/data/httpd/download.eclipse.org/releases/staging # License Consistency Summary: ======================= # Features with conforming (2011) license: 629 # Features with old (2010) license: 195 # Features with different license: 3 # Features with no license: 0 # Features with extra licenses: 0 # ======================= # Details: ======================= # Features with no license: ======================= # Features with different license: ======================= # org.eclipse.riena.build.feature.core.sdk.feature.group # org.eclipse.riena.build.feature.samples.sdk.feature.group # org.eclipse.riena.build.feature.sdk.feature.group #
