Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] IP Logs were due last Friday


I clicked on some of the jar files that were flagged in the tools.ptp project and they appear to be from releases from years ago (such as 1.0 and galileo). Is there any way to turn these off, or otherwise how should these be dealt with?


On May 29, 2013, at 6:58 PM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:

Greetings folks.

Most projects have submitted their Kepler IP Logs for review. If you have submitted your IP Log, please accept my thanks. But keep reading, there's some good stuff below.

The deadline to submit IP Logs for Kepler was last Friday. If you have not yet submitted your IP log, you are late. Being late has a downstream effect that and adds stress to the process. If you have not already done so, please make it happen ASAP.

The deadline to submit your PMC-approved review materials to EMO is June 5/2013. Earlier is fine (better, even). Send me the document, or a link to the document along with a link to the public approval discussion with your PMC. Please do not be late. Let me know if you require assistance.

Please take a minute to use the Download Review tool (e.g. [1]) to review your project downloads before submitting your IP Log. Note that I've added a handy "Review Downloads" link on project pages in the PMI (you need to be logged in as a project committer). I use this tool as part of the review that I do before handing the log off to the IP team to complete the review.

This page displays the result of scanning your project's download directory for JAR files. It scans the file structure itself as well as the contents of any ZIP, JAR, and WAR files it finds (I only just added support for nested JARs in JAR files). The scan runs weekly on Friday afternoon. Contact me directly via email if you want me to manually invoke the scan.

The tool is not perfect, but it is generally useful for most projects (it fails miserably on the Eclipse project due--I believe--to the shear size of its download directory). It does sometimes report reasonable files as potential problems (this deficiency is noted on the page itself).

To function, the tool depends on a mapping from CQ to bundle file name pattern that I maintain. I update the mapping whenever I discover a bundle pattern that's not covered. The tool currently only considers the absolute file name, so it incorrectly identifies JARs that do not have version information in their name as potential issues (many 'ant' files for example). A future version--that considers the full file path--will reduce the number of false hits.

It also attempts to identify the inclusion of bundles from other Eclipse projects (and their corresponding third-party libraries) based on file paths. Some reports do include 'org.eclipse.*' hits in cases that the project is difficult to determine from the bundle name (the generally happens when a project does not follow the convention of using their project short name as the third segment in bundles). I have another mapping for exceptions that I update periodically. I'm considering adding an entry in the project metadata to allow projects to explicitly specify bundle patterns that belong them.

Please take a few minutes to review the project downloads every-once-in-a-while. There should almost never be a legitimate missing CQ warning in the report. The only case in which this should happen is if the project has been given parallel IP check in permission for a library in advance of full approval of the CQ.



Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
<Mail Attachment.html>
cross-project-issues-dev mailing list

Back to the top