cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: [DOCS] Problem generating 4.4 API docs
Date Fri, 30 May 2014 20:22:35 GMT
Hi Will,

Based on my last memories of the apidocs tool and maven poms, I think it
used to scan built jar artifacts and reference them against something like
a properties file (commands.properties?) and internally scans bunch of
annotations in available class files to find apis and create apidocs. The
ApiDiscovery plugin uses the same approach to discover available apis but
during load time instead of build time.

I would also recommend a clean install in case there are any caching
issues. See if this helps.

Regards.


On Sat, May 31, 2014 at 1:14 AM, Will Stevens <wstevens@cloudops.com> wrote:

> Hey All,
> Paul Angus and I have both tested this and this is what we are seeing.
>
> When we compile the the 'master' branch, the docs in
> 'tools/apidoc/target/xmldoc/html', but they appear to be the wrong docs.
>  Yes, we know that the versions that appear in the output is hardcoded in
> the XSL files, but that is not what we are using as our reference.
>
> So in the 'tools/apidoc/pom.xml' the 4.4.0-SNAPSHOT is referenced.  I have
> also confirmed that when a build is done, the 'tools/apidoc/log/@AGENTLOG@
> '
> shows that the 'client/target/cloud-client-ui-4.4.0-SNAPSHOT/WEB-INF/lib/'
> directory is being referenced.
>
> However, when I check the 'tools/apidoc/target/commands.xml', it does not
> include API calls which were added in 4.3 (I can verify with the published
> 4.3 API docs).  Also, the docs that are generated in the
> 'tools/apidoc/target/xmldoc/html' directory also does not have the API
> calls that were added in 4.3.
>
> I am stumped as to how this is happening.  It is almost like the
> 4.4.0-SNAPSHOT is actually the 4.2.0-SNAPSHOT, but I am not sure how that
> would be possible.
>
> If someone who understands this piece of the software can have a look and
> verify what we are seeing, we would appreciate the insight...
>
> Thanks,
>
> Will
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message