"I think javadoc is a just a reference for programmers. If there's a
convenient way to get it, I'm satisfied"
That's the crux of it all... so +1 from me.
- Venkat
On 11/3/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
Let me propose the following. We need to close it quickly so that it won't
become a blocker for M2.
1) For *-api and *-spi, we're going to have the javadoc per module and
publish them into maven repo.
2) A separate distro to aggragate all the javadocs into one downloadable
archive.
3) An aggregate online javadoc on Tuscany web site for M2.
What level of linking (to JDK classes or other javadocs) do we want?
I think javadoc is a just a reference for programmers. If there's a
convenient way to get it, I'm statisfied.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, November 02, 2006 8:01 AM
Subject: Re: Javadoc for M2
>I agree with all these suggestions. In the SCA javadoc downloadable
> archive I would include the spec API along with tuscany-api,
> tuscany-host-api, and tuscany-spi. (Perhaps this is what you meant
> by *-api).
>
> This downloadable javadoc archive could either be combined with the
> downloadable standalone distribution, or separate from it. See my
> latest response to Jim for the reasons why I think it would be
> better to have this as a part of the standalone binary distribution
> on the download site for this release. However, I don't think the
> same considerations apply to the standalone distribution that we
> will publish to the maven repo. I would expect users of this
> version to use maven to get the javadoc from the maven repo as well.
>
> So my suggestion would be to not include javadoc in the standalone
> runtime that we publish to the maven repo but to include it in the
> binary/standalone version that we place on our web site for download.
>
> Simon
>
> Jeremy Boynes wrote:
>
>> The maven javadoc goal by default generates a -javadoc.jar for every
>> artifact it produces and allows that to be deployed to the repo. I
>> believe it does this because that is the format expected by the
>> different IDEs (it certainly is for IDEA and I think Raymond said it
>> worked for Eclipse as well). I think we would be wise to follow this
>> convention.
>>
>> That would mean that e.g. for -api there would be
>> tuscany-api-${version}-javadoc.jar
>> in the repo.
>>
>> I agree that we should just do *-api and -spi.
>> I also think we should do aggregated javadoc for all those modules
>> online on the website. We could make an archive of that available on
>> the download site (but I don't think we need to do that through the
>> maven repos).
>>
>> --
>> Jeremy
>>
>> On 11/1/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> On Nov 1, 2006, at 9:33 AM, Raymond Feng wrote:
>>>
>>> > Hi,
>>> >
>>> > I think it would be useful to package java in our M2 binary distro.
>>> > I would like to hear your opinions:
>>> I'd say as a separate downloadable jar since this would only be
>>> relevant to extensions providers and not applications developers.
>>> >
>>> > 1) What modules should we generate javadoc? I assume only for *-api
>>> > and *-spi.
>>> yes. Core is not an exposed api/spi.
>>> > 2) Should we package the javadoc with the standalone distro or as a
>>> > separate archive?
>>> separate archive
>>> >
>>> > Thanks,
>>> > Raymond
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>>
>>
>>
>
> --
> Simon C Nash IBM Distinguished Engineer
> Hursley Park, Winchester, UK [EMAIL PROTECTED]
> Tel. +44-1962-815156 Fax +44-1962-818999
>
>
> ---------------------------------------------------------------------
> 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]
