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

Bug 297024

Summary:	abstract getTemplatesStore() changed from protected to public in AbstractTemplatesPage
Product:	[Eclipse Project] Platform	Reporter:	David Carver <d_a_carver>
Component:	Text	Assignee:	Dani Megert <daniel_megert>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	david_williams, markus.kell.r, remy.suen
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description David Carver

2009-12-06 10:04:05 EST

In org.eclipse.ui.workbench.texteditor the AbstractTemplatesPage abstract method getTemplatesStore() was changed from a proected method to a public method.  This is causing code that was compiled with eclipse 3.5 to break when trying to compile against eclipse 3.6.

In particular the Web Tools platform XSL Tools component makes use of this class to provide a TemplatesPage for XSL templates.  This is a non-backwards compatible API change.

Comment 1 Markus Keller

2009-12-06 18:32:00 EST

> This is a non-backwards compatible API change.

See bug 296439 comment 9. This a binary-compatible change, but it's not source-compatible. http://wiki.eclipse.org/Evolving_Java-based_APIs allows to break source compatibility if deemed necessary.

Assigning to Dani for the final decision.

Comment 2 David Williams

2009-12-06 18:53:37 EST

I agree binary compatibility is most important, but ... many adopters will still consider it breaking change (that is, if they have to change anything, they consider it a breaking). One goal of many adopters is specifically to have a common code base they can compile with either prereq. While its beyond the scope of this particular bug, I wonder if its time to re-think the "Evolving" wiki page?

Comment 3 David Carver

2009-12-06 19:03:15 EST

The work around I have done is to change the visibility from protected to public in the code, and tested this with 3.5, and it compiled.

Comment 4 Dani Megert

2009-12-09 03:09:54 EST

Our prime directive is to be binary compatible. As mentioned by Markus source breakage can happen, that's why we have a migration guide.

In this particular case the cost for adopters is very low and it is documented in the migration guide. We have to keep the balance between making the life easy for existing clients and new ones.