Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 356382

Summary:	Indigo SR1 version of jdt batch compiler is unsigned
Product:	[Eclipse Project] Platform	Reporter:	David Williams <david_williams>
Component:	Releng	Assignee:	Platform-Releng-Inbox <platform-releng-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	kim.moir
Version:	3.7.1
Target Milestone:	3.7.1
Hardware:	PC
OS:	Linux
Whiteboard:

Description David Williams

2011-08-31 14:24:48 EDT

I know there is some history here, but have forgotten details. But, I think at a high level, jetty uses batch compiler? But wants it separate from rest of JDT? 

Not sure if this is a regression ... or, if someone else is building/providing this unsigned jdt compiler. Feel free to "move" if this issue belongs to someone else. 

See "unsigned" report at 
http://build.eclipse.org/indigo/simrel/

namely, 
http://build.eclipse.org/indigo/simrel/reports/verifydiroutput/unsigned.txt

Comment 1 Kim Moir

2011-08-31 15:12:14 EDT

The reason that it's unsigned is that the batch compiler is a extracted from the jdt.core bundle.  

It's rather a pain to implement because you have to issue another signing request for one bundle after the master feature is signed. 

This came up with the PMC a few weeks ago and they said not to bother implementing it because the cost outweighed the benefit.

Comment 2 John Arthorne

2011-08-31 15:27:00 EDT

(In reply to comment #1)
> This came up with the PMC a few weeks ago and they said not to bother
> implementing it because the cost outweighed the benefit.

In particular, the batch compiler isn't a bundle that is installed by end users via the Eclipse UI. It is produced to be bundled with runtimes such as Jetty. So, the signature isn't used for install-time verification. The only benefit I can think of is runtime verification if you are running with a jar signature checking enabled. For performance reasons I suspect most web servers don't run that way.

Anyway, it is something we could do if there is an important reason for it,  but we don't want to add the complexity/brittleness of an extra signing call in our build if it can be avoided.

Comment 3 David Williams

2011-08-31 16:20:01 EDT

I am personally fine with it since not "installed by end user", it'd never show up in a dialog that "you are installing unsigned bundles". 

I suspect it would set a good example to document it to the Planning Council as a "known exception to the rule" ... but, we could just count this bugzilla entry as that documentation. (I'm not asking for extra work, and there's no hard and fast rule about how to document exceptions ... just that projects should document them). 

I will add it to the "exception list" in the repository reporting, so it will not keep showing up on unsigned list. 

Thank you very much. Glad to hear it didn't surprise you.