You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jh...@virbus.de> on 2003/09/09 13:29:02 UTC
Problems integrating Cocoon build in our build system
We have a global repository that now also stores the Cocoon 2.1.1 sources.
If one wants to use Cocoon in his project he has to build it after setting
some properties (the normal local.*.properties). The Cocoon sources in the
repository shall stay untouched of course. Therefore I set the properties
${build.root}, ${tools.tasks.dest}, ${tools.loader.dest} and almost
everything works ...
1. Javadoc: It's not possible to build the Javadocs. I get an error message
that a temporary file could not be created. I guess this is because of the
write protection of the repository, but I don't know how to solve it.
2. validating jars: The current-jars.xml can not be accessed. This is
because of the param in validate-build.xml line 52:
<param name="current-files" expression="../../${build.temp}/current-jars.xml"/>
The ${build.root} is an absolute path pointing to a directory outside the
repository, so the document($current-files) =>
document("../..//absolute/path/current-jars.xml") in the stylesheet fails. A
possible solution is to make ${build.temp} always absolute (is it possible
in any way with Ant?) or to test in the stylesheet if it's absolute.
But this would only solve one half of the problem. The stylesheet is taken
from ${tools}/src/check-jars.xsl. Only for theory, but if this is also aside
the normal processing, the ../.. would be wrong too. We could move the path
resolving completely into the stylesheet, but that's not so nice IMO.
3. compiled tools classes: In general I don't like the idea of mixing source
files and generated (or here compiled) files. Why are the tools classes
output to the tools directory and not also to the build directory??
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: Problems integrating Cocoon build in our build system
Posted by Joerg Heinicke <jh...@virbus.de>.
Now, I have not been looking at it until some minutes ago. But unfortunately
it did not help me. The first steps I have already done and the xpatching of
any files I don't really need (at least until now).
And I wonder how the validate jars works for you if not only by accident.
The hard coded "relativation" of a possible absolute path can not work in
many cases. If I deactivate javadoc and validate jars it works for me as I
want it.
Joerg
Steven Noels wrote:
> Joerg Heinicke wrote:
>
>> We have a global repository that now also stores the Cocoon 2.1.1
>> sources. If one wants to use Cocoon in his project he has to build it
>> after setting some properties (the normal local.*.properties). The
>> Cocoon sources in the repository shall stay untouched of course.
>> Therefore I set the properties ${build.root}, ${tools.tasks.dest},
>> ${tools.loader.dest} and almost everything works ...
>
>
> Joerg, off the top of my head: have you looked at
> http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject
>
> We use this approach for a large Woody-based project we are working on
> with a customer, and it works rather well.
>
> </Steven>
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: Problems integrating Cocoon build in our build system
Posted by Steven Noels <st...@outerthought.org>.
Joerg Heinicke wrote:
> We have a global repository that now also stores the Cocoon 2.1.1
> sources. If one wants to use Cocoon in his project he has to build it
> after setting some properties (the normal local.*.properties). The
> Cocoon sources in the repository shall stay untouched of course.
> Therefore I set the properties ${build.root}, ${tools.tasks.dest},
> ${tools.loader.dest} and almost everything works ...
Joerg, off the top of my head: have you looked at
http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject
We use this approach for a large Woody-based project we are working on
with a customer, and it works rather well.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org