cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co xml-cocoon2 cd xml-cocoon2 ./build.sh
# lots-of-output, and in the end:
BUILD SUCCESSFUL Total time: 1 minute 43 seconds
# first time I ever got cocoon to build out of the box!
#############################################################
# using ant 1.5.1 directly won't work though:
~/.bash_profile # reset ANT_HOME 'n stuff ant distclean; ant webapp
# get's quite far, then:
package-deprecated:
[jar] Building jar: D:\home\lsimons\xml-cocoon2\build\cocoon-2.1-dev\cocoon-deprecated.jar
package:
compile:
blocks:
[mkdir] Created dir: D:\home\lsimons\xml-cocoon2\build\cocoon-2.1-dev\blocks
[xslt] Processing D:\home\lsimons\xml-cocoon2\project-info.xml to D:\home\lsimons\xml-cocoon2\build\
cocoon-2.1-dev\temp\blocks-build.xml
[xslt] Loading stylesheet D:\home\lsimons\xml-cocoon2\tools\src\blocks-build.xsl
BUILD FAILED
file:D:/home/lsimons/xml-cocoon2/build/cocoon-2.1-dev/temp/blocks-build.xml:2: The default attribute of p
roject is required
Total time: 34 seconds
#############################################################
I dunno what your medium-term plans are with regard to setting up maven or centipede or something like that, but if you're sticking with ant for some time to come, it would still really make life easier if most of the libraries you keep in cvs could go (like two copies of xalan :D), totalling about 25mb of the about 46mb of xml-cocoon2.
We recently did this for avalon-framework and avalon-logkit (http://cvs.apache.org/viewcvs.cgi/avalon/check-targets.ent) so I could help out if needed....
#############################################################
on a related note, now that I finally was able to build cocoon myself, I'll look at getting it running in gump again. On first glance the gump xml-cocoon2 project looks like it is a bit big to serve as "unit of integration". Have you tried splitting that up yet?
The way build.xml is laid out makes it rather difficult for me (not a cocoon user except in the form of forrest) to figure out where to start, considering
<!-- Set classpath -->
<path id="classpath">
<fileset dir="${lib}">
<include name="*.jar"/>
</fileset>
<fileset dir="${lib.endorsed}">
<include name="*.jar"/>
</fileset>
<fileset dir="${lib.core}">
<include name="*.jar"/>
</fileset>
<fileset dir="${lib.core}/jvm${target.vm}">
<include name="*.jar"/>
</fileset>
<fileset dir="${lib.optional}">
<include name="*.jar"/>
</fileset>
<path location="${build.mocks}"/>
<path location="${build.dest}"/>
</path> <!-- compile core source files -->
<javac destdir="${build.dest}"
debug="${compiler.debug}"
optimize="${compiler.optimize}"
deprecation="${compiler.deprecation}"
target="${target.vm}"
nowarn="${compiler.nowarn}"
compiler="${compiler}"
classpathref="classpath">
<src>
<!-- [FIXME] THE DEPENDENCY ON DEPRECATED SHOULD GO AWAY!!!! -->
<path location="${deprecated.src}"/>
<path location="${build.src}"/>
<path location="${java}"/>
</src>
</javac>results in a massive classpath by the time the "core" is compiled. Does anyone know how much of the stuff put into the classpath is needed by the core?
cheers,
- Leo
