This JSR has been Dormant
Reason: The Specification Lead chose to list this JSR as dormant in August 2012.
Updates to the Original JSR
the following information has been updates from the original proposal.
2010年04月09日:
This JSR will leverage the collaborative tools provided by the java.net community. A project will be established on java.net that will contain a public issue tracker for tracking most issues. The community will be able to provide feedback and seek clarification via a monitored public discussion forum.
The Early Draft feature of JCP 2.6 will be utilized to allow the public to see the specification in progress. The reference implementation will be developed entirely in the public project on java.net. The TCK will be developed privately by the specification lead.
The public can read the names of the people on the Expert Group.
No.
The Expert Group business is regularly reported on a publicly readable alias.
Not via e-mail, but all working materials are publicly available on our java.net project at https://jsf-metadata-spec-public.dev.java.net/.
The schedule for the JSR is publicly available, it's current, and I update it regularly.
The Update page is kept up to date with the current estimated schedule.
The public can read/write to a wiki for my JSR.
No.
I read and respond to posts on the discussion board for my JSR on jcp.org.
Yes.
There is an issue-tracker for my JSR that the public can read.
Yes, in our java.net project.
I have spoken at conferences and events about my JSR recently.
Not recently.
I am using open-source processes for the development of the RI and/or TCK.
Yes, utilizing our java.net project.
The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR.
Yes.
License Info
A) The Final Specification will use the standard JCP templates for evaluating
and implementing final JSRs.
B) The planned Reference Implementation license is attached as 276ri-license.txt.
C) The planned TCK license is attached as tck-license.txt.
2007年05月24日
The JSR 276 Expert Group is utilizing the collaborative tools provided by
java.net to develop the specification and related work materials. Please
visit the jsf-metadata-spec-public
project on java.net to check on our progress.
Early Draft Review: July 2007
Public Review: August 2007
Proposed Final Draft: October 2007
Final Release: November 2007
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification
Submitting Member: Oracle
Name of Contact Person: Jeffrey Stephenson
E-Mail Address: jeffrey.stephenson@oracle.com
Telephone Number: +1 650 607 3515
Fax Number: +1 650 607 3515
Specification Lead: Jeffrey Stephenson
E-Mail Address: jeffrey.stephenson@oracle.com
Telephone Number: +1 650 607 3515
Fax Number: +1 650 607 3515
Initial Expert Group Membership:
Oracle
Sun Microsystems, Inc.
Exadel, Inc.
JBoss, Inc.
Otrix
Supporting this JSR:
Oracle
Sun Microsystems, Inc.
Exadel, Inc.
JBoss, Inc.
Otrix
Section 2: Request
Design-time tools require both grammar and metadata information for Java Server Faces (JSF) components in order to provide a polished design-time experience. Grammar information, such as the set of available components and what properties exist on those components, is used by tools to guide the user towards valid editing operations. While grammar information can help the tool support the basic operations for creating and manipulating components, metadata can be used to enhance the design-time experience in a variety of ways. Design-time metadata is perfect for simple customizations like changing what name or icon a tool displays for a component, but it can also be used to arrange components or attributes into categories, or even provide information on common design patterns associated with a component.
Although the faces-config.xml language allows a component author to express a great deal of information about their components and renderers, it only has standard syntax for expressing a very minimal set of design-time metadata. In order to provide a polished design-time experience, tool vendors need more information. In the absence of a standard, tool vendors have started to invent proprietary mechanisms for supplying additional design-time metadata for JSF components. Unfortunately, that makes the job of the component author very difficult, if they plan to integrate with multiple tools. In addition, developers that use JSF technology have expressed their frustration and concern with not being able to choose their JSF tool independently from the component library that best meets their needs.
The hope is that through this JSR, the Java community can work together to define a standard solution to this problem. The Expert Group will consist of a representative set of tool vendors and component authors, and the feedback of the community will be actively solicited. The goal is to produce a specification that defines:
The resulting specification is intended to be compatible with both JSR 127 and JSR 252 without imposing any restrictions on JSF component authors.
In order to ensure that the design-time metadata can be consumed by a wide variety of existing and future JSF tools, it is anticipated that this JSR will not require tool vendors to implement any specific APIs. However, the extension mechanism mentioned above could be utilized to define additional metadata items that are tied to a specific API. For example, additional metadata items could be defined for associating the rich contextual property editors and customizers that are being developed in the Design-Time API for JavaBeans (JSR 273) with JSF components. The extension mechanism gives tool vendors the ability to change and innovate while still benefiting from a shared set of common metadata items and a standard mechanism for providing metadata.
JavaTM 2 Platform Enterprise Edition (J2EE)
This specification will primarily be of interest to component authors and tool vendors working with JavaServer Faces, which is part of the J2EE platform.
No.
Tool vendors have started to invent proprietary mechanisms for supplying design-time metadata for JavaServer Faces (JSF) components. The lack of a standard in this area has made it very difficult for a component author to integrate their components with the ever-growing set of tools that support JSF. Both tool vendors and component authors have acknowledged the need for a standard mechanism.
Successful adoption of this standard will enable component authors to provide metadata in one format that will work in all compatible tools, and developers that choose JSF technology for their web applications will be in the ideal situation of being able to pick the tool they want to use independently from the component set that best meets their needs.
The faces-config.xml language defined in JSR 127 (and later revised in JSR 252) only defines standard syntax for display-name, description, and icon metadata. In order to provide a desirable design-time experience, JSF tool vendors need more information.
One could make the argument that this work could be included in a future JSR for the Java Server Faces specification (JSF 2.0). The rationale for proposing a separate JSR now is two-fold. First, this JSR can be accomplished without requiring any changes to the JSF specification, and is intended to be compatible with all existing versions of JSF. Secondly, the relatively small scope of this JSR will allow it to be completed much sooner than a major revision of the JSF specification. It is vital to define a standard now before the number of component sets and proprietary solutions explode.
This JSR will define a standard mechanism for associating design-time information with JavaServer Faces components. It is intended to be compatible with JavaServer Faces 1.0 (JSR 127) and JavaServer Faces 1.2 (JSR 252).
Not at this time.
No.
No.
The specification will provide the ability to vary the value of a metadata item based on locale information. For example, component authors might provide a category name for their component that is translated into multiple languages. The goal is to use existing mechanisms, such as ResourceBundle, to provide this support.
No. However, the EG must ensure that this JSR is compatible with JavaServer Faces 1.0 (JSR 127) and JavaServer Faces 1.2 (JSR 252).
In addition, although it is anticipated that the resulting specification will not require tool vendors to implement a particular design-time API or architecture, care must be taken to ensure that this JSR is compatible and consistent with other design-time JSRs, such as the Design-Time API for JavaBeans (JSR 273).
Given the relatively small scope of this JSR, the intent is to pursue an aggressive schedule:
E-mail will be the primary mode of communication. Phone conferences and/or face-to-face meetings will be organized if required by the Expert Group. The java.net infrastructure will be leveraged (as described in 2.15).
This JSR will leverage the collaborative tools provided by the java.net community. A project will be established on java.net that will contain a public issue tracker for tracking most issues. The community will be able to provide feedback and seek clarification via a monitored public discussion forum.
The Early Draft feature of JCP 2.6 will be utilized to allow the public to see the specification in progress. The reference implementation will be developed entirely in the public project on java.net. The TCK will be developed privately by the specification lead.
The RI and TCK will be delivered stand-alone.
Not applicable.
The Specification, Reference Implementation, and Technology Compatibility Kit will be made available on a Royalty-Free basis, with commonly-used disclaimers on warranties on the technologies. A reciprocal license will be required as per Section 5C of the JSPA.
Section 3: Contributions
Contributions from tool vendors:
The lack of a standard in this area has forced JSF tool vendors to develop proprietary solutions, some of which have been contributed to this JSR as proposed starting points. The contributions from tool vendors, along with input from component authors, and the java.net community will be highly valued by the Expert Group in the effort to define a standard design-time metadata mechanism that meets the needs of the Java community.