On 13/08/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > On Thu, Aug 13, 2009 at 7:12 AM, Henrib<hbies...@gmail.com> wrote: > <snip/> > > > > > > > Rahul Akolkar wrote: > >> > >> Not really a direction per se: > >> * We've had some syntactic additions, but its been organic growth > >> * We do have a JSR-223 engine for convenience, I think we shouldn't > >> go too far with it (no jexl.conf à la JEXL-63 please) > >> * Same with Main classes, good for playing around but important to keep > >> simple > >> > >> No coincidence that my latest comment on JEXL-70 contains "The purpose > >> of Commons JEXL is to build JEXL, not complex command-line classes to > >> use JEXL" (and by way of extension, other such peripheral bits). > >> > > > > Ok... sort of. I've yet to understand the inclusion of jsr-223 support > > (Scripting language for the java platform) within JEXL; an external > > "jexl-script.jar" that implements the factory & the main method would have > > made the convenience part clearer. > > <snap/> > > In my mind, its the tradeoff between three additional smallish classes > and the complexity of adding a new build artifact -- if you want to > look at adding an m2 module for the 223 bits, that'd be fine with me. >
A separate jar also makes it more tedious to use JEXL as a JSR-223 scripting language. That was one of the main reasons for including the code in JEXL 2.0, rather than in BSF 3.0 or elsewhere. > > > Imho, the main method in JEXL itself should be a test class in the test > > package. > > > Yeah, OTOH, theres something to be said about having it in the jar > (specifically, ease of access). So, this one's for you and sebb to > discuss :-) Yes, that's why I put them in the main code jar not the test tree. Can't see any point otherwise, as the test classes are not shipped. > While we're at it, I see little value in the junit package. +1 Seems to me that might be better in the test code. > -Rahul > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
