Henri Yandell wrote:
On Wed, 24 Aug 2005, Henning Schmiedehausen wrote:
Hi,
I toyed with similar ideas for a long time (I even had once an intern
whip something up), however, there are a number of drawbacks:
- different versions. The osjava variant tries to get this right by
allowing the user to choose the versions.
- inter-project links. Phils' variant builds everything in one big
javadoc (don't do that. IMHO). So links beween projects are resolved
correctly. You might even toss in links to Suns' official API docs
for java.* and sun.* packages
Once the versions are in official locations, each project can set their
linking (least at osjava that's my plan). So links will work, but it
won't all be in one big centrally built javadoc.
Nicest would be to do this in maven.xml; have it automatically know the
structure of the local javadoc tree and link the dependencies in.
Easiest is to just hack each one into the project.properties.
More on this when I get put another burst of energy into it. Also as the
jar files are there, I think I can do something very cool with clirr :)
I got the "single big javadoc" thing to work using maven without having
to reference any of the projects directly (other than attributes, which
has its sources in a non-standard place). The packages come out sorted
in "reactor order", though and due to general lack of enthusiasm for
this approach, I did not spend any time trying to get jelly's util:sort
to work to fix this. The maven.xml linked below contains some things
that may be useful for the aggregation approach - collecting
dependencies and javadoc links from the subprojects.
http://people.apache.org/psteitz/apidocs/maven.xml
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]