[kepler-dev] Loading documentation

Christopher Brooks cxh at eecs.berkeley.edu
Thu Apr 13 12:20:47 PDT 2006

Hi Nandita,

Can we please please please have an extra section that reads the
KEPLER property and then tries to guess wildly about where KEPLER_DOCS
might be?

The reason is that it should be _really_ simple to start up kepler
from a tool like Eclipse.  As it is, we need to set both
the PTII and KEPLER properties to launch Kepler from within Eclipse.

There must be a default location for KEPLER_DOCS relative to KEPLER,

BTW - the way Vergil starts up is that it sets the ptolemy.ptii.dir
property to the value of $PTII.  The reason I chose ptolemy.ptii.dir
is because I want all the Ptolemy properties to be in a particular
namespace.  I encourage Kepler to do the same.  The reason I use
ptolemy.ptii.dir is that I've had to change environment variables in
the past, Ptolemy Classic had $ARCH, which conflicted with everything,
so we had to change it to $PTARCH - thus, by using a longer name, I
avoid conflicts (yes the odds of conflicting with PTII and KEPLER are
low but . . .) .  Also, if all the Ptolemy properties start with
ptolemy.* then it is easier to manage the Ptolemy properties, for
example the view jdk properties menu choice in Ptolemy sorts the
properties and it is obvious which are Ptolemy and which are java.

It might be nice if Kepler use ptolemy.ptII.dir instead of PTII, but
it is not a bug to use PTII.



        Hmm - the code should take care of the problem, but when I remove 
    the file, the docs don't show up!  And since I have a KEPLER_DOCS env 
    variable, it should never get called! I'll dig into it.
    Thanks for the info.
    Nandita Mangal wrote:
    > 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
    Dan Higgins                                  higgins at nceas.ucsb.edu
    http://www.nceas.ucsb.edu/    Ph: 805-893-5127
    National Center for Ecological Analysis and Synthesis (NCEAS) Marine Scienc
   e Building - Room 3405
    Santa Barbara, CA 93195
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org

More information about the Kepler-dev mailing list