I agree with the philosophy of making Trinidad the "Base", and refactoring Tomahawk into it. I've been using Seam a lot in my day job, and the Seam-Trinidad compatibility is more stable than Seam-Tomahawk. A point of contention with the Seam folks is the ExtentionsFilter, which they perceive to be too heavy-handed.
Having said this, I have had absolutely no free time this year to even look at either the Trinidad or Tobago architectures. Hopefully in the next 3 months my schedule will lighten. As Werner points out, this is non an uncommon situation :) Perhaps the best approach would be to take one or two of the Sandbox components that are perceived to be ready to graduate, and refactor them into Trinidad, instead of Tomahawk. If that works out well, and isn't overly complex to achieve, then we could look at moving more mainstream components from Tomahawk into Trinidad. On 3/15/07, Werner Punz <[EMAIL PROTECTED]> wrote:
Mike Kienenberger schrieb: > > > At some point we should discuss what an ideal JSF component framework > architecture looks like and whether it's feasible for all of our > components to be a part of such an architecture. > +1.... the at some point probably is now, with the jsf 1.2 transition, people please if you do not want that look into the users list half of the problems are bugs, due to the fact that one of the component sets has too few maintainers being able to have enough time to clean up the bugs (inherent problem of tomahawk in my opinion, it has a bunch of committers, but all of them are heavily bound by day to day duties, myself included currently working 70-80 hours per week on non Tomahawk stuff, the sandbox is full of interesting stuff probably overdue to be pushed into tomahawk for the same reason, time to fix up the last five percent) Getting people into component programming is hard, the api is unnecessarily complicated and overloaded with glue code, a common base, could ease tool development as well (we need well documented codegens and uis for helping people to kickstart it). one third is inherent incompatibility problems and one third is questions And the first question you geht, why so many components in the sets double... And then we have Tobago, an excellent framework which feels like being one big block designed for coherency and it has also problems working together with the rest. I think it is long overdue to get a good corebase here and more coherency, since there has to be done some overhaul for jsf 1.2, why not in a proper and decent manner.
-- Grant Smith
