You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Geoff Howard <ge...@leverageweb.com> on 2003/02/22 05:47:21 UTC
New Build Report
The build (build.bat webapp successful right out of the box with no
properties tweaks now) created folders with names that I assume were meant
to be expanded by ant - for example I have a folder named _literally_
D:\cvs\xml-cocoon2\${build.scratchpad.src}
I have the same for:
${build.scratchpad.dest}
${build.deprecated.src}
${build.deprecated.dest}
I also get the error reported earlier - Not allowed to define mixed content
in the element cocoon at
file:/D:/cvs/xml-cocoon2/build/cocoon-2.1-dev/webapp/WEB-INF/cocoon.xconf:3:
23
I looked over cocoon.xconf and didn't see any problem.
Finally, I tried build eclipse-project and got:
BUILD FAILED
file:///D:/cvs/xml-cocoon2/build.xml:925: Warning: Could not find file
D:\cvs\xm
l-cocoon2\${resource}\dev\eclipse\classpath-tmpl.xml to copy.
Total time: 7 seconds
which appears related to the first problem I mentioned above.
I need to get to bed, but I'll look into things tomorrow - very excited to
dig into the new build file.
Environment: JDK 1.4, Win2k, CVS Checkout about 10pm EST (GMT -05:00)
Thanks for the hard work on this, Stefano -
Geoff Howard
Re: New Build Report
Posted by Leo Simons <le...@apache.org>.
Stefano Mazzocchi wrote:
>> ant distclean; ant webapp
>
> Ah, didn't know that. I've just fixed it. Try again.
it woiks!
> Yes, help will be great, but only after the build is not shaky.
k. You got my e-mail :D
PS: ulterior motive is wanting to push continous integration to the next
level and see if I can get "the latest cvs of everything" genning the
avalon website, as a proof-of-apache-wide-backwards-compatibility-watching.
>> 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?
>
> What do you mean?
gump being a continous integration tool, a <project/> is its basic
"unit". My (limited) experience with continuous integration shows it is
beneficial to have relatively small chunks of code as a unit, ie it's
beneficial to split the 1.2mb cocoon jar into ten units or so as far as
integration is concerned. That way, it is way easier to isolate where a
build breaks.
In fact, gump is also useful in finding (automatically preventing)
circular deps. Like we had with avalon last week where altrmi depended
on some part of cornerstone, which depended on utility code in
avalon-excalibur, which depended on other utility code, which depended
on altrmi.
In tools like maven the dependency management is on a unit-is-jar basis.
>> 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?
>
> Unfortunately, all of it.
hmm. There is no "core" in the cocoon core?
from a quick glance at the code, it seems like for example
org.apache.cocoon.i18n could be seperated out into an independent
xml-cocoon-i18n target that depends only on avalon-framework and xpath.
I would expect similar things to be true for o.a.c.util, and for stuff
which looks like optional "add-ons", like
o.a.c.language.programming.javascript.
Looking at things the other way around, I would expect that "<depend
project="maybeupload"/>" refers to only a small part of cocoon, and that
"<depend project="junit"/>" is isolated into a seperate tree alltogether.
I guess I don't have to preach SoC around here -- It's beneficial to
have your SoC applied to GUMP, too. That way, 95% of GUMP can build even
when (for example) "deli" fails to build.
There's hundreds of examples I can give this way. Simply put,
o.a.c.generation doesn't depend on excalibur-logger, nor does
o.a.c.serializer, so you should tell gump that.
that's what I mean, I guess :D
cheers,
- Leo
Re: New Build Report
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> 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
Ah, didn't know that. I've just fixed it. Try again.
> 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.
Yes, I'm planning to do that.
> 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....
Yes, help will be great, but only after the build is not shaky. Let's
not put too many irons in the fire.
> #############################################################
>
> 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?
What do you mean?
> 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?
Unfortunately, all of it.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: HELP?: Trying to integrate portal-fw sample into webapp build product
Posted by Bill Barnhill <gw...@yahoo.com>.
>
> I'll see what I can do in the next few days.
>
> --
> Stefano Mazzocchi
> <st...@apache.org>
No rush, I've got it working by integrating parts
manually after build right now and can switch to an
integrated build whenever you're ready.
Thanks,
Bill
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Re: HELP?: Trying to integrate portal-fw sample into webapp build
product
Posted by Stefano Mazzocchi <st...@apache.org>.
Bill Barnhill wrote:
> I do have one problem though. I am currently working
> on setting up a web application based on the Cocoon
> portal-fw sample app and haven't been able to have
> that sample integrated with webapp build product as
> part of the build process.
the samples and the block samples are not yet included in the build
because I want to figure out a clean way of doing it.
the problem is that samples are not block-oriented, but
'impression-oriented', so they include features from all blocks and
refactoring them is a real PITA!!!
I'll see what I can do in the next few days.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
HELP?: Trying to integrate portal-fw sample into webapp build product
Posted by Bill Barnhill <gw...@yahoo.com>.
I also was able to build out of the box.
I want to say wow, I don't know how you got it to this
point so quickly.
I do have one problem though. I am currently working
on setting up a web application based on the Cocoon
portal-fw sample app and haven't been able to have
that sample integrated with webapp build product as
part of the build process.
I can get the app to work by manually copying the
samples files from within the portal-fw dir to the
installed cocoon webapp, but it's auto mounted not
integrated in with the main site map. This might not
make a difference, I don't know enough about Cocoon
yet to know the full implications.
I could get it integrated myself by modifying the
build file, sut it seems like there's probably a way
to do it without customizing the build further. I
tried setting exclude samples to false, but that
didn't seem to have any effect.
I will continue doing it manually(or with my own ant
file) unless someone can tell me the proper settings
for local.build.properties, or local.block.properties.
Thanks in advance,
Bill Barnhill
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Re: New Build Report
Posted by Leo Simons <le...@apache.org>.
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
RE: New Build Report
Posted by Geoff Howard <co...@leverageweb.com>.
Yes, the top two are fixed. And, if you haven't spotted it yet, I
sent a patch in to bugzilla for the eclipe-project target - it
was just a few typos.
Thanks,
Geoff
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Sunday, February 23, 2003 5:23 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: New Build Report
>
>
> Geoff Howard wrote:
> > The build (build.bat webapp successful right out of the box with no
> > properties tweaks now) created folders with names that I assume
> were meant
> > to be expanded by ant - for example I have a folder named _literally_
> > D:\cvs\xml-cocoon2\${build.scratchpad.src}
> >
> > I have the same for:
> > ${build.scratchpad.dest}
> > ${build.deprecated.src}
> > ${build.deprecated.dest}
>
> should be fixed now (I deleted them and committed the deleted version by
> mistake)
>
> > I also get the error reported earlier - Not allowed to define
> mixed content
> > in the element cocoon at
> >
> file:/D:/cvs/xml-cocoon2/build/cocoon-2.1-dev/webapp/WEB-INF/cocoo
> n.xconf:3:
> > 23
> >
> > I looked over cocoon.xconf and didn't see any problem.
>
> fixed as well. it was a spurious '-->' leftover that closed the comment
> before I expected and my text editor didn't syntax highlight it
> correctly and strangely enough the parser didn't complain about the
> other --> that was left in the text, very strange.
>
> > Finally, I tried build eclipse-project and got:
> >
> > BUILD FAILED
> > file:///D:/cvs/xml-cocoon2/build.xml:925: Warning: Could not find file
> > D:\cvs\xm
> > l-cocoon2\${resource}\dev\eclipse\classpath-tmpl.xml to copy.
> >
> > Total time: 7 seconds
> >
> > which appears related to the first problem I mentioned above.
>
> will look into this
>
> --
> Stefano Mazzocchi <st...@apache.org>
> Pluralitas non est ponenda sine necessitate [William of Ockham]
> --------------------------------------------------------------------
>
>
>
>
Re: New Build Report
Posted by Stefano Mazzocchi <st...@apache.org>.
Geoff Howard wrote:
> The build (build.bat webapp successful right out of the box with no
> properties tweaks now) created folders with names that I assume were meant
> to be expanded by ant - for example I have a folder named _literally_
> D:\cvs\xml-cocoon2\${build.scratchpad.src}
>
> I have the same for:
> ${build.scratchpad.dest}
> ${build.deprecated.src}
> ${build.deprecated.dest}
should be fixed now (I deleted them and committed the deleted version by
mistake)
> I also get the error reported earlier - Not allowed to define mixed content
> in the element cocoon at
> file:/D:/cvs/xml-cocoon2/build/cocoon-2.1-dev/webapp/WEB-INF/cocoon.xconf:3:
> 23
>
> I looked over cocoon.xconf and didn't see any problem.
fixed as well. it was a spurious '-->' leftover that closed the comment
before I expected and my text editor didn't syntax highlight it
correctly and strangely enough the parser didn't complain about the
other --> that was left in the text, very strange.
> Finally, I tried build eclipse-project and got:
>
> BUILD FAILED
> file:///D:/cvs/xml-cocoon2/build.xml:925: Warning: Could not find file
> D:\cvs\xm
> l-cocoon2\${resource}\dev\eclipse\classpath-tmpl.xml to copy.
>
> Total time: 7 seconds
>
> which appears related to the first problem I mentioned above.
will look into this
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------