After working and using Trinidad for about a year now, I have noticed that although there have been many releases, the project just doesn't seem to be progressing. I am curious what other MyFaces members think about this. Just by browsing JIRA, it seems that almost all the work is done is bug fixing, but not enhancing Trinidad. Here are some disturbing JIRA statistics from last week:
- 331 open issues in Trinidad - 239 are bugs in an unresolved state, 14 with a patch available and 154 of which are over 6 months old - 14 bugs are marked as blockers or critical, 9 of which over 6 months old - 140 unresolved improvement, wish or new feature requests, 21 with a patch available and 114 of which are over 6 months old - Only 4 issues are in progress, only 1 with recent updates (although many don't both to set "in progress" so this number is probably not very meaningful) - Only 45 improvement, wish or new feature requests have ever been fixed over the lifetime of Trinidad (less than 25% of those filed and not rejected) of which only 8 committers were involved Another sign of stagnation is that Trinidad has plenty of legacy UIXNode code from the early Oracle ADF days, there has been no movement to address this and bring Trinidad fully into the JSF architecture. Many of the components that are still ADF based are major ones like the tree and the navigation tree. New features seem to be debated harshly on the dev@ mailing list, there is always a strong resistance, sometimes by just a few people and silence from much of the rest of the community that results in lack of adopting any improvements. No new components have been added to Trinidad to my knowledge since the lightweight popup control (for which the author is no longer active). Only one new skin has been included, and that was donated by Oracle (suede skin). The demo has not improved, nor has the documentation or website undergone any major improvements. I think a large part of the lack of progress, but a high involvement for some bugs is the contribution of Oracle in their development of the rich client offering. By the way, as many know on this list, but some may not, I am an Oracle employee, but I am "wearing my Apache hat" for this email, and none of what I say here is representative of Oracle's standpoint. To make sure this is an Apache point of view, I have only included public information that anyone can learn about the rich client. Some may be aware that ADF development did not cease after Trinidad was donated. From that donation ADF has become the rich client: http://www.oracle.com/technology/products/adf/adffaces/index.html Looking at the javadoc (http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproject/adf-richclient-api/apidocs/index.html) you can see that the rich client is based on Trinidad's framework and some of the components but none of the renderers. What this means is that Oracle is very involved in assisting Trinidad's framework and UIXComponents, but not the Core components or the renderers. This is truly great to have such a large Java-based company backing an open source project, but there are some serious draw backs as well. Since the Rich Client just doesn't use Trinidad, it uses Trinidad as a foundation, this means that any changes to UIX components or the framework will appear in Rich Client as well. For example, the RichDocument (http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproject/adf-richclient-api/apidocs/oracle/adf/view/rich/component/rich/RichDocument.html) extends Trinidad's UIXDocument. This means that adding new functionality, attributes or changing the API of UIXDocument also affects RichDocument. So if say a Trinidad user or committer wishes to add an attribute onto UIXDocument that would not be beneficial for RichDocument, most likely and with past experience, you will find Oracle employees on the Apache list tent to resist the improvement and have sometimes vetoed the idea. As a result, any changes that would be beneficial to Trinidad, but harmful or even not ideal in some way to the Rich Client will be met with strong resistance or at least negative feedback. Also due to the fact that the rich client does not use all of the components and uses none of the Trinidad renderers, there will has never been any significant support from Oracle to fix, improve or document this code. This is why, I think, that Trinidad's Jira state is stale when it comes to new features and why there are no new components. For a hypothetical example: As a Trinidad committer, I put out an idea for a new attribute or new component. This feature may need a change to the trinidad-api in something like UIXComponentBase in order to work. Oracle is not interested in this feature as there is a good chance that since much of their code is written in JavaScript, that this change may be either redundant or harmful to the rich design and only apply to Trinidad. As such, Oracle Apache members disagree the improvement as they do not wish to have this functionality exposed on Rich* classes. Another problem is that if functionality is added to Trinidad at the core foundation or at the UIX* class level that needs support by the renderer, then it is also pushed back against. So if I were to change UIXColumn and add a new attribute that the org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ColumnRenderer would take advantage of, Oracle would have to either (1) implement that same functionality in its column renderer or (2) try to hide the attribute from the developers on RichColumn. What becomes more easy is that the feature is prevented by negative feedback on the mailing list or even vetoed so that it doesn't have to be ported. Now since the rich client is heavily JavaScript based, it is very dangerous to that product for Trinidad to change its PPR functionality significantly. Therefore, large performance improvements, more declarative AJAX support, XHR usage changes all are very detrimental to the rich client. The result of all this is that Trinidad becomes bound by the rich client, although I do not feel that any of this was on purpose to be this way. If the functionality is not deemed valuable to rich client, there is often negative feedback on the dev@ list just do to the nature of Oracle trying to protect the Rich Client and make it a solid component offering. If you follow the incubation process at Apache, the rich client was approved. There has been no code drop though, and it is unsure when this will ever happen (Oracle has not made any public statement on the progress of this to my knowledge). The information on Apache is very old: http://wiki.apache.org/myfaces/RCF_Proposal This one looks newer: http://wiki.apache.org/incubator/RCFProposal The donate source code is here: https://svn.apache.org/repos/asf/incubator/rfc Oops 404 :) So, as someone that cares about Trinidad, and not just Rich Client (yes I like the Rich client a lot, it is truly a great work with a lot of code and a great number of terrific features and I decided to work for Oracle to help build it), I also want to improve Trinidad and feel that the Rich Client is not a replacement to Trinidad, but rather an alternative. Here is why I think that Rich Client will not deprecate Trinidad if it is open sourced: 1) Trinidad supports more browsers (if you need IE6 support, the rich client will not be an option) 2) Trinidad is much faster due to less overhead for simple pages and people that visit one or two pages or your site (for at least the javascript footprint alone) 3) Rich client is more geared for web-applications rather than web pages and Trinidad seems more suitable for web sites in comparisson (not that the rich client cannot be used for web pages, but I don't see it being adopted for that niche for its mainstream usage) 4) Trinidad has a smaller learning curve to extend it (not many JavaScript APIs to learn) 5) Trinidad is server-side rendered with little javascript, appealing to many developers that would rather avoid heavy JS usage or are simply looking for a lighter client side component library. Basically the goals of rich client and Trinidad are not the same, one seeks to be a slick, robust, heavy-weight, JS feature rich platform where the other seeks to be a server-side rendered set of JSF components that supports AJAX. So I have been thinking lately, how can Trinidad get out of the shadow of the rich client and improve on its own? I think the major areas to address this question are: 1) Allowing improvements to Trinidad without them being brought into the rich client without intent (like a choice to merge code) 2) Fixing and refactoring old, antiquated and sometimes "broken" pieces of the Trinidad API, or just making it more possible from an Apache commiters point of view to update Trinidad's API 3) Removing all legacy code including for the most part UIX code (UIX node renderers for the most part) 4) Flexible and extensible. Trinidad is open-source, it is not a commercial product, but it often gets treated as such (hands off the code attitude, if you want to extend our code, use a different product), but I have heard from many users that they would appreciate it if Trinidad were more extensible and be more open for extending or adapting the code. 5) Fine grained building blocks to improve customization to allow components to look and behave . Example, the table should not have "select all/none" links, that should be a separate component so that people can create a table that works the way their company would like it to work, not always the way that was good for Oracle companies to have one standard look and feel. Would be nice things, but not required by any means: 1) use of a common AJAX library at MyFaces 2) use of a common validation framework at MyFaces 3) use of a common filter framework at MyFaces (specifically handling file uploads) 4) make Trinidad a component set instead of a render kit (Trinidad does not need custom renderers for h: core components, so why is it a render kit?) 5) hooks in the APIs to improve compatibility with other component libraries (allow someone to write a bridge library to join two normally incompatible libraries, like maybe A4J/RichFaces) 6) Better support for the user community to give back (Trinidad hosted plug-ins, easier to donate and maintain components in the sandbox, user donated skins, etc.) I believe that it is important to try to preserve Oracle's support of Trinidad at the bug fixing level, but allow Trinidad to live a separate life from the rich client so that it can grow. By creating a separation of Trinidad and the rich client, Trinidad could live a life of its own, becoming more open-source developer friendly and not having it be constrained to having only new functionality that is written for the rich client. A couple of options to address this that have come to my mind, are to either create a new branch for Trinidad (like 1.5.x or 2.x) that the rich client would not adopt, or spin off Trinidad into a new MyFaces project. In terms of a new project, the specifics could vary, but no matter how it was done, it would live as a library under MyFaces like Tobago and Tomahawk and would use pieces of Trinidad code to start with. This approach would give us a clean slate to start with and also plenty of experience and code to leverage from the existing source. APIs could be enhanced and cleaned up, removing any legacy methods or aproaches, and the UIXNode architecture would be easily removed. Such a port, being a lot of work, could have several advantages though. It would allow us to add more fine grained methods, more declarative base attributes, more flexible components. Since it has been proven that no one has the desire to clean up the old Trinidad code, this would be a way to get developers excited. Instead of just cleaning up code, it would be re-writing it with much less of a learning curve. Besides, new code is always something that inspires open source developers as opposed to maintaining someone else's code. Since it would be based on Trinidad (taken from, not using), it would still meet the same goals and therefore still have a home in MyFaces. With a new project, we could try to design it so that it would work with other MyFaces projects better (like Tomahawk). Having a new project would also allow developers who like Trinidad to be able to add new robust features and make new components and make other changes without the problem of Oracle trying to stop it from affecting the rich client. In such a new project we could even enhance the sandbox to not just components, but sub-projects. For example, there could be jQuery, YUI, Dojo based Trinidad components shipped as separate jars for those that want a little more JavaScript integration and want to not re-invent the wheel (there are so many JS libraries out there that would work fine in a JSF environment that no one has really embraced to help users do this). In summary, I love both Trinidad and the rich client, but I really feel that something needs to be done to help Trinidad out of its apparent stagnation. The Trinidad community has too restrictive to new features and too slow on Trinidad updates from what I have seen. The components with their renderers have not improved in a very long time (practically since the donation). This is not a vote, this is just a discussion I wanted to spark. To help find out what people think, here are some ideas on a quick response: 1) I like the idea of a new library based on JSF 1.2 and taken from Trinidad as a starting point 2) I like the idea of a new library, and I think it would be great to start it as a JSF2 only set of components 3) I like the idea of two separate Trinidad branches, not creating a new library 4) I think something should be done, not sure what, but I really don't want another component library offered at MyFaces 5) I'm indifferent 6) I like things the way they are and do not want change with respect to Trinidad 7) Other: (enter here) Thanks for reading this through. -Andrew PS, my preference is #1 in the list above.
