> The following bundle is incorrectly listed under
Java Bundles with a BREE;" it
is a Java bundle:
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.)
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!
Sam Davis <sam.davis@xxxxxxxxxxx>
Cross project issues
02/27/2015 02:36 PM
Legal, structural, and configuration requirements for simultaneous release
On Fri, Feb 27, 2015 at 10:13 AM, Wayne Beaton <wayne@xxxxxxxxxxx>
> We have some great scripts that take care of making sure that projects
participating in the simultaneous release are doing the right sorts of
> 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.
> Wayne Beaton
> The Eclipse Foundation
> cross-project-issues-dev mailing list
> 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
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev