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