OpenSymphony dirty laundry

For a while now, I’ve tried very hard now not to blow up publicly about the pitiful state of opensymphony. Previously I’ve resisted from whining too much because, well, it’d be a bit like spitting in your own eye. Not to mention that in this particular case, it felt a bit too obnoxious (even for me) to whine and complain about something that is directly in my power to fix.

No more though! I feel much better about whining now because the stupid system that is in place actually makes it impossible for me to fix things, even though I’ve tried. For one thing, there is absolutely no direction or ‘leadership’ of any sort whatsoever. Joe Walnes had lost interest a couple of years ago, and any new projects he comes up with will be housed almost anywhere but in OS. Mike of Atlassian now has a shiny company to pour all his efforts into, so OS is only useful to him insofar as it benefits his company. Any open source urges he might feel will happen under the Atlassian banner as it’s good marketing (Seraph, for example). The most work I’ve seen him do for OS is converting the website to a broken-halfcompleted state to a pastel atlassian look (note the beta message that’s been at the top for a few months now). Sorry Mike, you’re a great guy, but lets be honest here, your performance for the last 18 months with regards to opensymphony has been pitiful at best, at least from my (maybe ignorant/uninformed) perspective.

To be fair, Pat Lightbody at least has some genuine interest in opensymphony (an interest that is offset with a busy real job and no actual dependencies on opensymphony for anything). My constant nagging at him has had a 25% success rate, so it’s just a matter of sticking at it and nagging as often as possible.

What finally drove me over the edge was that damn website. I’ve wanted things updated on it for months now, and nothing ever happens. I’m not updating content to make myself look good, or to try and generate more business for my company, or for cosmetic reasons. It’s simple stuff like making sure javadocs are current, and links are accurate and so on. I’ve asked for the jira installation to be updated, but I guess there’s no reason for that to happen since we’re a charity case and not a paying customer. The website, wiki, and jira server go down mysteriously for days on end.

All in all being affiliated with opensymphony has been nothing but a hindrance for osworkflow lately. The benefit in terms of marketing is more than offset with the inability to rely on basic project infrastructure. Chris Miller has felt similar frustrations when trying to release OSCache 2.0, where the release had to be held up for weeks on end due to our inability to ensure the javadocs on the website are updated.

Ah well, to cheer myself up, I’ll hurl a few cruel jabs towards webwork2. I note with much hilarity that the project has now been ‘in development’ for 10 months, rapidly approaching the year mark. It is used by a handful of people in a number of mostly toy apps. API’s still change on a day to day basis. Looks like Pat has finally woken up to the havoc that Jason and friends have wreaked on the codebase (not to mention idiotic rewrites just to up the coolness/masturbatability factor) and is now busily undoing the retardation and restoring webwork1 type behaviour. There’s hope, sure, but I for one am rather dubious of a framework that brags of simplicity and ease of use yet has taken almost a year to arrive at beta2 (due Real Soon Now).

46 Responses to “OpenSymphony dirty laundry”

  1. Patrick Lightbody Says:

    Alright, well I think that some of the things said here are a bit mean (the “havoc” caused is merely the changes that we’ve all been doing in making sure 2.0 is 1.3 compatibile — not because the original 2.0 code was broken).

    However, the website, jira, infrastructure is overall pretty poor. I agree 100% with that. SOMETHING needs to happen. And with the services being owned by Mike and my limited ability (granted, this recently expanded in to slightly less limited ability), we’re pretty much helpless.

    I know Mike is super busy (Confluence is going to rock, and Jira already does), but maybe it’s time that we get enough donations to run the OS services on our own — cohosted somewhere were folks like Chris, Hani, and I can (working as a team) get things like the website and jira instance updated in a matter of hours rather than months.

  2. Anonymous Says:

    I HAVE THE POST NUMBER PI!

  3. Jason Carreira Says:

    I’m not sure why I’m being blasted for WW2 changes… I’m only recently becoming involved in the WebWork2 codebase. I spent most of my time on the core Xwork stuff (Action invocation, interceptors, validation). The main stuff I had done in WW2 before recently was the form token implementation.

    Yes, the taglibs have been changing a goodly amount recently as we’re getting close to the final releases. That’s a GOOD THING, as you’ve been complaining about a lack of interest in backwards compatibility. Well, now we’ve got everything working and we’re crossing our “t”s and dotting our “i”s, so quit yer whinin.

    As for OS infrastructure, yes, it has had its problems. I think between all of the opensymphony stuff and javablogs it may be too much for the one box they’re running it all on. Yes, I agree that we should make it more open for OS people to contribute to the website, maintenance, etc. but I hardly think it’s fair to bile all over Mike…

    You know where I’d like to see OS go, we discussed it in the OS email that went around a few months ago. I’d like to see OS be more than it is and stand up in the Java OSS community to stand for quality as an anti-Jakarta. I think abusive tantrums like this only hinder that vision, though.

  4. Sam Newman Says:

    You realise of course that if the OpenSymphony website was built using Maven, you wouldn’t have to worry about the javadocs being out of date :-)

    Sorry, couldn’ resist!

  5. Matt P Says:

    I just pre-ordered http://www.amazon.com/exec/obidos/tg/detail/-/0471463620/002-7118307-9510404

    Did I waste my money? :)

    From the bits and pieces of sample code, I can find, webworks looks much less “tedious” than struts(looking for a change).
    I was going to give it a try for an on the side consultant job. I do wish there were more well designed sample applications. I can only find the hello world/small sample apps. Where can I find a couple webwork 1.3/2 apps that use the “whole bag of tricks”?

    Also, for getting up and running with ww, do you recommend digging into the 2.0 or staying with 1.3?

    Matt P.

  6. Patrick Lightbody Says:

    Matt,
    No you didn’t waste your money. Hani is venting for a very valid reason — the website (and docs, which depend on the website) is crap. And it is somewhat out of our (my) control — but Mike is slowly helping me fix that. Mike, as well as Hani and myself, are just very busy.

    I am going to be bold and predict that the website will be updated in 24 hours. :)

    As for WebWork 1.3 vs 2.0, I’d go straight to 2.0 — it’s a lot better in many ways. But if you do go with 1.3, the upgrade path will be pretty easy (a core goal of 2.0).

    -Pat

  7. Drew McAuliffe Says:

    As for the “toy app” comment, I just moved a ww2-based app to production today for a pretty major electronics/game company whose name rhymes with “bony”. 25-50 user base, growing to upwards of 800 over the next year.

  8. Anonymous Foolz Says:

    Where the hell is the code from the upcoming book?

  9. Toy App Maker Says:

    “5-50 user base, growing to upwards of 800 over the next year.”

    Are you serious? God, that ranks right up there with E-Bay, huh.

    What a joke. You do realize that to some of us, anything less than thousands of users is “toy app” territory.

  10. Gavin Says:

    See, what you guys need is a Christian Bauer. But theres only one of him. And I have him and you’re not getting him. :-P

  11. Patrick Lightbody Says:

    Toy App Maker,
    The cowardly criticism is pretty sad. With that said, 800 users isn’t a _huge_ application, but it certainly isn’t small either. Unless you are making apps for Amazon (last I heard, they don’t use Struts or WebWork 1.3 or 2.0), odds are you’re much closer to the 800 users territory than the 10,000,000 users territory — so shut yer trap unless you can offer up some real projects you’ve worked on.

    Rock on Drew.

    -Pat

  12. Dick Zetterberg Says:

    To Matt P:
    The petstore application has been implemented using Webwork 1.3. Have a look at it here:
    http://xpetstore.sourceforge.net/

  13. Anonymous Says:

    Jason says “I think abusive tantrums like this only hinder that vision, though.”

    No, what hinders this vision is you going to every public forum, be it a blog’s comments, TSS, etc, slagging off Jakarta projects like Struts and saying how it stinks worse than dog shit.

    You don’t see Gavin deriding OJB/Cayenne/Kodo/etc do you? That’s why people respect Gavin and his work.

  14. boxed Says:

    I tried to fix the OS homepage, but the fact that CVS is totally out of whack and tells me to fuck off hasn’t helped.

    Jason said: “Well, now we’ve got everything working and we’re crossing our “t”s and dotting our “i”s, so quit yer whinin. ”

    By “everything” you don’t actually mean any backwards compatbility do you?

  15. Jason Carreira Says:

    “No, what hinders this vision is you going to every public forum, be it a blog’s comments, TSS, etc, slagging off Jakarta projects like Struts and saying how it stinks worse than dog shit. ”

    I’ve never seen Gavin hold his punches on Entity beans or JDO 1.x… Gavin tells it like it is (or how he sees it, I happen to agree). I try to tell it like I see it. Struts DOES suck. If you don’t think so, then fine, you can have your opinion. I would encourage you, however, to try another framework to see what the rest of us are talking about.

    Struts doesn’t need Anonymous posters defending it, it’s doing just fine. The problem, as I see it, is that many people fail to look past Jakarta for opensource Java, and that’s just a shame.

  16. Jason Carreira Says:

    “By “everything” you don’t actually mean any backwards compatbility do you? ”

    Yes, I do. I’ll let Patrick answer more fully, since he’s been leading up the backwards compatibility charge, but it’s going to end up being pretty compatible.

  17. Ron Eisele Says:

    Struts vs. WebWork

    Hello, all…been lurking, reading the BileBlog for some time (entertaining, certainly). On the whole Struts vs. WW thing, I’ve taken into account all the rants here against anything Jakarta and/or Struts, but it really all seems to come from a certain jealousy that WW is not the top framework. I could be wrong, certainly, but I’d like to see on the OS site (or here) detailed analysis of why WW is better…Struts does the job for me now. Just saying it ‘sucks’ is not enough to turn people to something else; criticisms directed at any technology have to be put into context…i.e. “EJB’s suck” is an empty statement. Experienced devs know when to use ‘em, where to use ‘em, and what to avoid.

    Anyway, keep the rants here at bileBlog, but perhaps dig into why Struts (or other framework)users should consider WW…this is touched upon in WW’s FAQ, but…don’t know if it’s feasible, or seen as valued, but I’d like to see it…

    ‘course, may just have to break down and d/l, give it a whirl, and write my own if I can see it’s “better”….cheers, all!

  18. Toy App Maker Says:

    Actually the nature of the work I do, and the company I work for will not be disclosed here. Simply put, I am literally not at liberty to discuss it–if you know what I mean. So cowardly criticism is all you’ll get. And you’ll just have to accept that–because you know I’m right anyway.

    Just read “Drew McAuliffe’s” post again. It’s lame. He’s insinuates that just because he rolled out some app for Sony that uses ww2, and the fact that they have 25-50 users (growing soon to 800!) somehow validates ww2′s fitness for large scale applications.

    Our apps don’t use WW, OS, Struts or any other crap like that. It’s just good old in house code written using Patterns from the Core J2EE Patterns book.

    So, just because you toss some steaming pile of dung into production, doesn’t mean it will scale. And an 800 user base doesn’t convince me otherwise.

    And by the way, your whole “tell me what you’ve written or shut up” attitude is just as lame. Some of us work for agencies and companies on projects that some here could only have wet dreams about. And if you think Amazon has the largest collection of users and “personal information” then you need to get a new tin foil hat!

  19. Nick Minutello Says:

    +1 on the OS rant.

    Anyone tried building Webwork 1.3 from src?

    How fecking hard is it to make sure that there are ant scripts and that they work?
    How fecking hard is it to ship the right libraries?

    -Nick

  20. Nick Minutello Says:

    +1 on the OS rant.

    Anyone tried building Webwork 1.3 from src?

    How fecking hard is it to make sure that there are ant scripts and that they work?
    How fecking hard is it to ship the right libraries?

    -Nick

  21. Enlightened One Says:

    I have to agree with the Toy App Maker. All the Struts and WebWork crap is just masturbatory garbage. The use of core J2EE patterns in house to create an adequate MVC based architecture suited directly to project requirements will always do the job. Why try to shoehorn some Struts/WebWork lameness into a production application that has specific requirements that don’t fit with Struts/WebWork? Struts/WebWork and similiar projects will always belong to toy apps and hobby projects.

  22. okay,whatever Says:

    why would anyone create a mvc pattern library/framework in this day and age? do you also rewrite remote method call frameworks, persistency frameworks, security frameworks, the whole fscking stack???? I know you were trying to sound l33t and all, but…that’s one of the more ignorant comments to make…”similar projects will belong to toy apps and hobby projects”…yawn, whatever

  23. Silent Bob Says:

    Jason says that there is work afoot to ensure that WW2 will “end up being pretty compatible” with WW1.3. This is as lame as a one legged wombat.

    This is a sign of the folly of youth that seems to have blighted the whole intrepid adventure that has been WW2. Providing ‘sort of’ backwards compatability as an after thought indicates the project was off the rails before it even got out of the sidings. This goal should have been the prime directive so as to provide WW1x codebases for somewhere to go. Without providing backwards compatability it is just another example of the Open Source Masturbation anti-pattern – rather than enhancing something that exists, you go and create yet another incompatible and competing standard. The masterstroke was to call it Webwork 2, thus disguising the fact that it is really completely unrelated to Webwork 1.x – adding confusion to the minds of potential users and sending them scurrying back into the Jakarta burrow.

    Now I realise it is very easy to be wise after the fact, but it is also easy to do so before the fact with the benefit of experience and the clarity that comes without the mist of youth.

    How difficult would it have been to take WW1.3, surround it in test cases and fix the outstanding bugs before setting sail for the new world?! Maybe it would have taken a month to do that, but oh what a difference it would have made. It might actually be delivered by now and would have offered upgrade path that was a gentle slope rather than an endless fall into the abyss.

    Webwork 2 is never going to be fully backwards compatible – oh, but it’s going to try – and that is far more dangerous.

  24. Matt P Says:

    I am not sure that I get the “Anti-Jakarta” theme. I certainly respect the contributions people have made for many jakarta projects.

    Its not some much jakarta itself, but its the in-flexable/”fixed” attitude (generally corporate) that this is only “supported” way of doing things here. People charge ahead with tunnel vision regardless of the fact that there is another way that only requires a fraction of the effort(and it doesn’t require putting pegs in square wholes).

    -Matt

  25. Krusty Says:

    Bob’s got a number of good points there….

    Taking 1.3 and wrapping it with tests would put the codebase in great shape for WebWork 3.

    There could be a great merging of some of the nice bits of WebWork 2 and all the well used useful pieces of WebWork 1.3.

    btw — why the package renaming — webwork.* seems much better than com.opensymphony.webwork.*

  26. Jason Carreira Says:

    Some points:

    There were core things we wanted to change in WW2 that required a break of backward compatibility, the main one being using Ognl as the expression language. The EL in WW 1.x was yet another piece to maintain and is not as powerful as Ognl.

    Outside of this, configuration (for which some automatic conversion tools have been developed), and splitting up the ww:property tag, which was just playing too many roles, things will be completely backward compatible. I think this is a remarkable accomplishment considering the separation we’ve done to make XWork a completely generic command framework and to add features like Interceptors which can be used to add functionality to any Action invocation without changing your Action class.

    The package renaming from webwork.* to com.opensymphony.webwork.* is actually beneficial, since you can safely have WW1.x and WW2 running in the same application with no class path issues.

    In terms of “anti-Jakarta” I meant in the sense of being the opposite of Jakarta. I want to see OS projects be best of breed, clean code bases, and not interdependent to the point that you end up with a dozen jar files to use one project. There are real problems with the Jakarta libraries, and I want OS to stand in opposition to that way of development.

  27. BSD Says:

    Yes I have one and it’s bigger than yours.

    Swingin.

    Good grief. Why use the java class libraries when they may not be a perfect match for your project!? If it ain’t invented in house it’s crap. BSD I am.

  28. Silent Bob Says:

    Jason – you just don’t even begin to get it do you. I am not sure you understand what compatability means. You can still be compatible while completely changing the internals as long as you still abide to the existing contracts. That is what test cases are all about. Nothing you have mentioned precludes providing compatability (I won’t insult your intelligence by describing in detail the patterns that exist for doing such things). The only exception is moving the package structure (boy, don’t get me started on that one) – and the reason you gave for that change indicates that backwards compatability was ruled out from day one. (if it needed a new package then surely com.atlassian.webwork.not)

    The comment “I think this is a remarkable accomplishment” seems to confirm that this has been more of an exercise for a few egos than thought out development that would bring value to the masses.

    I’m not saying that Webwork 2 doesn’t have some very nice things in it. It does. The problem is that the way in which it has been approached was fundamentally flawed.

    The cynical part of me (you hadn’t seen that yet) say the only thing that remains to be seem is whether making Webwork 2 it a completely new offering will make The Book sell better.

    If only you’d read Joel before letting yourself loose on the codebase.
    http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=4238

  29. Patrick Lightbody Says:

    Silent Bob,
    You clearly don’t know what you’re talking about since compatibility IS a prime direction and has been since the start. I have the IRC logs from the meeting we had back in February to prove it — or ask any of the other 50+ people that were there.

    Yes, between then and now compatibility wasn’t perfect (and it still isn’t), but then again, 2.0 final isn’t out either, so bitching about that isn’t very fair (OTOH, bitching about a 10 month schedule is fair game). Feel free to email me directly if you have trouble accepting that or think that I’m lying or anything else — I won’t be checking this thread anymore, it’s quite retarded.

    To Nick,
    WebWork 1.3 does have a lame build. That’s fixed in 2.0. Deal.

    Boxed,
    The website is being set up at this very moment to allow you to help maintain it through the java.net CVS. Thanks.

    Enlightened One,
    You’re clearly very enlightened — why just yesterday I wrote my own JDBC driver for my company… I used good design patterns and it fit my needs perfectly, no shoehorning needed. And damn I was productive. (Just to make it clear, I was being sarcastic)

    Toy App Maker,
    Stop stroking yourself in public like this, it makes me want to vomit. Good for you, you’ve worked on an app that makes Amazon look like a pet project. I bet you’ve developed the cure for cancer as well. Personally, I only work on projects where in-memory DBs can work — after that it’s far too hard for my feeble mind to grasp. And i’m sure you have a 12″ penis to boot.

  30. The Druid Says:

    So a little bit of well-founded criticism results in a post which states that the entire thread is retarded.

    Maybe Mr. Lightbody’s having another bad day but the kind of crap he’s spewing reflects badly on the entire project.

    Maybe OpenSymphony should be renamed to OpenSore!

  31. Anonymous Says:

    “There were core things we wanted to change in WW2 that required a break of backward compatibility, the main one being using Ognl as the expression language. The EL in WW 1.x was yet another piece to maintain and is not as powerful as Ognl. ”

    hmmm….
    the WW 1.x Expression language was actually really good for working with the ValueStack — which is …. the main use case for the expression language. OGNL is most definately NOT good at working with the ValueStack.

    Sure there are some good things in WW2, but the replacement of the Expression Language with OGNL surely isn’t one of them.

  32. Anonymous Says:

    “There were core things we wanted to change in WW2 that required a break of backward compatibility, the main one being using Ognl as the expression language. The EL in WW 1.x was yet another piece to maintain and is not as powerful as Ognl. ”

    hmmm….
    the WW 1.x Expression language was actually really good for working with the ValueStack — which is …. the main use case for the expression language. OGNL is most definately NOT good at working with the ValueStack.

    Sure there are some good things in WW2, but the replacement of the Expression Language with OGNL surely isn’t one of them.

  33. Silent Bob Says:

    Ignoring the stinging, well structured attack from Pat (ooo, it hurt so much) and focusing on the issues…

    In “Prime Directive” the word prime means first, as in most important, overriding, etc. This has clearly not been the case.

    The point about OGNL and WWEL is an interesting one. I work on a large system using WW1.3. When I say large I mean large number of actions/pages rather than a million users with 12″ penises. The fact that the expression language and the property tags will not be backwardly compatible means that we will never move to WW2 – it would be roughly the same effort as moving to Struts or JSP .NET. The decision to break compatibility on the one part of the application (ie the web presentation) that cannot be adequately covered by unit tests means that there is no attractive upgrade path for anyone who has decided that saying hello to the world is passé. Every JSP has be rewritten and the entire system has to go through UAT by hand from the beginning in the minutest of detail. Value add?! I think not.
    All together now… say it with me… “DUH!!”

  34. Krusty Says:

    In fact why use OGNL, why not go with the JSTL expression language?

  35. Dick Zetterberg Says:

    As for Bob’s comments concerning the EL/OGNL issue I am in the same situation, and will probably never be able to justify the cost of a migration to WW2.
    My other concern with OGNL is the loss of “control” of the source. Since the expression language is a core part of the framework it is good to know that you have the complete source (which is not very big btw) and can easily modify it to suit your or the framwork’s needs if necessary. Yes, I know OGNL is also open source but it seems much bigger than the 3-4 EL classes in WW1.3.

    I can however understand that Jason and Patrick wanted to re-write the framework rather than writing unit tests and documentation for the now inactive, original programmers’ code (as Bob suggested). They are certainly putting a lot of energy in it and it will probably turn out very well. One could however consider if it would have been better doing the project with a different name than Webwork. New users who see that WW2 is soon to be released will probably not choose to use WW1. This means that the old users that are stuck in WW1 will be a diminishing group which is bad for them, because there are less people implementing new features/bug fixes/finding bugs.
    Ok, I do not feel that this is a very big problem for me, and I do not want to criticize Jason and Patrick for WW2, because after all they are doing “volunteer” work. If I can find it useful, then that’s great, if not then I have to stick with what I have or build it myself.

    Cheers,

    Dick Zetterberg

  36. The Druid Says:

    Following on Dick’s excellent contribution, is it time for another group to take over the maintenance of Webwork 1.x? The current developers focus is 100%+ on WW2.x and is likely to stay that way. Would the 2.x developers consider renaming WW2.x to something else?

    My feeling is that there are plenty of WW1.3 users out there who would appreciate some fixes to the code and improved docs, together with better examples – maybe I’m wrong?

  37. Nick Minutello Says:

    >> WebWork 1.3 does have a lame build. That’s fixed
    >> in 2.0. Deal.

    Pat,

    With all due respect, what sort of response is that?
    That, I have to say, is Microsoft-esque upgrade coersion if I ever saw it. :-)

    “Open Symphony … Quality Components – Because we care” – ahem!

    You might have noticed that there are a number of people still using WW 1.3 – and for various reasons probably wont be moving to WW 2. So having a good build for WW 2 is about as useful as tits on a bull for them.

    Having a practically nonexistant build for WW 1.3 just doesnt reflect well on OS at all. It doesnt demonstrate any attention to detail or quality, or any respect for the community of users.

    And what about Sitemesh while we are at it?

    Practically Everyone knows about and uses the “Writer Branch” (now, head) – which has been around for several months – but hasnt been released …. Has it gone to sleep?

    (At least it has a decent build so you can build from head…)

    -Nick

  38. Silent Bob Says:

    Druid – your idea has much merit. There is much more in Webwork 1.3 that is good than isn’t. The documentation is sadly lacking and could be improved, but this is the one thing that has been kept constant between the “two versions”. (Maybe we could, er, collaberate on a book!) There are a few things that could be fixed and done better – property editors for a start. Scott Farquhar is working on incorporating Pico into Webwork 1.3. This is to allow Jira to evolve – even Atlassian realise that Jira will never be able to digest the WW2 dogfood. It would not make commercial sense.

    The root cause of all the WW2 problems is that the good people that developer WW1.x have all left. A colleague of mine described this once as “like Kindergarten Cop 2 – all the adults have left and the kids are creating chaos”.

    I am more than happy to join in on a Webwork 1.x continuance. Alas the namespace has been defacated now, so maybe we could call it Real Webwork, or Continuity Webwork or something.

    I am more than happy to do the initially unglamourous stuff – tests, documentation, bug fixes, etc – before graduating to the stuff where angels fear to tread.

    How about you Hani? Are you in? Anyone else?

  39. Anonymous Says:

    For a silent guy bob sure speaks alot

  40. Jason Carreira Says:

    Perhaps if WW1.x users are concerned about backward compatibility you could jump on board and help Patrick and myself with the compatibility jar… This could include a port of the WW1.x EL and a different ValueStack implementation to allow the use of WW1.x frontends on top of XWork Actions. The framework is very flexible and all of this could be implemented, if there’s interest.

    I sense a lot of bitterness from Silent Bob and some of the others… If you had problems with directions taken, perhaps it was better to speak out earlier? I personally would hate to see WW go down the path of Struts and other projects which feel they can’t change or add new features for fear of breaking compatibility.

    Ognl DOES add a lot of value. Things like projections? I mean please… That’s just too powerful to dispute. Our wrapped version of Ognl DOES work well with the ValueStack… It’s actually more powerful for interacting with the ValueStack the the old EL was. Add in things like the NullHandler Matt and Pat just added (which will instantiate an object if it’s null and you’re trying to set properties on it) and its really a powerful feature.

    I think it would be an excellent idea if someone with good Perl / Regex knowledge (not I, unfortunately) wanted to step forward, we could build some scripts to automatically convert WW1.x JSP pages to WW2 pages (mainly changing the EL syntax and some uses of ww:property).

    How ’bout a little positive constructive thinking instead of the bitching and moaning?

  41. Nick Minutello Says:

    >> we could build some scripts to automatically
    >> convert WW1.x JSP pages to WW2 pages

    eek!

    And will they also test them?

    -Nick

  42. Silent Bob Says:

    Nick – I share your trepidation about the “conversion scripts”. There’s no way I’m going to let that thing loose on our codebase.
    Let’s see Jira apply the script to their code base and go fully Webwork 2.
    Come on Mike, do you feel lucky today?!
    Credit to Jason though. This thread had become awfully serious, but that all changed with the words “compatibility jar”. I haven’t laughed so hard for a long time. Colleagues were crowding around to read it for themselves. The tears were rolling down our cheeks and collecting in puddles on the desk.

  43. van Says:

    My $0.2…
    Even if Webwork2 goes first production release, I think I’ll still need some time to persuade myself to go WW2.

    Webwork1 is simple and easy to use, though people may not know the strength of PrepareAction and CommandDriven interfaces until the end of their project(that’s me, too); Webwork2, on the other hand, put forth a very good programming practice – reusable components. But unfortunately, it’s too awful to learn configuring the action execution paths before they can comfortably actually write Java codes; plus, way too much xml… even someone else had made a tool, and a XSLT is available to ease conversion of actions.xml to xwork.xml.

    Well, maybe just a matter of personal preference… though idiot, I think WW1+Servlet filter (as access control) is more suitable for me – which was what I recommend to the students at technical college taking projects from us (so that I can stop them from taking Struts).

  44. Toy App Maker Says:

    Patrick,

    Actually, I don’t have a penis, but I have C cups. So, now you can go stroke yourself

  45. Kangawallafox Says:

    >> Nick – I share your trepidation about the “conversion scripts”.

    Maybe we can write some scripts to convert ASP / ASP.NET as well!

  46. Toy App Maker Stroker Says:

    How many cups? 2 or 3?

Leave a Reply