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