Community
Participate
Working Groups
What reports? Well ... I'm just getting them going. See http://build.eclipse.org/indigo/simrel/ They are not quite done, not "fully automated", and, I'm sure, still some bugs and hard to read portions ... not to mention much could be added. But, when some of us open bugs about "missing about.html files" or "bundles use only 3 part version numbers" or "inconsistent licenses" some ask "where can we get those tests". Until now, they "come from all over" (Orbit, Webtools, Platform) each time tweaked for the one place they were running and relateively hard to get set up again ... hard, such as, a full days worth of work. Often for the common repository, I just had the test code my workspace, customized to run against the common repository, often requiring a little hand editing to filter out some obvious junk, etc. But, I've started to collect some in the callisto cvs repository and have them running on hudson, though the output simply goes in a directory on build machine. So, for a look at things to come, see http://build.eclipse.org/indigo/simrel/ That was ran against a fairly old repository ... it must be 10 hours old by now ... but the reports will update when ever our staging repository is updated. I was going to start a wiki, but I still can't log in to the wiki (bug 347853), so will attach a short description in a file that will go into the wiki. In any case, wanted to have this bug open for quick, general discussion of anything that's obviously wrong about the reports or something that is not understandable or explained well. My goal is to have something useful by RC3.
Created attachment 197058 [details] A little more description of tests and code to go on a wiki soon
great tool, just really really what I always wanted (but didnt know how to achieve myself) on a side note, on the page http://build.eclipse.org/indigo/simrel/reports/licenseConsistency.html riena is listed as "feature using different license" which actually just was an old version of the eclipse license that the tool didnt seem to catch….. in any event I have fixed that for the next RC
(In reply to comment #2) > great tool, just really really what I always wanted (but didnt know how to > achieve myself) > same here, thank you for providing a central page to all your tools you run on each release train. Great work !
> ... > > riena is listed as "feature using different license" which actually just was an > old version of the eclipse license that the tool didnt seem to catch….. > Yes, from what I can see, that "different" license was one with a date of "2005", whereas the "old license" check is actually looking specifically for the 2010 license, which is when we started the "consistent license" effort. Hence, I'll improve the report to say "old 2010 license" to make that clearer. Anything other than 2010 or 2011 license will (still) be flagged as "different". Thanks,
I see slightly different numbers for license consistency in my code, but it could be due to using a different URL. I also don't check for "old" versus "different" license text. Repository URL: http://download.eclipse.org/releases/indigo/201105270900 Summary: ======================= Features with conforming license: 479 Features with different license: 319 Features with no license: 1 Features with extra licenses: 0 =======================
By the way, it is fantastic to see all these reports in one place, and auto-generated by the build. Great work!
*** Bug 347959 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > By the way, it is fantastic to see all these reports in one place, and > auto-generated by the build. Great work! +1 I'm embarrassed to see how many we missed with AMP -- coincidently a number of them (signing and SUA) have been fixed this week but didn't make it in -- but aside from going through say each licensing file hand by hand I had no way of knowing before whether I had missed something or not. For example, I'd gone through last year and I thought put all of the write artifacts into plugins and features but somehow missed a number of the about.html. So thanks, these automated tools are exactly what's needed to help the smaller projects conform.
On the BREE report, I have a project that has User Assistance components only, Welcome page intro, etc.. Interestingly, I get a warning when I set a required platform, even though I don't have a Java builder specified, only Schema and Manifest so I set the BREE just to make it go away.. I wonder what is triggering PDE to complain..perhaps that I have a classpath file defined..
Thanks for this tool. Is it possible to be notified when something is wrong with our project?
(In reply to comment #10) > Thanks for this tool. > > Is it possible to be notified when something is wrong with our project? Yes. Just as soon as someone implements it. :) Doubt that'll happen for Indigo, but hopefully next cycle. If you'd find it helpful, for now, you could subscribe to the RSS feed for _all_ "indigo.runReports" jobs, so you'd at least be notified of each run. But, for now, they are all "successful" even if a report has problems. I suspect we'll progressively make success/failure stricter and stricter, over tie.
Two recent issue have come up, I wanted to capture. 1. features can have edl-v10.html instead of epl-v10.html, so report should accept either. (That I can fix for last few runs). 2. the 4 part versioning test could maybe be improved to help catch typos in the 4th part qualifier. It is a fairly common problem to mistype this key word, such as something like 'qualfer' in which case that ends up being the qualifier literally, instead of substituting a more appropriate date/time type stamp. While we have no way of knowing what the "right" qualifier should look like, maybe we could list all those that start with 'q' or 'qu' or something, to help spot typos. That second one can wait till future (and maybe there's a better heuristics) .. but just wanted to capture the issue and idea. [Thanks, Miles].
Just to capture a small bug, when there are no unsigned jars (like there's supposed to be) then no "unsigned jars" file is created, so the (hard coded) link in our HTML page results in 404. Could put a dummy file there, or something for short term.
I think this bug has serviced as much purpose as it can. There's actually been lots of little improvements over the year, culminating in instructions on "how to run locally". http://wiki.eclipse.org/SimRel/Simultaneous_Release_Reports_Running_Locally While many more improvements can (and likely will) be made, seems best to handle those with new bugs.
