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.
> 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.
> 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.
> 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
> 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
-- Chuck Hill Senior Consultant / VP DevelopmentPractical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
This archive was generated by hypermail 2.0.0 : Tue Feb 16 2010 - 14:15:52 EST