Jim,
I have responded to Jeremy's post on the details of what should
be released and in which locations.
As you say, personal preference on this point does vary, and there
is quite a variation between other projects on how they handle this.
I looked at a few other project releases to see what they do.
Spring has online javadoc, but I don't see a downloadable version.
Their minimal download includes source so I presume that people are
exepcted to generate it from this (your approach). Tomcat and Axis2
have downloadable javadoc packages that are separate from their
binary distribution. Ant, Xerces, XMLBeans, Hibernate, and Celtix
include javadoc in their binary distribution, so there are quite a
few precedents for doing this.
At this stage of Tuscany I think we are targeting application
developers and extension developers, so I would be more inclined to
have a downloadable binary package that is a development/runtime
"kit" rather than a pure runtime. When we are ready to start
promoting Tuscany as a runtime for use with pre-built applications,
it would make sense to have a pure runtime download.
Simon
Jim Marino wrote:
On Nov 1, 2006, at 3:20 PM, Simon Nash wrote:
Comments inline below.
Simon
Jim Marino 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.
The spec API and tuscany-api are relevant to application developers
and extension developers.
The spec API jars are obviously relevant, tuscany api much less so
(hopefully applications developers would not use these very much, if at
all)
tuscany-spi is relevant only to extension
developers but as you said in earlier posts, these are an important
segment of the audience for M2.
Yes and that's why I believe we should bundle them separately. I
generally prefer not to download javadoc at all on my machine for two
reasons. One is I typically access it online. The second is if I use it
a lot, I also want the source. So, I download the source and setup my
IDE appropriately; it can display javadoc directly from the source.
For simplicity I think it is better
to bundle all of these in the standalone distro rather than create
many separate downloadable packages.
It would probably be informative to look at how other similar projects
manage distributions. Spring for instance has a baseline distro without
Javadoc or optional dependencies, i.e. something similar to our core
distribution.
I don't want to belabor the point, however, as I think we have
different philosophical views on what is easier, a single large
distribution that one must modify to create runtime and dev images or
smaller units that people can deal with individually.
Perhaps we should just have both? If we want to have both, could you
please respond to Jeremy's previous post in this thread with a proposal
on how to resolve the issues he raised?
Jim
Also this would match how
javadoc is packaged in SDO M2.
1) What modules should we generate javadoc? I assume only for *-
api and *-spi.
yes. Core is not an exposed api/spi.
Agreed.
2) Should we package the javadoc with the standalone distro or as
a separate archive?
separate archive
Combined (see reasons above).
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]
---------------------------------------------------------------------
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]
