Re the javadoc,
* including custom overview etc. is just configuration that can be
played with (like you did with the samples)
* getting the sdo-api doc in there would be tricker as that's outside
the source tree. it may be possible to reference it, I think there's
config for that (some form of external javadoc reference)
* it may be possible to filter the source files that are included
(e.g. to cut out impl details, sample source)
I've not got any experience with that.
Re the sample source - I included that to match what you have. It's
easy to exclude by excluding the sample module. It would be fairly
easy to add another assembly config that just included the sample
source (which sounded like what Simon was suggesting). For that
matter, you could also to that to package the javadoc separately.
--
Jeremy
On Oct 6, 2006, at 11:48 AM, kelvin goodson wrote:
Jeremy,
that looks like a great improvement, thanks. After the full build
I see a
binary distro containing a javadoc folder as a peer of the lib
folder, and
it has merged javadoc for the all of the implementation projects.
(I need to
resolve the fact that there is a sample-sdo folder in there, on the
basis of
Simon Nash's comments on the RC2, but I think that's my problem.)
So I have a few thoughts that you may have further ideas about.
Let me tell you what I think the ideal situation is for javadoc in the
binary distribution, and where I hope we can get to with this
release.
Ideally the javadoc that a user finds in the binary distribution
documents
just the interfaces an SDO user is interested in, i.e. the SDO
API, + our
Tuscany specific extensions like SDOUtil, + our tooling, like
XSD2JavaGenerator. I didn't think I could get to that situation in
the time
available, so my plan is to get a merged javadoc that includes all
those
things, + a lot of stuff the user is not interested in, and then
provide
an overview.html that gets sucked in by the javadoc executable to
form part
of the top level index.html. This overview would provide links to the
things of interest to a user. So what you have provided is infinitely
better than what I had provided in RC2 (i.e. nothing), but if we
were able
to get the sdo-api javadoc in there too, and the process also
catered for
adding a hand crafted overview.html, as we have in the samples
project,
then that would be a great advance.
Best Regards, Kelvin.
On 06/10/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On IRC Kelvin mentioned possibly re-jigging the SDO distribution
format to include the assembly phase in the parent pom. The idea was
that would make it easier to aggregate things like JavaDoc across the
modules.
I've taken a swag at this in my sandbox:
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/jboynes/
sdo
This builds two ways: one to produce local artifacts, the other to
produce a distribution.
The first way is what we had before and allows you to build SDO as
part of a larger reactor build (i.e. what we do when we build sdo,
das and sca together). The default goal is "install" set by the
reactor and that puts the binary jars in your local maven repo as
usual. You can run this from the command line using "mvn package" or
"mvn install"
The second way does that, followed by a packaging step. That build
aggregate javadoc across the modules (which is a slow step) and then
builds the distribution bundles. This is intended to be run just to
cut the release. You run this with "mvn package javadoc:javadoc
assembly:assembly" and it:
* builds and tests the jars as usual
* generates javadoc aggregated across all the sdo modules
* builds zip and tgz archives containing legal, jar files, the sample
source and the javadoc - we can fine tune this as needed
Kelvin, can you give this a go and see if it's what you want in the
distro.
Any other comments? Is this something we might want to do for DAS and
SCA as well?
--
Jeremy
---------------------------------------------------------------------
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]
