[kepler-dev] Loading documentation
Nandita Mangal
nmangal at sdsc.edu
Thu Apr 13 12:01:38 PDT 2006
Hi Dan,
The docsInfo.txt is used when reading the documentation from the canvas
via 'GetDocumentation', as a backup test , in the case that KEPLER_DOCS
env. variable retrieved nothing ....It was just a backup way of checking
the path is set to which location for testing purposes and isn't really
used otherwise.
I can definitely do away with using it, if its causing troubles in
building installers.
Here is the code using it from "getdocumentation"
//Javadocs located under a new location in Kepler
String keplerDocsHome = System.getProperty("KEPLER_DOCS");
if(keplerDocsHome == null)
{
//try other way to access environment variable value.
BufferedReader inDocsInfo= new BufferedReader(new
FileReader("./doc/docsInfo.txt"));
....
thanks,
nandita.
Dan Higgins wrote:
> Hi Nandita,
>
> I was trying to understand why I needed to regenerate the
> documentation every time I checkout a new version of Kepler. I haven't
> looked at your code but it appears that 'ant generateDoc' creates a
> file called 'docsInfo.txt ' in the $kepler/doc/ directory and that
> that file contains the path to the directory that contains the
> documentation xml files. It appears that Kepler actually reads the
> file to find the documentation. Is that correct?
>
> If so, I would like to suggest a change. We use an environment
> variable KEPLER_DOCS to create the baseline documentation. Why don't
> we continue to use it inside Kepler for opening a documentation
> window? [The problem with using a file is that it is only correct for
> the machine where the docs were generated and this creates
> difficulties when we build installers or someone moves Kepler or the
> kepler-docs directory]. If the code used the KEPLER_DOCS env variable,
> I can set that on the command line that starts Kepler. Otherwise I
> need to rewrite the file in installers and, in any case, we need to
> make the path relative rather than absolute so that the user can put
> Kepler anywhere they wish.
>
> Dan
>
More information about the Kepler-dev
mailing list