oh -- i totally misunderstood ... your complaint is not that you can't build, it's that you can't run the app in deployment. from what you're explaining, this actually is behaving as i would expect. the classpath file is written in a somewhat abstract form and the wo launcher script provides the values you need to resolve those variables. the variables themselves are technically resolved by WOBootstrap (though i have a variant launcher script that resolves them in the script itself, as well -- it doesn't much matter).
so basically, the settings in your wolips.properties should NOT impact deployment except insofar as the jars that were found in the frameworks identifier during build time based on those properties must exist in the deployment frameworks specified by your NEXT_ROOT.
so if you want to customize this per-app, i would recommend probably setting NEXT_ROOT inside your app launch script ... it might be possible to set it from monitor, but I've never done this.
in summary, embed your frameworks ;)
ms
On Feb 16, 2010, at 10:30 AM, Patrick Robinson wrote:
>> The relationship between wolips.properties in Eclipse and Ant is weird an tenuous. I would probably specify -Dwolips.properties=/absolute/path when you build -- i think that works? i'm a little surprised the absolute wolips.properties path in build.properties doesn't work (though that's really hokey anyway).
>
> As far as I can tell, specifying -Dwolips.properties does the *exact* same thing as putting wolips.properties=absolute-path in build.properties: It just preemptively sets the wolips.properties property before ant gets to this directive in build.xml that sets it:
>
> <property name="wolips.properties" value="${user.home}${file.separator}Library${file.separator}Application Support${file.separator}WOLips${file.separator}wolips.properties" />
>
> But regardless of where it finds the wolips.properties file, here's what it does with it:
> - It uses wo.apps.root to decide where to put an install
> - It fails with a messasge if wo.system.frameworks or wo.local.frameworks are not set
> - It does some stuff I don't care about, if target is ssdd
> - It includes jars in wo.extensions in the classpath, during the compile task
>
> The wocompile task must use the values of (for example) wo.local.frameworks and wo.system.frameworks to find things, in order to compile, but it doesn't affect the build product at all. And at this point, I'm not even sure it should! What's getting put into (for example) dist/Project.woa/Contents/MacOS/MacOSClassPath.txt are lines that begin with either APPROOT, WOROOT, or LOCALROOT, etc. I haven't yet figured out where APPROOT is set, but WOROOT and LOCALROOT are relative to NEXT_ROOT, which, if it's not set, is essentially "/". So it kinda seems like part of the task of deploying one of these bundles should be to set NEXT_ROOT, if it's something other than /. Right?
>
>> And while I find it to be kind of crazy, I should point out that the Maven folks would say that Maven takes care of all of this for you. You would just specify the WO frameworks dependency in your app pom and it would just pick the right jars to build with. Pick your poison -- both build systems suck in different ways.
>
> I can deal with sucky systems -- but only as long as I know what they're doing. :-)
>
> - Patrick
>
This archive was generated by hypermail 2.0.0 : Tue Feb 16 2010 - 11:26:35 EST