I agree with Juan. This is the biggest barrier to Tapestry adoption. Most people I know who are working even for big corporations are not used to Maven. In fact I know at least 100 developers from various companies in our area and nobody uses Maven. Most people want a dynamic web project in eclipse with the ability to export/import the application from/into eclipse as a war file.
I have wasted a lot of time myself with Tapestry5 already. Most of the articles and examples either don't work or are incomplete. I think Tapestry5 is probably very innovative, easy and fast, but getting the development environment setup right is very tough (without maven). The other problem is the understanding the best practices for Spring, Hibernate integration etc. The Jumpstart application tries to do this. It would be nice if the Jumpstart application was available as a war file (with sources) which could then be imported as a regular Dynamic web project in Eclipse. But to get Jumpstart to work on Eclipse is a marathon activity with thousands of steps. I gave up. How about 1 step: simple war file with all the sources that is easy to import into Eclipse? The Tapestry4NonBelievers site does this, but their war file is not compatible with the latest Tapestry releases. Also, that application is very small with only a few concepts being covered. I have used other frameworks (specifically ZK) that are very well documented and easy to use, come with a comprehensive set of examples that is easy to download and setup. Even Wicket has a good demo application (as war file with sources) that ships with every release that just works. It would be really helpful if every release of Tapestry shipped with a standard demo project (like the Spring Petshop or ZK Explorer or Seam Hotel Reservation) with all the best practices illustrated (Spring/Hibernate integration etc). Without a book, and no working example code that can easily be installed (without maven), it is very hard to learn the framework (however simple the framework might be). Juan E. Maya wrote: > > did u follow the tapestry quickstart in > http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it > could get easier than this. U can even run it inside eclipse if u have > the m2 plugin for maven. > > i do agree with u that the documentation could be better, however, > reading your message somebody could believe that starting a new > tapestry project is extremely difficult and it's totally the contrary. > > On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<nor...@myasd.com> wrote: >> 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 >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > -- View this message in context: http://n2.nabble.com/-Tapestry-Central--Why-chose-Tapestry--tp3089605p3095973.html Sent from the Tapestry Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
