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]

Reply via email to