You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Mike Kienenberger <mk...@gmail.com> on 2015/05/29 04:48:03 UTC
Successfully building 1.x branches and regenerating parser files
[Was: Re: Upgraded Commons and Velocity 2.0]
I've been working with the various branches (1.3.1, 1.4, 1.5, 1.6.x,
1.7.x) to see what's out there and to determine what might need to be
done.
I was able to get things working this time for the most part. I think
the maven build tools threw me off track last time, but this time I
started with branches that existed before maven, and by the time I
worked up to later branches, I was continuing to use the same tools.
1.3 and 1.4 won't build without some code changes -- they use enum as
a variable.
1.5, 1.6.x, and 1.7.x all build using the ant script once you adjust
the download.xml script and the build properties to new locations:
Here's the diffs for 1.7.x, but the same changes apply to all three:
Index: build.properties
===================================================================
--- build.properties (revision 1682357)
+++ build.properties (working copy)
@@ -119,8 +119,8 @@
#
# We download directly from the ibiblio maven repository
-repo.m1.url= http://www.ibiblio.org/maven
-repo.m2.url=http://www.ibiblio.org/maven2
+repo.m1.url= http://mirrors.ibiblio.org/maven2
+repo.m2.url=http://mirrors.ibiblio.org/maven2
#
# Jars to be downloaded
jar.antlr.version= 2.7.5
Index: download.xml
===================================================================
--- download.xml (revision 1682357)
+++ download.xml (working copy)
@@ -62,7 +62,7 @@
<target name="do-http-m1-download" unless="skip-download">
<setproxy proxyhost="${proxy.host}" proxyport="${proxy.port}"/>
- <get src="${repo.m1.url}/${download.groupId}/jars/${download.artifactId}-${download.version}.jar"
+ <get src="${repo.m1.url}/${download.groupId}/${download.artifactId}/${download.version}/${download.artifactId}-${download.version}.jar"
dest="${build.lib}/${download.artifactId}-${download.version}.jar"
usetimestamp="true"
verbose="false"
@@ -84,7 +84,7 @@
<target name="do-http-test-m1-download" unless="skip-download">
<setproxy proxyhost="${proxy.host}" proxyport="${proxy.port}"/>
- <get src="${repo.m1.url}/${download.groupId}/jars/${download.artifactId}-${download.version}.jar"
+ <get src="${repo.m1.url}/${download.groupId}/${download.artifactId}/${download.version}/${download.artifactId}-${download.version}.jar"
dest="${build.test.lib}/${download.artifactId}-${download.version}.jar"
usetimestamp="true"
verbose="false"
Now all I've done so far is to compile the jar -- I haven't actually
tried to use it yet.
The other thing I was able to do is get the parser modified. I
started with the original issue adding support for the parser, which
not only provided some documentation but also made sure I was using
the correct ancient version of javacc -- I see a lot of my issues in
the past were using a newer version of javacc.
https://issues.apache.org/jira/browse/VELOCITY-222
That got me started under velocity 1.5. I finally noticed the
post-processing cleanup step (basically deletes a lot of the generated
files) hidden in the source directory, and that got me to a compiled
jar with the changes. Again, I need to actually test the jar against
real templates, but the compiling step now works.
The same process worked for 1.6. 1.7 has an ant parser task that
seems to do all the work for you without any post-processing.
So...
Ant support still exists in the 1.x branches and is easily repaired.
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.
On Thu, May 28, 2015 at 10:07 PM, Sergiu Dumitriu
<se...@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-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org