Ok, you're not crazy - the build is in fact broken. Sort of. What is
broken is
an old validation target that was recently put back in (validate-jars in
src/targets/validate-build.xml). It appears that everything is actually
built correctly,
but this old target has not been correctly updated to deal with blocks (at
least on
windows). By the way, sorry for accusing you of using the old build
method - I was looking at your second attempt using -D instead of
build.properties and leapt to conclusions.
For now, your quickest bet is to go to src/targets/webapp-build.xml and find
the line:
<target name="webapp" ...
and remove the string validate-jars (and the comma) from the depends
attribute (try line 127, column 191 or so)
Unfortunately, when validate-jars was put back in, an override mechanism
wasn't added so you're stuck manually editing the build file for now.
I'll be submitting a patch to first of all add the override mechanism so
that this won't trip people up until the target is fixed.
(speaking to developers now)
Unfortunately, fixing the target looks non-trivial to me. The problem seems
to be that moving the jar libs into src/blocks broke the basic mechanism.
The filter on @JARS@ into build/temp/current-jars.xml for the blocks jars
produces entries like:
<jar>D:/eclipse/workspace/cocoon-2.1/src/blocks/batik/lib/batik-all-1.5b2.ja
r</jar>
On quick inspection, check-jars.xsl seems to be looking for literal string
matches from lib/jars.xml which will be impossible if fileset is returning
absolute paths. I tried various combinations of relative paths with no
success. Either some trick is needed to make
<xsl:if test="count($directory/jars/jar[normalize-space(text()) = $this]) =
0">
<xsl:message terminate="yes">
allow relative paths to match the absolute path (don't this this is
feasible?)
or
fileset needs to be made/configured to return relative paths (don't know ant
well enough myself)
or
some other means of checking jars needs to be devised (custom task?).
Is this broken only on windows, or does this affect *nix and mac?
Geoff
> -----Original Message-----
> From: Geoff Howard [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 25, 2003 8:12 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Cocoon-2.1-dev build fails
>
>
> The build process for 2.1dev has very recently changed and is still
> stabilizing. While
> these problems may in fact be real, it's difficult to tell because you
> appear to be following the old method for customizing the build
> (no surprise
> since the docs probably
> still instruct you to).
>
> If you haven't, read through INSTALL.txt for the new instructions. First
> try what it
> says (which is to copy build.properties to local.build.properties
> and modify
> the
> values you're interested in). But if that doesn't work, erase or
> hide that
> file
> and modify build.properties directly. For individual blocks, the
> process is
> the same
> but you'll use blocks.properties instead.
>
> If all this still fails, make sure you do build clean and try again, as
> there are
> often at this stage files moving around the repository which
> necessitates a
> clean build.
>
> As this is under active development, please do report back with your
> findings and
> if no developers seem to answer, post on the dev list or file a report in
> bugzilla. I'll try to keep track of what's happening.
>
> Geoff
>
>
> > -----Original Message-----
> > From: neil [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, March 25, 2003 5:22 PM
> > To: Cocoon-Users (E-mail)
> > Subject: Re: Cocoon-2.1-dev build fails
> >
> >
> > Re:
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=104862608911688&w=2
> >
> > I like the way the build tries to let you include just what you
> > want, but there
> > are a few little problems with it. Yesterday I checked out the
> > CVS HEAD and now
> > using jdk-1.4.1, windows2000/cygwin ...
> >
> > 1.
> > I tried excluding blocks I don't need by using
> > local.blocks.properties, but when I ran
> > cocoon (in tomcat-4.1.18) I got:
> >
> > java.lang.NoClassDefFoundError:
> EDU/oswego/cs/dl/util/concurrent/Executor
> > at org.apache.cocoon.Cocoon.contextualize(Cocoon.java:204)
> > at
> > org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet
> > .java:1304)
> > at
> > org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:505)
> > at
> > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapp
> > er.java:934)
> >
> > It seems that src/blocks/xmldb/lib/xmldb-api-20011111.jar
> > includes the package
> > EDU/oswego/cs/dl/util/concurrent which is referenced elsewhere.
> > So the xmldb block
> > cannot be excluded.
> >
> > 2.
> > I tried to exclude samples and docs:
> >
> > ./build.sh -Dinclude.webapp.libs=yes \
> > -Dexclude.webapp.samples=yes \
> > -Dexclude.webapp.documenation=yes \
> > -Dexclude.webapp.javadocs=yes war
> >
> > and got:
> >
> > Writing: C:\cocoon-2.1\build\webapp\WEB-INF\cocoon.xconf
> >
> > scratchpad-samples:
> > Copying 57 files to C:\cocoon-2.1\build\webapp\samples
> > Copied 1 empty directory to C:\cocoon-2.1\build\webapp\samples
> > Copying 87 files to C:\cocoon-2.1\build\webapp\samples
> >
> > BUILD FAILED
> > file:///C:/cocoon-2.1/build.xml:637: IOException:
> > java.io.FileNotFoundException:
> > C:\cocoon-2.1\build\webapp\samples\samples.xml (The system
> > cannot find the file
> > specified)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
