The text in http://tapestry.apache.org/tapestry5.1/quickstart/ is ambiguous.
In one place it says *-DarchetypeCatalog= http://tapestry.formos.com/maven-repository*, but inside the example box there's *-DarchetypeCatalog= http://tapestry.formos.com/maven-snapshot-repository* which does not work. *Unfortunately, many users see only the latter url!* Olle 2009/6/17 Norman Franke <nor...@myasd.com> > 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+Maven)<http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+%28including+Maven%29> >>> 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 >> >> > -- Olle Hallin Senior Java Developer and Architect olle.hal...@crisp.se www.crisp.se
