On Feb 16, 2010, at 2:15 PM, Chuck Hill wrote:
> On Feb 16, 2010, at 6:30 AM, Patrick Robinson wrote:
>
>> There's a wiki page,
>> http://wiki.objectstyle.org/confluence/display/WOL/Using+WOLips
>> +With+Multiple+Versions+of+WebObjects
>> that has some "optional" instructions at the bottom for building
>> with ant, and I'm having trouble understanding just what these do
>> (and don't do) for you. If someone could just confirm or correct
>> my ideas here, I'll be happy to update wiki the wiki page(s).
>>
>> "OPTIONAL - Setup Eclipse's Ant Builder to use the newly Installed
>> Version of WebObjects"
>> The suggestion here is to add a "wolips.properties=..." to your
>> build.properties. According to Mike's Mar 2009 post at
>> wolips.blogspot.com, this can be an absolute or relative path,
>> just like Eclipse Preferences => WOLips => Build => WOLips
>> Properties File. Although the wiki page doesn't make this clear,
>> it looks to me like this is the "project-specific" way to specify
>> a different wolips.properties file, whereas Preferences -> WOLips
>> Properties File is the "workspace-specific" way. Is that correct?
>
> Yes, give or take it actually working. So far I can't find a
> project relative way to select the wolips.properties that works in
> both Eclipse and in command line builds. I think that _I_ want is
> a _project_ relative path (e.g. project/../WOLips/
> wolips.properties) so that I can have several Eclipse projects
> share the same file in a workspace that has other projects using a
> different setup. This is trivial in Ant, but probably not possible
> with today's WOLips. Absolute paths work, but have their own
> issues (different paths on different machines).
>
>> And am I also correct that BOTH of these approaches are useful
>> *only* in directing Eclipse's internal build/run systems where to
>> find wolips.properties, but have little to do with building with
>> ant for deployment (that is, neither [right-click build.xml, Run
>> As -> Ant Build], nor [WOLips Ant Tools -> Install], nor [ant
>> command line build] )?
>
> They are also used from Ant.
Hang on.... I think that ONLY the "wolips.properties setting in
build.properties" approach works from Ant. I can't get the WOLips
preference setting to have any influence on what Ant does, even if I
specify an absolute path. As a matter of fact, I can set the WOLips
preference to point to a "bad" wolips.bad.properties, not specify a
wolips.properties property at all in build.properties, and have a
"good" wolips.properties just sitting there in its default location
-- with the result that internal builds completely fail, but Ant
builds work just fine (since build.xml assumes it should use the
default wolips.properties at the default location).
And since that's the case, I don't see that the Eclipse "WOLips
Properties File" is of any real use, at least currently. I'd _much_
rather just set a property in my build.properties, and have things
work in all cases (see below).
>> The handling of this in the stock build.xml looks like this:
>> <property file="build.properties" />
>> <property name="wolips.properties" value="${user.home}$
>> {file.separator}Library${file.separator}Application Support$
>> {file.separator}WOLips${file.separator}wolips.properties" />
>> <property file="${wolips.properties}" />
>>
>> So you *could* override the "wolips.properties=" property in your
>> build.properties; however, a relative filename is *not* going to
>> be found,
>
> For that particular bit of Antishness, it is going to be relative
> to the project not to the intended ...Application Support/WOLips.
> I will hazard a guess that this is simply a bug no one had run into
> before. If you want that, it should be something more like this:
>
> <property file="build.properties" />
> <property name="wolips.properties" value="wolips.properties" />
> <property file="${user.home}${file.separator}Library$
> {file.separator}Application Support${file.separator}WOLips$
> {file.separator}${wolips.properties}" />
>
> FWIW, I have my own build scripts that I use for all of my apps.
> It is probably less Eclipse friendly, but seems more manageable
> from the command line.
I think your little switcheroo there is *exactly* what the stock
build.xml ought to look like, because now, you can just add (for
example):
wolips.properties=wolips.533.properties
to your build.properties, and it works for both the internal builder
and for Ant. Eclipse will treat it as being relative to ~/Library/
Application Support/WOLips/, and so does the Ant script.
>> the values in wolips.properties will not be read, and the project
>> will not build. And even if you were to specify the absolute path
>> to wolips.properties (/Users/me/Library/Application Support/WOLips/
>> wolips.something.properties) in your build.properties, OK ... the
>> project will build, but the values specified in wolips.properties
>> have no effect on what gets done in the ant build. It looks to me
>> like the values from wolips.properties are used only in a build
>> for a servlet deployment. Is that correct?
>
> No, but it appears from later messages that you mean "the values
> specified in wolips.properties have no effect on what happens at
> runtime", which is a correct statement.
Yeah, I was initially confused on that point.
>> On the other hand, it looks like you could set NEXT_ROOT to point
>> to the "base dir" where you've installed WebObjects (on your
>> deployment system), and all might go well. As far as I can tell,
>> this appears to be the only way to handle the situation where your
>> frameworks are in different locations on the development and
>> deployment systems. Right? (Of course, other than by embedding...)
>
> I think so, but I embed my frameworks like a real developer. :-P
I am soundly persuaded.
>> Is this how all of this is intended to work? Yeah, I know I
>> should be embedding my frameworks :-) --- we're gonna do that.
>> But in the meantime, I'd like to get a handle on how this is
>> designed to work.
>
>
> Like Mike said, "barely".
>
> Chuck
- Patrick
This archive was generated by hypermail 2.0.0 : Thu Feb 18 2010 - 10:07:42 EST