#End-user visible features that appear by default are bad.&nbsp; Examples include the appearance of the WPE action on the Open With action in the project explorer and the validation framework.&nbsp; Once these features are contributed an adopter is stuck with them.&nbsp; Short of doing hacky things like calling non-API methods or worse, calling setAccessible to get private data.&nbsp; This is bad due to premise 1: adopters get stuck exposing things to their users that they may not like or conflict with a similar feature that they want to implement in their own way or based on a superior internal technology.<br>

#End-user visible features that appear by default are bad.&nbsp; Examples include the appearance of the WPE action on the Open With action in the project explorer and the validation framework.&nbsp; Once these features are contributed an adopter is stuck with them.&nbsp; Short of doing hacky things like calling non-API methods or worse, calling setAccessible to get private data.&nbsp; This is bad due to premise 1: adopters get stuck exposing things to their users that they may not like or conflict with a similar feature that they want to implement in their own way or based on a superior internal technology.<br>

−

#Frameworks that are depend on non-overridable data such as JSF tag metadata are difficult to customize for same reason as observation.<br>

+

#Frameworks that depend on non-overridable data such as JSF tag metadata are difficult to customize for same reason as observation 1.<br>

−

#Default implementations

+

#Singletons make it difficult to extend a framework because it make things difficult to configure (generally singletons configure themselves) and control lifecycle (when do you dispose the singleton?).&nbsp; This is bad due to premise 3.<br>

+

#Frameworks that use long-running processes, whether background or foreground, make it difficult for adopters to tune experience.&nbsp; This is a problem due to premise 4.

+

+

+

+

Based on this analysis, we propose to change the bundling and system architecture in the following ways to improve adoptability:

+

+

+

+

#Break up the JSF feature into smaller features.&nbsp; Only the core feature will live in the SDK release.&nbsp; The rest will be availabe in an optional download.

+

#Eliminate singletons and replace them with relocatable services managed by OSGI.

Flexibility of Adoption

Based on lessons learned over almost five years of experience with the JSF project as both committers and adopters, we have come to some conclusions about the limitations of our current bundling architecture with respect to adoption. These are based on the following premises:

The most common, and therefore premier, adoption scenario is to create an update site that is installed directly on top of some subset of WTP and its dependencies.

Adopters may support other scenarios such as productizing, but they will still need to support option 1.

Frameworks that create long-lived objects or react to events without the adopter doing anything make it very difficult for adopters to tune their end-user experience.

Only a choice few base platform features like JDT have become so "defacto standard" that adopters are comfortable exposing them to end users without significant customization. WTP JSF Tools is not in this category.

The WTP API policy and the Eclipse annual release cycle combine to make it very difficult to evolve API and user visible features once they are released.

This leads us to the following observations about adoption of the JSF Tools Project:

End-user visible features that appear by default are bad. Examples include the appearance of the WPE action on the Open With action in the project explorer and the validation framework. Once these features are contributed an adopter is stuck with them. Short of doing hacky things like calling non-API methods or worse, calling setAccessible to get private data. This is bad due to premise 1: adopters get stuck exposing things to their users that they may not like or conflict with a similar feature that they want to implement in their own way or based on a superior internal technology.

Frameworks that depend on non-overridable data such as JSF tag metadata are difficult to customize for same reason as observation 1.

Singletons make it difficult to extend a framework because it make things difficult to configure (generally singletons configure themselves) and control lifecycle (when do you dispose the singleton?). This is bad due to premise 3.

Frameworks that use long-running processes, whether background or foreground, make it difficult for adopters to tune experience. This is a problem due to premise 4.

Based on this analysis, we propose to change the bundling and system architecture in the following ways to improve adoptability:

Break up the JSF feature into smaller features. Only the core feature will live in the SDK release. The rest will be availabe in an optional download.

Eliminate singletons and replace them with relocatable services managed by OSGI.