Hi,
yet another properties file sounds like a bad idea. The
wobuild.properties declare a set of properties useful for all builds
with woproject. And it might be better to have one properties file for
all user of woproject then maintaining one for each project. Let's take
a look at this file:
wo.dir.root=/
wo.woroot=/
wo.dir.user.home.library.frameworks=/Users/ulrich/Library/Frameworks
wo.dir.local=/
wo.wosystemroot=/System
wo.dir.library=/System/Library
wo.dir.user.home.library=/Users/ulrich/Library
wo.dir.local.library=/Library
wo.dir.library.frameworks=/System/Library/Frameworks
wo.dir.local.library.frameworks=/Library/Frameworks
wo.wolocalroot=/
wo.dir.system=/System
There are a some duplicates. The properties with the dir inside should
be used. I think this stuff is self explaining. Anyway I can add some
lines to docu if there is demand for it.
Some lines from the woproject build file as an example on how to
generate the wobuild.properties:
<project name="woproject" default="dist" basedir=".">
.
.
// load the wobuild.properties file
<property
file="${user.home}${file.separator}Library${file.separator}wobuild.prope
rties"/>
.
.
// make "check" the first target
<target name="dist" depends="check">
.
.
// This target calls check within the
build-user-home-wobuild-properties.xml.
// This target fail if the wobuild.properties could not be found.
// The cool thing is that this build script creates the
wobuild.properties in that case and informs the user that he has to run
the script again.
// The build script build-user-home-wobuild-properties.xml creates the
values in the wobuild.properties on all platforms where
// the NEXT_ROOT is set and MacOSX and corrects the path separator on
windows
<target name="check">
<ant antfile="build-user-home-wobuild-properties.xml" target="check"/>
</target>
</project>
Ulrich
On Montag, 28. Juli 2003, at 18:32 Uhr, Jerry Porter wrote:
> Hello,
>
> I agree with Kaj.
>
> How about making it so that the existence of the wobuild.properties
> files is checked for, and if not found, then assume the properties are
> already loaded.
>
> We use the project Wonder build functionality and we use a
> build.properties file in our home directory. It would be nice if we
> didn't need yet another properties file to manage.
>
> It would also be nice if the properties that are needed by the
> woproject build functionality were documented somewhere. Then we
> developers could decide which file to place these properties.
>
>
> On Monday, July 28, 2003, at 10:20 AM, Kaj Hejer wrote:
>
>> At 18:12 +0200 28-07-2003, Ulrich Köster wrote:
>>> Hi Kaj,
>>>
>>> the advantages of the wobuild.properties.
>>> - easy replacement for support of different wo versions
>>> - faster then the lockup trough the environment
>>>
>>> From the docs:
>>>
>>> WOApplication behavior depends on various properties in the
>>> wobuild.properties file that specify common
>>> locations of the frameworks used by the application.
>>> These properties can be initialized with the
>>> build-user-home-wobuild-properties.xml. Per
>>> default the woapplication task expects this file in
>>> $user.home/Library/wobuild.properties. If no
>>> file is found the woapplication task resolves the property
>>> WOBUILD_PROPERTIES from the java properties
>>> and
>>> the environment(in this order) to find the file.
>>>
>>>
>>> I think it's not to much work to set it up. Anyway it makes the
>>> cowork
>>> of woproject wolips much easier.
>>
>>
>> I understand and I agree that wobuild.properties in most cases is a
>> good idea.
>>
>> My point is that if we for some reason :) don't want to use
>> wobuild.properties it should be possible to not get the
>> WOBuildPropertiesNotFoundException.
>>
>>
>> -Kaj :)
>>
> Jerry E. Porter
> Software Engineer
> Wireless Matrix Corporation
> 102, 1530 - 27th Ave. NE
> Calgary, Alberta, Canada
> T2E 7S6
> Main: 1-403-250-3949
> Fax: 1-403-250-8163
> jerry.porte..rx-ca.com
> http://www.wirelessmatrixcorp.com
>
>
This archive was generated by hypermail 2.0.0 : Mon Jul 28 2003 - 13:41:33 EDT