You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gianugo Rabellino <g....@bibop.it> on 2001/09/27 12:54:01 UTC
Cocoon Ant task
Ciao,
I'm almost finished with the Cocoon ant task. Basically it's quite
a hack, being mostly a sligtly modified version of Cocoon Main.java,
but it works quite well (I tried it with the Avalon docs changing the
java task to the new Cocoon task) and I find it pretty useful for
my needs.
I'm more than willing to donate this small software to the ASF: is
the Cocoon team interested in it? Better yet: this is meant as an
optional Ant task, so it might make sense to donate it to the Ant
team. Yet using this task means also that you need to have a
fully working Cocoon environment (with all the libraries) so it
might be a bit overweight for the standard Ant distribution and
could fit better inside Cocoon (which package?).
Please let me know: if you're interested I might send you a working
version today or tomorrow.
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Ant task
Posted by Stefano Mazzocchi <st...@apache.org>.
Gianugo Rabellino wrote:
>
> On Fri, Sep 28, 2001 at 09:43:29AM +1000, Jeff Turner wrote:
> > > <target name="cocoon">
> > > <cocoon destination="${base.dir}/docs"
> > > context="${base.dir}/documentation"
> > > workdir="${base.dir}/work"
> > > urifile="${base.dir}/documentation/root.uris"
> >
> >
> > I was wondering, would it be possible to have Ant automatically
> > determine which *.xml files are "out of date", and use that list instead
> > of hardcoded lists in *.uris files?
>
> It would be possible, but there is a problem with the whole sitemap
> concept: it's not possible, in a general way, to associate a "virtual"
> URI, such as the one matched in the sitemap to a concrete xml file
> (or resource, or whatever). The fact that a list containing "foo.html"
> and "bar.html" depends on "foo.xml" and "bar.xml" and the assumption
> that, being the source file unchanged, the resource should not be
> processed, is outside the scope of an Ant task: it should be a Cocoon
> responsability to perform these checks and decide what to do.
>
> This is how Cocoon's own caching works, but I really don't know if
> the CLI environment can use it in different runs.
I don't know if the current cache implementation does so (haven't tested
yet), but for sure this is something that only Cocoon can control since,
as Gianugo explained, we are not dealing with files anymore, but with
URI spaces that are mapped to the file system by cocoon internal
machinery.
Probably few of you noted the link-translating capabilities of the CLI:
let's make an example. Suppose you have something like
http://host/path/file1
http://host/path/file2
where the first x-links to the second.
Suppose that depending on some agent settings, they are serialized as
PDF.
The CLI is capable of:
1) perform xlink crawling.
2) perform URI -> filesystem name mangling.
3) perform internal link translation based on previous filename
mangling.
This results in two files named
file1.pdf
file2.pdf
but file1.pdf contains links that point to file2.pdf.
So the PDF snapshot of the live URI space is fully browsable on disk.
This is possible because of the xlink semantics and view capabilities of
Cocoon2: the link view of a resource returns all the xlinks that the
resource has and the link-translating view performs link translation
*before* the format is actually serialized. So, this method is general
enough on *any* binary format and we don't have to implement
link-translating behavior for every binary format we support (as some
web-site grabbers have to do).
Note that this link-translating capability is disabled for security
reason if the call comes from a servlet.
With this pretty complex machinery, it's evident that Ant cannot
understand if one of the two has changed.
So, yes, a great feature to have but it should be Cocoon's cache to
handle this, Ant cannot.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Ant task
Posted by Gianugo Rabellino <g....@bibop.it>.
On Fri, Sep 28, 2001 at 09:43:29AM +1000, Jeff Turner wrote:
> > <target name="cocoon">
> > <cocoon destination="${base.dir}/docs"
> > context="${base.dir}/documentation"
> > workdir="${base.dir}/work"
> > urifile="${base.dir}/documentation/root.uris"
>
>
> I was wondering, would it be possible to have Ant automatically
> determine which *.xml files are "out of date", and use that list instead
> of hardcoded lists in *.uris files?
It would be possible, but there is a problem with the whole sitemap
concept: it's not possible, in a general way, to associate a "virtual"
URI, such as the one matched in the sitemap to a concrete xml file
(or resource, or whatever). The fact that a list containing "foo.html"
and "bar.html" depends on "foo.xml" and "bar.xml" and the assumption
that, being the source file unchanged, the resource should not be
processed, is outside the scope of an Ant task: it should be a Cocoon
responsability to perform these checks and decide what to do.
This is how Cocoon's own caching works, but I really don't know if
the CLI environment can use it in different runs.
Anyway yes, i agree that this would be useful and worth
investigating.
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Ant task
Posted by Jeff Turner <je...@socialchange.net.au>.
On Thu, Sep 27, 2001 at 05:10:39PM +0200, Gianugo Rabellino wrote:
[snip]
> <?xml version="1.0"?>
>
> <project name="Cocoontask" default="cocoon" basedir=".">
>
> <property name="base.dir" value="../jakarta-avalon/build" />
>
> <taskdef name="cocoon"
> classname="org.apache.tools.ant.taskdefs.optional.cocoon.CocoonTask"/>
>
> <target name="cocoon">
> <cocoon destination="${base.dir}/docs"
> context="${base.dir}/documentation"
> workdir="${base.dir}/work"
> urifile="${base.dir}/documentation/root.uris"
I was wondering, would it be possible to have Ant automatically
determine which *.xml files are "out of date", and use that list instead
of hardcoded lists in *.uris files?
Then if you modify just one file, just that file gets processed.
--Jeff
> logfile="cocoon.log"
> loglevel="INFO"
> followlinks="true" />
>
> </target>
>
> </project>
[..]
> Ciao,
>
> --
> Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Ant task
Posted by Gianugo Rabellino <g....@bibop.it>.
> > I'm more than willing to donate this small software to the ASF: is
> > the Cocoon team interested in it? Better yet: this is meant as an
> > optional Ant task, so it might make sense to donate it to the Ant
> > team. Yet using this task means also that you need to have a
> > fully working Cocoon environment (with all the libraries) so it
> > might be a bit overweight for the standard Ant distribution and
> > could fit better inside Cocoon (which package?).
>
> I think we should use it for Cocoon first and see later on how Ant can make use
> of it. As Berin proposed that we should build smaller jar for parts of Cocoon
> (interfaces, core, samples, etc.) maybe we find the "smalles possible
> environment" to use it. Also, most of the needed jars are already in Ant (xerxes
> xalan) and thus only things like batik could be a huge part of it to process svg
> graphics.
Agreed. What can be a good package name for the thingy?
> > Please let me know: if you're interested I might send you a working
> > version today or tomorrow.
>
> Yes, I personally would.
Great :) Based on the "release early, release often" pattern,
here goes a first try against current Cocoon CVS. It must be
used like this (this sample is being run against Avalon docs):
<?xml version="1.0"?>
<project name="Cocoontask" default="cocoon" basedir=".">
<property name="base.dir" value="../jakarta-avalon/build" />
<taskdef name="cocoon"
classname="org.apache.tools.ant.taskdefs.optional.cocoon.CocoonTask"/>
<target name="cocoon">
<cocoon destination="${base.dir}/docs"
context="${base.dir}/documentation"
workdir="${base.dir}/work"
urifile="${base.dir}/documentation/root.uris"
logfile="cocoon.log"
loglevel="INFO"
followlinks="true" />
</target>
</project>
Basically all you have to do is change the package (suggestions
are more than welcome) if you don't want to put it inside ant
and it *should* work. It needs some further work, though, but
it should give you an idea. Comments are more than welcome.
Of course, if you find it valuable, please consider this as
a donation to the ASF.
Ciao,
--
Gianugo Rabellino
Re: Cocoon Ant task
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Gianugo Rabellino <g....@bibop.it>:
> Ciao,
>
> I'm almost finished with the Cocoon ant task. Basically it's quite
> a hack, being mostly a sligtly modified version of Cocoon Main.java,
> but it works quite well (I tried it with the Avalon docs changing the
> java task to the new Cocoon task) and I find it pretty useful for
> my needs.
Cool.
> I'm more than willing to donate this small software to the ASF: is
> the Cocoon team interested in it? Better yet: this is meant as an
> optional Ant task, so it might make sense to donate it to the Ant
> team. Yet using this task means also that you need to have a
> fully working Cocoon environment (with all the libraries) so it
> might be a bit overweight for the standard Ant distribution and
> could fit better inside Cocoon (which package?).
I think we should use it for Cocoon first and see later on how Ant can make use
of it. As Berin proposed that we should build smaller jar for parts of Cocoon
(interfaces, core, samples, etc.) maybe we find the "smalles possible
environment" to use it. Also, most of the needed jars are already in Ant (xerxes
xalan) and thus only things like batik could be a huge part of it to process svg
graphics.
> Please let me know: if you're interested I might send you a working
> version today or tomorrow.
Yes, I personally would.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org