Carlos,

It's not just JSPs first of all. ${xxxx} is a pretty common syntax used for various templating and expression evaluation needs. For example, you might see that in a Spring application context file when somebody uses PropertyPlaceHolderConfigurer to externalize some values to a separate properties files. Or OSWorkFlow uses it to evaluate expressions in workflow definitions. There are lots of other cases...

So there's a conflict here. There's a general need to do filtering while you build, and I've certainly worked on plenty of projects in the past where we filtered the entire set of JSPs (or whatever the templates were), and pretty well all non-class files in the app since in ant at least (and Maven may be just as efficient) you didn't pay a huge penalty for copying with filtering.

As for the use cases for filtering during the build, we're talking about having different dev/staging/production profiles, or very lightweight 'branding' type changes that don't warrant entirely different template files, etc. So this is is things like properties files with JDBC properties, server addresses, etc. It's also JSP/template pages for the web site, and the web.xml file. It applies to various lib specific xml files.

Given the need, I just consider it completely unacceptable (irresponsible really) to rely on luck that tokens used for build-time filtering will not conflict with the same tokens used by some run time (post build-time) system or library that uses the same ${xxx} syntax. It's a complete non-issue with ant, as you can pick whatever token replacement syntax you need.

Colin

On 4/29/2006 7:54 PM, Carlos Sanchez wrote:
Colin, can you explain what's the use case here?

I don't see the probelm with JSPs because you would at most filter the
web.xml setting a parameter that is later accessed at runtime from the
jsps. I can't think about a use case where you would need to filter
all the jsps at build time.

On 4/29/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrote:
Hi,

When turning on filtering for resources in Maven2, is there any way to
override the default filter string pattern of '${token}'?  I can't find
any mention of any way to customize this, in any docs.

The use of ${token} as a token is IMHO a really bad choice, given the
fact that it's such a common token replacement syntax in various page
templating technologies like JSPs. These are exactly the kinds of files
likely to be copied around as resources, leading to all sorts of
potential conflicts in filter instances meant to be replaced by Maven,
and instances meant for the JSP engine.

Regards,
Colin


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to