Tuesday, November 3, 2015, 8:31:41 AM, Woonsan Ko wrote: > Hi, > > I've just made an initial experiment PR to use Maven instead: > - https://github.com/apache/incubator-freemarker/pull/8 > > Build works well mostly and seems to create an artifact properly > (target/freemarker-2.3.24-SNAPSHOT.jar). > > However, as described in the PR, there are some issues and things to note: > - Two unit tests fail: RealServletContainertTest#basicTrivial() and > RealServletContainertTest#basicELFunctions(). > This seems related to war initialization issue. For example, the > existing ant build copies all the necessary jar files into WEB-INF/lib > somehow, but the new maven doesn't have that.
I haven't looked into this (yet), but there's no Ant magic involved. After all the JUnit tests run successfully be merely right clicking on the project in Eclipse, then choosing Run as JUnit Test. > - To support incompatible multiple versions of jython, I decided to > use the latest version of jython only and use Reflection APIs for the > older versions of jython in two classes because those two classes are > very small/simple and seems more effective using Reflection APIs. I'm worried about runtime efficiency there, at least when it comes to getPythonClassName. Reflection is relatively slow, especially a lot of it. > - Similarly, I simply added a new jsp-api 2.1 operation in a base > class to support both 2.0 and 2.1 at runtime. I think this approach > should be simpler than complex dependency management and multiple > compilations. You are still linking to JSP 2.1 classes there (JspApplicationContext and ELContext as the declared return value), even if you are just throwing UnsupportedOperationException there instead of returning an instance. And so it will still fail on runtime, unless I miss something. > Regarding RealServletContainertTest and testing with embedded jetty > server, one of natural solutions in Maven is to organize the project > into multiple modules. > For example, maybe we can change the project structure into this: > > - freemarker > |- core > `- test > `- web > > If test/web is a 'war' package project, then we don't have to copy > jars into WEB-INF/lib manually, but we can probably take advantage of > the existing features of jetty plugin or other (e.g, cargo) for > packaging in (integration)test phase, for instance. Right now I hope that we actually don't do any such hack with Ant either, and so there won't be Maven work around either. (See earlier.) > Also, the Reflection API usages for those two test classes seem okay > enough to me, but if there's any strong reason to validate those as > early as possible, then maybe we can add more submodules for each > specific purpose. I don't see reflection in *test* classes in the pull request. You meant the non-test classes? > Anyway, I'd like to share my initial experiment with you folks and > hear from you about approaches. > If we need to restructure the modules, then it should be better to get > a consensus in prior anyway. So, the reason I though Maven won't cut it is exactly the problem with linking to multiple dependency versions. Right now the number of such cases is quite low, compared to most earlier FreeMarker versions, but I don't know how that will change in the future. Anyway, I would accept any solution where it's just awkward to do these, but using a solution that substantially affects the actual output (i.e., has runtime impact), all because of the build tool, well... it's hard to accept for me. OTOH I do want Maven, and ready to accept all kind of horrid hacks as far as they won't affect the runtime. And so I'm thinking if we could just drop in some classes as resources, and those classes are just built manually and dropped and committed into the source... very very awkward, yes, but for the few cases we will endure it, and then the runtime won't be affected (no reflection used). Only, then some special test cases will be needed to check if those classes aren't out of sync with what they meant to link to and such. (BTW, we will also need the OSGi meta data, Manual building, etc. But all that when everything else is done.) -- Thanks, Daniel Dekany > Kind regards, > > Woonsan > > > ---------- Forwarded message ---------- > From: Daniel Dekany <[email protected]> > Date: Sat, Oct 31, 2015 at 1:02 AM > Subject: Re: Question on unit testing > To: Woonsan Ko <[email protected]> > > > It would be in fact very good news if this thing can go with Maven... > looking forward for the results! > > > Thursday, October 29, 2015, 10:54:50 AM, Woonsan Ko wrote: > >>>> By the way, IIRC, you mentioned in old ML that it's planned to migrate >>>> to Maven some day. Is it right? If so, when do you want to do that? >>> >>> I'm not sure if that would work out well, given that FM needs to be >>> compiled against multiple versions of the same library (including >>> rt.jar). But if someone works this topic out, it might turns out that >>> it's feasible after all. I don't know. But the bet is on Gradle. And >>> that will probably only happen when someone other than me takes that >>> task. >> >> I think it should be possible with Maven (e.g, by using multiple >> activatable profiles and system dependencies). I'd like to experiment >> it in a branch. Will let you know if I make some progress. :-) >> >> Cheers, >> >> Woonsan >> > > -- > Thanks, > Daniel Dekany >
