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