> The following bundle is incorrectly listed under "Non Java Bundles with a BREE;" it is a Java bundle: > org.eclipse.mylyn.wikitext.markdown.ui_2.4.0.v20150113-0050.jar
Not too many people care about this level of detail (other than me), and technically, it is not a "requirement", per se, but, I think such reports are "educational". So, I'll explain why it's considered a "non-Java" bundle, and then either you (everyone) will be better educated ... or, even better ... someone can explain that I'm wrong, and then I will be better educated. It is a non-Java bundle because there are no ".class" files in it. Therefore, a "BREE" is not needed. All I see, in it, is $ find . -type f ./help/cheatSheet/Markdown.md ./META-INF/eclipse.inf ./META-INF/ECLIPSE_.SF ./META-INF/ECLIPSE_.RSA ./META-INF/MANIFEST.MF ./plugin.properties ./plugin.xml ./about.html This, we'd call it a "resource only" bundle. This does not mean it does not belong on a classpath, etc., but it itself does not use "Java" so a BREE is not needed ... it should be "compatible" with any level of Java. (Corrections welcome.) > I'm seeing a bunch of warnings saying "This jar contains entries whose signer certificate will expire within six months" at > http://build.eclipse.org/simrel/mars/reporeports/reports/verifydiroutput/verified.txt but I don't know what that means or what to do about it (if anything). First, to reassure you, once it does "expire", it will still be considered "valid", because we "sign" our jars using TSA (Time Stamp Authority) so in the future, code that checks if it is valid, can see that "it was valid at the time it was signed, so it is still valid" (checking for "revoked" certificates, and similar, is a separate part of checking its validity). But, as to what it means ... other than, did I forget to mention this? ... the certificate is going to be updated with "renewed" version on Monday. See Bug 450783 - Time to update signing certificate? I asked webmasters to wait until "after Luna SR2" ... just to make sure there was no chance for "funny things to happen" close to the end of the release. In theory, for nearly all use-cases, it would not matter if some bundles signed with one certificate, and other bundles signed with another certificate ... but, there are some special cases where it does (usually involving "split packages" or "fragments") where two bundles must be signed with the same certificate, (and then only if using "pure Java" with strict verification turned on). While none of us are positive what Java considers a same or different certificate (such as, if it includes one that is "renewed" -- my guess is 'yes, different') I thought it best not to risk it. Probably more than you wanted to know, eh? Thanks for asking! From: Sam Davis <[email protected]> To: Cross project issues <[email protected]>, Date: 02/27/2015 02:36 PM Subject: Re: [cross-project-issues-dev] Legal, structural, and configuration requirements for simultaneous release participants Sent by: [email protected] The following bundle is incorrectly listed under "Non Java Bundles with a BREE;" it is a Java bundle: org.eclipse.mylyn.wikitext.markdown.ui_2.4.0.v20150113-0050.jar I'm seeing a bunch of warnings saying "This jar contains entries whose signer certificate will expire within six months"at http://build.eclipse.org/simrel/mars/reporeports/reports/verifydiroutput/verified.txt but I don't know what that means or what to do about it (if anything). Sam -- Sam Davis Software Engineer, Tasktop Dev Committer, Eclipse Mylyn http://tasktop.com On Fri, Feb 27, 2015 at 10:13 AM, Wayne Beaton <[email protected]> wrote: > > Greetings. > > We have some great scripts that take care of making sure that projects participating in the simultaneous release are doing the right sorts of things. > > http://build.eclipse.org/simrel/mars/reporeports/ > > I've already started opening some bugs to get projects to clean up. While I do enjoy every opportunity to interact directly with projects (e.g. file bugs to address any issues), it would be great if you could spend a few minutes to look at the lists and make sure that your project's artifacts aren't in violation. Naturally, if you feel that your project is listed incorrectly, or there is some sort of consideration that needs to be granted, please bring to the attention of this group. > > I'll start public shaming in the week following EclipseCon. I'd love to have this nailed down for M6. > > Speaking of EclipseCon... The Eclipse Foundation will have a booth in the exhibit hall. We have a few slots open for any projects that want to do a demonstration. To register, just add your name/project in an empty an slot in the table. > > https://wiki.eclipse.org/EclipseCon/Booth > > Wayne > -- > Wayne Beaton > @waynebeaton > The Eclipse Foundation > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
