I hear what your saying, I'm still not convinced :-)
On Thursday 18 June 2009 09:57:11 p.stavrini...@albourne.com wrote: > Hi Joel, > > I understand your argument with Maven, most people at some point have 'felt > the pain' but with or without maven the devil is in the details, getting > started is not that hard really, but customizing Tapestry to your > environment is very often the root cause or configuration constipation, a > problem which extends from the world of Java where there are so many > resources, libraries and tools that it can often be a pain to integrate and > use all of them efficiently. Its widely acknowledged that Java has inherent > flaws in versioning and dependancy management (if only I had a penny for > every post I have seen relating back to classpath, and library versioning > issues), and thats the problem Maven tries to solve. In a small operation > you can get away with doing dependency management manually, but not for > enterprise applications or any development of scale. > > regards, > Peter > > ----- Original Message ----- > From: "Joel Halbert" <j...@su3analytics.com> > To: users@tapestry.apache.org > Sent: Thursday, 18 June, 2009 11:37:34 GMT +02:00 Athens, Beirut, > Bucharest, Istanbul Subject: Re: [Tapestry Central] Why chose Tapestry? > > I'm still not convinced that using Maven is a good thing. > It's fine for those people that use it day to day already, but for those > people who have no need/interest in picking up another framework and who > just want to get on with using Tapestry its a real bug bear. > > I've always just downloaded the binaries for whatever project I'm using and > dropped them into my project. I very rarely have versioning issues (if > every at all in fact). I'd go so far as to say that this is preferable - > you know exactly what code your using, and why, because you've put it there > yourself rather than having some opaque system under the hood doing it for > you. This would seem to give you a greater degree of control over whats in > your environment - important when it comes to deploying. > > On Wednesday 17 June 2009 22:15:23 Norman Franke wrote: > > I did, and that worked using jetty on the command line. Eventually, > > following the other instructions, I was able to even get that working > > in Eclipse. However, it is very basic: no hibernate, no security/ > > authentication. > > > > I started following the instructions in the tutorial, which do not work. > > > > Norman Franke > > Answering Service for Directors, Inc. > > www.myasd.com > > > > On Jun 17, 2009, at 2:21 PM, 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+Ma > > >>ve n) 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 -- 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
