On 12/18/12 7 :46AM, "Nicholas Kwiatkowski" <nicho...@spoon.as> wrote:
>
>On Tue, Dec 18, 2012 at 7:45 AM, Nicholas Kwiatkowski
><nicho...@spoon.as>wrote:
>
>> echo
>> == Apache Batik 1.7 build file ================================
>> echo
>>
>> echo
>> JAVA_HOME: ${env.JAVA_HOME}
>> echo
>> VM: 20.6-b01, Sun Microsystems Inc.
>> echo
>> javac.source: 1.6
>> echo
>> javac.target: 1.6
>> property
>> compile-prepare
>> mkdir
>> Created dir: E:\Apache\develop\modules\thirdparty\batik\classes
>> echo
>> debug true, optimize on, deprecation off
>> property
>> compile
>> javac
>> property
>> determine-svn-revision-svn-info
>> dirset
>> pathconvert
>> exec
>> Execute failed: java.io.IOException: Cannot run program "svn" (in
>> directory "E:\Apache\develop\modules\thirdparty\batik"): CreateProcess
>> error=2, The system cannot find the file specified
>> condition
When we forked batik I tried to make minimal changes to their build file.
One of the many things the build file does is it runs svn to determine the
current revision and tweaks a few things based on that. It looks like svn
isn't in your path. Given we are running with a static copy of batik with
known revision numbers I doubt we need to do this and maybe it is best if
I figure out what it is doing and bypass the steps that actually use svn
to do an svn info --xml on some of the batik directories. It may be that
we don't even need this information at all but I have not looked enough to
figure that out.
Carol
>> determine-svn-revision-transform
>> determine-svn-revision-from-file
>> loadfile
>> condition
>> determine-svn-revision-set
>> property
>> delete
>> determine-svn-revision
>> prepare-build
>> mkdir
>> Created dir: E:\Apache\develop\modules\thirdparty\batik\batik-1.7
>> mkdir
>> Created dir: E:\Apache\develop\modules\thirdparty\batik\batik-1.7\docs
>> mkdir
>> Created dir: E:\Apache\develop\modules\thirdparty\batik\batik-1.7\lib
>> batik-all-flex-jar
>> jar
>> Building jar: E:\Apache\develop\lib\batik-all-flex.jar
>>
>> Snippit from the log file... Again, I don't know if it was supposed to
>> fail, but I don't remember seeing that in 4.8
>>
