Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <434D3C27.1040705@reverycodes.com>
Date: Wed, 12 Oct 2005 12:39:03 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: javadocs navigation
References: <433EF6D4.6040209@apache.org>
 <20051002014142.9A7A926D13B@avs2.arnes.si>
 <loom.20051011T230153-516@post.gmane.org> <434C7C97.2080107@reverycodes.com>
 <434C8020.40403@apache.org> <722ae8b85e8d0b226fdc45c9c3fab38c@apache.org>
 <434CCAA3.7050303@apache.org> <434D336E.9000001@apache.org>
 <434D37D3.1000903@odoko.co.uk>
In-Reply-To: <434D37D3.1000903@odoko.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Upayavira wrote:
> Stefano Mazzocchi wrote:
> 
>> Sylvain Wallez wrote:
>>
>>> Or more simpler, and we already talked about this, what about tagging 
>>> the source files themselves to be able to produce javadocs of a 
>>> restricted set of classes, i.e. those that are considered public API 
>>> and that people can safely rely on.
>>
>> There you go! +1
> 
> So how do we decide what is internal, what is external? The discussion 
> is likely to be "fun".

Let's start small - let's mark as public, external classes only those where we 
have consensus, and leave "questionable" classes out, have a discussion on them 
later.


> We could have a wiki page containing all classes, and mark the ones on 
> that wiki page that we want to be public. Then a script could add the 
> necessary javadoc markup.

Wiki page, where each java class can be marked as one of:
   public / private / dispute / not-marked-yet.


> If that approach sounds okay, I'd happily volunteer to write the script 
> to add the markup, assuming it is a simple enough markup.

Sounds good

Vadim