Hen and all,
We put allot of work over the summer into getting the top level site to its current state. Having it be modular and easily updatable. Why is this coming across as difficult to maintain?
jakarta-commons/commons-build/ `maven site:deploy` updates the top level.
jakarta-commons/commons-build/ is where we maintain all the top level documentation. Each project uses this plus their own project to generate their maven site with the commons branding. There are references to the commons-build jsl and menu contents in each project.properties for the subprojects. You checkout commons-build and your project, go to your project directory and run `maven site:deploy` and your site is updated.
Currently each project is responsible for the content of its site. This was the only way to maintain the fact that different projects wanted to have different strategies for publishing reports and javadoc documentation. Its a solution that unified the look and feel while maintaining sub-project autonomy.
Don't get me wrong, I'd like to see a fully integrated commons site and I like the idea of a common javadoc/xref for the whole thing. Its just getting all the custom reporting in line. And allowing the individual projects to update pages when they want is very important too.
-Mark
Henri Yandell wrote:
Oh. Sales pitches (that I've made before and need to move on again):
http://multidoc.osjava.org/ (needs hacking to work with Clover)
http://builds.osjava.org/
I've had both setup for Commons before and need to get them going again.
Idea being, we would have a jakarta.apache.org/commons/builds site which had the developer stuff, and a lot of the current commons site could be removed (all the maven reports etc), and we could tighten the release site down a lot; which will help get rid of a lot of the extra noise.
Hen
On Wed, 3 Nov 2004 17:18:51 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
I think we should have two websites.
The first is a user-based one and contains information on the latest releases. The second is a developer-based one and contains information on HEAD and diff's between the latest release and HEAD.
The second one would be generated nightly, perhaps as part of a nightly build and would be report-centric. The first would only be changed on a release, and would be documentation-centric. It should be much quicker to make changes to than the current one is.
I'd like to multidoc both of them (currently many components don't have a javadoc for the last release, or in the alternative case, a javadoc for HEAD) to make it easier to see
I'd also like to decouple the Commons part of the site from all the release parts. Currently it seems to me that we've coupled the Commons site itself to the components and it's a pain in the arse. Might have improved in the last month or so.
Just thoughts that I eternally hope to have time to work on...
Hen
On Tue, 02 Nov 2004 18:40:23 +0100, Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
That looks great, I'm definitely interested. It solves a part of the problem, the only issue left is the generation of the documentation.
I guess the best would be to integrate this as a maven plugin, maybe as an enhancement of the javadoc plugin. In the meantime we could integrate your code in the commons-build scripts.
Emmanuel Bourg
Corey Scott wrote:
To whom might be interested,
I have developed an extension (sort of) to the JDiff maven plugin that checks-out a version (defined by property ${maven.jdiff.javadoc.tag}, defaults to CURRENT) and then generates the javadoc. The docs are generated in: ${docsDest}/apidocs/${maven.jdiff.javadoc.tag}
There is probably more to be done, eg. adding links to the menu, but this is my first attempt with jelly (so the code is likely to be a little sloppy also)
Questions: 1) Is anyone is interested? 2) Does this solves our problem with auto-generating the commons website regularly? 3) As its strictly not related to the JDiff plugin, where should I submit it?
Many thanks, Corey
PS. I going to post this to the Maven dev list as well, sorry for anyone who ends up with 2 copies, but I just wanted to make sure Commons people where aware of it, cause I thought it might be useful
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
