> 1) Company decides to adopt Trinidad for a project > 2) They are either (a) crunched for time or (b) need to get a release out > 3) From mgmt, they are told they have to implement a feature > 4) Trinidad has no way to support this feature, but the current > renderer has a method that would allow me to do it if it were > protected > 5) So assuming #3, the method is protected and in the trinidad-impl.jar > 6) I extend the method, hacking the renderer and get the code to work > as required by my company and my customers. > 7) We ship on this code to get it out the door > 8) In the meantime, I create a JIRA issue to expose the functionality I > require > 9) It goes through weeks of debate (operating on recent Trinidad > experience on this comment) and finally 2 days to 5 months later makes > it into a SNAPSHOT build
so... we can fix that, to be more agile, right? > 10) My company has a policy to only use released versions, so I wait > and wait for the release (which is much better for Trinidad users that > Tomahawk which has less than yearly release cycles) > 11) When it finally becomes API, I port my code from the hack of > subclassing the code to the new API > > So as you can see, it was never my intention to treat the usage of the > protected method as a solution, but a temporary way to get my code to > work. Asking users to log bugs and wait for discussion and then > implementation and then a release is simply not feasible for many > companies that need to get software out the door. > > So when I say #3 then #2, I mean to allow people to get their code out > quickly and then go through the proper channels to improve the code. > Saying #2 only is just not feasible for companies to meet deadlines > and many companies will not permit you to change open source code and > ship the changed versions (some afraid of licenses, some afraid of > maintenance). > > I fully agree that #2 is the solution though and even that we need to > make some part of the trinidad rendering in the API, because I > strongly feel that only having components in the API is just not > customizable enough, and I don't think that components with 300 > attributes and facets is the way to go. > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
