I should have said "most of the Jakarta people". Tapestry was not originally a Jakarta project and the people involved in it did not bring those biases with them. Of course I exclude you from my criticism (sorry if you took offense);
No offense taken whatsoever.
The fact that OGNL has been around for over 5 years is a testament to the usefulness of OGNL. The Struts people have known about it since its inception but my queries have always fallen on deaf ears. So what do they do? They build their own inferior expression language just because OGNL is not Jakarta. At least that's my view of it.
But that view is only Struts-centric, not Jakarta-wide. OGNL is in use in Jakarta. At this point, screw Struts anyway. JSF deprecates pretty much anyway.
I seem to recall someone already doing this, or something similar. There was a posting on the ognl-interest mailing list about it last week.Maybe if you provide the JSTL hooks to plug in OGNL you could convert more folks to it. Many Jakarta projects are contemplating migrating up to top-level Apache status, like Ant did. The community is the real focus, and what Apache and Jakarta were founded upon. Jakarta has just taken on too much and is not a cohesive community.
A guy I chatted with at the Atlanta NFJS symposium last fall had done it. He was an OGNL fanatic. I probably have his business card laying in my stack somewhere if you want me to dig it up.
Excellent. BTW WebOGNL does not have a non-caching mode. It has a more sophisticated resource-handling facility than Tapestry that can do more abstract timestamp checks on any resource, templates included, so that it can maintain cache coherency. So you can even hot-deploy templates into a production application.
Very cool. Tapestry's caching is not fine grained enough to accommodate hot deploy nicely. It throws everything away at the end of a request when caching is disabled. It could certainly take a lesson from what you have done.
I've found that some tasks are really slick with Ant because they fit the Ant model; other tasks are not applicable where they would be useful - like the <condition> task, which can only be used in a <target> - why? Because it's an action in a target.
Oh, did I mention.... all tasks in Ant 1.6 can live outside of targets. In fact, you can have a <target>-less build file if you like.
A redesigned Ant would allow for a more object-oriented approach to build files.
I look forward to your contributions to such tool! I'm +1 on Drew as committer, in fact :)
Not to be too argumentative here but the problem with Ant is not fixable with the current implementation. The additions you mention are useful, but incremental. The problem is the core design of the way Ant does its work. Trying to fix the current code base is like trying to turn a log cabin into a skyscraper by piling it higher with logs.
The heavy question here is can a codebase evolve to where it should be? Or does it have to be thrown away and rewritten from scratch? Ant 1.6 is in many ways dramatically different under the covers.
And not to be argumentative here either, as we all know it is very easy to complain about something (and sure, complaints are valuable too), but I encourage those that complain to do so constructively. Help make Ant (or whatever project it is) better... even if that involves throwing a lot away or even starting from scratch. Or get momentum behind something perhaps superior like Rake.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
