myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Petracek" <>
Subject Re: [VOTE] layout for myfaces-commons project
Date Sun, 22 Jun 2008 12:46:18 GMT

what's about an uniform layout for all myfaces-projects?
(currently it's also a blocking topic for me to
setup myfaces-extensions-validator.)


2008/6/20 Scott O'Bryan <>:

> 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.


Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

View raw message