You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Marc Portier <mp...@outerthought.org> on 2002/08/23 13:35:32 UTC
[wip][update] build refactoring - first use possible
Hi all,
been fleshing out more in the new build system
there is something working now:
./build.sh -buildfile build.build.xml clean docs
will now do the equivalent of what the (old) build.xml does
Except:
- it will do it based on the better separation of concerns we
have been discussing (could be a bit slower, please feedback)
- it will no longer require the 'clean' cause this nukes the
cocoon cache internally before re-generation
However:
when using this new way of working I get loads of
o.a.fop.fo.expr.PropertyEcxception
anyone that has a clue?
Question:
we still have the not-liked filtering in our build
I saw the maven guys used it for configuring more then the skin
Any opinions on being able to configure more?
(By the way the siteplan idea should be the way to get rid of
this filtering as well IMHO.)
Upcoming:
- webapp target (any other targets from the old build people
would like to keep?)
- the seeding stuff
- redo of bot to fit-in with this new way --> and adding the bot
target again
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org mpo@apache.org
Re: [wip][update] build refactoring - first use possible
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Marc Portier wrote:
> Nicola,
>
> tested. this works fine.
> recompiled (using jdk 1.3) the cocoon.jar and modified the
> forrest.build.xml to exploit the mentioned features.
> Note: don't forget to ./build.sh clean to get rid of the old
> cocoon*.jar in ./build/ subdirs.
>
> One remark though:
> - brokenlink.txt would be even more meaningfull as a
> site-debugging tool if it would also list the xml file (at least
> the current URI of html) that was holding the broken link :-(
Yup, this is next on my list :-)
I want to make it use the same DTD as the LinkWhateveritscalledI
dontrememberGenerator, so we can reuse stylesheets.
Ok, so now Cocoon and Forrest handle broken links gracefully!
YAY! :-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [wip][update] build refactoring - first use possible
Posted by Marc Portier <mp...@outerthought.org>.
Nicola,
tested. this works fine.
recompiled (using jdk 1.3) the cocoon.jar and modified the
forrest.build.xml to exploit the mentioned features.
Note: don't forget to ./build.sh clean to get rid of the old
cocoon*.jar in ./build/ subdirs.
One remark though:
- brokenlink.txt would be even more meaningfull as a
site-debugging tool if it would also list the xml file (at least
the current URI of html) that was holding the broken link :-(
-marc=
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: zaterdag 24 augustus 2002 19:42
> To: forrest-dev@xml.apache.org
> Subject: Re: [wip][update] build refactoring - first
> use possible
>
>
>
> Nicola Ken Barozzi wrote:
> >
> >
> > Marc Portier wrote:
> > ... (btw we should asap stop to tolerate
> >
> >> [broken-link]s in our output, when nicola comes to write the
> >> <forrest> task to replace the cocoon CLI, then
> generating a clear
> >> output-log of broken link to-froms should be a definate
> >> requirement from my part
> >
> >
> > There is no need for a forrest tag for it... I have
> just seen where it
> > happens in code and will patch it as soon as I get
> back home this evening.
>
> Ok, so while I was at it I also did other tweaks and
> now I've committed
> the changes :-)
>
> Which means that the -V (verbose) option on the
> commandline now shows
> more compact info and best of all Cocoon doesn't choke
> anymore on broken
> links!!! :-D
>
> Instead it creates an error page @ the same location
> where the broken
> linked page should be.
>
> Next step is to make it not regen pages that have not changed.
>
> If someone wants to commit it in Forrest, it's in the
> C1 branch.
> Please also add the other options that are specified
> in the Cocoon
> build.xml file (-V and the broken links result page).
>
Re: [wip][update] build refactoring - first use possible
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Marc Portier wrote:
> ... (btw we should asap stop to tolerate
>
>> [broken-link]s in our output, when nicola comes to write the
>> <forrest> task to replace the cocoon CLI, then generating a clear
>> output-log of broken link to-froms should be a definate
>> requirement from my part
>
>
> There is no need for a forrest tag for it... I have just seen where it
> happens in code and will patch it as soon as I get back home this evening.
Ok, so while I was at it I also did other tweaks and now I've committed
the changes :-)
Which means that the -V (verbose) option on the commandline now shows
more compact info and best of all Cocoon doesn't choke anymore on broken
links!!! :-D
Instead it creates an error page @ the same location where the broken
linked page should be.
Next step is to make it not regen pages that have not changed.
If someone wants to commit it in Forrest, it's in the C1 branch.
Please also add the other options that are specified in the Cocoon
build.xml file (-V and the broken links result page).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [wip][update] build refactoring - first use possible
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Marc Portier wrote:
... (btw we should asap stop to tolerate
> [broken-link]s in our output, when nicola comes to write the
> <forrest> task to replace the cocoon CLI, then generating a clear
> output-log of broken link to-froms should be a definate
> requirement from my part
There is no need for a forrest tag for it... I have just seen where it
happens in code and will patch it as soon as I get back home this evening.
Gotta go now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [wip][update] build refactoring - first use possible
Posted by Marc Portier <mp...@outerthought.org>.
> > there is something working now:
> > ./build.sh -buildfile build.build.xml clean docs
> > will now do the equivalent of what the (old) build.xml does
>
> I'm just about to head off to bed, but :
>
> fresh-site-zip:
>
> BUILD FAILED
> /old/home/jeff/homeoverflow/apache/xml/xml-forrest/buil
> d.build.xml:201:
> /old/home/jeff/homeoverflow/apache/xml/xml-forrest/src/
> resources/fresh-site not found.
>
> Perhaps you didn't check in that directory?
>
indeed, excuse me
>
> > Question:
> > we still have the not-liked filtering in our build
> > I saw the maven guys used it for configuring more
> then the skin
> > Any opinions on being able to configure more?
>
> Yes please.. I need *lots* of configurability. Eg,
> currently the sitemap
> hardcodes relative paths, like 'content/xdocs' and
> 'resources/images'. I'd
> really like those to be configurable, so that I can
> override them to the Maven
> defaults (by default, /xdocs and /xdocs/images respectively).
>
> Actually, the cleanest way to handle dynamic,
> property-driven Maven situation
> is probably to create a sitemap on the fly, when the
> plugin is first invoked.
>
you must be kidding :-)
this and more is in my siteplan idea (earlier post)
(with slight modification: not on first invocation only, but on
every invocation that changed the plan)
all there is to tweak and tune (and hopefully extend in future)
about forrest...
I'ld like all those config-details to be grasped in a single
siteplan.xml
from this file we could generate
- the sitemap (with matchers that follow the file-extension-trail
pattern)
- the catalog (so people could add new types)
- the ant-version of the catalog (so we can use the xmlvalidate
tags on content of our DTDs)
- a config file for some all-absolute-links-tranformer that can
translate aliases in cross refs and make all absolute links
relative
- parts of ant tasks, to copy-in the content of different parts.
that could become the level where the bot jumps in as well.
like that forrest becomes a bit of an ant for building sites
IMHO we need the siteplan-overview to be able to get links and
generation right
if we rather have ant throw our site together, then there is no
real reason to use something powerfull like the cocoon sitemap to
generate a concistent site (btw we should asap stop to tolerate
[broken-link]s in our output, when nicola comes to write the
<forrest> task to replace the cocoon CLI, then generating a clear
output-log of broken link to-froms should be a definate
requirement from my part)
-marc=
>
> --Jeff
>
> > regards,
> > -marc=
>
Re: [wip][update] build refactoring - first use possible
Posted by Jeff Turner <je...@apache.org>.
On Fri, Aug 23, 2002 at 01:35:32PM +0200, Marc Portier wrote:
> Hi all,
>
> been fleshing out more in the new build system
Cool :)
> there is something working now:
> ./build.sh -buildfile build.build.xml clean docs
> will now do the equivalent of what the (old) build.xml does
I'm just about to head off to bed, but :
fresh-site-zip:
BUILD FAILED
/old/home/jeff/homeoverflow/apache/xml/xml-forrest/build.build.xml:201: /old/home/jeff/homeoverflow/apache/xml/xml-forrest/src/resources/fresh-site not found.
Perhaps you didn't check in that directory?
> Except:
> - it will do it based on the better separation of concerns we
> have been discussing (could be a bit slower, please feedback)
> - it will no longer require the 'clean' cause this nukes the
> cocoon cache internally before re-generation
>
>
> However:
> when using this new way of working I get loads of
> o.a.fop.fo.expr.PropertyEcxception
> anyone that has a clue?
I think it means an attribute value is bad. I got them in another project when
I had:
<fo:table-column column-width="something_bad"/>
No idea otherwise :/
> Question:
> we still have the not-liked filtering in our build
> I saw the maven guys used it for configuring more then the skin
> Any opinions on being able to configure more?
Yes please.. I need *lots* of configurability. Eg, currently the sitemap
hardcodes relative paths, like 'content/xdocs' and 'resources/images'. I'd
really like those to be configurable, so that I can override them to the Maven
defaults (by default, /xdocs and /xdocs/images respectively).
Actually, the cleanest way to handle dynamic, property-driven Maven situation
is probably to create a sitemap on the fly, when the plugin is first invoked.
--Jeff
> regards,
> -marc=