Well we develop T5 in Eclipse as a Dynamic Web Project using ANT and IVY for builds and dependencies. (+SVN for version control) There was a fair amount of work to set it up along with the CI server etc, but it works pretty well for us and everything was new to us. Anyway it is definitely possible.
We considered Maven briefly, but a combination of nightmare stories (2 on Howard's blog itself), completely confusing documentation, Howard's intent to move T5 away from Maven (what happened to that plan over the last year or so?) and impending deadline for project start meant that we dumped Maven for a simpler system. Was that the correct decision? I don't know - Ivy took a while to figure out but generally does what it's told and only that and the rest is done using Ant scripts. It may have been a bit more work, but at least we understand how it works inside out. We do have to get dependencies from public Maven repositories (which can be problematic) - we only do this once and put it into a company-wide shared Ivy repository. Seems like Maven is a bit like Marmite... ;-) > -----Original Message----- > From: Ivano Luberti [mailto:lube...@archicoop.it] > Sent: 18 June 2009 13:47 > To: Tapestry users > Subject: Re: [Tapestry Central] Why chose Tapestry? > > 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+Mav > en) 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 > > > > > > -- > ================================================== > dott. Ivano Mario Luberti > Archimede Informatica societa' cooperativa a r. l. > Sede Operativa > Via Gereschi 36 - 56126- Pisa > tel.: +39-050- 580959 > tel/fax: +39-050-9711344 > web: www.archicoop.it > ================================================== > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
