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 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"
org.apache.maven.surefire.testset.TestSetFailedException: 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"
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"
       at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
       at java.lang.Class.newInstance(Class.java:436)
       at
org.apache.maven.surefire.testset.PojoTestSet.<init>(PojoTestSet.java:55)
       at

org.apache.maven.surefire.junit.JUnitDirectoryTestSuite.createTestSet(JUnitDirectoryTestSuite.java:64)
       at

org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96)
       at

org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209)
       at org.apache.maven.surefire.Surefire.run(Surefire.java:156)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
       at

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:497)
       at

org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
       at

org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)

I have absolutely no idea how to turn off things like unit tests in
Maven to see if I can even get an artifact.

If I run "mvn compile" it tells me there's nothing do to, but my working
copy of svn has no changes. Nothing to do, but nothing done, seems like.

-chris



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

Reply via email to