"Will Glass-Husain" <[EMAIL PROTECTED]> writes:
>Hi,
>I just wanted to check in that we are ok for an October 31 "feature freeze"
>for 1.5, with a beta release shortly thereafter. The date's a little
>arbitrary (if we miss it, who cares?) but it's a useful target.
That sounds very good. I want to polish some of the rough edges of the
build process (especially the maven build) and fix upcomings bugs in
ant but that's basically it.
About the open TODOs that I sent out yesterday I will write something a bit
later.
The following things I'd like to investigate before feature freeze:
- isInitialized() - While we can init() a RuntimeInstance, I cannot find out
whether it already has been init()'ed. We do have a flag though. I want to
make it visible by a getter. It's actually a very simple change and I see
no problems here.
- Context factory - Currently we create our VelocityContext objects by using
new VelocityContext(). This is one point that really hurts integration into
other projects. I want to look into building a factory that returns new
context instances (and maybe recycles old ones). This is just a brainfart
ATM and I don't know yet if this is actually useful or even doable.
- "more common interface" This is something that I ponder around for a while
and might even work out well with the Factory above. I want to be able to
use a "common interface" like Map with Velocity. Either by wrapping a given
Map object into a VelocityContext or by allowing VelocityContext to implement
Map. Having such a thing would allow projects like Turbine to "decouple" from
Velocity specifc interfaces.
This is something that might end up in Velo 2.0. Don't know yet.
>I'd like to suggest that all user-visible changes be complete by 1.5-beta.
+1
>(only bug fixes thereafter). To me, that includes documentation.
+0. One of the good things of the beta -> rc -> release cycle is that once you
have feature freeze, you can really take some time for docs. This might
even involve shuffeling files around. So I don't want to feature freeze
the docs.
>VELOCITY-403 Enhance Velocity's LogSystem and internal use thereof
>VELOCITY-146 Macros not evaluated on the first attempt
>VELOCITY-373 Enhance ParseErrorException
>VELOCITY-401 remove all J2EE build tasks
401 is resolved IMHO.
>VELOCITY-186 #set does not allow to assign nulls---cannot it be changed?
>VELOCITY-405 Document new Event Handler features
>Henning, Nathan - is this a reasonable approach? I'm excited by the idea of
>letting the general user population to play with all the new features with a
>binary release.
Big +1. As a said in the thread with Daniel, I do want to apply some
formatting magic and I really want to tackle the 257 javadoc warnings
when building. I assume that I will do these right after Oct 31th
before we build the first beta.
BTW: Is Oct 31th all arbitrary? It is a monday and my current job
constraints allow me to put time into Velocity either in the Fri-Sun
time frame or in the evening if I get any online connectivity at the
hotel. So I'd say that these cleanups might happen around Nov 4th.
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]
