Re: WO Framework build ant woes
Re: WO Framework build ant woes
- Subject: Re: WO Framework build ant woes
- From: Chuck Hill <email@hidden>
- Date: Thu, 10 Jul 2008 13:25:06 -0700
On Jul 10, 2008, at 12:00 PM, Florijan Stamenkovic wrote:
2. If the above is true, what exactly is the purpose of the
"compile" target, what does WOCompile do differently?
It should do the same thing, but from the command line.
Yeah, that chimes with my own conclusions about it, all the fuss
inside seems to be primarily classpath oriented. Any idea then why
is it there? Why not simply rely on Eclipse's compiling?
For deployment, I do a deep clean and build totally from the command
line. It also allows you to check out and build on the server
(deployment, test, continuous integration, whatever) without needing
GUI access to Eclipse.
3. The "compile" target in the framework failed because I didn't
have the Frameworks folder in my users's Library. After creating
the Frameworks folder, which I guessed to be the quickest
solution, the <wocompile srcdir="Sources" destdir="bin"> task
failed with a NullPointerException. Any suggestions?
I use this:
<!-- Distribution WOProject compilation -->
<target name="compile" depends="setProps">
<wocompile destdir="bin"
debug="${wocompile.debug.flag}"
optimize="${wocompile.optimize.flag}"
deprecation="on">
<src refid="${project.source.path}"/>
<classpath refid="project.classpath"/>
</wocompile>
</target>
I like this, it is short :)
Short is good. I have tried to apply the DRY principal to my Ant files.
Plus some steps to set up <src refid="${project.source.path}"/>
project.source.path is an entry in build.props? You do something
special, or just point to Sources?
Our build is, uh, kind of funky as we use a Design by Contract tools
that instruments / generates Java. So...
<!-- Source classpaths for contracted and uncontracted builds for
this project.
This is done here, outside of a task, as a sort of hack to get
the project.source.path property set correctly. Things
declared outside of a
task are evaluated before any task is
performed. -->
<path id="uncontracted.class.path">
<dirset dir=".">
<include name="src"/>
<include name="Tests"/>
<include name="GeneratedEOs"/>
</dirset>
</path>
<path id="contracted.class.path">
<dirset dir=".">
<include name="ContractedSource"/>
<include name="Tests"/>
<include name="GeneratedEOs"/>
</dirset>
</path>
<!-- Selects uncontracted.class.path as project.source.path if
use.dbc is not defined. -->
<target name="choose.uncontracted.path" unless="use.dbc">
<!-- This will already have been set to contracted.class.path
if the use.dbc task is run -->
<property name="project.source.path"
value="uncontracted.class.path"/>
</target>
<!-- Selects contracted.class.path as project.source.path if
use.dbc is defined. -->
<target name="choose.contracted.path" if="use.dbc">
<property name="project.source.path"
value="contracted.class.path"/>
</target>
and <classpath refid="project.classpath"/>
May I ask what does project.classpath resolve to? Does it tap into
Eclipse's project cp stuff, or?
<!-- Non-source Classpath for project-->
<wopath id="project.classpath">
<frameworks dir="${user.frameworks.path}"
bundles="${client.frameworks}/${gvc.frameworks}/$
{wonder.frameworks}" />
<frameworks dir="${local.frameworks.path}"
bundles="${library.frameworks}" />
<frameworks dir="${system.frameworks.path}"
bundles="${system.frameworks}" />
<path refid="webobjects.extensions"/>
</wopath>
And ${client.frameworks}/${gvc.frameworks}/${wonder.frameworks} are
defined as:
<property name="client.frameworks" value="ClientPrototypes/
Cadrelient/Cadrelient/ClientSecurity/MicrosoftPlugIn" />
<property name="gvc.frameworks" value="GVCEOFExtensions/
GVCEOFValidation/GVCFoundation/GVCMail/GVCThreadedTasks/
GVCWOExtensions/QualifierAdditions" />
<property name="wonder.frameworks" value="Ajax/ERChronic/
ERExtensions/FrontBasePlugIn/JavaWOExtensions/WOOgnl/WOLips" />
<property name="library.frameworks" value="Dummy" />
<property name="system.frameworks" value="JavaFoundation/
JavaEOAccess/JavaEOControl/JavaJDBCAdaptor/JavaWebObjects/JavaXML" />
These have to be maintained manually when the classpath is updated in
Eclipse. This is just a temporary measure until Mike's Classpath
Magic is ready. BUT it is WAAAAY better than the woproject/ madness.
Thanks go to Anjo for this.
4. Can I modify the "compileAndBuild" so that it works like the
"build" (ditch "compile"), in short, why should I use
"compileAndBuild" when using the ant from another project ant
(embedding the framework)? I guess that is kind of the same as the
question nr. 2.
Embedding does not use the Ant form another project (AFAIK).
Adding the following to the init.build seemed to make sense, just to
ensure the latest build of the to-be-embedded framework:
<ant dir="../Framework" antfile="build.xml" target="build"></ant>
The wiki example does something similar, in the second part, which
explains how to embed a framework that is a project, and not an
already made thing.
I am too lazy to read that right now. :-)
<!-- Framework inclusion -->
<frameworks root="../Framework/dist" embed="true">
<include name="*.framework"/>
</frameworks>
A comment on this, something rather bizarre happened as a
consequence. I ended up having 2 frameworks in my app's Contents.
One was the <FrameworkName>.framework (which I wanted there), and
another one was <AppName>.framework, which I have no idea how it
even came to exist... Super strange. A workaround was to use this
instead (the third line differs):
<!-- Framework inclusion -->
<frameworks root="../Framework/dist" embed="true">
<include name="Framework.framework" />
</frameworks>
Not sure why that happened.
I don't handle it there as I am usually building multiple
application for packaging and deployment.
So, what do you do? Have an ant build external to all projects that
aggregates the work? I'm trying to find a nice, clean, maintainable
way to handle this, so that I hopefully never have to look at it
again...
I find that there is some difference for each client, so I usually
have one master build file that handles clean, build, package, test,
functional tests, etc. I think that most of this can be extracted out
to a common, reusable set of tasks. I just have not done that yet.
I'd wait until Mike finishes his classpath changes before doing any
work on this. Things may change greatly.
Fair enough.
Chuck
--
Practical 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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden