Ok. That pretty much vetoes seperating out the parser code. Then I will
start to fix up the maven build and the docs.
sorry... it was a good idea.
----- Original Message -----
From: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>
Newsgroups: hometree.jakarta.velocity.dev
To: <[email protected]>
Sent: Sunday, October 30, 2005 4:04 AM
Subject: Re: Separating out the generated parser code
"Will Glass-Husain" <[EMAIL PROTECTED]> writes:
Hi,
I'm reluctant to endorse changes to our public API for versions 1.x.
Creating custom directives is obscure, but I'm sure there's others who do
this. (One of the articles linked to from our web site has an example of
a
custom directive, for instance.) I think we should continue to have a
"drop-in upgrade" objective for all publically documented features.
Ok. That pretty much vetoes seperating out the parser code. Then I will
start to fix up the maven build and the docs.
Also - I wanted to check. Are we keeping the capability introduced in the
recent patch of tracking the template name in parse errors? I like the
sound of your proposed changes on this but want to confirm the errors will
continue to have the template name.
Yes, they should have. Even better, the MacroParseException will now
behave similar to the introduced changes in ParseException. If they
don't, then I messed up and it's a bug. :-)
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
