On Apr 10, 2009, at 6:52 PM, David Sean Taylor wrote:
I would like to discuss moving all documentation out of projects and
into the portals/site directory, for example:
site/jetspeed-2.1.3/
site/jetspeed-2.2/
site/pluto-1
site/pluto-2
This was actually proposed to me by Ate. I was originally against
doing so. But after a long talk, I began to see the benefits but to
be honest Im still not entirely convinced, although I am warming to
the idea.
Let me summarize the reasons for separating the documentation from
the source trees:
1. Documentation is never completed with the final release. We often
continue documentation after the release goes out. With 2.1.3, we
wrote most the documentation after the release in a post-release
branch
2. Documentation can be completely different for some versions, but
the same for other versions. This allows us to decouple the
documentation into a more easy to work with group of version,
separated from the incremental release versions
There are some issues with this approach:
1. You will need a master POM for the documentation in order to get
the general project information such as mailing list, authors.
2. Its not really clear to me how we will generate Projects Reports.
If we do, I assume we use the latest release version that the
documentation is going against
To simplify things, there will be no need for using /trunk, /tags,
etc. svn sub folders for them.
Why not??? Maybe not tags but surely branches and trunk.
Your opinions are welcome. I would like to decide before the set of
upcoming releases (pluto 2.0, jetspeed 2.2.0) are finalized.
At geronimo the human written documentation is in the confluence wiki
and we just use the maven generated site for javadocs, source xref,
etc. When we start a new version we copy the wiki and start
updating. I personally find this a relatively palatable format to
write documentation in, much easier than the ones I can figure out
that maven supports.
thanks
david jencks
Thanks
