Introduction Hello and welcome to the JSR-314 Expert Group for developing version 2.0 of the JavaServer Faces specification. If you're a veteran of JSR-127, or JSR-252, thanks for coming back again, we're very glad to have you. If you're new to JavaServer Faces spec development, welcome! We look forward to more fresh ideas. My name is Ed Burns. Roger Kitain and I will be your co-spec leads for this JSR. Goals This is the first big "new feature" JSR for JSF technology since JSF started. As stated on our JSR [1], "This JSR will bring the best ideas in web application development (circa 2007) to the Java EE platform." The JSR-314-EG@JCP.ORG list will be the email list of record for discussions on the other goals listed in JSR-314 [1]. Getting to know each other We know some of you from JSR-127, or JSR-252, but others are new. We'd like for everyone to share their java.net user name. If you don't have one, get one at . We'll add everyone to the javaserverfaces-spec-{eg,public} projects. Please reply-all to this email, including where you live who you represent a link to your homepage or blog your areas of expertise and interest that are relevant to this JSR, for example, ajax transactions, protocol design, large scale systems, render-kits, I18N. the areas of the spec that you could be counted on to help shape, for example, ajax integration, loading resources, zero deployment time, etc. the top three things you absolutely must have in this JSR. We will use this information to build a map of the skills and interests we have on our team, and we'll use this map to help us with estimates and task assignments. Platform JavaServer Faces 2.0 will be a part of Java EE 6. This means we depend on Servlet 3.0. We can assume portlet 2.0 for any portlet integration requirements. We will make every effort to keep the minimum requirements for a JSF 2.0 implementation so that it can effectively run inside of a container that implements JSP 2.1 and Servlet 2.5. At some point during development, it will be necessary to depend on features in Servlet 3.0 and in those cases, we'll try to make it possible to still be functional on a Servlet 2.5 container. I suggest we will support Firefox 2 and later, Internet Explorer 7 and later, and Safari 3.0 and later. Rights and Responsibilities Based on lessons we've learned from JSR-127 and JSR-252, we think it would be useful to lay out some rights and responsibilites of the JSR-314 Spec Leads and EG members. * Your rights as a JSR-314-EG member - timely response to emails - the issues you raise get dealt with and not fall on the floor - be informed of schedule milestones and release plans as soon as possible. - have your spec leads be fully allocated to leading the EG as their primary official job responsibility, on paper and in practice. - have expectations set realistically, for example, the EG needs to be made aware that the JCP process can take a long time, months even, between when the actual spec discussion work is done, and when it is final. During that time, we're going through JCP process steps, working on the TCK and polishing the RI, writing the documentation, integrating it into the release vehicle, and qualifying it with third party products. - have access to quality tools for distributed collaborative development. For example, the issue tracker at javaserverfaces-spec-public at java.net. I would really like to have a private EG chat room, on IRC perhaps, but I need someone to volunteer a maintained machine on the Internet for this purpose. * Your responsibilities as an EG Member - be active in email discussions - On the occasions when we specifically ask for a VOTE, such as whether or not we declare that we've hit a JCP milestone, cast one. - conduct all email in a professional manner, no flaming - follow email discussion guidelines in this message - stay within the scope of the JSR - respect the spec lead's final call on the schedule for the JSR. * Our rights as spec leads - The ability to make the final call on the schedule for the JSR, after sincerely considering EG input. - The ability to make executive decisions to settle deadlocks - The ability to shut down threads that are digressions. * Our responsiblities as spec leads - All new discussion threads receive a response within two days from Roger or I, barring planned absences. - All discussion threads managed. If appropriate they are associated with an issue-tracker issue. - see that each discussion thread is summarized and labeled as CLOSED when the discussion is resolved. - keep the spec document up-to-date as issues are resolved Process All official spec discussion will happen on JSR-314-EG@JCP.ORG. This list is archived at [4]. We used the archive heavily in JSR-127, so please test that you can access the archive. Your userid will be the email address you gave to jcp.org when you joined. Your password will be your JCP private page password. Please send all mail in ASCII, not HTML. If you must, non ASCII attachments are ok, but generally it's better to put that sort of thing as an attachment to an issue in the issue-tracker. As mentioned above, everyone needs a java.net user id. We'll be using the javaserverfaces-spec-public [5] and javaserverfaces-spec-eg [6] projects. In the spirit of JCP 2.6, we intend to use the former more than the latter, since the latter is private to EG members only. We'll use the javaserverfaces-spec-public issue tracker for all issues. Generally only the spec leads will be submitting issues here, but you may be asked to submit one yourself for expedience. We'll use the javaserverfaces-spec-eg issue tracker to host the development of the spec document itself. We may have occasional conference calls if the need arises. Reference Implementation and TCK The official reference implementation for JSR-314 is being developed out in the open on the java.net project called javaserverfaces. Please let us know if you have a problem with this practice. The TCK will be developed by Sun internally. Email practices During JSR-127, we used the following conventions, and they seemed to work reasonably well, especially for the purposes of looking back over the archive. The subject line of All core discussion threads will be prefixed by [TargetVersion-IssueNumber-ShortName]. TargetVersion is optional and is assumed to be JSFv2.0 if omitted. Having this convention covers us if we end up talking about something targeted at JSFv2.1 or 3.0. IssueNumber is the issue number in the javaserverfaces-spec-public issue tracker. If we need to refer to an issue in the EG private tracker, prefix the number with "EG". ShortName is a WikiWord that enables us to look at the email subject line and quickly recall the topic of the thread. For example, Subject: "[43-XMLSchema] Status" If you want to originate a thread, send it to the EG prefixed by [NEW] in the subject line. If the spec lead sees the need for an issue tracker issue, we'll put it in the issue tracker, re-subject the email to be prefixed with [IssueNumber-ShortName], and discussion will continue on that thread, NOT the thread with [NEW] in the title. Put [ADMIN] at the start of the subject line for all schedule and administrative related emails (such as this one). We're open to other suggestions about how to best conduct the EG discussions over email. Next Steps I am taking vacation starting tomorrow and I'll be back on 25 July 2007. In the meantime I would like get the introductions out of the way and get the information necessary to build the skills and interests map. My co-spec-lead Roger Kitain will be collecting this data and building the map. Once we know what sort of skills we have on our team, I would like to take our two distilled repositories of requirements [1] [2] and refine them into one document, at [3]. The format of this document should be light-weight, but I would like as much as possible to have all the requirements disjoint from one-another, and of a similar level of detail. Roger will help shape this document. Once we have a first draft of [3], I would like to perform a dependency analysis to determine ordering of the tasks. At that point, Roger and I will start assembling our first cut at a schedule. Once we have an ordering of the tasks, we'll assign effort estimates to each task. The estimate should be the "number of days of EG email discussion to get the issue into a form such that it is ready for one individual to write the specification for it". Finally, we'll take everyone's "top three features" list and help us prioritize the order in which we'll tackle the tasks. This data will then be folded into another draft of the schedule. Again, welcome, and we look forward to collaborating in the coming months! Ed and Roger [1] http://www.jcp.org/en/jsr/detail?id=314 [2] http://wiki.java.net/bin/view/Projects/Jsf2RequirementsScratchpad [3] http://wiki.java.net/bin/view/Projects/Jsf2Requirements [4] http://archives.java.sun.com/jsr-314-eg.html [5] https://javaserverfaces-spec-public.dev.java.net/ [6] https://javaserverfaces-spec-eg.dev.java.net/ Appendix: JSF Spec History To set the context, I'd like to share some history from JSR-127. From the email archive, here is a brief timeline of JSR-127 development 17 August 2001 The first official email on JSR-127 was sent. August - November 2001 Gathering basic requirements, analyzing the state of the art of existing frameworks, choosing the top-level package name, business and licensing terms, and producing a basic component architecture. December 2001 - February 2002 ObjectManager (precursor to managed-beans), first event model proposal, First draft of spec, discussion of spec, first validation proposal, BEA brings the importance of the Corporate Developer to the project. March - June 2002 First discussion on config file, first discussion of EL alignment, with respect to JSTL EL, FactoryFinder proposal, event model discussions, first RI snapshot announced, Craig McClanahan takes over from Amy Fowler as spec lead, request processing lifecycle proposal, concrete vs abstract component classes, spec editorial discussion, application handler discussion, Component trees and JSP pages discussion. July - September 2002 Standard RenderKit, refocus priorities on component model and event model, re-examine JSR requirements, JCP Community Review (12 August 2002), conversion, L10N, formatting, Public Review Draft release. November 2002 - February 2003 Introduced enact issue tracker usage, Ed Burns joins as co-spec lead, state saving proposal, organizational work, NamingContainer, Facets, RendererDelegation, event model rework March - June 2003 ApplicationHandler, ConfigFiles, NavigationHandler, ManagedBeans, PhaseListener, ValueBinding, Hans asserts that JSP/Faces interaction has major issues, rtexprvalues for our TLD, Public Review Draft 2 release, with RI. July - October 2003 Introduced EG-accessible scarab issue tracker usage, UIData grid proposal, MethodBinding, Attribute/Property transparency, PropertyResolver/VariableResolver decorator pattern, validator, component binding proposal, "id" as a tag attribute, OutputMethods, concrete html components, component messages, StateSaving November 2003 - January 2004 Continuing discussion, spec edits, bug reports, portlet integration, EA4 release of RI and spec, camelCase identifiers, converters, Standard RenderKit specification, component namespace, NamingContainer.SEPARATOR_CHAR and CSS, Multiple RenderKits, RenderKitId and StateSaving. February - August 2004 Bug reports, 1.0 release candidate, ResourceBundle lookup, 1.0 handoff 1.0 to JCP (12 February 2004), justification for "#{} delimiters", Calls for new features in jsf 1.1 and jsf 1.2, announcement of 1.1 version of spec, JavaOne face-to-face meeting, introduce my new manager, Tony Ng. Webtier-alignment email discussion commences. VariableResolver alignment. PropertyResolver alignment, September 2004 Continuing PropertyResolver discussion ahead of JSF 1.2. October - December 2004 Kick-off of JSR-252 and JSF 1.2. MethodBindings, Decorators, ResourceBundles, StateSavingWindowId, XML Schema, BigDecimal, ViewLifecycle, ELResolver, JSFJspTaglib, ValueBinding, MethodBinding, the big #{} vs ${} debate, UIDataProtectedModel, CoreTagsSpec, "div" renderer, StringLiteralAndAction, ImplicitObjectELResolver, EARLY DRAFT REVIEW January - March 2005 StateSavingAndSecurity, ComponentMessageAssociation, AttributeTagELExpressions, DuplicateButtonPress, TreeCreation, ContentInterweaving, Face to Face Meeting, HeaderClasses, StartupTime, JSP-126 Faces "action" attribute, UIComponent.setValueExpression, JspIdGeneration, PluggableELResolver, c:forEach, TCCI, UIInputReset, RestoryViewBindingSpec, LostUpdate April - June 2005 ELContext and ELResolver, PUBLIC REVIEW SPEC, JspApplicationContext, Deferred Expressions in Tag Files, CommandLinkFormRendererDependency, MultipleRenderKits, ClientIdSpecification, ResourceBundleELResolver, c:forEach, UIDataStateSaving, TCCIAndUIColumn.encodeChildren, ManualRequiredValidation, TwoExtensionElements, ResourceInjectionSupport, ExternalContext.get*ContentType, ManagedBeanResourceBundle, formNameAttribute, July - September 2005 JDK 5 requirements debate, JavaScriptFreePages, UIColumnEncodeAll, PerInstanceMessageOverride, h:inputParam, convertClientIdCalledOnce, CurrentLocaleInELContext, LifecycleInitParam, UpdateFailedMessage, UpdateFailedMessage, PROPOSED FINAL DRAFT, RequestPostBackDetection, AutocompleteAttribute, JavaSE5Generics, SessionMapClear, FacesConfigOrdering, ManagedBeanLifecycleAnnotation October - December 2005 ManagedBeanLifecycleAnnotations, ContainerManagedAuthentication, ContainerManagedPersistence January - March 2006 BackwardsIncompatibilities, CreatManagedBeanOnStartup, EnumManagedBeanProperties, ChangeApplicationActionSignature, CoercionRulesForEnums, Jsf2.0Discussion, ComponentIdentifiers, InvokeOnComponent, ExternalContext.encodeNamespace, JspVersionForTagFiles, ViewIdCalculation, ExternalContext.isUserInRole, HeaderClassesFooterClasses, ComponentIdentifiers, EnumConverter, ValueExpressionFacetTagName, SelectItemsUnescape, UIDataLongMethods April - June 2006 FINAL DRAFT July - September 2006 WhoDerivesTheViewId, MaintenanceReleaseConstraints, ErrataItems, CommandLinkSpecification, EnumConverterClarifyJavadocs, UIComponentELTag.setBinding, componentIdAssertion, f:viewRLocaleAttributeValueNamingConvention, UISelect.validateValue, setPropertyActionListener, DataTableAccessibility October - December 2006 JSF2.0Timing January - March 2007 JSF2.0 April - June 2007 ComponentTreeManagement, JSF 2.0 JSR Filed