On 05/30/2014 10:40 PM, Will Stevens wrote:
Thanks Rohit, I will do all those steps.
I know the git branch is correct, but I will do a clean anyway.
Removing the maven repositories is a good idea.
NB; for this issue, e.g., fear of old cloudstack stuff being used rather
then newly built bits, removing by;
rm -rf ~/.m2/repository/org/apache/cloudstack
is a good idea.
Removing all of ~/.m2 will cause the entire cache, including non
cloudstack artifacts, to need to be re-downloaded. That takes time, and
the same artifact dependencies will be downloaded again hence a time
consuming noop.
To mitigate ~/.m2 artifact cache download time during build from
scratch, and the purpose is not to repopulate ~/.m2 cache from scratch,
this directory minus cloudstack artifacts, can be saved and preloaded
prior to the build start. If there are new artifact updates, maven will
detect this and only download the new stuff.
/Ove
Thx,
Will
On Fri, May 30, 2014 at 4:35 PM, Rohit Yadav <bhais...@apache.org> wrote:
Check if git branch or source code in question is correct, git clean -df
(note: this will remove files not tracked by git), check that
the commands.properties has the API you were searching in apidocs, remove
~/.m2 and do mvn clean install, if that does not work check if the
API/plugin in question implements a valid CloudStack API (annotations
etc.). Lastly, if nothing worked probably apidocs needs fixing.
Regards.
On Sat, May 31, 2014 at 1:55 AM, Will Stevens <wstev...@cloudops.com>
wrote:
By clean install you mean starting from scratch, not 'mvn clean install'
right? I have been doing mvn clean installs...
Will
On Fri, May 30, 2014 at 4:22 PM, Rohit Yadav <bhais...@apache.org>
wrote:
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 <wstev...@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
--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706668199 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)
