Maven by itself is not that big of a deal. Almost any system using declarative builds and dependency management would have worked to improve Java builds.I've felt frustrated by Maven too. I've frequently complained about the quality of some of the plugins... but...
In the shop I work in, historically every developer was a project manager, developer, and 'salesman'. This led to many projects, most using Ant to build. Each Ant build would perform fundamentally similar builds, but each project's build code was different. You couldn't efficiently work on another developers project without reading the Ant build first, and you certainly couldn't expect any certain goals to be defined. This boils down to a lack of developer discipline, which is what the Maven lifecycles enforce. Moving to maven made our builds consistent. It took a bunch of rogue coders and forced them to produce predictable builds; a HUGE improvement. That said, this isn't a consulting shop that creates stand alone applications. We must maintain anything we create, so creation efficiency is less of a priority than long term maintainability. If I were a consultant and a customer said 'screw the long term' I would whip off an Ant build. It can be faster to create. It also may secure my status as the sole consultant, if I make my build really wacky ;-D The real benefit of creating regular builds is that it gives you the ability to use continuous integration and artifact management. If you haven't set up all the infrastructure and tried it, it may seem unneeded. For our shop, it has improved things greatly. In the past, there had been several occasions where a developer left the company without checking in source code that was in production. The developer's code worked for long enough for their machine to be reformatted and given to someone else, then a bug surfaced. Oops... lost source code, with no developer. Using a continuous integration server with scheduled and automated deployments prevents any project from going live without being in source control. Problem gone. I do understand that not everyone has these sorts of problems. For those that do, maven/continuum/archiva are great. On Thu, Jun 18, 2009 at 4:37 AM, Joel Halbert <j...@su3analytics.com> wrote: > 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+Mave > > >>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 > >
