cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: New Build Report
Date Mon, 24 Feb 2003 16:32:34 GMT
I did a clean checkout and tried some stuff

cvs -d :pserver:anoncvs@cvs.apache.org:/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



Mime
View raw message