I should clarify that you shouldn't necessarily feel compelled to use that 2.0_Exp branch. I think it has some good fixes in there, though, so you may want to check out the commit history on it.
On Thu, Sep 25, 2014 at 8:27 PM, Nathan Bubna <nbu...@gmail.com> wrote: > https://github.com/apache/velocity-engine > > https://github.com/apache/velocity-engine/tree/2.0_Exp > > Now, that said, i've not used the git mirror. The Subversion repository > may still be considered the primary one by the infrastructure guys, but i > assume they work together well enough. > > As far as Anakia/Texen, i'm not sure anyone still uses those. Don't bother > with them, for now. > > If slf4j works better for Android, that seems like a fine log adaptor to > me. > > Here's the CLA: http://www.apache.org/licenses/icla.txt > > On Thu, Sep 25, 2014 at 7:19 PM, Frederick N. Brier <fnbr...@gmail.com> > wrote: > >> Hi Nathan, >> >> I looked for the Velocity Git repo and could not find it on the Apache >> Git page. I just started with the 1.7 source code and initialized my own >> git repo and was making changes there. If you can post the git URL, I >> could clone it and try and meld my changes on to a branch and push the repo >> to Github so everyone could see it and evaluate it. >> >> While I am not familiar with Anakia/Texen, my thought was that if others >> were interested, the single module Maven project would become a >> multi-module project with at least 3 child modules: velocity-core, >> velocity-anakia, and velocity-texen. >> >> I didn't start my current project using Velocity. My background is more >> enterprise systems and not Android. So I started writing an XML schema to >> represent my domain objects and started bumping my head on a number of >> Android limitations, specific to XML. BTW, Android development tools rock, >> but I quickly found out that I couldn't use JAXB, Thymeleaf, or XMLBeans < >> https://code.google.com/p/android/issues/detail?id=76265>. There are >> several options out there for template engines, but all the ones that would >> work on Android seemed very limited. As mentioned, I'd used Velocity >> several times, years ago. So I figured I'd give it a whirl. >> >> Log4j can apparently work on Android, but enough posts were out there >> that made me nervous. Having already experienced problems with libraries, >> I decided to pare down Velocity to its minimum. That is the reason for >> trimming out the LogChute, Commons-Logging, Log4J, etc. It's amazing how >> much code could be eliminated. With IoC, the tests might even get leaner. >> SLF4J <http://www.slf4j.org/> is a real thin facade for logging and >> there are adapters to all the other logging frameworks. It is lightweight >> and there is an slf4j-android <http://www.slf4j.org/android/> project. >> >> I was not even aware of a 2.x branch, what its goals are, or what has >> been done. I can sign a CLA. Could you please post me the git repo that >> has the 2.x code? BTW, my middle name is Nathan :). >> >> Fred >> >> >> On 09/25/2014 05:49 PM, Nathan Bubna wrote: >> >>> Hi Frederick! >>> >>> Thanks for posting this here. Currently, we have a 1.x branch that is >>> stable and in a long-term maintenance mode and a 2.x branch that is not >>> really ready for consumption yet. To be honest, it's been so long since i >>> worked on 2.x that i can't remember what changes we did get done (i could >>> go look). Most of the core committers are, for one reason or another, >>> focusing their development energies elsewhere, with little intention to >>> get >>> back into it. That said, we do still actively oversee the project and are >>> more than willing to help mentor any newcomers in navigating the ASF >>> processes for contributing and working on new releases. >>> >>> It sounds to me like the work you have done thus far is largely >>> non-compatible with the 1.x branch. In particular, the removal of >>> Texen/Anakia and LogChute. I'm not especially familiar with SLF4J, so i >>> would love to hear your reasons for yanking the LogChute adaptor instead >>> of >>> just providing an SLF4J bridge for it. That said, if you are interested >>> in >>> jumping in on a 2.x branch, i would help you regardless of your >>> decisions. >>> People around here may have opinions on changes, but the "apache way" is >>> that those who do the work should make the decisions. :) >>> >>> So, yes, we are interested in your work! Do you have it public anywhere >>> we >>> can look at it? Are you working on a fork of our git mirror? Or did you >>> check it out of the subversion repo? The next question is whether you are >>> interested in working through Apache's contribution/committer process. >>> If >>> so, you should take a look at the 2.x branch and consider putting a CLA >>> (contributor's license agreement) on file with the ASF secretary, as that >>> is needed for both large contributions and new committers (which you >>> would >>> hopefully become). >>> >>> -nathan >>> >>> On Thu, Sep 25, 2014 at 5:20 PM, Frederick N. Brier <fnbr...@gmail.com> >>> wrote: >>> >>> Dear Velocity Team Members, >>>> >>>> I was looking for a template engine that would work on Android, and had >>>> used Velocity a couple of times, years ago. The latest version is 1.7. >>>> There haven't been any code changes in 4 years, although there were some >>>> recent bug reports. Log4j has some issues on Android and I shifted to >>>> Maven from Ant back in its 2.x days. So I restructured the codebase to >>>> use >>>> Maven, moved the Texen and Anakia code to the side, stripped out the >>>> custom >>>> LogChute code and changed it to use SLF4J. There are some minor >>>> problems >>>> just getting the 1.7 source distribution to build. I found a number of >>>> bugs along the way and a number of the unit tests were not even being >>>> run >>>> by the Ant build. I managed to get all but one of the unit tests to >>>> work >>>> (UberSpect related) that had been working before, and several that were >>>> not, are now. Several unit tests depended on the LogChute architecture, >>>> which with great difficulty, I changed. Having unit tests depend on >>>> logging feels like a hack, is very fragile, and difficult to understand >>>> because it isn't clear where the logging statement is being executed. >>>> It >>>> would be much better to restructure the code to use the more >>>> contemporary >>>> IoC design patterns, so mock objects could be injected. Injecting the >>>> MockIntrospectorCacheImpl was painful. Another unit test motivated me >>>> to >>>> add an initial implementation of an EventListener for the Velocity >>>> engine. >>>> >>>> The rewritten library works under Android, but would still need a lot of >>>> love before I'd be call it ready for a new release. What are Apache and >>>> the Velocity team's plans for the project? Velocity is the template >>>> engine >>>> used by Maven's Site component, so the project is still needed. My >>>> priorities are to deliver my Android application, but if Apache is >>>> interested, I could keep working and polishing it. Thank you for your >>>> time. >>>> >>>> Sincerely yours, >>>> Frederick N. Brier >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >>>> For additional commands, e-mail: dev-h...@velocity.apache.org >>>> >>>> >>>> >> >
