Hi, >> The execution "javadocs-distr" in the "uimaj" POM (the one in trunk) runs the >> "javadoc" goal, not the "aggregate" goal. That looks like only per-module >> JavaDoc is generated. It appears to be the only place where the JavaDoc >> plugin is configured. Where is the aggregate JavaDoc generated and how is >> it later published? > > This generates the aggregate javadoc. I recall, vaguely, that the aggregate > goal assumed we wanted javadocs for everything, instead of just for the > user-accessible APIs. > > To get the aggregate set generated, this goal has a configuration which > includes > specifying multiple "sourcepath" elements, one for each module that has > user-referenced APIs. And then it also includes some > otherwise-by-default-excluded packages that have the word "impl" in them > (which > is one of the naming convention we used for internal, implementation-detail, > subject to change, etc., kind of packages). See the "excludePackageNames" > element in the configuration for the javadoc in the POM.
Hm, I'll check this again and possibly stick with "aggregate" for uimaFIT then. >>> The third is that tools like Eclipse can get the source from Maven (the >>> source.jar) when needed for debugging, automatically. It's unclear (to me >>> at >>> least) the use case(s) that would make use of the JavaDocs-by-module on >>> Maven >>> central. >> For Eclipse, the JavaDoc artifacts are indeed quite redundant, at least if >> the >> sources are available. In principle, it could be imagined, though, that the >> JavaDoc is post-processed and augmented, so that it contains more information >> than the "plain" JavaDoc from the source. >> >>> Likewise, I'm not sure what the use-case(s) are for putting the >>> test-sources on >>> Maven Central. Tests are typically done during builds, and those are done >>> typically by developers, who checked out the sources from SVN. >> It's not a good practice, but it's possible to reference a test artifact from >> module A so it can be used by the tests in module B. > I'm not sure how this would work in practice. Normally, Maven dependencies > refer to JAR artifacts (or compiled folders) that can be put into the > classpath > of something, like a test-runner. I don't see how putting a reference to a > Maven-located artifact which was a "source" artifact would work? Badly written on my side. I meant putting the test-jars there for reference from other tests. When the test-jars are there, having the test-sources as well is - of course - convenient. Addressing a test artifact is done by adding a "classifier" to the dependency. I'm not promoting this kind of dependencies between tests. Cheers, -- Richard -- ------------------------------------------------------------------- Richard Eckart de Castilho Technical Lead Ubiquitous Knowledge Processing Lab (UKP-TUD) FB 20 Computer Science Department Technische Universität Darmstadt Hochschulstr. 10, D-64289 Darmstadt, Germany phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117 [email protected] www.ukp.tu-darmstadt.de Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de -------------------------------------------------------------------
