Whether it is done by updating one of the existing projects to 2.0 first
and then enhancing it with the additional functions or by starting from
scratch, I think that it is a good idea to get one solid component set
for JSF 2.0 that would consolidate the requirements that are currently
addressed by all three.
On a somewhat related question, at some point in the future, potentially
with any 2.0 component set(s), would it be best to move the component
sets into a separate project instead of as subprojects of the MyFaces
core? It might make sense to maintain one project for the spec driven
development done in the core and one for the widget libraries.
I'd also like to chime in my agreement with Curtiss' that it would be a
good idea to start looking at creating a new branch soon for JSF 2.0
core development now that the draft spec is nearing completion. I would
certainly be interesting in devoting my time to the project as well.
Mike
Scott O'Bryan wrote:
I would still echo sentiments that it would be most helpful to start
from an existing project. There are so many issues and requirements
that the existing renderkits have had years to work out, I think it
would be a much better starting point. Encouraging people to move off
of their existing renderkit is the only way to get developer support
for OpenSource projects and the only way to do that is to address all
the requirements from all three projects.
Scott
Curtiss Howard wrote:
Jesse Alexander (KSFH 323) wrote:
I am wondering whether the event of JSF 2.0 would not be a good
moment to create a new component set.
I'd like to chime in here with my +1.
I imagine maintaining three separate-but-similar component sets is
quite a bit of work and, from what I can tell with the JSF 2.0, there
will be enough major differences in the programming model to make
backwards compatibility quite a chore (as Jesse noted). Merging the
three sets would be difficult, so then why not try for a new set that
takes all the best parts and is built "from the ground up" to
leverage the JSF 2.0 programming model and concepts? It would not
preclude Tomahawk, Tobago et al from moving to JSF 2.0 if that is the
choice, but at the same time it would provide a fresh, unified JSF
2.0 component set that isn't hamstrung by backwards compatibility
concerns and could move in its own direction if need be.
On a related note, what is the status of MyFaces and JSF 2.0? Is
there any interest yet in creating a branch and "skeletoning" an
implementation as the draft is released/updated? This is an area I'm
interested in pursuing and would offer some effort if the community
is interested.
Curtiss Howard
