Hi Jeremy
* 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
is it an absolute constraint that we have one shared Tuscany wide spec folder for all subprojects? Could I for instance have ... java/sdo java/sdo/spec ... ... java/sdo/implementation java/sdo/implementation/impl java/sdo/implementation/tools java/sdo/implementation/plugin java/sdo/implementation/sample I know you were reluctant to move the java/spec/sdo project into the java/sdo hierarchy in discussions we had a week or so ago when we moved the samples, but it would make my life much easier if I could aggregate spec and impl javadoc using a pom at the java/sdo level Regards, Kelvin. On 06/10/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
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]
