Jean T. Anderson | 1 Apr 01:00 2005

Re: DITA plugin

Ross Gardler wrote:
<snip />
> I notice the DITA toolkit is CPL licensed. I'm pretty sure that this is 
> not ASF2 compatible (it requires derivative works to be licensed under 
> the CPL. So we can't work on this in ASF repositories. 

You're correct -- and legal-discuss <at> apache.org confirmed that.

> This is not a problem from the point of view of the plugin becuase they can be hosted anywhere. 

> I'll create a module at my Burrokeet project (which also uses Forrest ) 
> for this plugin unless there is somewhere else you would like to house 
> it. Discussion should be kept here though as it is a FOrrest plugin not 
> a Burrokeet one.

wow -- thanks! that's much appreciated!

  -jean

Ross Gardler | 1 Apr 01:06 2005
Picon

Re: [DISCUSS] feeder plugin contract in the view

Thorsten Scherler wrote:
> On Thu, 2005-03-31 at 18:36 +0100, Ross Gardler wrote:
> 
> <snip what="lots of agreed stuff"/>
> 
>>>>Lets return to your observation that "a forrest:view is comparable with 
>>>>a view on a table of a db. It is a subset of data". The key thing about 
>>>>a view in a database is that it does not contain any data, it only 
>>>>contains information about what data should be presented.
>>>>
>>>
>>>
>>>exactly. 
>>>
>>>...but you can parse params to the view to specify which sets of data
>>>you want have returned, right?
>>
>>Lets keep it simple at first - no paramaters (yet).
> 
> 
> Hmm, what about
> <forrest:contract name="feedback-dyn">
> <forrest:properties contract="feedback-dyn">
>   <forrest:property name="main">
>     <feedback to="webmaster <at> foo.com"
> href="mailto:webmaster <at> foo.com?subject=Feedback&#160;" >
>     Send DYNAMIC feedback about the website to:
>    </feedback>
>   </forrest:property>
> </forrest:properties>
(Continue reading)

Jeff Levitt | 1 Apr 02:11 2005

Re: DITA plugin

--- Ross Gardler <rgardler <at> apache.org> wrote:

> OK, I've had a look at the build files. The
> preprocessing stage is 
> actually optional. There are some things that don't
> work if you don't do 
> it (like conrefs whatever they are).
> 

Conrefs are strings pulled in from other files.  So
for example, instead of calling our product "Derby
Version 10" everywhere, we can put the version number
in a conref file, and call it whenever we want it in
the dita files.  That way we only change the version
number in one place when he have a new release.  You
might call a conref an entity depending on what tools
you use, but for DITA, we use a conref file.

I suppose we can skip that step for now.

> So, I propose that for this first instance we ignore
> the preprocessing 
> step and just focus on getting the files into a
> forrest site.
> 
> I'm done for the night now so here's where I am up
> to. I should get time 
> to look at this again in a few days time. In the
> meantime if you want to 
> have a go at getting started, I (and others) will be
(Continue reading)

David Crossley | 1 Apr 02:52 2005
Picon

Re: DITA plugin

Jean T. Anderson wrote:
> 
> So far my understanding is that 'forrest site' is an all or nothing deal 
> for all files under xdocs. For example, if we put dita source under 
> xdocs we couldn't tell forrest to exclude building those. --Or could we?

Just a note to clarify this point (though other solutions
were proposed later in these email threads) ...

Forrest (actually Cocoon) can be told to exclude certain
file patterns from processing using Cocoon's cli.xconf
configuration file:
http://forrest.apache.org/faq.html#ignoring_javadocs

--David

issues | 1 Apr 04:38 2005

[JIRA] Assigned: (FOR-391) website docs/site split

Message:

   The following issue has been re-assigned.

   Assignee: David Crossley (mailto:crossley <at> apache.org)
---------------------------------------------------------------------
View the issue:
  http://issues.cocoondev.org//browse/FOR-391

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: FOR-391
    Summary: website docs/site split
       Type: Task

     Status: Open
   Priority: Major

    Project: Forrest
 Components: 
             Documentation and website
   Fix Fors:
             0.7-dev
   Versions:
             0.7-dev

   Assignee: David Crossley
   Reporter: Dave Brondsema

    Created: Wed, 24 Nov 2004 10:51 PM
(Continue reading)

Dave Brondsema | 1 Apr 05:04 2005
Picon

Re: svn commit: r158748 - forrest/trunk/docs-author/skinconf.xml

crossley <at> apache.org wrote:
> Author: crossley
> Date: Wed Mar 23 00:21:34 2005
> New Revision: 158748
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=158748
> Log:
> Add a message to every doc to be sure people know which version it relates to.
>
> Modified:
>     forrest/trunk/docs-author/skinconf.xml
>
> Modified: forrest/trunk/docs-author/skinconf.xml
> URL: http://svn.apache.org/viewcvs/forrest/trunk/docs-author/skinconf.xml?view=diff&r1=158747&r2=158748
> ==============================================================================
> --- forrest/trunk/docs-author/skinconf.xml (original)
> +++ forrest/trunk/docs-author/skinconf.xml Wed Mar 23 00:21:34 2005
>  <at>  <at>  -111,6 +111,21  <at>  <at> 
>    <!-- Heading types can be clean|underlined|boxed  -->
>    <headings type="underlined"/>
>
> +  <!-- Optional message of the day.
> +    motd-title : This text will be added in brackets after the <html><title>
> +    motd-page : This text will be added in a panel on the face of the page,
> +    with the "motd-page-url" being the hyperlink "More".
> +    Values for the "location" attribute are:
> +      page : on the face of the page, e.g. in the spare space of the toc
> +      alt : at the bottom of the left-hand navigation panel
> +      both : both
> +    -->
(Continue reading)

Dave Brondsema | 1 Apr 05:06 2005
Picon

Re: merging separate sets of generated docs, default tabs

David Crossley wrote:
> Dave Brondsema wrote:
>
>>Ok.  What about href="/docs"?  I think because it is a 'href' it would
>>keep it from failing the build, and it would still be relative.
>
>
> That should work. I woder why we didn't think of that before.
> Maybe it was all getting confused with the separate 0.6 docs.
> Dunno. Lets try it.
>
>

Done.  I had forgotten about this.

>>Regarding the 2nd change: I removed the project-related tabs from
>>docs-author, so that the docs would be completely independent.  This
>>lets a user have a local copy of the docs with no broken links; it is
>>also like the way the httpd docs are.  Any problem with this?
>
>
> When the docs are on the website, how will we navigate back to the
> Project and Welcome information if there are no tabs.
>

The breadcrumbs and logo link back to the main site, although that may
not be obvious.  http://httpd.apache.org/docs-2.0/ only has breadcrumbs;
I think it is okay.

> --David
(Continue reading)

Jean T. Anderson | 1 Apr 05:44 2005

Re: DITA plugin

David Crossley wrote:
> Jean T. Anderson wrote:
> 
>>So far my understanding is that 'forrest site' is an all or nothing deal 
>>for all files under xdocs. For example, if we put dita source under 
>>xdocs we couldn't tell forrest to exclude building those. --Or could we?
> 
> 
> Just a note to clarify this point (though other solutions
> were proposed later in these email threads) ...
> 
> Forrest (actually Cocoon) can be told to exclude certain
> file patterns from processing using Cocoon's cli.xconf
> configuration file:
> http://forrest.apache.org/faq.html#ignoring_javadocs
> 
> --David

ok, cool. the 'forrest site' processing time dropped to 1 minute 5 seconds.

thanks!

-jean

David Crossley | 1 Apr 05:54 2005
Picon

Re: problem with docs at forrest.apache.org/docs/dev/

David Crossley wrote:
> David Crossley wrote:
> > Dave Brondsema wrote:
> > > 
> > > /docs/dev/ nested below /docs/ seems weird.  I think it would be better
> > > to host the current stable release at a url like: /docs/0.7/.  This
> > > would also permit us to keep documentation for all old releases
> > > (although we would probably want warnings on them if they are too old).
> > >
> > > 0.6 docs had to be kept at /docs/ because they didn't have a split
> > > docs/site structure so I kept it as-is.  I had been thinking we'd move
> > > to something like /docs/0.7/ for future releases, but I can't find any
> > > discussion about this in particular.
> > 
> > We probably jumped to the conclusion that we only would have
> > the current release and the current dev version.
> > 
> > I agree with this new approach. So would it be like this ...
> > 
> > Assuming that we don't want to version the top-level docs.
> 
> Is that a legitimate assumption? It would change our layout if we do.
> I don't know the answer yet either.
> 
> > f.a.o/ ... the top-level docs, from trunk/site-author 
> > f.a.o/docs/ ... is .htaccess to redirect to current release docs.
> > f.a.o/docs/0.6/ ... from the forrest_06_branch (*)
> > f.a.o/docs/0.7/ ... from the forrest_07_branch, when it is released
> > f.a.o/docs/0.8/ ... the next development, from future trunk/docs-author/

(Continue reading)

David Crossley | 1 Apr 06:06 2005
Picon

Re: svn commit: r158748 - forrest/trunk/docs-author/skinconf.xml

Dave Brondsema wrote:
> 
> <motd-page-url>/docs/≤/motd-page-url> doesn't work if these docs are
> standalone (e.g on my machine).

Yeah, sorry. I knew it would make a broken link for local docs,
but thought that it was more important to get the website happening
at this stage.

Would it help to use a full URL to the online docs?

--David


Gmane