I just can tell you our experience as wicket users. We recently moved a production system from wicket 2.0 (was an alpha version or so) to 1.4RC1. This system is now in production again. It runs as stable as the old one. We developed two applications with 1.4RC1 (going through M1 to M3) which are in production now for some weeks and we had no problems at all. So much about stability of wicket 1.4 from a users point of view.
Stefan -----Ursprüngliche Nachricht----- Von: Susan Liebeskind [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 23. November 2008 13:50 An: [email protected] Betreff: Stability of Wicket 1.4RC1 methods/interfaces: new development on 1.3.5 or 1.4RC1? My project team has decided we will go with Wicket to replace our aging Struts 1.x infrastructure, so we're starting to learn to use Wicket in earnest. The next question we face is whether to use Wicket 1.3 or Wicket 1.4. Since Wicket 1.4 is at RC1, and there is substantial use of generics in Wicket 1.4, our belief is that it makes sense for use to start out using Wicket 1.4RC1. The logic is that since the 1.4 release is at RC1, things are pretty stable and methods/interfaces are not going to change in any significant way. Is that a fair assumption to make? For those experienced Wicket developers on the list, would you recommend starting brand new development now with Wicket 1.4RC1 or fall back to Wicket 1.3.5? ---- My problem is that I'm trying to work through the examples for Wicket in Action (version 0.9, available from http://code.google.com/p/wicketinaction/downloads/list) with my trusty hardcopy of the book in hand, and translate from what I am reading about in Wicket 1.3.x to the new genericized approach built into Wicket 1.4. I was hoping that the migration guide at the URL http://cwiki.apache.org/WICKET/migrate-14.html but unfortunately, the information I need to get the Wicket in Action 0.9 example code up and running is not in that guide. Alas, a March posting on the user list regarding Wicket in Action's support for 1.4 which suggested that one should be able to ignore the compiler warnings about generics didn't play out -- I'm getting errors, not warnings I can ignore. The change log for 1.4RC1 consists of a links to JIRA tickets, which requires some slogging through many detailed bug reports. When one is is new to a software technology, it's hard to see the forest for the trees sometimes, and I don't think I have enough experience in Wicket to be able to make much sense of a trudge through those bug reports...just yet. I did locate an old news posting here (http://wicket.apache.org/wicket-14-m3-news.html) which covered the switchover to a non-genericized Component class. This news item told me how to solve the errors I was seeing with Component.[get|set]Model et. al, in the Wicket in Action example code, by replacing these calls with Component.[get|set]DefaultModel. That's getting me further (and I'm also happy to contribute my diffs back to the authors if they are interested). Perhaps that snippet can be added to the migration guide now? But the overall sparseness of the 1.3-1.4 migration guide as of this writing, makes me suspicious that there are perhaps some subtleties in the migration process that I, as a newbie, will miss. Perhaps there are changes I should be making to this example code, even though things are nearly compiling, but those changes/best practices are simply are not yet documented. These are the kinds of issues that can come back to haunt you if you start development with a less-than final release :-( So perhaps we should be sticking with Wicket 1.3 because the examples and documentation is more readily available for a pre-genericized Wicket? And also, because there is no date for when the 1.4 final release will be available, and things still could change? Or use Wicket 1.4RC1 and be optimistic that we're close enough to the final product, even though the documentation isn't out there yet to support this release, and it will be slower going at first? Any advice for people just starting out? Thanks. Susan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
