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