forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <...@outerthought.org>
Subject RE: Using forrest for other projects / minimal setup
Date Mon, 05 Aug 2002 11:15:49 GMT
Christian,

> I just proposed forrest to another open source project (no, not
way to go...

> FOP, Joerg voluntered to do this ;-)
> First I marked up the existing docs and everybody liked it and
> asked how they could use forrest themselves.
> Well, I started from xml-forrest, removed some stuff
> (scratchpad/contrib/jtidy/centipede/..) which seemed unnessary
> for the documentaion generation and it worked but is still a lot
> of stuff for this "rather simple" task.
> 
> So my question is how other projects (including xml.apache.org)
> should use forrest?

there is a number of answers to that question
1. on the pure logical data-flow level: 
   http://www.krysalis.org/forrest/forrest-contract.html
2. but what you are referring to is the more administrative/
   operational level...

on that level we recently kind of wrapped up the forrestbot 
that can be used in a number of ways:

[alternative 1] central forrestbot
very gump-like offers to do the work centrally for your project
(this is the hoped way to have xml.apache.org running eventually 
 I guess)
- operational mode: just send this group a mail with how/where
the ./content/xdocs sources for your project can be found, and
how/where they should get published (currently outerthought 
has a server that is running that very job: one of the build 
projects is http://krysalis.org/forrest)
- pro:
   - no own hastle, we keep the running forrest more or less 
     in sync with cvs for you
   - nagg mails tell you if you have to take a closer look
   - separate your-project stuff from the forrest stuff
- con:
   - lesser control for you, we run it each 6 hours, and add in 
   - for scp deploy there is the issue of giving the forrestbot
     your private key.
   - we don't have cvs deploy (ideas on how to do this still welcome)


[alternative 2] run your own forrestbot instance
which is: pretend you're your own centrum of the world :-)
- operational mode: create your own bot configuration xml file
  and have your own cronned shell script to call the 
  ant bot -Dbot.forrestbot.xconf=yourfilehere
- pro: 
    - more control to you
    - still separated project from forrest
      (one forrest install will do)
- con: set it up yourself (easy)

this would pretty much be how you setup things for
e.g. all inhouse projects of your company to be published
on one central http server.


leaving us for what you are heading for:

[alternative 3] call forrest from your own build process:

> 
> IMHO this should be as simple as possible, something like:
> You need this (probably rather big) jar, that ant task and that's all.

I agree.
Although the ant-task might be in first releases an <ant> call to 
a forrest provided build file, I guess?

In fact you can already do this by calling the ant bot target 
of alternative 2 _not_ from a cronned shell script, but just
from your own build file instead.

Of course the _real_ message of your mail is you don't want 
to have the forrest-mess inside your own project-mess?
I think the nicest way to have this would be to use the cent 
approach provided by krysalis centipede (although there has 
been some rumour there IIRC on providing a solution that 
installs centrally on your system as opposed to inside
each project)


anyone else ideas?
I was hoping to do the build.xml revamp this week,
(using the new templates of the bot, to line up)
if we find a nice solution to this we could add this in 
in the same effort...

it's my personal believe that having a clean 'way to use' 
forrest out asap will help us grow the user group.
those users will probably offer reflections on nicer new 
documentation mechanisms to add in. 

HTH,
-marc=

Mime
View raw message