Well we can, but I think we have some legacy solutions out there that
are not easily changed. Does anyone besides Trinidad and (from what I'm
hearing) Tobago have JSF1.2 specific branches?
Scott
Gerhard Petracek wrote:
hello,
what's about an uniform layout for all myfaces-projects?
(currently it's also a blocking topic for me to
setup myfaces-extensions-validator.)
regards,
gerhard
2008/6/20 Scott O'Bryan <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Mike, the problem with this approach is one of forward compatibility.
Let me explain. The ExternalContextUtils in the MyFaces commons,
when it existed in Trinidad, had api's for handling request input
streams and whatnot because the ExternalContext did not. If
someone used that API and then wanted to run their application
using JSF1.2 and the 1.2 version of the commons, they would need
to do a mad scramble to get the proper api's added. Furthermore,
if when you design an API for a 1.1 branch, and you don't take
into account later versions of JSF, you increase your changes that
that contract will have to be changed. That, for instance, a
particular piece of functionality will not be duplicable in a
later release. Forcing consideration in later branches helps
eliminate this as a possibility.
IMO, most new development should be done on the later branches and
posted to earlier branches as appropriate. That's why I'm a
proponent of having a trunk which reflect's the latest code and
branches which get backports as needed. If the libraries are
allowed to not be "forward" compatible, they will, essentially,
become useless for just about anyone to use. I know I for one
would be reluctant to use an open source project that I know will
require a lot of work before I can upgrade. I would rather just
develop something in house.
That said, I'm far less concerned with what happens on outward
facing projects then I am with infrastructure projects. If API's
do not allow upward mobility in infrastructure, EVERYONE looses in
the community. Backward compatibility? Presumably not, because
the old api's would still function the same, they just might
become feature limiting.
Ultimately though, the commons project has to support the policies
of the "strictest" outward facing project, unless it is intended
for that project NOT to have to depend on commons.
Scott
Mike Kienenberger wrote:
Let's not forget that working on open source software is quite
different than working on proprietary software. For open
source, you
work on what you need and you share what you've done with others.
Some people need JSF 1.1 and will be working there. Some
people need
JSF 1.2 and will be working there. Some will need 2.0.
Keeping it
all consistent would be ideal, but realistically, everyone
needs to
work on what they need. To say that no work will be allowed
on JSF
1.1 is not helpful. Yes, it'd be great if everything applied
to one
branch can be applied to another, but if someone is still
working on
JSF 1.1 fixes and features, they may not have access to JSF 1.2 or
2.0.
My suggestion is that we keep this in mind and allow for some
flexibility. It may be that some work committed to 1.1
remains as a
JIRA item until someone needs it in JSF 1.2 or 2.0. And a
bug fix to
1.2 may remain as a JIRA item for 1.1 until it's needed.
As an example, I'm doing a lot of work with a legacy app these
days
(which is why I'm not actively doing JSF development) and it uses
Cayenne 1.1. That's now 4 versions old as Cayenne has
transitioned
from 1.1 to 1.2 to 2.0 to 3.0. I don't expect the cayenne
community
to support my needs by back-porting all bug fixes, but I do
have the
ability to back-port and maintain those fixes myself as a
developer,
even though the branch is not officially supported by the project.
And at the same time, if the problem I fix is still an issue
in 3.0,
I'm not expected (or required) to make sure that every version of
Cayenne after 1.1 has that fix applied. I would open a JIRA
issue,
but since the architecture is quite different for later
versions, it
would be up to someone using a newer version to solve and apply it
(with or without the code I used to fix it). On the other
hand, I
would typically try to also fix it for 1.2 since the ease of
applying
such a patch is greatly reduced.
Myfaces Core and Tomahawk has always been very weak on
providing bug
fixes for older versions. If anything we should be trying to
make
that task easier rather than more difficult.
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
