Re: [m2] Is there any way to override the default filter pattern for resources?

[Carlos Sanchez <ca...@apache.org>]

About the JSP use case, although you could filter the entire set of
jsps, based on the info you gave I still think it's a bad idea. You
would need to package different war files for different deployments. I
like more the idea of a common war with external configuration based
on the stage, profile or however you want to call it. At most only the
web.xml should be filtered.

Anyway the only conflict you would get is if the same file has build
time and runtime tokens, as you can always include/exclude the files
to process with maven. And the idea of filtering everything just for
the sake of filtering doesn't make much sense.

Another thing to consider is if you actually want to use build time
*or* run time tokens, they would need to have same name.

On 4/30/06, Colin Sampaleanu <co...@exis.com> wrote:
> 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 <co...@exis.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org