Updated and trimmed Velocity on Github
I posted this in a sub-tree of messages, so some people may not have seen it, but I pushed a Mavenized and updated version of Velocity 1.7, that builds under Maven3, and was updated for Java 7, along with all the libraries except for the parser, up to Github https://github.com/fbrier/velocity. I delayed pushing it because I was asked to merge with the 2.0 branch and I never had a chance. Plus the changes and commits to my own repo were pretty radical in moving files around and stripping out commons-logging. It does build, pass all of its tests and installs the jar in your local Maven repo. There is a lot I did not do, as I moved the code related to anakia, runtime, servlet, and texen into ./src/alt (vs. ./src/java), to keep it, but push it off to the side. My intention was to create a multi-module build where those 4 sub-projects would have their own jar and could be included as a Maven dependency for those that needed them. So you would have velocity-anakia and velocity-texen. Unfortunately, I never had the time... With all the comments, I would probably try and make the parser a Maven sub-module too. It is nice to see all the activity on the project. Fred
Re: general@velocity mailing list
Sounds good to me :). On 05/30/2015 04:11 AM, Mike Kienenberger wrote: And while we're at it, why have a general@apache mailing list? Something inherited from Jakarta? It's not archived or publicly visible on nabble or mail-archive.com. Users have a difficult enough time determining whether a posting should go to user@ and dev@. I see nothing that differentiates between general@ and user@. I propose we remove the mailing list from our mailing lists page, and post a last message to general@ that we're shutting down general@ and switching existing subscribers to user@, and include instructions on how to unsubscribe from user@. That's if we want to go opt-out. Or go with opt-in, and post a last message to general@ that we're shutting down general@ and include instructions on how to subscribe to user@. Opt-in is probably the better approach. Then we ask infra to shut down the mailing list and optionally set up a redirect from general@ to user@. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: Upgraded Commons and Velocity 2.0
I did a large amount of work last year on the Velocity 1.7 branch, split it into a main project and sub projects that integrated with other components, updated the packages, switched to slf4j and got it building under Maven. I am using it in an Android project I am trying to finish. That has stalled for the moment as I am on contract. I posted this on this list and everyone was supportive, but they wanted me to look at the 2.0 branch and see if I could not lose those updates. I did not know about the 2.0 codebase. I have not had time to try and merge the changes. I would be more than happy to push my changes to github and have anyone review them and determine if the changes I made would be a good restarting point. I have always liked Velocity. And doesn't IntelliJ still use it in their base framework for the templates? Fred On 05/28/2015 08:33 AM, Mike Kienenberger wrote: On Thu, May 28, 2015 at 11:21 AM, Jacob Champlin jac...@rentec.com wrote: On 05/28/2015 10:48 AM, Mike Kienenberger wrote: I would like to point out that we are very happy running Velocity 1.7, in fact there is not a single new feature we want. So we agree its a stable mature product that doesn't need a lot of changes. Our problem is the world around it has been changing, and Velocity isn't keeping up. Apache Commons in particular. Looks like its easy to go to latest lang, and digester, but collections is a different beast. So velocity isn't even keeping up with its dependencies from the same organization. Not to mention I am sure the code could benefit from newer java features. And I'm in the same boat. I don't need velocity to evolve. I just need it to keep up and remain backward-compatible so that it can continue to be used as other software packages are upgraded. I'm going to make time soon to try once again to work forward from my 1.3.1 environment up the chain of releases to 1.7 while maintaining backward compatibility. I'm far more interested in a 1.8 maintenance release than a 2.0 release. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: Upgraded Commons and Velocity 2.0
My updated Velocity 1.7 (which I changed to 1.8) is now pushed to github. https://github.com/fbrier/velocity I did not do this earlier, because I did not want to start a new project, just contribute my code. Based on all the comments in the thread, I am throwing it out there. I know it isn't perfect, but it does work, build, pass all the tests (and those it does not, were probably not being run by the Ant build), with all the latest libraries and JDK 1.7 using Maven. Please let me know what you think. Fred On 05/29/2015 07:41 AM, Mike Kienenberger wrote: On Fri, May 29, 2015 at 10:33 AM, Nathan Bubna nbu...@gmail.com wrote: If Mike wants to revive the Ant build for 1.7, i have no problem with that. I do remember the JJParserState issue when rebuilding the parser though. Always bugged me, but i never saw an easy fix. My first try at an easy fix failed, but I've got a v2 patch in issue 862 that will work -- I cheated and used the ant replace task to add the import after the package declaration. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: Successfully building 1.x branches and regenerating parser files
So this whole thread about javacc made me realize I was using the parser source files that were checked in and I was not regenerating the parser with each build. I started to look at how to do that and realize that many of the files had been modified, modified and copied, and that may be why they were just checked in. It sounds like Mike just set it up so every build is now regenerating the parser? Or was that happening before and I missed it when I converted from Ant to Maven? Also, I noticed that javacc us up to release 6.1.2 and the associated Maven plugin is 2.6. Is there a problem moving to 6.1.2 and sticking with 4.2? Should I change my Maven build to regenerate the parser? Or is it enough that I pushed my code to Github. Thank you. Fred On 05/29/2015 06:59 AM, Mike Kienenberger wrote: I have created issues 861 (improve parser documentation) and 862 (fix parser import generation) to clean up the parser building process. https://issues.apache.org/jira/browse/VELOCITY-861 https://issues.apache.org/jira/browse/VELOCITY-862 On Fri, May 29, 2015 at 9:33 AM, Mike Kienenberger mkien...@gmail.com wrote: I've already created issue 860 and I have already attached individual patches for fixing the build scripts in 1.5, 1.6.x, and 1.7.x branches. https://issues.apache.org/jira/browse/VELOCITY-860. Modifying unusable build files to point to the right download locations is one thing, but I'm on the fence about whether we should change the 1.3.1 or 1.4 java files to make them build on newer versions of java. Using an older version of java or possibly using a source target javac flag leaves them usable as is. If a person really wants to make them work under a newer version of java, it's easy to rename the variables, but that would have to be done each time the parsing files are regenerated using the older javacc packages. I am currently in the process of updating the build instructions for the parser, and removing the old build.sh script -- it only adds confusion now that the main build script does everything necessary. I should be finished with that in a couple of minutes. On Fri, May 29, 2015 at 9:03 AM, Sergiu Dumitriu sergiu.dumit...@gmail.com wrote: Good work! Mike, could you provide these instructions as patches, one for each branch? So, given that getting a working build for the 1.7.x branch is actually quite easy, we could quickly fix a couple of things and release 1.7.1. Does any committer want to take the lead on that? On 05/29/2015 08:48 AM, Mike Kienenberger wrote: On Thu, May 28, 2015 at 10:48 PM, Mike Kienenberger mkien...@gmail.com wrote: 1.3 and 1.4 won't build without some code changes -- they use enum as a variable. These were generated parser files. A find and replace of enum to enmr was all that was needed. Or going back to java 1.3 :) Parser modification also seems possible now, although the large number of changes between my generated code and the old generated code seems to indicate that I'm still not using the same version of javacc that the original code was generated from. 1.6 is a close enough match that I suspect it uses javacc 3.2. That probably means 1.5 was generated with something older and 1.7 was generated with something newer. Part of the differences turned out to be code reformatting of the generated files. Velocity 1.5 used javacc 3.1. 1.6 used javacc 3.2. Velocity 1.7 used javacc 4.2 but JJTParserState.java file needs to be manually reverted manually after running the parser task. The newly generated JJTParserState only changes the file checksum and loses the org.apache.velocity.runtime.parser.node.Node import. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org -- Sergiu Dumitriu http://purl.org/net/sergiu/ - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Spent time working on Velocity
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
