Thanks all, now I have a more complete picture. This list is wonderful ! Blower, Andy ha scritto: > 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 > > >
-- ================================================== 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
