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]>: > 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
