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 <[EMAIL PROTECTED]> 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 <[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]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
