You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Simon Kitching <sk...@apache.org> on 2006/04/29 22:55:17 UTC
Re: [m2] Is there any way to override the default filter pattern
for resources?
On Sat, 2006-04-29 at 16:09 -0400, Colin Sampaleanu 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.
Well, I believe that any tokens not recognised will be left unchanged.
So if you ensure non-conflicting names are used for those tokens you
want to substitute during builds, eg
${buildtime.username}
instead of
${username}
won't this achieve what you want?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Is there any way to override the default filter pattern
for resources?
Posted by Colin Sampaleanu <co...@exis.com>.
On 4/29/2006 4:55 PM, Simon Kitching wrote:
>On Sat, 2006-04-29 at 16:09 -0400, Colin Sampaleanu 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.
>>
>>
>
>Well, I believe that any tokens not recognised will be left unchanged.
>So if you ensure non-conflicting names are used for those tokens you
>want to substitute during builds, eg
> ${buildtime.username}
>instead of
> ${username}
>won't this achieve what you want?
>
>
Simon,
Unfortunately this is just way too unpredictable. We're talking about
mixing up the tokens from Maven with those from any other templating
technology used in resources that are being copied. Somebody can for
example come along, add a variable that is used during the build, and
then kill a similarily named substitution variable in a template file of
some sort that is used at runtime in the app, and you won't even
necessarilly find out about it until later.
To compound the potential for problems, there are plenty of maven tokens
which are not very distinctly maven-specific, i.e. they don't have any
sort of unique prefix.
There really needs to be a way to force a syntax which is exclusive to
Maven's use... I find it really hard to believe that nobody else has not
seen this as an issue in the past. I've always done lots of ant
filtering in the past in my ant buils, and made sure that I used a token
syntax that didn't conflict with any sort of filtering inside any app
template files.
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org