[kepler-dev] build.xml and JAVA_HOME

[Aaron Schultz]

Agreed, I included the check on JAVA_HOME because of bullet 4 in 
INSTALL.txt and also I saw that it was being used to set properties in 
the build file.  However those properties (javadir and javadirvar) are 
not used anywhere in build.xml, build-ptolemy.xml, or build-doc.xml and 
JAVA_HOME is only used in the generateDocSetup target to set 
lib/tools.jar in the classpath (which the generateDoc target runs just 
fine without).

I think cleaning up these variables and using ${basedir} to replace 
env.PTII and env.KEPLER is a good solution.  I'm unclear if not having 
PTII and KEPLER in the environment would effect anything else?  
INSTALL.txt could be modified with where PTII and kepler-docs 
directories should be placed (either in the same directory as kepler or 
as sub directories).  I'll keep playing with this as I tool up on Ant 
and learn more about the build process.

Aaron

Chad Berkley wrote:
> I think these are all good ideas.  I'll add them to a post-1.0 bug.  I 
> removed the requirement for JAVA_HOME.  I hadn't realized that was in 
> there.  Aaron pointed out to me the other day that we could have an 
> error message alerting users to the state of these env. variables and 
> I asked him to add the functionality so he could learn a bit of ant 
> and have a chance to dig into the build system a bit.
>
> chad
>
> Matthew Jones wrote:
>> I agree, it would be better if we could build without requiring that 
>> JAVA_HOME is set.  For that matter, I would prefer if we didn't need 
>> to set KEPLER or PTII either.  For KEPLER, we can use the ant basedir 
>> property which is always set to the directory where the build is 
>> launched -- this would be a simple change.  Its not even clear to me 
>> that env.KEPLER is used anywhere except in the javadoc target, and it 
>> would be easily replaced with either a relative path or ${basedir}.
>>
>> For PTII, I think we should check if PTII is set, and if so, check it 
>> and use that dir, but if not then see if ptii is found in a sibling 
>> dir of $KEPLER, and if so use that.  If both of those fail, then 
>> abort with an error saying we can't find ptii. By checking for the 
>> environment variable first, we allow people to use different versions 
>> of PTII while still making the default case where it is checked out 
>> in a sibling directory the default.
>>
>> These changes would significantly simplify our build and eliminate 
>> the most frequently reported build problem that is reported to us.
>>
>> Matt
>>
>> Christopher Brooks wrote:
>>> Hi Aaron,
>>>
>>> You modified build.xml with this log message:
>>>
>>>   Added a condition to the preinit target to make sure that the
>>>   environment variables are set.  Otherwise, the build fails with a
>>>   message.
>>>
>>> The diff is:
>>> bash-3.00$ cvs diff -r 1.380 -r 1.381 build.xml
>>> Index: build.xml
>>> ===================================================================
>>> RCS file: /cvs/kepler/build.xml,v
>>> retrieving revision 1.380
>>> retrieving revision 1.381
>>> diff -r1.380 -r1.381
>>> 4,6c4,6
>>> <  *     '$Author: crawl $'
>>> <  *       '$Date: 2008/04/02 21:09:41 $'
>>> <  *   '$Revision: 1.380 $'
>>> ---
>>>>  *     '$Author: aschultz $'
>>>>  *       '$Date: 2008/04/17 23:45:07 $'
>>>>  *   '$Revision: 1.381 $'
>>> 118a119,126
>>>>       <condition property="env_ok">
>>>>          <and>
>>>>            <isset property="env.PTII"/>
>>>>            <isset property="env.KEPLER"/>
>>>>            <isset property="env.JAVA_HOME"/>
>>>>          </and>
>>>>       </condition>
>>>>       <fail message="Environment not initialized: PTII=${env.PTII} 
>>>> KEPLER=${env.KEPLER} JAVA_HOME=${env.JAVA_HOME}" unless="env_ok"/>
>>>
>>> This means that we are now requiring JAVA_HOME be set.
>>>
>>> It looks like the automatic build is failing, see
>>> ttp://nmi-s003.cs.wisc.edu/nmi/index.php?page=results/runDetails&runid=83360 
>>>
>>>
>>>
>>> If JAVA_HOME is not set, then I get this error message:
>>>
>>> bash-3.00$ ant run-dev
>>> Buildfile: build.xml
>>>
>>> preinit:
>>>
>>> BUILD FAILED
>>> /export/home1/cxh/src/kepler/build.xml:126: Environment not 
>>> initialized: PTII=/home/eecs/cxh/ptII 
>>> KEPLER=/home/eecs/cxh/src/kepler JAVA_HOME=${env.JAVA_HOME}
>>>
>>> Total time: 1 second
>>> bash-3.00$
>>> I looked at this message and had no clue that I had to set JAVA_HOME.
>>> Perhaps the error message could be more explicit, perhaps each
>>> variable could be checked separately?
>>>
>>> However, it it really necessary that JAVA_HOME be set?  Can't we
>>> determine this programmatically?  The problem is that if the
>>> java in the user's path and JAVA_HOME are different, then there
>>> will be problems.
>>>
>>> In Ptolemy II, we compile and invoke ptII/config/JavaHome.java,
>>> which will tell us the value of the java.home property.
>>>
>>> What was the error message that you were seeing?  Did it have
>>> to do with compiling PtDoclet.java, which requires
>>> ${JAVA_HOME}/lib/tools.jar?
>>>
>>> I'm not sure how best to handle this in ant, but is there
>>> a way that ant can compile a Java program and use that value?
>>>
>>> I'm somewhat resistant to have the user set JAVA_HOME, I've
>>> found that it ends up causing no end of support problems.
>>>
>>> BTW - The ant docs say that JAVA_HOME must be set, but the reality
>>> is that ant works ok without JAvA_HOME being set.  IMHO - it is a 
>>> bug in ant that I'm asked to set JAVA_HOME.
>>>
>>> _Christopher
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev 
>>>
>>
>