Ivano - I use Eclipse 3.4 with the inbuilt server runtime environment - using tomcat & jetty. I don't use Maven, instead I just dropped the few tapestry 5 jars i needed into my projects. It should take no time at all to set up, and should work fine for you.
On Thursday 18 June 2009 13:46:40 Ivano Luberti wrote: > I'm a T4 user that is evaluating if to move to T5. > If I well understand Norman message, it is not possible to develop with > T5 using Eclipse3.4 with WTP like with T4? > > I work in a small company: we use Eclipse 3.4 with WTP. We use SVN for > versioning and ANT to generate deployments. > > To introduce Maven would be really time consuming and hence exepnsive. > > Norman Franke ha scritto: > > I've been using T4/4.1 for several years and have been quite pleased > > with it. I've been using it with Hibernate, and while not perfect, > > it's worked pretty well. We've found it much faster to embed a web > > browser in our main app and do editing, queries and the like via > > Tapestry than writing native code. > > > > I have a new project to replace our aging billing system. I figured > > this would be a great way to learn T5. So, I'm migrating me, not an > > app. :-) > > > > I was pondering posting this, but this thread sort of pushed me over > > the top. Note that I don't disagree with anything Howard said. > > However, this almost became "Why I almost dumped Tapestry entirely." > > > > I'm writing this in order to solicit feedback and maybe help others. > > I've been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite > > time time, and I'm very productive developing use them (and T4.1) I > > think this is a pretty common development environment. > > > > To get started in T5 for a fresh new app, my first thought was to > > follow the tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/. > > > > Chapter 2 just plain didn't work for me. I think part of it is due to > > Maven generally being extremely fragile and working less than half of > > the time. However, even after working around that, you can't just > > import the project into Eclipse. At least not under Eclipse 3.4.2. > > > > No problem, I thought. Maven is annoying anyway. I'll just create a > > Dynamic Web project (like I do for T4.1) and download the T5.1 binary > > distribution. That's even worse. It comes with no README listing > > dependencies or anything useful, and includes tons of libraries that > > don't appear to be even needed. Tapestry failed to start up during > > initialization. Why have a binary distro that doesn't work? > > > > Back to Maven. After some googling, I found this article: > > http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven > >) Shouldn't this be included in the tutorial? Sadly, the tutorial is > > extremely basic, but at least it works. (And is the only way I've found > > to actually create a new project in Eclipse to date.) > > > > Next, I tried Tapestry Jumpstart. After hours of configuration and > > random errors (using Tomcat), it worked. However, it's so fragile and > > klugy that I just can't see using it in production. I don't care about > > OpenEJB. I want just plain T5.1 and Hibernate. Plus running in a > > remote tomcat sessions eliminates many of the developer productivity > > benefits of T5 in the first place. One thing I liked about T4 was that > > I could deploy a WAR to a stock Tomcat install, and it would just > > work. That won't happen with Jumpstart. Plus. it if takes 3 hours to > > just get a working developer environment, why even bother? > > > > Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on. > > Sadly, AppFuse's T4 support is now broken due to a dependancy on > > tapestry-flash that appears to be missing and following the > > instructions on the AppFuse Tapestry 5 page doesn't work anymore > > either, resulting in tons of missing resources. > > > > So, since T5 doesn't appear to provide much in the way of > > authentication / security (a very basic requirement for almost all > > webapps), I started down the tapestry5-acegi approach. Of course, that > > doesn't work with T5.1. I managed to get it working and then upgraded > > to tapestry-spring-security 2.1.0-SNAPSHOT. Still didn't work without > > augmentation. (Thanks to maven for not updating the packages when I > > switched to the snapshot, too. I had to delete the "nu" directory in > > my ~/.m2 directory. One more reason Maven blows. It just doesn't do > > what you want.) > > > > I'd love to see more people use Tapestry, but after attempting a new > > project, I'd feel embarrassed asking people to give Tapestry a look at > > this point. Heck, I'm thinking maybe sticking with T4.1 is the way to > > go, despite all the benefits of T5. But, I really do want to start in > > on T5 since I've loved using T4 for the last few years, and it does > > seem to be a step forward. > > > > I think its common to want to just get something working in order to > > get a feel for the framework. Doing so in Tapestry, at least for me, > > has been a waste of two days. I finally, on the third day, I have > > something that appears to allow the tutorial to work with basic > > security. I'm not sure if others have similar problems and just gave > > up without comment, making other frameworks seem more popular? > > > > Norman Franke > > Answering Service for Directors, Inc. > > www.myasd.com > > > > On Jun 16, 2009, at 7:20 PM, Howard wrote: > >> I recently had an e-mail exchange with a Tapestry user; after > >> congratulating me on creating Tapestry, he went on with the following > >> observation on his organization: The company I work at unfortunately > >> chose JSF for their big app. The reason was that Tapestry was "brittle" > >> in the sense that, if one developer breaks something, on a page or a > >> service, very often the whole site won't come up because the initial > >> registry startup will fail. Or for example, if page A has a pagelink to > >> page B, and page B is broken, then page A won't render. While I agree > >> that we shouldn't ship unless the whole app is working, this is a > >> thousands of pages big app with hundreds of mediocre (as in likely to > >> break things) developers. They'd rather have 80% of the thing working > >> than nothing at all. I never thought of this for my own projects, and > >> haven't had the time to examine the truth of their claims. What's your > >> take? > >> I provided the following response: > >> Early failures are absolutely, 100%, the only path towards code > >> quality. You may have heard the phrase "no broken windows" (see "The > >> Tipping Point" by Malcom Gladwell for more details) but the short form > >> is that when errors go uncorrected (whether they are broken windows in > >> an abandoned building, or broken code in an application) they tend to > >> multiply quite rapidly. > >> The things that will "break" a link from page A to page B are > >> substantial problems such as invalid templates, references to unknown > >> properties or components, or compile errors in the page B class ... > >> things that no other developer should ever see when page B's developer > >> is working and checking in code. That is, problems that should never be > >> checked into trunk, but instead kept in a local workspace or a private > >> branch. > >> An organization that thinks that fail early is a problem is an > >> organization that isn't prepared to develop a large application in any > >> technology. The image I'm getting is one where there is no build > >> server, no continuous integration, at best CVS for source code > >> management (or possibly one of those "shared directory" > >> monstrosities) .... i.e., a chaotic environment where errors are > >> allowed to be checked in to the trunk and can go unnoticed for some > >> time. > >> The solution to coding errors in pages or components is not to wait > >> until your testers (or end users) find the bugs, but to identify and > >> fix the bugs early. That's called "engineering discipline" and the > >> reality is that even self-professed "mediocre" developers can do it. > >> Tapestry helps because it fails early and has great exception reporting > >> to guide you right the problem so that you can fix it. > >> Another factor here is enforced helplessness. If only Fred understands > >> page B and he's out when it's broken, then all development stops > >> waiting for Fred to get back. I hit this problem myself, years ago > >> working on a large Struts application (those words give me the heebie > >> jeebies now!). We had lots of code, a fragile and slow build process, > >> and many little code "fiefdoms". I spent too much wasted time twiddling > >> my thumbs. > >> Nobody should "own the code"; if page B is is broken, Julie (who > >> normally develops page A) should be free to fix it. Julie will need to > >> understand the page B code well enough to fix it, but also you need an > >> overall environment with shared source, no repository locks (that is, > >> nothing that says "Only Fred can change this file"), and no management > >> PHB's getting in the way. Pair programming is the best way for Fred and > >> Julie to share knowledge so that they can understand each other's code. > >> Even if pairing occurs only part time, it's very effective at knowledge > >> transfer as well as ordinary coding. > >> The idea that "mediocre" developers should use JSF as it is more > >> tolerant of errors is absurd! Tapestry 5 is designed to improve > >> productivity for all developers, by streamlining, simplifying, being > >> smart and being concise ... not to mention live class reloading and > >> best-of-breed exception reporting, which makes it fast to identify and > >> fix those errors. > >> If your doctor tells you to eat less red meat, that doesn't mean you > >> should switch to a diet of fried chicken three meals a day! Likewise, > >> if you have concerns with code quality from your developers, you should > >> not switch to a less agile, more code-intensive, less supportive > >> development model and hope to catch all the bugs in QA. Sweeping > >> problems under the rug is never a winning strategy. > >> Coming down off my soap box, I should also add that Tapestry 5.1 works > >> a little bit differently than 5.0 in this respect, so it does (in fact) > >> defer more of the page loading and validation until a link is actually > >> clicked. This is more for performance reasons than to shield developers > >> from application problems. Even in 5.0, the loading and validation was > >> the "reach" from page A to pages explicitly referenced (usually via > >> PageLink during the rendering of page A), so it's a highly unlikely > >> case that a single error in a 1000 page application will keep the > >> application from starting up, unless the start page of the application > >> links to all 999 other pages. > >> Re-reading the above post I can't emphasize enough: you can't ignore > >> quality problems. Quality problems lead to development failures, > >> schedule slips, missing functionality, low morale and high turnover. > >> Saying "we don't have time to fix the quality problem first" is to > >> ignore the the second law of Thermodynamics. You are expecting a > >> miracle, literally writing it into your project plan. > >> Formos addresses this issue two ways: First, we use Scrum and deliver > >> on (typically) 4 week cycles. Thus we set real deadlines and have a > >> constant check on quality (we're providing working code constantly). We > >> don't even try to predict what we'll be doing six months or two years > >> from now, we just deliver a steady, manageable stream of software. > >> Secondly, Formos uses Tapestry because of all the reasons that the > >> anonymous developer's organization rejected it, and for many, many more > >> reasons besides. > >> > >> -- > >> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM -- Joel Halbert 020 3051 8637 075 2501 0825 j...@su3analytics.com www.su3analytics.com www.storequery.com SU3 Analytics Ltd, The Print House, 18 Ashwin St, London E8 3DL. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
