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 >>> >>> >>> >
