Thanks, Mike... these are the conclusions I was slowly coming to.
Especially the summary. :-)
- Patrick
On Feb 16, 2010, at 11:25 AM, Mike Schrag wrote:
> 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 - 14:00:11 EST