Re: [VOTE] New site layout - Apache CMS
+1 - Your great work is appreciated. On 05/16/2016 07:19 PM, Claude Brisson wrote: Hi Folks. The site hasn't moved for years, and nobody really knows how to build it (it used patched Maven plugins that were once installed somewhere on a machine that has since disappeared). Should we want to release something today, we're more or less stuck. Plus, the design is now really outdated, there are plenty of dead links, etc... So I felt it was time to do something about it, and I had a few days this week : the opportinuty makes the thief, I revamped the site layout and moved its sources from xdoc/apt/doap/... to markdown and xslt (and a few lines of perl). The site sources are visible here: https://svn.apache.org/repos/asf/velocity/site/cms/trunk/ There is a preview here: http://test.renegat.net I made several choices in the revamping process. I'll try to lighten a bit the menus, moved Anakia, DVSL, Texen and DocBook Framework to an Archive section, got rid of most of useless empty report pages but tried to keep most essential ones. If you feel something is missing, just tell me. Now to the vote: switch to this new site and to the Apache CMS? [ ] -1 [ ] 0 [ ]+1 Should the vote pass, I'll open an infra issue to switch to the Apache CMS. Once done, every commiter will be able to update pages on the site by use of a simple bookmarklet (which will commit changes, let one preview the staged result, then push changes to the production site). Other users can use the bookmarklet to submit patches. -- Claude - 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 probably shouldn't have suggested java language updates go into 1.7.1 or 1.8. I take it back. My goal was just to suggest that Velocity had fallen behind the times. -Jacob On 05/29/2015 10:33 AM, Nathan Bubna wrote: I've had some Maven hiccups, but it was working for me the last time i tried. 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. I agree that the goals for 2.0 are too ambitious. I would support a not-so-revolutionary 2.0. I doubt i'll find time to help with the code or apply/test patches, but i may be able to help with a release, and i can at least help with feedback. I think the idea of a 1.7.1 that updates dependencies is good, but any major Java language updates should probably be in 2.0, not a theoretical 1.8. I could be swayed on that if that's really what the people doing the work want to do, but that's my gut instinct. In any case, if people want to work on Velocity, i'm happy to help guide/advise and try and get those working on it the privs they need. :) We stopped using it at work, and as a father of 4 little kids, i haven't been up to spending much personal time on it, but it's still my favorite little corner of the ASF. On Thu, May 28, 2015 at 7:07 PM, Sergiu Dumitriu sergiu.dumit...@gmail.com wrote: That is all very weird... Am I the only one that never had any issues building Velocity with Maven? Building in Eclipse won't work, because Eclipse uses its own Maven reimplementation, along with its own Maven plugins. Any real Maven plugin won't work in Eclipse unless Eclipse re-implemented it. I think that both Eclipse and Maven are to blame for the lack of support, but the bigger share of the fault lies, IMHO, with Eclipse, since it didn't bother to support one of the most popular build tools for Java, and one that's been around for 10 years (maven2 that is, maven1 is even older). It seems that two plugins used on trunk aren't supported in the current version of Eclipse: javacc and antrun. Both are used for generating the parser. So, since that can't be done in Eclipse, the simple workaround is to do that from the command line. On the 1.7 tag, the pom.xml file is very incomplete, and I think that the real build is still supposed to be done by ant (check out what's in the build subdirectory), except that that build file is also broken, and this time the problem is that ant isn't as future-proof as Maven, and the dependencies that it manually tries to download are now broken links. Personally, I think that Maven is much better than Ant, and switching back would be a step backwards. However, a project should use the tools that the majority of developers/contributors are familiar with, so I won't object to such a change. Given that 1.7 has no working build, be it ant or maven, and trunk has a working build, even if it's only on the command line, I think that going back to 1.7 is not a good option. IMHO, the goals set for 2.0 are too ambitious for the developer time available, so if we don't want the project to die, we should: - see what's left to do for a working, stable release - do some quick cleanup to make it work with modern tools - fix important bugs - release a not-so-revolutionary 2.0 On 05/28/2015 03:58 PM, Christopher Schultz wrote: Mike, On 5/28/15 3:41 PM, Mike Kienenberger wrote: No, maven isn't mandated. I'd be happy if we reverted back to ant as Eclipse and ant is also what I use, and the only thing maven ever did for me to was to make everything more complicated and slow. For better or worse, it appears most of us old-time velocity users who would be motivated to contribute appear to prefer ant. I will add investigating what would be required to reinstate the old ant build for the 1.x branch to my list. I suspect it's mostly adapting to the new new project layout, but my maven skills are minimal. Let me see how painful building 1.7 is right now. Are you saying that the grammar does not work for you? When running mvn from a fresh checkout of Velocity 1.7 (svn:https://svn.apache.org/repos/asf/velocity/engine/tags/1.7, last-changed r1040245), I get this: Downloading: http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire-junit/2.4.3/surefire-junit-2.4.3.jar 14K downloaded (surefire-junit-2.4.3.jar) [INFO] Surefire report directory: /Users/chris/Documents/Eclipse/velocity-1.7/target/surefire-reports org.apache.maven.surefire.booter.SurefireExecutionException: Unable to instantiate POJO 'class org.apache.velocity.test.TestClassloader'; nested exception is java.lang.IllegalAccessException: Class org.apache.maven.surefire.testset.PojoTestSet can not access a member of class org.apache.velocity.test.TestClassloader with modifiers public; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: Unable to instantiate POJO 'class
Re: [VOTE] Mike Kienenberger as committer
+1 - I like the way that man thinks. :) On 05/29/2015 11:20 AM, Nathan Bubna wrote: Hi all, Mike Kienenberger has been an active part of the Velocity community for at least a decade, IIRC. He is already a committer and PMC member on various ASF projects (http://people.apache.org/committer-index.html#mkienenb). And now he's begun filing issues and patches. I figure it's easier to give him commit access than to commit those things for him. :) What say ye? [ ] +1 Sounds good. [ ] +/- 0 Not sure, because... [ ] -1 No. Because... My vote is +1 Vote ends in about three days (sometime Monday) - 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
On 05/28/2015 03:00 PM, Christopher Schultz wrote: Jacob, On 5/28/15 9:13 AM, Jacob Champlin wrote: So building 2.0 has not gone well. There are no valid instructions online, eventually I figured out: $ svn checkout http://svn.apache.org/repos/asf/velocity/engine/trunk velocity-master $ cd velocity-master $ mvn However, almost all the velocity-core test cases fail, which does not inspire confidence. I must admit that I stopped doing anything on Velocity/Tools after trunk went to using Maven. I can't figure out how to build it in Eclipse, so it's currently dead to me :( Granted, that's my own failure, but given that Velocity 2.0 developed seemed to have stalled long ago, it seemed like sticking with Velocity 1.7 wasn't a big problem. -chris Chris, Kind of off topic but ya I am no Maven fan. Dependency hell does exist, but I have never thought maven was the answer. Give me a plain old ant script any day. Does ASF require its projects to use it? -Jacob - 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
On 05/28/2015 09:44 AM, Mike Kienenberger wrote: On Thu, May 28, 2015 at 9:13 AM, Jacob Champlin jac...@rentec.com wrote: So building 2.0 has not gone well. There are no valid instructions online, eventually I figured out: $ svn checkout http://svn.apache.org/repos/asf/velocity/engine/trunk velocity-master $ cd velocity-master $ mvn However, almost all the velocity-core test cases fail, which does not inspire confidence. So now we are left with a choice. Wade knee deep in trying to clean all this up, in which I wouldn't do half the stuff Velocity does... 1) I would drop maven 2) I would go to 1 single distributable jar So basically fork velocity or go to change 10 years of code to Freemarker. Fun. You are not alone. I had the same concerns in April of 2014, and I also have 10 years of very complicated templates to deal with. Worse, it's also not possible to build later Velocity 1.x versions, such as 1.6, either. Especially the grammar, wherein lies a serious compatibility issue with 1.3.1 versions. It was frustrating enough that I gave up due to a personal lack of time and feedback from previous developers on how things worked. For now, I continue to press on with Velocity 1.3.1. I think the only thing that will prevent Velocity from going to the attic is for some of us to jump in and possibly revert some of the design decisions that prevent ongoing development. Funny thing is 10 years ago, I had the choice between Freemarker and Velocity. I went with Velocity because it was an Apache backed project, and I assumed it had more developers maintaining it. So it was software from an established open source house, vs some guys pet project. So I agree that some of us should jump in and try to save this. However, this is not what I should be working on right now. I am sure everyone else is in the same boat, which is how it got to be this way. - 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
On 05/28/2015 10:02 AM, Antonio Petrelli wrote: 2015-05-28 15:57 GMT+02:00 Jacob Champlin jac...@rentec.com: On 05/28/2015 09:44 AM, Mike Kienenberger wrote: On Thu, May 28, 2015 at 9:13 AM, Jacob Champlin jac...@rentec.com wrote: So building 2.0 has not gone well. There are no valid instructions online, eventually I figured out: $ svn checkout http://svn.apache.org/repos/asf/velocity/engine/trunk velocity-master $ cd velocity-master $ mvn However, almost all the velocity-core test cases fail, which does not inspire confidence. So now we are left with a choice. Wade knee deep in trying to clean all this up, in which I wouldn't do half the stuff Velocity does... 1) I would drop maven 2) I would go to 1 single distributable jar So basically fork velocity or go to change 10 years of code to Freemarker. Fun. You are not alone. I had the same concerns in April of 2014, and I also have 10 years of very complicated templates to deal with. Worse, it's also not possible to build later Velocity 1.x versions, such as 1.6, either. Especially the grammar, wherein lies a serious compatibility issue with 1.3.1 versions. It was frustrating enough that I gave up due to a personal lack of time and feedback from previous developers on how things worked. For now, I continue to press on with Velocity 1.3.1. I think the only thing that will prevent Velocity from going to the attic is for some of us to jump in and possibly revert some of the design decisions that prevent ongoing development. Funny thing is 10 years ago, I had the choice between Freemarker and Velocity. I went with Velocity because it was an Apache backed project, and I assumed it had more developers maintaining it. So it was software from an established open source house, vs some guys pet project. So I agree that some of us should jump in and try to save this. However, this is not what I should be working on right now. I am sure everyone else is in the same boat, which is how it got to be this way. Please don't complain, but maintain. You can fork it in Github, participate with patches, you can even publish your fork (changing its name). I was working for Velocity some years ago, remember that most of us are not paid by anyone to do this work, we are all volunteers. Apache projects are not made by professionals, although someone invests money on them, but it's not always this way. Antonio I agree, that is what open source is all about. Just easier said than done. -Jacob - 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
On 05/28/2015 10:48 AM, Mike Kienenberger wrote: On Thu, May 28, 2015 at 10:42 AM, Antonio Petrelli But when repository branches do not build from source, releases do not build from source, and no one seems to be around to suggest how it's supposed to work, the Velocity development team destroys the ability to attract and maintain new community members, which can only lead to the project's slow death and migration to the Attic. And probably it is the best, but saddest, thing to do. If I agreed with that, I wouldn't be part of this conversation. People are still willing to contribute. I have enough of a vested interest in Velocity that I will eventually make progress on this issue. :) But now is the time to start enabling contributors to eventually become committers and then PMC members while there are still interested and willing contributors in the community. 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. - 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
On 05/28/2015 10:47 AM, Antonio Petrelli wrote: 2015-05-28 15:57 GMT+02:00 Jacob Champlin jac...@rentec.com: Funny thing is 10 years ago, I had the choice between Freemarker and Velocity. I went with Velocity because it was an Apache backed project, and I assumed it had more developers maintaining it. So it was software from an established open source house, vs some guys pet project. So I agree that some of us should jump in and try to save this. However, this is not what I should be working on right now. I am sure everyone else is in the same boat, which is how it got to be this way. One last thing, Jacob, did you consider Mustache? https://mustache.github.io/ Antonio I have not, syntax seems more of a jump from Velocity than from FreeMarker. Will take a better look. -Jacob - 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
On 05/28/2015 11: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. So is it possible to create a 1.8 branch from 1.7 in the ASF world? I would be happy to contribute our changes to that. However, my fear is this project needs more than another branch and some code changes. There would be a lot of documentation work that frankly we are not likely to put effort into that. I also think it may need to give up the 5 year 2.0 dreams. -Jacob - 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
