Sparqle, You've hit on exactly the same problems I've seen with Tapestry. Further, there have been too many places where Tapestry 5 does not work with X environment (i.e. JBoss 4 or 5 or Glassfish, without modifications) and it just gets brushed off as "its not our problem, somethings wrong with X"
Though I haven't seen anyone trying to import/export a WAR into Eclipse, that one kind of surprised me. All of the Java developers I know (except for 1) won't touch Maven, and use project specific Ant scripts on a continuous integration server. The only place where I've found Maven convenient is just for obtaining library dependencies. I then copy them and throw Maven away. On Wed, Jun 17, 2009 at 6:28 PM, Sparqle <dsrika...@gmail.com> wrote: > > 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 > >
