Bill Arnette wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Edmund Schweppe
Sent: Wednesday, September 14, 2005 1:54 PM
Arnette, Bill wrote:
When writing a build file that does everything from checking out the
source to creating the installation package, it would be nice if you
could run a target from the command line without running the
dependencies. Is this possible now?
If you really need this ability - which implies that your target really
*doesn't* have dependencies - it's easy enough to do, using the <call> task:
<Bill>
No. The targets do/will have dependencies, I just don't want to run them
all the time while debugging and developing an automated build. I'd rather
not have to create separate targets just for development/debugging purposes.
</Bill>
Let me rephrase Edmund's point. If it ever makes sense to invoke a
target without invoking its dependencies, then they're soft
dependencies, not hard dependencies. By this, I mean that the purpose
of the dependency is to only make sure that the results correctly
represent the latest state, and not to ensure that the prerequisites for
even running this target have been satisfied. So, for example, you
might have a test target which will fail horribly if the tests haven't
even been built, but which can run to completion if they have been
built, even if they don't represent the latest version of the source code.
There are several different ways to implement this, depending upon the
precise situation. For example, you might put a condition on all of the
targets that specifically do checkouts from the repository, e.g.:
<target name="checkout-some-component"
unless="${property::exists('skip-checkouts')}" > ...
This works if there are a number of targets with a common theme such as
this, so that you're not forced to create a huge number of properties to
specify at the command line.
The way I prefer to do it (and I'm guessing that Edmund might do it this
way, as well), is to separate the hard and soft dependencies into
different targets, at two separate levels of abstraction. So, for
example, you might have a target run-tests that just runs the tests with
whatever is there, and a target test that cleans, builds, and runs the
tests. The latter becomes a dependency-only target, e.g.
<target name="test" depends="clean-tests, build-tests, run-tests" />
This is also nice because it's a separation of concerns - the issue of
how to run a test is separated from the issue of what needs to happen
before running a test. It satisfies the single-responsibility goal,
since a target is either responsible for the dependencies or for the
execution steps, but not both.
>not have to create separate targets just for development/debugging
purposes.
This is a false aesthetic. It's like building a computer system for an
automobile with no connector for diagnostics, since you don't need that
to drive the car. Development is what creates the end product. If you
do something that improves development, you've done something that
improves the end product.
Gary
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Nant-users mailing list
Nant-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
