Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41896528.4040903@latte.harvard.edu>
Date: Wed, 03 Nov 2004 18:09:28 -0500
From: "Mark R. Diggory" <mdiggory@latte.harvard.edu>
Reply-To: mark_diggory@harvard.edu
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [general] Website? Re: [Commons websites] not updated recently
References: <e8bc90dc041026080979d6b849@mail.gmail.com>
	 <417E7C79.1020905@lfjr.net>	 <e8bc90dc04102609392a269acb@mail.gmail.com>
	 <417FDADB.4000305@lfjr.net>	 <e8bc90dc04110203374b77fa5e@mail.gmail.com>
 <4187C687.60009@lfjr.net>	 <31cc373604110314186b1c3803@mail.gmail.com>
 <31cc373604110314237f9aed7@mail.gmail.com>
In-Reply-To: <31cc373604110314237f9aed7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 <flamefew@gmail.com> 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 <smanux@lfjr.net> 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: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

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