You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Stephen McConnell <mc...@apache.org> on 2003/02/23 04:57:27 UTC

Re: forrest problems


Jason van Zyl wrote:

>On Wed, 2003-02-19 at 11:38, Berin Loritsch wrote:
>  
>
>>Leo Simons wrote:
>>
>> > Hey Nicola,
>> >
>> > wanted to update avalon.apache.org, so got myself the latest forrest 
>>from cvs and ran 'forrest'. Got myself a StackOverflowException (see 
>>attachment) :(
>> >
>> > help?
>>
>>
>>Me Too. :(
>>
>>I need to generate the rough skin for the bindownload.ehtml so I can add
>>in the proper stuff and point people to the download directory.
>>
>>It's a pain, but we need this working ASAP.
>>
>>The LogKit 1.2 release is technically made (the archives are now in the
>>proper place), but I need to update the references to the archives.
>>    
>>
>
>If you are going to make Maven builds I again urge you to consider using
>Maven itself for the docs. Look at this:
>
>http://jakarta.apache.org/turbine/maven/reference/user-guide.html#Multi%20Project%20Builds%20and%20the%20Reactor
>
>And in there is a description and pointer to the db.apache.org set.
>Literally a few templates and 50 lines of Jelly and you get a top-level
>site you don't have to manually manage and it will generate all the
>sub-project docs too. For almost everything simple velocity templates
>will do and the most complicated it gets is:
>
>    #foreach ($reactorProject in $reactorProjects)
>    <section name="$reactorProject.name Mailing Lists">
>      #foreach ($mailingList in $reactorProject.mailingLists)
>      <p>
>        <b>$mailingList.name</b>
>        <br/>
>        <a href="mailto:$mailingList.subscribe">Subscribe</a> |
>        <a href="mailto:$mailingList.unsubscribe">Unsubscribe</a> |
>        <a href="$mailingList.archive">Archive</a>
>      </p>
>      #end
>    </section>
>    #end
>
>You can harvest anything you need from the subproject POMs.
>  
>

Jason:

I'm running into a problem when attempting to build a set of projects 
using the reactor.  The problem concerns relative versus absolution 
references used by the "maven.xdoc.jsl" property.  If the property is 
relative (i.e. "../../somewhere/site.jsl") the classic maven build works 
fine - however - if I run the reactor over the project it generates an 
error:  

   BUILD FAILED
   Unable to obtain goal [generate-site] -- null:8:30: <attainGoal> 
null:47:30:
   <attainGoal> null:485:46: <attainGoal> null:267:54: <j:include>
   could not include jelly script

It appears to be looking for the file realtive to the base directory in 
which the reactor is running.  Ok - so if you change the 
"maven.xdoc.jsl" property to "${basedir}/../../somewhere/site.jsl" then 
both the reactor and target builds fail.

Any suggestions?

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




Re: forrest problems

Posted by Stephen McConnell <mc...@apache.org>.

Jason van Zyl wrote:

>On Sun, 2003-02-23 at 00:43, Stephen McConnell wrote:
>  
>
>>An update:
>>
>>It appears that the "maven.xdoc.jsl" property must be expressed as a URI 
>>- i.e. file:/whatever.  For some reason this problem does not occur when 
>>executing the site target from the target project with a relative path 
>>but does occur when running from the target using an absolute path or 
>>running the reactor with eith absolute or relative paths.
>>    
>>
>
>Is the build somewhere I can see?
>  
>

Nope - but its really easy to replicate.
Just define the property maven.xdoc.jsl relative to ${basedir} and try 
to generate the site - it will fail because the file include is 
expecting a "file:/F:/dev/whatever" and instead it will get something 
like "F:/dev/whatever".

>We are moving away from relative paths. All paths should be specified
>with ${basedir}.
>  
>

That would be preferable.

>What are you trying to do exactly?
>  
>

Simply doing site generation with a layout that's sufficiently different 
from Maven to justify using an alternative site.jsl.

Cheers, Steve.

>  
>
>>I tracked down the problem to the following fragment in the XDOC 
>>plugin.jelly script:
>>
>>        <j:file name="${outFile}" encoding="${outputencoding}"
>>          omitXmlDeclaration="true" outputMode="xml"
>>          prettyPrint="no">
>>          <j:include uri="${stylesheet.toString()}"/>
>>        </j:file>
>>
>>The <j:include uri="${stylesheet.toString()}"/> is the source of the 
>>build failure referenced above.
>>
>>Cheers, Steve.
>>
>>    
>>
>>>Any suggestions?
>>>
>>>Cheers, Steve.
>>>
>>>      
>>>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




Re: forrest problems

Posted by Jason van Zyl <ja...@zenplex.com>.
On Sun, 2003-02-23 at 00:43, Stephen McConnell wrote:
> 
> An update:
> 
> It appears that the "maven.xdoc.jsl" property must be expressed as a URI 
> - i.e. file:/whatever.  For some reason this problem does not occur when 
> executing the site target from the target project with a relative path 
> but does occur when running from the target using an absolute path or 
> running the reactor with eith absolute or relative paths.

Is the build somewhere I can see?

We are moving away from relative paths. All paths should be specified
with ${basedir}.

What are you trying to do exactly?

> I tracked down the problem to the following fragment in the XDOC 
> plugin.jelly script:
> 
>         <j:file name="${outFile}" encoding="${outputencoding}"
>           omitXmlDeclaration="true" outputMode="xml"
>           prettyPrint="no">
>           <j:include uri="${stylesheet.toString()}"/>
>         </j:file>
> 
> The <j:include uri="${stylesheet.toString()}"/> is the source of the 
> build failure referenced above.
> 
> Cheers, Steve.
> 
> >
> > Any suggestions?
> >
> > Cheers, Steve.
> >
-- 
jvz.

Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


Re: forrest problems

Posted by Stephen McConnell <mc...@apache.org>.

Stephen McConnell wrote:

>
>
> Jason van Zyl wrote:
>
>> On Wed, 2003-02-19 at 11:38, Berin Loritsch wrote:
>>  
>>
>>> Leo Simons wrote:
>>>
>>> > Hey Nicola,
>>> >
>>> > wanted to update avalon.apache.org, so got myself the latest 
>>> forrest from cvs and ran 'forrest'. Got myself a 
>>> StackOverflowException (see attachment) :(
>>> >
>>> > help?
>>>
>>>
>>> Me Too. :(
>>>
>>> I need to generate the rough skin for the bindownload.ehtml so I can 
>>> add
>>> in the proper stuff and point people to the download directory.
>>>
>>> It's a pain, but we need this working ASAP.
>>>
>>> The LogKit 1.2 release is technically made (the archives are now in the
>>> proper place), but I need to update the references to the archives.
>>>   
>>
>>
>> If you are going to make Maven builds I again urge you to consider using
>> Maven itself for the docs. Look at this:
>>
>> http://jakarta.apache.org/turbine/maven/reference/user-guide.html#Multi%20Project%20Builds%20and%20the%20Reactor 
>>
>>
>> And in there is a description and pointer to the db.apache.org set.
>> Literally a few templates and 50 lines of Jelly and you get a top-level
>> site you don't have to manually manage and it will generate all the
>> sub-project docs too. For almost everything simple velocity templates
>> will do and the most complicated it gets is:
>>
>>    #foreach ($reactorProject in $reactorProjects)
>>    <section name="$reactorProject.name Mailing Lists">
>>      #foreach ($mailingList in $reactorProject.mailingLists)
>>      <p>
>>        <b>$mailingList.name</b>
>>        <br/>
>>        <a href="mailto:$mailingList.subscribe">Subscribe</a> |
>>        <a href="mailto:$mailingList.unsubscribe">Unsubscribe</a> |
>>        <a href="$mailingList.archive">Archive</a>
>>      </p>
>>      #end
>>    </section>
>>    #end
>>
>> You can harvest anything you need from the subproject POMs.
>>  
>>
>
> Jason:
>
> I'm running into a problem when attempting to build a set of projects 
> using the reactor.  The problem concerns relative versus absolution 
> references used by the "maven.xdoc.jsl" property.  If the property is 
> relative (i.e. "../../somewhere/site.jsl") the classic maven build 
> works fine - however - if I run the reactor over the project it 
> generates an error: 
>   BUILD FAILED
>   Unable to obtain goal [generate-site] -- null:8:30: <attainGoal> 
> null:47:30:
>   <attainGoal> null:485:46: <attainGoal> null:267:54: <j:include>
>   could not include jelly script
>
> It appears to be looking for the file realtive to the base directory 
> in which the reactor is running.  Ok - so if you change the 
> "maven.xdoc.jsl" property to "${basedir}/../../somewhere/site.jsl" 
> then both the reactor and target builds fail.


An update:

It appears that the "maven.xdoc.jsl" property must be expressed as a URI 
- i.e. file:/whatever.  For some reason this problem does not occur when 
executing the site target from the target project with a relative path 
but does occur when running from the target using an absolute path or 
running the reactor with eith absolute or relative paths.

I tracked down the problem to the following fragment in the XDOC 
plugin.jelly script:

        <j:file name="${outFile}" encoding="${outputencoding}"
          omitXmlDeclaration="true" outputMode="xml"
          prettyPrint="no">
          <j:include uri="${stylesheet.toString()}"/>
        </j:file>

The <j:include uri="${stylesheet.toString()}"/> is the source of the 
build failure referenced above.

Cheers, Steve.

>
> Any suggestions?
>
> Cheers, Steve.
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: forrest problems

Posted by Stephen McConnell <mc...@apache.org>.

Stephen McConnell wrote:

>
>
> Jason van Zyl wrote:
>
>> On Wed, 2003-02-19 at 11:38, Berin Loritsch wrote:
>>  
>>
>>> Leo Simons wrote:
>>>
>>> > Hey Nicola,
>>> >
>>> > wanted to update avalon.apache.org, so got myself the latest 
>>> forrest from cvs and ran 'forrest'. Got myself a 
>>> StackOverflowException (see attachment) :(
>>> >
>>> > help?
>>>
>>>
>>> Me Too. :(
>>>
>>> I need to generate the rough skin for the bindownload.ehtml so I can 
>>> add
>>> in the proper stuff and point people to the download directory.
>>>
>>> It's a pain, but we need this working ASAP.
>>>
>>> The LogKit 1.2 release is technically made (the archives are now in the
>>> proper place), but I need to update the references to the archives.
>>>   
>>
>>
>> If you are going to make Maven builds I again urge you to consider using
>> Maven itself for the docs. Look at this:
>>
>> http://jakarta.apache.org/turbine/maven/reference/user-guide.html#Multi%20Project%20Builds%20and%20the%20Reactor 
>>
>>
>> And in there is a description and pointer to the db.apache.org set.
>> Literally a few templates and 50 lines of Jelly and you get a top-level
>> site you don't have to manually manage and it will generate all the
>> sub-project docs too. For almost everything simple velocity templates
>> will do and the most complicated it gets is:
>>
>>    #foreach ($reactorProject in $reactorProjects)
>>    <section name="$reactorProject.name Mailing Lists">
>>      #foreach ($mailingList in $reactorProject.mailingLists)
>>      <p>
>>        <b>$mailingList.name</b>
>>        <br/>
>>        <a href="mailto:$mailingList.subscribe">Subscribe</a> |
>>        <a href="mailto:$mailingList.unsubscribe">Unsubscribe</a> |
>>        <a href="$mailingList.archive">Archive</a>
>>      </p>
>>      #end
>>    </section>
>>    #end
>>
>> You can harvest anything you need from the subproject POMs.
>>  
>>
>
> Jason:
>
> I'm running into a problem when attempting to build a set of projects 
> using the reactor.  The problem concerns relative versus absolution 
> references used by the "maven.xdoc.jsl" property.  If the property is 
> relative (i.e. "../../somewhere/site.jsl") the classic maven build 
> works fine - however - if I run the reactor over the project it 
> generates an error: 
>   BUILD FAILED
>   Unable to obtain goal [generate-site] -- null:8:30: <attainGoal> 
> null:47:30:
>   <attainGoal> null:485:46: <attainGoal> null:267:54: <j:include>
>   could not include jelly script
>
> It appears to be looking for the file realtive to the base directory 
> in which the reactor is running.  Ok - so if you change the 
> "maven.xdoc.jsl" property to "${basedir}/../../somewhere/site.jsl" 
> then both the reactor and target builds fail.


An update:

It appears that the "maven.xdoc.jsl" property must be expressed as a URI 
- i.e. file:/whatever.  For some reason this problem does not occur when 
executing the site target from the target project with a relative path 
but does occur when running from the target using an absolute path or 
running the reactor with eith absolute or relative paths.

I tracked down the problem to the following fragment in the XDOC 
plugin.jelly script:

        <j:file name="${outFile}" encoding="${outputencoding}"
          omitXmlDeclaration="true" outputMode="xml"
          prettyPrint="no">
          <j:include uri="${stylesheet.toString()}"/>
        </j:file>

The <j:include uri="${stylesheet.toString()}"/> is the source of the 
build failure referenced above.

Cheers, Steve.

>
> Any suggestions?
>
> Cheers, Steve.
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net