I have completely started from scratch with a new clone of the CloudStack repo.
Master is now pointing to 4.5, so I checked out the 4.4 branch. I put all the deps in place as well as the vhd-util file. I completely removed my ~/.m2 directory so I am starting from completely clean. I checked the directory structure for 'commands.*' before building and the only one was the following: client/tomcatconf/commands.properties.in It does not have all of the API calls in it (the UCS section for example is not up to date). I built the project successfully and then did the same check to see what 'commands.*' files were available. Now I have: client/target/cloud-client-ui-4.4.0-SNAPSHOT/WEB-INF/classes/commands.properties client/target/conf/commands.properties client/target/generated-webapp/WEB-INF/classes/commands.properties client/tomcatconf/commands.properties.in tools/apidoc/target/commands.xml I checked the 'client/target/conf/commands.properties' and verified it does not have the updated UCS api calls. I checked the generated docs and they are still pre-4.3. How do we go about getting commands.properties updated? Why is the commands.properties two releases behind? Its not even up to date for 4.3. Cheers, Will On Fri, May 30, 2014 at 4:59 PM, Ove Ewerlid <ove.ewer...@oracle.com> wrote: > 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) >
