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]